在 Agent 出错之前，先设计恢复方式

自动化方案通常把成功路径写得很细，却把所有失败压缩成一句“重试”。恢复需要单独设计：什么事件会让系统停止、哪些状态必须保留、谁接管，以及哪些动作绝不能重复。

真正困难的情况往往不是明确失败，而是结果未知：请求超时后，邮件可能已经发送，付款可能已经提交，记录也可能只更新了一半。手册必须让接管者先查清外部事实，再选择继续、补偿或保持停止。

用六个字段写恢复手册

• **停止信号：**哪个可观察事件会暂停新任务？
• **最后安全状态：**从哪个检查点开始恢复？
• **影响范围：**哪些记录、用户、工具和外部动作受影响？
• **负责人：**谁有权决定下一步？
• **回退或补偿：**已完成动作如何撤销或补救？
• **重试规则：**哪些步骤可安全重复，哪些需要复核，哪些禁止自动重做？

把这些信息放在工作流旁边，而不是藏在事故发生时没人会打开的文档中。

案例：批量续费邮件

Agent 准备并发送续费提醒。收件人不匹配，或退信率超过约定阈值，就是停止信号。文案生成可以重做，但发送不可盲目重复。

最后安全状态要保存已批准名单、消息内容指纹和发送流水。恢复时排除已发送地址，把有争议的记录交给客户负责人；如果正文改变，还要重新批准。

案例：库存同步

Agent 从多个系统读取库存并更新店铺。一个来源延迟，却把所有商品都报告为零。这里的停止信号是库存覆盖率突然下降，而不是接口报错。

工作流应冻结写入、保留最后可信数值，并记录停止前已经更新的商品。恢复时先用第二个信号核对延迟来源。盲目重试只会反复发布错误的零库存。

做一次桌面故障演练

选择一种可信的失败，不接触生产环境，完整走一遍手册。五分钟后操作人员能看到什么？接管凭证是否可用？怎样区分已完成与待处理动作？

如果演练中必须临时从日志拼凑状态，就应该把相应检查点补进产品。

为每一步标记恢复语义

把工作流拆成可观察步骤，并为每步选择一种恢复方式：

• **安全重放：**相同幂等标识重复提交不会产生第二次效果。
• **先查后重试：**超时后先查询远端状态，只有确认未执行才再次提交。
• **补偿动作：**原动作不能撤销，但可以用另一项受控动作减少影响。
• **人工裁决：**系统无法独立确定正确状态，必须把材料交给负责人。
• **永久停止：**一旦触发安全红线，本批任务不得从原位置自动恢复。

不要把“接口支持重试”当成安全重放。必须验证目标系统怎样识别重复、标识保存多久、参数变化后是否仍被视作同一次操作，以及并发请求会发生什么。

可复制的恢复记录

记录项	需要保存的内容
run_id / step_id	批次、对象与当前步骤的稳定编号
输入指纹	实际使用的关键参数与版本
外部操作号	可查询远端真实状态的标识
状态	待执行、执行中、成功、失败或未知
已见副作用	已发送、已修改、已扣款等事实
下一允许动作	查询、撤销、补偿、转人工或终止
接管材料	证据、负责人、时间和决定

状态不能只有“成功/失败”两项。“未知”必须是一等状态，它会阻止自动重试并触发核对。批量任务还要记录单个对象结果，不能因为批次整体失败就重放已经完成的对象。

设计恢复与重新开放门槛

恢复前先回答：停止信号的根因是否确认，影响对象是否已经盘点，错误动作是否完成补偿，待处理队列是否仍然有效，凭证和依赖是否可信，针对性案例是否通过。然后由有权限的人选择从检查点继续、重新生成部分结果或取消整批任务。

重新开放应先从受控的小范围开始，观察同一停止信号和人工修正，再逐步扩大。不要因为服务重新返回正常状态就一次性释放积压队列；旧任务的资料、批准或时间窗口可能已经失效。

常见问题

回滚和补偿有什么不同？ 回滚把状态恢复到原样；补偿承认原动作已发生，用退款、撤回通知或修正记录等新动作降低影响。补偿本身也需要权限和审计。

失败后应该自动重试几次？ 先看动作是否安全重放以及失败类型。对明确的暂时性读取失败可以有限重试；对外部写入结果未知，零次盲目重试才是安全默认。

手册多久演练一次？ 工作流动作、工具、身份、队列机制或负责人发生变化时必须重演；平稳期间也按风险约定周期，并记录发现与下一次触发条件。

不适用边界

恢复手册不能替代危险动作的预防。第一道防线始终是移除不必要的权限；恢复是第二道防线，用来限制工具、输入或假设仍然出错时的影响。