智能体在 demo 里一条龙跑通，到了真实环境却常在第三步翻车：API 超时、工具返回脏数据、模型胡说、下游挂了。能不能从失败里恢复，是玩具和产品的分水岭。容错不是加几个 try-catch，而是一套「预期会出错、并为出错设计」的工程纪律。本文给出智能体错误恢复与容错的实战法：重试、降级、熔断、补偿，以及哪些错误该让人来兜底。
先给错误分三六九等
不是所有错误都该自动重试。瞬时错误（网络抖动、限流 429 、超时）值得重试；永久错误（参数非法、鉴权失效、权限不足）重试只会浪费资源，必须立刻失败并上报。把错误分类，是设计容错的第一步：对的一类走重试退避，错的一类走降级或人工。可结合 智能体调试实践 把常见错误先盘点清楚，再决定每类怎么处置。
重试要带退避，别暴力轮询
最简单的容错是重试，但无脑重试会把瞬时故障打成雪崩。正确做法是带指数退避和抖动：第一次等 1 秒，第二次 2 秒，封顶后停止；并设最大次数，超过就转降级。退避加抖动能避免一堆客户端在同一时刻同时重试、把下游打挂。把重试逻辑集中封装，而不是散落在每个工具调用里。
降级与熔断：宁可少做，不要全崩
某个非核心工具挂了，智能体不该整条链路失败。降级是「拿不到就换方案」：推荐服务挂了就返回兜底列表，搜索挂了就靠缓存。熔断是「连续失败就先停」：某依赖短时间屡次出错，先切断调用一段时间，给它喘息，避免持续拖累主流程。和 智能体测试策略 配合，把降级和熔断分支也写进测试，别等线上才第一次触发。
用补偿而不是回滚来收拾残局
智能体常会执行有副作用的操作（发消息、写库、调支付）。出错了不能简单「回滚」，因为外部系统状态未必能撤销。正确思路是补偿：记录每一步做了什么，失败时按相反顺序做补偿操作（已发消息就补一条更正、已建单就取消）。这一步要把「可补偿」当成工具设计的前置要求，而不是事后补救。
人兜底与清晰报错
有些错误不该自动吞下：涉及钱、涉及不可逆操作、或连续多次失败仍无进展。这类要停手并把上下文交给人，给出「卡在哪、为什么、需要什么」的结构化摘要，而不是扔一句「出错了」。可参考 智能体交接模式 把控制权平稳交回人类或其他智能体，保留完整轨迹便于接手者快速定位。
- 分错误：先把错误分成瞬时可重试与永久须失败两类。
- 加退避：瞬时错误用指数退避加抖动重试，设上限与最大次数。
- 做降级：非核心依赖挂了返回兜底，不让单点拖垮主流程。
- 上熔断：依赖短时屡败先切断，给下游喘息后再试探恢复。
- 记补偿：副作用操作记录步骤，失败时按逆序做补偿而非回滚。
- 交人兜底：钱、不可逆、连续失败的，停手并给结构化摘要交人。
常见问题
所有错误都该自动重试吗？
为什么不能用简单回滚处理失败？
降级会不会让智能体偷偷答错？
哪些情况必须交回给人？
评论 (0)