一次 Agent Run 如何可靠推进

一个 Agent 能连续调用工具，不等于它能可靠完成任务。真正困难的是：中断后知道从哪里继续、失败后不重复副作用、外部状态变化后重新校准，并用证据判断任务是否完成。

一条 Agent Run 的学习主线

1接收目标

→

2形成动作提案

→

3校验并执行

→

4观察外部事实

→

5验收结果

读图结论：模型负责开放判断，运行时负责把状态、副作用和验收变成可控过程。

为什么聊天历史不是运行状态

聊天历史适合保存交流语境，却不能可靠表达任务处于哪个合法阶段。例如模型说“已经发布”，只是一段生成文本；发布平台返回的部署 ID、访问地址和验证结果，才是可用于推进状态的外部事实。

运行时至少需要区分三类信息：

• 对话信息： 用户目标、补充说明和解释性内容。
• 运行状态： 当前步骤、已确认约束、待执行动作和恢复位置。
• 业务事实： 数据库记录、部署状态、支付结果等权威系统数据。

把三者混成消息数组，会导致恢复时无法判断哪些内容只是模型推测，哪些动作已经真实发生。

最小状态机

type RunState =
  | { status: 'planning'; goal: string }
  | { status: 'waiting_approval'; action: ProposedAction }
  | { status: 'executing'; operationId: string }
  | { status: 'verifying'; operationId: string }
  | { status: 'succeeded'; evidence: Evidence[] }
  | { status: 'failed'; reason: Failure; recoverable: boolean }

状态机的价值不是让流程变得僵硬，而是阻止非法跃迁。例如尚未获得发布确认时，不能从 planning 直接进入 executing；调用超时后也不能直接写成 failed，因为外部动作可能已经成功。

超时后的未知结果

假设 Agent 调用发布接口，服务端完成发布，但响应在网络中丢失。客户端看到超时，如果立即重试，可能重复发布；如果直接终止，又会把成功任务报告为失败。

正确处理顺序是：

1. 为动作分配稳定的业务幂等键或操作 ID。
2. 请求超时后进入“结果未知”，而不是直接判定失败。
3. 查询权威系统中的操作状态。
4. 已成功则继续验证；明确未执行才考虑重试。
5. 查询仍无结果时，进入人工恢复或安全降级。

如何证明任务完成

完成条件必须落到可观察证据，而不是模型自述。

目标	不充分的判断	可验证证据
页面已发布	模型说“发布成功”	部署 ID、HTTP 状态、页面标题检查
Tool 已执行	生成了 Tool Call	权威系统记录和结果 Schema 校验
中断已恢复	流程继续输出文本	从 Checkpoint 恢复且副作用未重复

实践任务

实现一个最小“发布页面”状态机，并注入一次响应丢失：外部服务真实写入成功，但客户端收到超时。验收时需要展示状态迁移日志、操作 ID、恢复查询和最终验证结果。

记忆卡

一句话模型： Agent Runtime 接受模型提出的动作，但必须用合法状态迁移和外部事实校准执行结果。

后续面试题将从状态恢复、幂等和未知结果三个角度检验是否真正掌握这一机制。