Agent Runtime 是什么：从一次调用到一个持续执行的任务

用户提交：“订单 A1042 有质量问题，帮我申请退款。”服务器调用模型，模型识别出订单和意图，接口返回了结果。可是商家还需要核验图片，主管可能明天才批准，支付系统也可能暂时没有响应。这项工作显然不能依赖最初那条 HTTP 连接一直保持。

Runtime 解决的是任务怎样跨越这些边界继续运行。它记录执行到哪里，安排什么时候由哪个执行者继续，处理等待、重复输入、崩溃和取消。模型理解得再准确，也不会自动替应用保存这些状态。

请求结束之后，任务还存在吗

同步接口通常把请求、执行和响应放在同一个生命周期：调用一个函数，得到一个结果。长任务则需要先建立持久身份，返回 task ID，随后通过查询或事件展示进度。

创建任务的响应可以是“已接收，任务 T17 等待资料”，不能因为接口返回 200 就说退款完成。接收请求、完成计算、业务系统受理与资金最终到账是不同事实。哪一个算业务完成，需要在任务契约中定义。

若用户刷新页面再次提交同一申请，系统还要识别这是重复请求还是新的部分退款。网络请求 ID 通常不承担这个职责，业务应使用明确的申请标识和去重规则。后面会专门解释它与 operation ID 的区别。

不是所有任务都需要模型自主规划。退款中“缺资料就补充、超范围就拒绝、批准后才执行”是可事先写清的控制逻辑。模型可以从自然语言提取意图、整理证据，但不能自行删除业务要求。

ReAct 强调推理与环境动作交替，但不要求系统暴露模型的私有思维过程。可观察内容应是动作、工具结果和必要的决策说明。模型没有工具调用时也未必代表任务成功：它可能缺资料、预算耗尽，或者错误地提前停止。

“生成后反思”同样是一个可以选择的步骤，不是免费提升质量。字段格式错误先用结构校验，证据不足先补资料，只有确实需要语义评审时才使用额外模型，并记录它究竟修复了什么。

本系列采用虚构教学事件：订单 A1042 在版本 12 时已签收十天，质量问题尚未核验。之后商家收到新证据，版本 13 标记核验通过。用户申请退回 29900 分人民币，教学政策要求对此申请取得明确批准。

模型可以生成一个候选申请，但服务端仍要读取订单、检查归属、剩余可退金额和政策。批准后，执行器向模拟支付系统提交，再核对结果。整个过程可以包含 Agent，但资金动作不依赖模型自行解释“差不多批准了”。

这里特意区分版本 12 和 13，避免把前面 Harness 系列的“尚未核验”悄悄改写成“已经确认”。任务读到哪个版本、为何可以继续，都应该有记录。

Harness 组织模型可用的规则、工具和环境，并验证候选产物。Runtime 安排这段工作何时执行，保存进度、接受外部输入，并在执行者更换后继续。框架则提供图、中间件或工作流等编程抽象。

这些是职责划分，不是统一产品分层。LangGraph、Temporal 或 AgentScope 可能各自覆盖其中一部分；某个 SDK 提供 Checkpointer，也不意味着它已经配置好你的队列、业务账本和多租户认证。

可以把 Runtime 与 Harness 的接口设计为一次有界推进：输入任务状态和预算，返回新的状态、等待原因或产物引用。长期等待先持久保存，再释放执行资源。下一次收到有效事件后，由 Runtime 再安排推进。

持久任务与外部动作的关系

参数错误需要用户修正，权限拒绝需要停止相关动作，临时网络故障可能重试，远端执行结果未知则需要查询。把它们都写成 failed=true，恢复器就无法决定下一步。

例如支付服务已经接受退款，却没来得及返回响应。调用方知道的是“没有拿到结果”，不是“退款没有发生”。立即创建一笔新操作重试，可能产生重复退款；根据稳定操作标识查询回执，才有机会判断真实状态。

同样，用户取消请求也不等于撤回已经完成的退款。Runtime 需要区分取消意图、实际停止和已经发生的业务结果，而不是把 task 状态改成 cancelled 就丢掉所有操作记录。

后续示例先用 SQLite 保存任务与事件，再用独立数据库模拟支付服务。这样读者能看到本地事务不能覆盖远端动作。接着用 LangGraph 展示真正跨进程的暂停恢复，再阅读 Temporal、AgentScope Java 和 DBOS 的固定源码。

模拟支付不连接真实资金系统。示例环境、可选依赖和运行步骤集中在实践指南下载。

下一篇先给任务、运行尝试和业务动作分别建立状态与身份。没有这些区分，后面的重试和恢复很容易对错对象。