AI 流程不怕慢，怕的是一步失败全盘停摆。容错处理回答的是一个朴素问题：某一步失败了，接下来怎么办？是原地重试、换个路子，还是干脆放弃并报告——把这些预案提前写进流程，就是容错的全部内容。
失败之后的几条去路
常见处置有四条：重试，适合偶发性失败，隔几秒再试一次往往就过了；降级，换一个简化方案先顶上，比如拿不到完整数据就用缓存；跳过，标记该步失败继续走后面，最后汇总说明；终止上报，问题太大就停下来交给人。四条去路对应四类故障，选错去路比不去路更糟。
扣子的流程里可以给节点配置失败分支，通义千问驱动的应用在工具报错时也常见自动重试逻辑。配预案前先分清失败的性质：是临时抖动，还是确定性错误——前者值得重试，后者重试一百次也是白费。
静默失败之外还有一类延迟失败：当时看着成功，事后发现不对——发了邮件但附件是旧的，生成了文件但数据缺了一段。这类问题最难防，因为流程当时拿到的返回是「成功」。对策是关键动作后加一步校验：发完邮件回读一封确认，生成文件后抽查一行数据。多花一步，换来的是把「以为对了」变成「验证过对了」，对交付类任务值得。配置失败分支时，把每条分支的触发条件写具体，「出错就走这条」这种写法等于没配。
| 失败类型 | 识别信号 | 关键点 |
|---|---|---|
| 临时抖动 | 偶发，隔几秒再试往往就过 | 属于重试的对象 |
| 确定性错误 | 重试多次结果一样 | 重试只会放大故障 |
| 静默失败 | 没报错但内容不对 | 接住报错不够，还要校验返回内容 |
| 延迟失败 | 当时返回成功，事后发现不对 | 最难防，当时根本看不到错 |
生活类比：快递送不到怎么办
快递第一次投递失败，会有第二次、第三次，这是重试；几次不成放驿站，这是降级；收件地址根本不存在，直接退回并通知寄件人，这是终止上报。一套完整的投递体系，把各种失败都安排了去处。
快递比方对不上的地方在于：包裹失败是看得见的，Agent 的失败有时是静默的——工具返回了内容但内容是错的。所以容错不光要接住报错，还要对返回内容做基本校验，识别「没报错但不对劲」的情况。校验这步也有讲究：全量校验慢，抽样校验快但有漏网，按动作的重要性定校验力度，和容错的其他决策一样是个分寸问题。
重试与换路的分寸
- 重试要有上限和间隔，连着重试十次只会放大故障。
- 重试两次仍败就该换路，别在死路上加倍投入。
- 每次失败都要留痕，方便事后统计哪一步最脆弱。
- 换路之前先判断：是这条路死了，还是目标服务整体不可用。
速查清单：
- 偶发失败：重试加间隔，上限三次。
- 持续失败：降级或跳过，汇总时说明。
- 致命失败：终止上报，附上日志。
- 延迟失败：关键动作后加一步回读校验。
预案写在平时，才轮得到在故障里用上。
流程里的正式关卡，见审批节点；事后回看的依据，见执行日志；代码类任务的隔离运行，见沙箱执行；网页任务的失败应对，见浏览器 Agent；它与老式自动化的分工，见RPA。
收住一句：容错的本质，是把「万一」当成必然会发生的事来提前安排。预案越具体，故障时的动作就越不慌。
聊聊容错处理的常见疑问
- 重试间隔怎么定？：常用递增间隔，比如隔两秒、五秒、十秒各试一次。给外部服务留恢复时间，也避免密集重试加重对方负担。
- 跳过失败步骤会不会留隐患？：会，所以跳过必须配套两件事：结果里明确标注缺了什么，后续环节对缺失有兜底逻辑。
- 容错和重跑整个任务什么关系？：容错是任务内的局部补救，重跑是任务外的整体重来。局部能救就局部救，救不了再整体重跑，成本差一个量级。重跑前记得带上上次的日志，别让同样的坑踩两遍。
