失败恢复与幂等

用途：让长时间运行的多 Agent 任务在崩溃、超时、部分失败后可恢复

失败类型

类型	例子	处理策略
瞬时失败	网络抖动、限流 429、依赖超时	退避重试（有上限与预算）
确定性失败	提示不可满足、输入缺失、任务描述错误	不重试，直接 BLOCKED 并要求澄清
部分完成	5 个子任务成功 3 个、文件写了一半	从检查点恢复，禁止整体重跑（成本高且可能重复副作用）
外部副作用已发生	已提交 PR、已发消息、已改数据	幂等键 + 补偿（撤销/关闭），不能简单重放
无进展循环	反复自我修正、结论震荡	无进展检测 + 终止 + 升级人工

可恢复性的三个前提

状态外置：进度、决策、产物写入持久存储（文件/DB），不依赖对话上下文存活。
检查点：每个阶段结束固定快照（已完成任务、产物哈希、上下文摘要），重启时从检查点继续。
幂等步骤：任意步骤可安全重跑，重复执行结果一致。

幂等的实现

副作用	幂等手段
创建分支/提交	以任务 ID 命名，存在则复用；提交前比较内容
开 PR/Issue	唯一键（任务 ID）+ 查询后创建；更新而非新建
发消息/通知	消息 ID + 去重表
写文件	内容哈希相同则跳过；不同则显式覆盖并留痕
调外部写接口	业务幂等键 + 对端支持去重
数据变更	条件更新（版本号/状态守卫），或先查后写 + 事务

没有幂等就不要重试：重试会把“一次失败”变成“多次副作用”。

补偿与回滚

不可逆操作（删数据、发消息、支付类）必须有前置确认或补偿动作设计。
长任务应记录“已执行动作清单”，失败时可按清单逆向补偿或至少生成人工处置单。
回滚单位是任务级（一个子任务的所有变更一个提交），便于精确撤销（与 diff 归属一致）。

超时与预算的联动

超时不是失败处理的终点：超时后必须判定为 BLOCKED/UNVERIFIED（而非“当作完成”），并保留已完成部分与进度记录，供后续续跑或人工接管。

观测与排障

每个节点记录：输入摘要、输出摘要、耗时、成本、重试次数、失败原因分类。
提供“按任务 ID 看全过程时间线”的视图，比翻日志有效。
关键告警：重试率、无进展终止数、检查点恢复次数、幂等冲突次数（这些是系统健康度信号）。

常见误区

误区	修正
失败就整体重跑	成本翻倍且可能重复副作用；用检查点 + 幂等
状态放在对话上下文里	进程重启即丢，必须外置
对确定性失败反复重试	先归因，再决定是否重试
无幂等的重试	重复 PR、重复通知、重复写入
超时当作完成	归为未验证并保留进度
不可逆操作无确认	前置确认或补偿路径

延伸阅读

本站：回执与权威状态绑定、冲突与 diff 归属、成本与延迟预算
工作流引擎（Temporal、Step Functions 类）关于持久化执行与重放的公开文档