SWE-bench Verified 的头条分数已经从 2023 年 10 月的 1.96% 一路爬到 2026 年 4 月的 80.9%，所有人都盯着这条曲线欢呼。但这曲线只丈量一件事——一次做对。决定一个自主智能体能不能上生产的，从来不是顺境里的优雅，而是第 47 步崩了之后它怎么活下来。本期横评聚焦业界最不愿公开的那张暗账：故障恢复（fault recovery）的执行机制。结论很反直觉——当下自愈设计的塌方不在"恢复不了"，而在三处更隐蔽的地方：重试没有上限、检查点语义稀疏、重规划把已完成进度当垃圾丢掉。这三式叠加，把一个"能 self-heal"的 demo 在真实负载下变成一台精密的预算焚烧炉。
| 恢复策略 | 适用错误类型 | 恢复时延 | 进度损失 | 预算失控风险 | 典型踩坑 |
|---|---|---|---|---|---|
| 无限重试（无 cap） | 瞬时抖动 | 不可控 | 无 | 极高（烧穿） | 把语义错当瞬时错无限重试 |
| 有界重试 + 指数退避 | 限流/网络抖动 | 秒~分钟级 | 无 | 中 | cap 设错仍可能放大 |
| 检查点恢复（朴素） | 崩溃/上下文溢出 | 分钟级 | 回到上一存档 | 低 | 75% 存档无恢复语义 |
| 语义感知检查点 | 崩溃/长程中断 | 秒级 | 仅丢失败步 | 低 | 实现复杂、依赖插桩 |
| 全局重规划 | 规划失效/死胡同 | 重 | 高（丢弃已完成子任务） | 中 | 把婴儿和洗澡水一起倒掉 |
| 补偿事务 | 已提交的不可逆副作用 | 重 | 0（前向修复） | 中 | 补偿动作本身也可能失败 |
下文逐一拆解其中最致命的三式塌方，外加三处常被忽略的次级失效。
最危险的自愈代码，恰恰是看上去最"负责任"的那段。Claude Code 代码库自身记录过一次事故：1,279 个会话各自连续触发 50 次以上的 compaction（上下文压缩）失败，工程团队察觉之前，单日烧掉约 25 万次 API 调用。智能体本身没坏——它在精确执行被赋予的恢复逻辑，问题在于这段逻辑没有天花板。Compaction 失败，于是重试 compaction；重试又失败，于是再重试。一个本该两步跳出的瞬时抖动，被焊成了一条只受钱包约束的死循环。
# 反面：没有熔断器的恢复循环
def compact_and_recover(ctx):
while ctx.overflow(): # 条件不消失
try:
return compress(ctx)
except CompactionError:
continue # 永远会再试，永不退出
教训不是"别重试"，而是恢复路径必须带熔断器：次数 cap、预算 cap、错误分类闸门。瞬时错（429/超时）才走退避重试；语义错（schema 不匹配、工具不存在）重试一万次结果也不会变，必须立刻跳出转重规划。这一式是训练营里最值钱的反例——把"1,279 会话 / 25 万 call"这个数贴在第一页，比讲十页架构图都管用。
第二个塌方藏在"我以为我存档了"。arXiv 2604.28138 的 Crab 论文（HKUST，2026-04）用一句话戳破了朴素 checkpoint/restore 的幻觉：超过 75% 的 agent turn 不产生任何与恢复相关的状态。也就是说，绝大多数所谓"检查点"保存的是空操作、纯读取、无副作用的中间产物——存了等于没存，真要恢复时既不减少重算，也提供不了语义边界。这就是为什么很多团队接了持久化却发现"恢复后行为反而更怪"：存的不是状态，是噪声。
# 语义感知存档：只在副作用边界落盘
def maybe_checkpoint(turn):
if turn.has_side_effect or turn.mutates_world:
snap = serialize(turn.deltas_only) # 只存增量，不存全量
snap.add_tag(turn.intent) # 带"恢复到这能干嘛"的语义
store.append(snap)
# 无副作用的 turn：直接跳过，省下那 75% 的空存档
破解之道是语义感知检查点：只在副作用边界（写库、发请求、改文件）落盘，且只存增量 delta 而非全量快照，并给每个存档打上"恢复到这一点能继续做什么"的语义标签。Crab 这类 semantics-aware runtime 把恢复开销从"全量回放"压到"秒级续跑"。对训练营而言，这是从"会存档"到"会恢复"的分水岭课题。
第三式最隐蔽，也最伤。智能体遇到死胡同触发 replan，常规实现是推倒重来——重新生成一整份计划。问题是，旧计划里已经成功执行的子任务（已下载的依赖、已创建的文件、已支付的首付款）随之被遗忘。重规划后要么重复执行造成副作用双花（这一点与"回滚即双花"是同源病灶），要么因为环境已变而彻底卡死。UltraHorizon（arXiv 2509.21766）在超长程场景下观测到的能力断崖，很大一部分正是来自这种"重规划即归零"的累计进度流失——任务越长，一次盲目重规划的代价越呈指数放大。
正确做法是增量重规划：把已完成子任务标记为 committed，replan 只对未完成部分生效；对已提交的副作用走补偿（compensation）而非撤销（rollback）。这与分布式事务的 saga 模式同构——前向修复永远比回滚便宜。变现上，"不丢进度的重规划"是可以直接做成 SDK 卖给企业级 agent 平台的硬需求。
退避重试治不好的，往往是语义错。一个最经典的误判：工具返回 {"error": "city not found"}，agent 的 catch-all 把它归为"可重试"，于是用同样的入参重试五十次。错误分类闸门（error taxonomy gate）必须前置：HTTP 层错误（5xx/429/超时）走重试，应用层语义错误（参数非法、资源不存在、权限不足）直接跳出。代码里这往往只是一个 if is_transient(err) 的判断，但它决定了智能体是优雅降级还是烧穿预算。
对已提交的不可逆操作（发邮件、转账、部署），撤销根本不存在——你能"回滚"一封已发出的邮件吗？这时唯一的恢复路径是补偿事务：再发一封更正邮件、再转一笔反向账。但补偿动作本身也可能失败，于是需要补偿的补偿，形成 saga 链。真正稳健的设计会在执行前就预判可逆性：可逆操作放心做、失败就回滚；不可逆操作必须先过审批或在 saga 框架里登记补偿函数。忽视这一点，就是把"自愈"建成一颗随时双花的定时炸弹。
最后一式是哲学层面的：恢复的对象搞错了。智能体检测到异常，本能反应是"把环境还原到出错前的状态"。但很多时候真正该恢复的不是环境，而是智能体自身的认知——它对任务的理解已经漂移，恢复一个旧环境只会让漂移的认知再次撞上同样的墙。这与目标漂移（十万 token 断崖）是孪生病灶。健康的恢复回路要先做意图复核（re-ground intent）："我为什么来到这一步？这一步还在服务原始目标吗？"——再决定恢复环境还是修正路径。
flowchart TD
A[第47步：异常发生] --> B{错误分类}
B -->|瞬时错 429/超时| C[有界重试 + 指数退避]
B -->|语义错 参数/权限/不存在| D[立即跳出]
B -->|崩溃/上下文溢出| E[语义感知检查点恢复]
B -->|死胡同/规划失效| F[增量重规划]
B -->|已提交不可逆副作用| G[补偿事务 saga]
C --> C1{触及 cap?}
C1 -->|否| H[继续]
C1 -->|是| D
D --> I{意图复核 re-ground}
E --> I
F --> J[保留 committed 子任务<br/>仅重排未完成部分]
G --> K[前向修复 不回滚]
J --> I
K --> I
I --> L{认知是否漂移?}
L -->|否| H
L -->|是| M[修正路径而非还原环境]
M --> H
style A fill:#fdd,stroke:#c33
style C fill:#ffd,stroke:#c90
style E fill:#dfd,stroke:#3a3
style F fill:#dfe,stroke:#3aa
style G fill:#fdd,stroke:#c33
style M fill:#ddf,stroke:#33c
这张图揭示了所有塌方的共同根因：它们都缺同一道闸门。无限重试缺的是 cap，检查点稀疏缺的是语义标签，重规划归零缺的是 committed 标记。把这些闸门焊进恢复路径，成本极低，却是 demo 与生产的分界线。
榜单衡量智能体顺境里能飞多高，恢复机制决定它逆境里活不活。三式塌方——重试无顶、检查点稀疏、重规划归零——的共同处方只有六个字：加 cap、带语义、留进度。把这九个字焊进恢复路径，比再调一个百分点的头条分数值钱得多。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。