Wiki Notes

Appearance

Agent计划回放专题 ​

版本：v1.1

最后更新：2026-07-07

适用对象：需要为 Agent planner、工作流编排器、多 Agent 协作链路、长任务恢复和人工接管场景设计回放、复盘与评测闭环的产品、平台、工程与算法同学

很多 Agent 系统看结果时只看到：

  • 成了
  • 没成

但对复杂任务来说，真正决定成败的常常不是最终输出本身，而是中间那条计划链路：

  • 它最开始是怎么拆任务的
  • 何时修改过计划
  • 哪一步开始偏航
  • 哪些工具调用或审批事件改变了原本路径
  • 为什么系统最后转人工、补偿或放弃

这也是为什么成熟的 Agent 系统几乎都会建设计划回放能力。

OpenAI 的 Integrations and observability、Trace grading、Evaluate agent workflows 文档，以及 LangGraph 的 persistence / time-travel / durable execution 思路，都在强调同一个事实：

  • 复杂 Agent 链路不能只看结果，必须能回看计划是如何形成、如何变化、如何和执行交织在一起的

一句话理解：

  • 计划回放不是重放一段日志，而是重建“计划如何驱动执行、执行又如何反过来改写计划”的过程

1. 什么是计划回放 ​

更实用的理解通常是：

  • 把 Agent 在任务过程中的计划、修订、执行状态、关键证据、工具影响和人工介入还原出来

重点不是展示一个：

  • 最终计划文本

而是重建：

  • 初始计划如何形成
  • 计划如何被执行
  • 计划在哪些节点被修改
  • 为什么修改
  • 修改后对后续执行产生了什么影响

所以计划回放的本质是：

  • 对规划链和执行链做联合回放

2. 为什么计划回放对 Agent 特别重要 ​

复杂 Agent 失败时，真正的问题常常不在“最后一句输出”，而在更早的位置：

  • 初始任务分解就错了
  • 计划改了，但执行器没同步
  • 工具结果变了，但 planner 没 replan
  • 审批边界出现后，系统仍按旧计划继续推进
  • 已经进入半完成状态，但人工不知道从哪接手

如果没有回放能力，这些问题通常只能靠猜：

  • 到底是 planner 差
  • 还是 executor 差
  • 还是工具链差
  • 还是状态同步出了问题

计划回放的价值就在于：

  • 把“凭感觉复盘”变成“基于结构化轨迹复盘”

3. 计划回放解决的不是日志展示，而是因果重建 ​

普通日志通常只能回答：

  • 某个工具调过了
  • 某个节点报错了
  • 某个函数超时了

但计划回放真正需要回答的是：

  • 当时系统为什么选择这一步
  • 这一步基于哪个计划版本
  • 后续偏差是从哪一版计划开始出现的
  • 当时有哪些备选路线被放弃
  • 某次人工审批或结果校验是如何改变路径的

也就是说：

  • 日志是碎片化事件
  • 计划回放是结构化因果链

4. 哪些信息最值得纳入回放 ​

更有价值的通常包括：

  • 原始任务目标
  • 初始任务分解
  • 计划版本记录
  • 每一步执行结果
  • 工具调用和工具结果
  • 结果校验、权限校验和审批影响
  • replan 原因
  • 失败、跳过、人工接管和补偿节点

这些信息连起来，才能真正看到：

  • 计划如何形成
  • 计划如何变化
  • 计划如何偏航

5. 一个更实用的回放对象模型 ​

不要把计划回放理解成“把所有消息按时间排一遍”。

更成熟的做法通常是把回放对象拆开：

json
{
  "task_id": "task_001",
  "goal": "完成退款审批并同步 CRM",
  "plan_versions": [
    {
      "plan_id": "plan_v1",
      "created_at": "2026-07-07T10:00:00Z",
      "steps": ["load_order", "check_policy", "update_crm"]
    },
    {
      "plan_id": "plan_v2",
      "created_at": "2026-07-07T10:00:06Z",
      "reason": "approval_required_discovered",
      "steps": ["load_order", "check_policy", "request_approval", "update_crm"]
    }
  ],
  "execution_events": [],
  "human_actions": [],
  "outcome": {}
}

这个模型至少提供三种能力：

  • 看初始计划长什么样
  • 看计划中途怎么变了
  • 看执行事件和计划版本如何对应

没有计划版本模型，回放很容易退化成“最终 plan + 一堆日志”。

6. 一个更实用的回放视角 ​

可以按四层来重建，而不是只按时间线列事件。

6.1 目标层 ​

  • 任务目标是什么
  • 成功条件是什么
  • 关键约束是什么

6.2 规划层 ​

  • Agent 打算怎么做
  • 初始计划是什么
  • 后续为何 replan

6.3 执行层 ​

  • 实际做了什么
  • 调了哪些工具
  • 哪些步骤成功或失败

6.4 偏差层 ​

  • 计划与执行差在哪
  • 偏差从哪一步开始出现
  • 偏差是策略性调整还是失控

这种结构能更快回答：

  • 问题是出在计划、执行，还是计划执行不同步

7. 计划版本化是回放的基础能力 ​

一个常见误区是：

  • 只保留当前最终计划

这会直接丢掉最有价值的部分：

  • 计划是如何演化的

建议至少记录：

  • plan_version
  • created_at
  • parent_plan_version
  • replan_reason
  • changed_steps
  • removed_steps
  • new_constraints

例如：

json
{
  "plan_version": 2,
  "parent_plan_version": 1,
  "replan_reason": "tool_result_requires_approval",
  "added_steps": ["request_approval"],
  "removed_steps": ["direct_status_update"]
}

有了这种变化记录，团队才能清楚看出：

  • 是 planner 发现了新事实而合理调整
  • 还是系统无意义摇摆

8. 为什么“计划步骤”必须能映射到执行事件 ​

很多回放系统最大的缺陷在于：

  • 能看到计划
  • 能看到工具事件
  • 但看不出哪个事件对应计划中的哪一步

更稳妥的做法通常是给每个计划步骤分配稳定的 step_id，并在执行事件里显式带上。

json
{
  "step_id": "s3",
  "plan_version": 2,
  "event_type": "tool.execution.succeeded",
  "tool_name": "request_approval",
  "trace_id": "tr_001"
}

这样我们才能回答：

  • 哪个步骤执行了
  • 哪个步骤被跳过了
  • 哪个步骤失败后触发了 replan

没有这层映射，计划回放几乎一定会变成“像回放，但不是完整回放”。

9. 回放不是只看成功链，也必须看失败与中断链 ​

很多系统一开始做回放，只展示成功流程，因为：

  • 成功流程更整齐
  • 演示更好看

但真正最有价值的样例，往往是：

  • 失败中断
  • 人工接管
  • 审批卡住
  • 补偿触发
  • 重试后仍失败

原因很简单：

  • 系统问题最密集地暴露在这些坏样例里

所以更成熟的回放系统必须能看见：

  • 中断点
  • 跳过点
  • 分支切换点
  • 人工接管点
  • 补偿点

10. 为什么计划回放和工具观测事件模型强绑定 ​

工具观测事件模型专题 解决的是：

  • 系统事件如何被统一建模

而计划回放要做的，其实就是把这些事件重新组织成：

  • 一条可解释的规划与执行链

最有价值的事件通常包括：

  • tool.request.created
  • tool.policy.denied
  • tool.execution.started
  • tool.validation.failed
  • human.approval.requested
  • tool.compensation.started
  • human.handoff.started

这些事件只有和 plan_version、step_id、task_id 挂上关系，才会成为真正可用的回放材料。

11. 为什么计划回放和任务分解评测是同一闭环的前后两端 ​

Agent任务分解评测专题 关注的是：

  • 分解本身好不好

计划回放关注的是：

  • 这份分解在真实执行里表现如何

二者关系非常紧密：

  • 好的分解，是否真的提升成功率
  • 哪类分解最容易在执行时偏航
  • 哪类步骤最容易触发 replan

所以更成熟的做法通常是：

  • 用评测找出薄弱分解模式
  • 用回放理解这些模式为什么会失败

回放是评测结果的解释层，评测是回放样例的量化层。

12. 为什么回放要和人工纠偏工作台连起来 ​

人工纠偏工作台专题 最需要的并不是一堆原始日志，而是：

  • 当前任务做到了哪
  • 原计划是什么
  • 现在偏到了哪
  • 哪一步最适合人工接手
  • 已有哪些动作不可逆

一个好的计划回放，应该帮助人工快速回答：

  • Agent 已经做了哪些事
  • 哪些步骤完成了
  • 哪些步骤失败了
  • 当前最合理的接管点在哪里

否则人工接管就只能从头重新理解整条链路，成本会非常高。

13. 为什么回放对长任务恢复特别重要 ​

长任务恢复策略专题 的一个核心问题是：

  • 任务中断后怎么恢复

如果没有计划回放，恢复时常常只能看到：

  • 当前状态值

却看不到：

  • 这个状态是怎么来的
  • 哪些步骤已经试过
  • 哪些分支已经被证明无效

所以更稳妥的恢复通常需要两层：

  • 当前状态快照
  • 最近一段关键计划回放

也就是说，计划回放不仅服务复盘，也直接服务恢复。

14. 一个更实用的详情页结构 ​

计划回放详情页不建议只做事件列表。

更适合的结构通常是：

14.1 概览区 ​

  • 任务目标
  • 当前状态
  • 成功 / 失败 / 人工接管结果

14.2 计划版本区 ​

  • 初始计划
  • 计划修订时间线
  • 每次修订原因

14.3 执行映射区 ​

  • 每个计划步骤对应哪些事件
  • 哪些步骤完成、失败、跳过

14.4 偏差区 ​

  • 计划与执行不一致点
  • 偏差开始位置

14.5 人工与治理区 ​

  • 审批
  • 人工接管
  • 补偿
  • 风险拦截

这比简单的“trace 原样展示”更能帮助人理解。

15. 一个更实用的偏差分类方法 ​

计划与执行的偏差，不应一概当成错误。

更好的做法通常是分类：

15.1 合理偏差 ​

  • 工具结果暴露新事实
  • planner 合理 replan

15.2 风险驱动偏差 ​

  • 审批要求导致新增步骤
  • policy 拦截导致分支切换

15.3 失控偏差 ​

  • 重复计划摇摆
  • 没有新证据却反复 replan
  • 工具失败后仍重复走旧路径

15.4 同步失败偏差 ​

  • planner 改了计划，但 executor 仍按旧计划跑

把偏差分好类，回放结果才能真正用于治理，而不只是展示。

16. 为什么计划回放也需要压缩 ​

完整原始回放很重要，但并不是所有用户都需要看最底层细节。

更成熟的做法通常是同时提供：

16.1 原始视图 ​

  • 面向深度排障和审计

16.2 摘要视图 ​

  • 面向运营、产品、知识 owner 和人工接手

摘要视图通常可以保留：

  • 计划版本变化
  • 关键步骤状态
  • 关键证据和失败原因
  • 当前建议接管点

这和 推理轨迹压缩专题 是同一思路：

  • 在线执行和人工消费，都更需要有结构的摘要，而不是全量细节

17. 线上应该监控哪些回放指标 ​

17.1 覆盖指标 ​

指标用途
runs_with_plan_versions有多少运行保留了计划版本
steps_with_event_mapping多少步骤能映射到执行事件
failed_runs_replayable失败运行可完整回放比例

17.2 质量指标 ​

指标用途
replan_rate计划重写频率
drift_rate计划与执行偏差率
human_handoff_with_replay人工接手时是否有可用回放
planner_executor_desync_rate计划执行不同步比例

17.3 治理指标 ​

指标用途
replay_cases_promoted_to_eval回放样例进入评测比例
top_replan_reasons高频重规划原因
top_failure_points最高频偏航节点

这些指标能帮助判断：

  • 回放系统是真的在支撑治理
  • 还是只是多存了一份数据

18. 计划回放如何进入评测体系 ​

如果回放只是用来“看起来很酷”，价值会非常有限。

真正更有用的做法通常是：

  • 把失败回放沉淀成评测样例
  • 用回放分析高频偏航模式
  • 用回放验证新 planner 是否真的改进
  • 用回放对比不同策略、模型和工具组合

例如，可以把一次失败回放结构化成：

json
{
  "case_id": "replay_case_001",
  "failure_type": "planner_executor_desync",
  "first_drift_step": "s4",
  "replan_reason": "approval_required",
  "expected_behavior": "executor should wait for approval step"
}

这类样例非常适合进入：

  • planner 回归集
  • workflow 回归集
  • trace grading 规则

19. 常见反模式 ​

19.1 只保留最终结果，不保留计划过程 ​

后果：

  • 真正的规划问题很难被定位

19.2 计划修改没有版本记录 ​

后果：

  • 看不到计划是如何演化的

19.3 无法把计划步骤映射到执行事件 ​

后果：

  • 计划和执行像两张分离的图

19.4 回放只能看成功任务 ​

后果：

  • 最有价值的坏样例被丢掉

19.5 回放结果不进入评测和复盘 ​

后果：

  • 每次复盘都像第一次

19.6 回放视图堆满原始日志 ​

后果：

  • 人很难快速定位真正的因果链

20. 优化计划回放的常见手段 ​

20.1 给计划做显式版本化 ​

  • 不要只保留最终 plan

20.2 给每个步骤分配稳定 step_id ​

  • 让执行事件可映射

20.3 把人工和治理事件也纳入回放 ​

  • 不只是工具调用

20.4 区分原始视图和摘要视图 ​

  • 不同角色看不同密度的信息

20.5 用回放直接反哺评测和工作台 ​

  • 不让回放停留在展示层

20.6 把偏差分类做成结构化字段 ​

  • 便于统计和定位高频模式

21. 一个可执行的落地流程 ​

21.1 先定义计划对象和版本对象 ​

至少包含：

  • plan_version
  • step_id
  • depends_on
  • replan_reason

21.2 把执行事件接到步骤上 ​

确保：

  • 每个关键事件都能映射回步骤

21.3 把人工与治理节点纳入同一时间线 ​

包括：

  • 审批
  • 拒绝
  • 补偿
  • 转人工

21.4 做摘要回放层 ​

方便：

  • 运营
  • 产品
  • 知识 owner
  • 人工接手

21.5 把失败回放沉淀成评测资产 ​

不要只用于一次性排障。

21.6 用指标持续复盘 ​

看：

  • 偏航点
  • 重规划模式
  • 计划执行不同步问题

22. 推荐搭配阅读 ​

23. 落地检查清单 ​

  • 是否保留了初始计划和中途修订记录，而不是只保留最终计划？
  • 是否给计划版本、步骤和执行事件建立了稳定映射？
  • 是否能在回放里看出计划与执行的偏差从哪一步开始？
  • 是否把审批、补偿、人工接管等治理事件纳入回放时间线？
  • 是否区分原始回放视图和摘要回放视图，服务不同角色？
  • 是否把失败回放样例沉淀成评测与回归资产？
  • 是否能支持人工接管时快速理解当前上下文与最佳接手点？
  • 是否监控了 replan_rate、drift_rate、planner_executor_desync_rate 等关键指标？
  • 是否对回放对象和事件字段做了版本化与 schema 约束？
  • 是否定期复盘高频偏航模式并回流到 planner、workflow 或工具策略优化中？

24. 推荐资源 ​

以下资源在 2026-07-07 检查时可访问，适合作为 Agent 计划回放、trace 评分、持久化与可观测设计的官方参考。

OpenAI ​

LangGraph / LangSmith ​

25. 最后总结 ​

Agent 计划回放不是为了把过程“展示出来”，而是为了让团队真正看见：

  • 计划怎么形成
  • 计划怎么变
  • 计划和执行在哪里开始脱节
  • 人工该从哪里接手

如果没有这层能力，很多复杂 Agent 问题最后都会被误判成：

  • 模型不够强
  • 工具不够稳

但其实根因常常是：

  • 计划错了
  • 计划改了但执行没跟上
  • 偏航发生了却没人看得见

更成熟的做法，是把计划版本、执行事件、治理节点和人工接管点统一进一条可回放、可评测、可统计的链路里。

这样回放就不只是“复盘工具”，而会成为 planner、workflow 和人工协同持续优化的核心基础设施。