# 重试无顶即烧穿：自主智能体自愈三式实测 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；重试又失败，于是再重试。一个本该两步跳出的瞬时抖动，被焊成了一条只受钱包约束的死循环。 ```python # 反面：没有熔断器的恢复循环 def compact_and_recover(ctx): while ctx.overflow(): # 条件不消失 try: return compress(ctx) except CompactionError: continue # 永远会再试，永不退出 ``` 教训不是"别重试"，而是**恢复路径必须带熔断器**：次数 cap、预算 cap、错误分类闸门。瞬时错（429/超时）才走退避重试；语义错（schema 不匹配、工具不存在）重试一万次结果也不会变，必须立刻跳出转重规划。这一式是训练营里最值钱的反例——把"1,279 会话 / 25 万 call"这个数贴在第一页，比讲十页架构图都管用。 ### 塌方二：检查点稀疏——75% 的存档是无效操作 第二个塌方藏在"我以为我存档了"。arXiv 2604.28138 的 Crab 论文（HKUST，2026-04）用一句话戳破了朴素 checkpoint/restore 的幻觉：**超过 75% 的 agent turn 不产生任何与恢复相关的状态**。也就是说，绝大多数所谓"检查点"保存的是空操作、纯读取、无副作用的中间产物——存了等于没存，真要恢复时既不减少重算，也提供不了语义边界。这就是为什么很多团队接了持久化却发现"恢复后行为反而更怪"：存的不是状态，是噪声。 ```python # 语义感知存档：只在副作用边界落盘 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）："我为什么来到这一步？这一步还在服务原始目标吗？"——再决定恢复环境还是修正路径。 ## 三、自主体故障恢复决策流 ```mermaid 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 子任务
仅重排未完成部分] 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 与生产的分界线。 ## 四、场景化推荐 - **个人 demo / 黑客松**：有界重试 + 指数退避足矣，cap 设 3 次，别碰检查点。第一性原则是"宁可失败，不可烧穿"。 - **企业级长程 agent（运维、研报、持续部署）**：必须上语义感知检查点 + saga 补偿。预算 cap 和错误分类闸门是上线红线，二者缺一不可。 - **自主编码智能体（SWE 类）**：增量重规划是核心，且必须带 git 检查点——committed 子任务对应一次 commit，失败时 revert 单步而非全盘。 - **面向 C 端、含不可逆操作的 agent（交易、发送类）**：任何不可逆动作执行前强制审批钩子，恢复只走补偿、永不撤销。 - **训练营变现**：把"Claude Code 1279 会话 / 25 万 call"作为开篇冲击案例，三式塌方各配一段可复现的 Python 反例与正例，结尾给一份"恢复路径 checklist"作为可带走的交付物——这套结构可直接包装成两天的工程实战课。 ## 五、一句话结论 榜单衡量智能体顺境里能飞多高，恢复机制决定它逆境里活不活。三式塌方——重试无顶、检查点稀疏、重规划归零——的共同处方只有六个字：**加 cap、带语义、留进度**。把这九个字焊进恢复路径，比再调一个百分点的头条分数值钱得多。 ## 参考来源 1. [Self-Healing Agent Pipelines 2026: Autonomous Failure Recovery Architecture](https://agentmarketcap.ai/blog/2026/04/10/self-healing-agent-pipelines-2026-production-architectures-autonomous-failure-recovery) — Claude Code 1,279 会话 / 单日 25 万 API call 烧穿事故与无上限重试根因 2. [Agent Self-Correction Benchmarks 2026: The Score Nobody Talks About](https://agentmarketcap.ai/blog/2026/04/10/agent-self-correction-benchmarks-2026) — 自纠正能力为何是生产最关键却最被榜单忽视的指标 3. [Crab: A Semantics-Aware Checkpoint/Restore Runtime for Agent Sandboxes (arXiv:2604.28138)](https://arxiv.org/html/2604.28138v1) — 75% agent turn 无恢复相关状态，朴素检查点的语义稀疏性 4. [UltraHorizon: Benchmarking Agent Capabilities in Ultra Long-Horizon Scenarios (arXiv:2509.21766)](https://arxiv.org/abs/2509.21766) — 超长程场景下 agent 能力断崖与进度流失 5. [SWE-bench Verified Progress Timeline 2023–2026](https://agentmarketcap.ai/blog/2026/04/09/swe-bench-verified-progress-timeline-2023-2026) — 头条分数 1.96%→80.9% 的演进数据 > [!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 等场景全覆盖。