Agent 的恢复、回放、断点续跑和 Eval
提出问题
Agent 上线后，最棘手的问题往往不是第一次执行失败，而是失败后系统不知道发生了什么，也不知道能不能继续。
长任务可能已经查了资料、调用了工具、写了备注、创建了任务。此时如果简单重跑，可能重复执行副作用；如果直接标记失败，用户又要从头开始；如果没有日志，团队连问题是 plan drift、tool misuse、工具超时还是上下文错误都分不清。
恢复、回放、断点续跑和 Eval 的目标，是让 Agent 的执行过程成为可检查、可复现、可改进的工程对象。
场景
看一个研发代码修复 Agent。
用户在仓库里提出：
修复支付回调偶发重复入账的问题，补测试，并跑相关测试。
Agent 可能会执行这些步骤：
- 阅读支付回调代码和订单状态机。
- 搜索已有幂等实现。
- 修改回调处理逻辑。
- 增加重复回调测试。
- 运行测试并根据失败继续修改。
- 汇报变更和验证结果。
这个任务不适合简单一次 prompt，因为工具结果会改变后续计划。但如果没有恢复设计，失败会很难处理：
- Agent 修改了代码但测试命令超时，重启后不知道哪些文件是自己改的。
- 第一次测试失败后，Agent 反复改同一段逻辑，进入循环。
- 工具返回权限错误，Agent 把它解释成测试失败，继续无效修复。
- 中途崩溃后重新执行，从头搜索和修改，覆盖用户刚做的改动。
- 最终答案说“测试已通过”，但日志里实际只有部分测试运行成功。
Agent 可靠性不是只看“最终修好了没有”。还要看它是否安全地修改、正确地解释工具结果、在失败后能恢复，并且没有重复执行高风险动作。
分析问题
问题类型
恢复和 Eval 要覆盖 Agent 的过程，而不只是答案。
模型可以帮助理解失败原因和重拟计划，但不能单独决定“已经执行过什么”。系统必须保存可验证状态。
收益和成本判断
恢复体系的收益：
- 长任务失败后可以继续，而不是从头重来。
- 副作用动作不会因重试重复执行。
- 线上事故可以回放，定位是计划、工具、上下文还是模型问题。
- Eval 可以覆盖 Agent 的中间过程，避免只看最终答案。
- 团队能稳定迭代 prompt、工具和工作流，而不是靠主观感觉。
成本也不可忽略：
- 需要设计状态存储、checkpoint 和动作日志。
- 工具调用要有幂等 key、版本和结构化错误。
- 回放要记录模型、参数、上下文摘要和工具返回。
- Eval 样本需要人工标注和持续维护。
- 断点续跑需要处理“状态确定”和“状态不确定”的分界。
如果只是低风险、短任务、无副作用的草稿生成，失败后重新生成即可。只要 Agent 会修改文件、写入业务系统、发送通知、跑长时间任务或跨多轮工具调用，就应该设计恢复和 Eval。
列举方案
方案阶梯
恢复能力可以逐步建设。
第一层是基础日志。至少记录用户目标、最终输出、错误和耗时。
第二层是结构化步骤。计划不能只是一段文本，应有 step id、目标、状态、开始和结束时间。
第三层是工具动作日志。每次工具调用记录工具名、参数、权限上下文、返回、错误类型和是否有副作用。
第四层是 checkpoint。关键步骤后保存当前计划、已完成动作、产物位置、预算消耗和下一步候选。
第五层是幂等和补偿。写入、创建任务、发送消息、修改文件等动作要能避免重复，必要时能撤销或补偿。
第六层是断点续跑。恢复时先判断哪些步骤已完成、哪些动作已生效、哪些状态不确定，再决定继续、跳过、重试或转人工。
第七层是回放系统。用同一份输入、上下文快照、工具结果和模型版本复现执行过程，用于事故复盘和回归测试。
第八层是 Agent Eval。评估计划是否漂移、工具是否误用、是否循环、恢复是否安全、最终产物是否符合目标。
什么时候简单 Workflow 足够
以下情况不需要复杂 Agent 恢复：
- 任务步骤固定，失败节点明确。
- 每个节点都可以独立重试。
- 没有写入、外部通知或不可逆副作用。
- 任务耗时短，重新执行成本低。
- 输出只作为草稿，用户会复核。
- 系统不需要复现模型的中间决策。
例如固定的“上传文档 -> 抽取字段 -> 人工校对 -> 入库”流程，用 Workflow 的节点状态和重试机制即可，不需要开放 Agent 断点续跑。
什么时候需要 Agent 工程
以下情况应建设恢复和 Eval：
- Agent 执行时间长，可能跨请求、跨进程或跨设备。
- 工具结果会改变后续计划。
- Agent 会写文件、写库、创建任务、发送消息或触发审批。
- 失败后不能简单从头重跑。
- 需要区分模型错误、工具错误、权限错误和业务校验失败。
- 团队需要回放线上失败并做回归测试。
- Agent 质量不能只靠人工看最终输出判断。
研发代码修复、客户批量运营、数据分析报表、工单处理和自动排障，都属于需要恢复工程的典型场景。
恢复状态设计
一个可恢复 Agent 至少要保存四类信息。
恢复时不要默认“失败前的动作都没发生”。正确做法是先读取动作日志和外部系统状态，确认副作用是否已经生效，再选择续跑策略。
Eval 设计
Agent Eval 应该分层，不只评最终结果。
Eval 样本应覆盖正常样本、边界样本和故障样本。故障样本要故意模拟工具超时、权限失败、数据缺失、上下文冲突、部分写入成功和模型输出不合规。
决策判断
方案选型表
反模式
第一种反模式：只保存最终回答。
Agent 的风险发生在过程里。没有计划、工具和动作日志，就无法知道最终回答是否经过错误路径得到。
第二种反模式：把 checkpoint 当成聊天摘要。
摘要可以帮助模型理解，但恢复需要结构化状态：哪些步骤完成、哪些工具调用成功、哪些副作用已经发生。
第三种反模式：失败后自动从头重跑。
如果上一次已经创建任务、发送通知或修改文件，从头重跑可能扩大事故。重试前必须检查动作是否幂等。
第四种反模式：回放依赖实时工具。
事故复盘时，外部数据可能已经变化。回放应优先使用当时的工具返回快照，必要时再标注实时差异。
第五种反模式：Eval 只看 task success。
一个 Agent 可能最终完成任务，但过程越权、超预算或误用工具。生产 Eval 必须评估过程安全。
第六种反模式：没有故障注入样本。
只用正常样本评估，会让 Agent 在演示中表现很好，线上遇到超时、权限失败和部分成功时立刻失控。
工程清单
- 场景边界：任务是否长、是否有副作用、是否允许从头重跑。
- 状态模型：目标、计划、动作和产物是否结构化保存。
- Checkpoint：关键步骤后是否保存输入、输出、预算和下一步。
- 工具日志：工具参数、返回、错误类型、权限上下文是否记录。
- 幂等设计：写入、通知、文件修改和扣费是否有去重机制。
- 断点策略：恢复时如何判断继续、跳过、重试、补偿或转人工。
- 回放能力：是否能使用当时的上下文、工具结果和模型版本复现。
- Eval 样本：是否覆盖正常、边界和故障样本。
- Eval 维度：是否评估目标保持、工具选择、参数、循环、恢复和最终质量。
- 监控指标：step count、loop rate、duplicate action rate、recovery success rate 是否可见。
- 人工接管：状态不确定或高风险动作失败时是否能让人处理。
- 版本管理：prompt、工具、模型、工作流和 eval 集是否有版本记录。
结论收束
Agent 可靠性必须评估过程，而不只是评估答案。
短任务、无副作用、可重跑的场景，用基础日志和手动重试就足够。长任务、动态工具、写入动作和线上生产场景，则需要 checkpoint、幂等、断点续跑、回放和分层 Eval。
恢复能力让 Agent 失败后不至于失控；回放能力让团队知道为什么失败；Eval 能把这些失败变成可回归的工程样本。三者合在一起，Agent 才能从演示系统走向可运营系统。