Failure Recovery：Agent 失败后怎么收住现场？

今天先记住

Failure Recovery（失败恢复）不是“失败了再试一次”这么粗糙。它要回答的是：哪一步失败了，失败前有没有改变外部状态，能不能从检查点继续，还是必须停止并让人介入。

它在大地图里的位置

今日坐标

评估 / 修正 → Failure Recovery

txt

用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> ▶ 评估 / 修正
  -> 最终输出

前面讲可观测性，是让你看见 Agent 哪一步坏了。失败恢复接在它后面：看见问题之后，系统应该重试、回滚、换路径、暂停，还是直接把局面交给人。

它到底是什么

失败恢复是一组围绕状态变化设计的规则。它通常包括 checkpoint（检查点）、retry policy（重试策略）、timeout（超时）、compensation（补偿动作）、idempotency key（幂等键）和人工接管。

关键不在名词，而在边界：读文件失败和 push 失败不是一类事。读文件没改外部状态，可以换路径或重试；push 超时则麻烦得多，因为你不知道远端到底有没有收到提交，下一步必须先观察远端状态，而不是闭眼再 push 一次。

为什么 Agent 里会用到它

Agent 会跨工具、跨网络、跨文件系统做事，中间任何一步都可能失败。普通 Chatbot 失败最多是少回一句；Agent 失败可能留下半写入文件、重复提醒、错误提交、未清理的临时状态。

所以失败恢复要把“失败”拆细：是输入不足、模型输出不合 schema、工具参数错、网络超时、权限不足，还是外部系统已经部分执行。每一类失败对应不同动作。能重试的重试，不能重试的先查状态，会造成损失的停下来。

怎么判断它有没有用

如果某一步只读不写，可以设置短重试和备用路径。
如果某一步会写文件、发消息、提交代码，要先记录动作前状态，再执行。
如果工具返回超时但动作可能已经发生，下一步应该观察结果，而不是直接重复执行。
如果恢复规则只写“失败后重试 3 次”，没有区分失败类型，它很可能会把小错放大成重复动作。

一个小例子

txt

Input:
用户说：“生成并发布 2026-07-31 的 AI Agent Daily。”

Process:
1. 写入 docs/ai-agent/2026-07-31.md。
2. 检查敏感内容。
3. git add 指定文件。
4. commit 成功。
5. git push 超时。

Recovery:
先执行 git status 和 git log，确认本地提交存在。
再查询远端 main 是否已经包含这个 commit。
如果远端已有，标记为已发布；如果远端没有，再执行一次 push。

Output:
状态从 push_unknown 变成 published 或 needs_retry，而不是盲目重复提交。

这个例子可以用来判断真实系统：好的恢复不是“再跑一遍全流程”，而是先定位停在哪个状态，再选择最小的下一步。

常见误区

把恢复等同于重试。重试只适合暂时性、可重复、不会造成副作用的失败。
没有检查点。失败后只能从头跑，容易重复执行已经完成的动作。
忽略部分成功。外部系统超时不代表动作没发生。
不记录失败分类。所有错误都叫 failed，后面就只能靠人猜。

今天自测

为什么 push 超时后不能马上再 push？
哪些 Agent 动作适合自动重试，哪些必须先观察状态？
如果一个系统没有检查点，失败恢复会退化成什么？

Failure Recovery：Agent 失败后怎么收住现场？ ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​