11.3 容错模式与系统级恢复
AI Agent 系统在生产环境中需要面对网络中断、API 超时等各种故障。本节介绍四大容错模式(熔断器、隔舱、超时、重试)、幂等性设计、检查点恢复、SAGA 补偿事务和“错误作为观察”设计模式。
11.3.1 四大容错模式
1. 熔断器
熔断器的状态转移流程如下:
图 11-3:熔断器状态机
熔断器通过状态机实现故障隔离。首先定义状态枚举和配置:
2. 隔舱
隔舱模式的实现代码如下:
3. 超时
实现如下:
4. 重试
具体实现代码如下:
图 11-4:重试机制流程(可重试判断 + 指数退避)
图 11-5:四大容错模式级联防护 重试策略通过指数退避和抖动来处理瞬时故障。首先定义重试配置和策略:
11.3.2 幂等性设计
核心实现如下: 幂等性管理器确保相同操作只执行一次,即使请求重复。通过生成操作的哈希键来检测重复:
11.3.3 检查点恢复
实现代码如下: 检查点管理器在长流程中定期保存状态,支持故障恢复。首先定义检查点数据结构:
可恢复工作流使用检查点来支持长流程的容错执行:
11.3.4 SAGA 模式与补偿事务
重试和检查点解决的是“重来一次就好”的故障,但有一类操作无法靠重来兜底:带有真实副作用的多步流程。以航班预订为例,它不是一个动作,而是一串顺序操作——订座、扣款、出票,每一步都在调用一个外部系统,每一步都可能失败。
最朴素的做法(整体重试)会很快失效:如果座位已订、扣款却失败,再整体重试就会重复订座甚至重复扣款,把系统推向更坏的状态。真正需要的是逐步重试,并在某一步重试耗尽后,只回滚已经发生的那些步骤。
图 11-6:SAGA 正向流程与逆序补偿
这正是分布式系统中的 SAGA 模式:把一个长事务拆成若干个本地事务,为每个步骤配一个补偿动作;当正向流程在某一步失败时,按相反顺序对已完成的步骤执行补偿,把系统退回一致状态。SAGA 用最终一致性替代了单库事务的 ACID 原子性——这是在“无法把多个外部系统装进一个数据库事务”时的标准取舍。
三条设计约束贯穿始终:
补偿必须幂等:补偿动作可能因重试或崩溃恢复被多次调用,重复补偿必须安全(参见 11.3.2 节)。
逆序补偿:按完成的相反顺序回退,后发生的副作用先撤销。
失败步骤也要补偿:失败步骤的副作用是否已部分提交是未知的,因此把它一并纳入补偿范围,靠幂等性兜底。
协调器复用 11.3.1 的重试策略,让每一步先各自吸收瞬时故障:
把航班预订接入协调器——每个补偿都以预订号 booking_id 作为幂等键,即使正向回执丢失也能正确冲正:
下沉到工作流引擎。上面的协调器是手写的;在生产中,补偿逻辑可以下沉为工作流引擎的声明式配置。以 LangGraph 的官方容错原语为例:每个节点配 retry_policy 自动重试,重试耗尽后由 error_handler 返回一个 Command(goto="compensate") 转入补偿节点,再用 set_node_defaults 给所有节点统一挂载:
引擎托管 SAGA 的好处在于转移的原子性:error_handler 只在重试全部失败后触发,且这次“转入补偿”的跳转会随检查点一起提交。即使进程在补偿执行到一半时崩溃,恢复时也会重新调度补偿节点,而不会回到那个失败的正向步骤——这正是 11.3.3 检查点恢复与 SAGA 组合后的价值:补偿过程本身也是可恢复的。
SAGA 只提供最终一致性:从某一步失败到补偿完成之间,存在“已扣款、尚未退款”的中间窗口。检查点让它可恢复,告警让它可见,二者把窗口压到尽可能短,但无法消除——这是放弃单库原子性必须接受的代价。
11.3.5 “错误作为观察”模式
OpenClaw 的独特模式:系统不抛异常打断流程,而是将错误信息注入观察流。 错误作为观察模式允许系统继续执行,而不是抛出异常。首先定义错误观察数据结构:
11.3.6 实战:完整的容错系统
示例代码如下:
11.3.7 总结
容错模式的四大支柱:
熔断器
快速失败,保护下游
故障 API、不稳定服务
隔舱
资源隔离,避免级联
并发控制、资源限制
超时
防止无限等待
网络请求、长操作
重试
自动恢复瞬时故障
临时故障、网络抖动
辅助机制:幂等性、检查点、SAGA 补偿、错误作为观察,构成完整的生产级容错系统。
[1] P95 百分位数(0.95)为经验值,实际系统应基于历史执行时间数据标定,并考虑业务 SLA 要求。
最后更新于
