大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG
我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
文章目录
- 引言
- 一个真实场景
- 核心问题
- 本质一句话
- 一、问题本质：Agent 系统天然是“部分成功系统”
- 示例
- 问题
- 本质
- 二、为什么 try-catch 不够
- 示例
- 本质
- 三、核心目标：系统最终一致
- 核心思想
- 四、关键设计一：幂等性
- 什么是幂等
- 示例
- 实现方式
- 本质
- 五、关键设计二：重试机制
- 但不能无限重试
- 正确方式
- 示例
- 本质
- 六、关键设计三：超时控制
- 示例
- 必须设计
- 本质
- 七、关键设计四：Saga 补偿模式
- 思路
- 示例
- 结构
- 本质
- 八、关键设计五：状态机驱动恢复
- 正确方式
- 示例
- 本质
- 九、关键设计六：Checkpoint
- 示例
- 如果没有 Checkpoint：
- 正确方式
- 本质
- 十、关键设计七：死信队列
- 示例
- 解决方式
- 本质
- 十一、关键设计八：降级机制
- 示例
- 示例
- 本质
- 十二、关键设计九：恢复优先级
- 示例
- 本质
- 十三、关键设计十：可观测性与审计
- 示例
- 本质
- 十四、实战架构：失败恢复系统
- 核心特征
- 十五、终局理解：失败不是异常，而是“常态”
- 本质变化
- 总结
引言
很多人第一次做 Agent 系统时，都会默认一种逻辑：
执行成功 → 系统继续 执行失败 → 报错结束但现实世界不是这样的。
在真实环境中：
网络会超时 接口会失败 Agent 会误判 任务会中断 外部系统会崩溃问题不是：
“会不会失败？”
而是：
“失败之后怎么办？”
一个真实场景
Agent 自动完成订单流程： 创建订单 扣减库存 支付失败结果：
库存已经减少 订单状态异常 用户无法重新支付核心问题
AI 系统真正危险的，不是失败，而是“失败后一半成功”。
本质一句话
失败恢复与补偿机制，本质是在“不可避免的失败”中，重新找回系统一致性。
一、问题本质：Agent 系统天然是“部分成功系统”
传统单体系统：
一个函数 一次调用 一次返回Agent 系统：
多步骤 多工具 多 Agent 跨系统调用示例
Agent → 调用支付系统 → 调用库存系统 → 调用通知系统 → 调用日志系统问题
某一步成功 某一步失败本质
Agent 系统很少“全部成功”或“全部失败”，而是“部分成功”。
二、为什么 try-catch 不够
很多人第一反应：
try{execute();}catch{retry();}但现实问题是：
失败可能发生在外部系统 失败可能是延迟失败 失败可能已经修改状态示例
支付接口超时 但实际上已经扣款本质
失败，不一定意味着“没有执行”。
三、核心目标：系统最终一致
失败恢复的真正目标不是：
绝不失败而是：
即使失败，系统最终仍然正确。
核心思想
允许失败 但必须恢复四、关键设计一：幂等性
这是 Agent 系统最核心的基础。
什么是幂等
同一个操作执行多次 结果仍然一致示例
createOrder(orderId);即使重复调用：
不会创建多个订单实现方式
if(exists(orderId))return;本质
幂等性，是“安全重试”的前提。
五、关键设计二：重试机制
失败后，系统必须支持自动恢复。
但不能无限重试
错误方式：
失败 → 无限 retry正确方式
最大重试次数 指数退避（Exponential Backoff） 随机抖动（Jitter）示例
retryDelay*=2;本质
恢复机制，必须“有限制”。
六、关键设计三：超时控制
很多失败，本质上是：
永远等待示例
外部 API 卡住 Agent 一直阻塞必须设计
if(costTime>timeout){abort();}本质
系统必须“知道什么时候放弃”。
七、关键设计四：Saga 补偿模式
这是多步骤 Agent 系统的核心。
思路
如果：
步骤 A 成功 步骤 B 失败那么：
执行 A 的“反向操作”示例
扣库存 支付失败 → 回滚库存结构
Do ↓ Fail ↓ Compensate本质
补偿，不是“撤销”，而是“反向修正”。
八、关键设计五：状态机驱动恢复
不要用“if else 地狱”。
正确方式
pending → processing → success → failed → compensating → recovered示例
if(state==="failed"){enter("compensating");}本质
恢复流程，本质也是“状态流转”。
九、关键设计六：Checkpoint
长任务不能“一次跑到底”。
示例
任务执行 30 分钟 第 29 分钟失败如果没有 Checkpoint：
全部重跑正确方式
保存阶段状态 从最近节点恢复本质
恢复能力，来自“阶段性保存”。
十、关键设计七：死信队列
有些任务：
永远无法成功示例
参数错误 数据损坏 权限永久拒绝解决方式
失败次数超过阈值 → 放入死信队列 → 人工处理本质
系统必须允许“放弃恢复”。
十一、关键设计八：降级机制
系统不能“全崩”。
示例
AI 服务不可用 → 回退规则系统示例
if(llmUnavailable){useRuleEngine();}本质
恢复不仅是“修复”，还包括“降级生存”。
十二、关键设计九：恢复优先级
不是所有失败都一样重要。
示例
支付失败 → 高优先级恢复 日志失败 → 低优先级恢复本质
恢复系统也需要“调度”。
十三、关键设计十：可观测性与审计
你必须知道：
哪里失败 失败多少次 恢复是否成功 补偿是否完成示例
{"task":"payment_flow","state":"compensated","retry":3}本质
无法观测的恢复系统，本质上不可控。
十四、实战架构：失败恢复系统
完整结构如下：
任务执行（Execution） ↓ 错误检测（Error Detection） ↓ 重试系统（Retry） ↓ 状态恢复（Recovery） ↓ Saga 补偿（Compensation） ↓ 降级系统（Fallback） ↓ 监控与审计（Monitoring）核心特征
允许失败 支持恢复 支持补偿 支持降级十五、终局理解：失败不是异常，而是“常态”
很多人做系统时：
把失败当成特殊情况但大型 Agent 系统真正的设计哲学是：
失败不是例外，而是系统运行的一部分。
本质变化
从： “避免失败” 变成： “设计失败后的恢复能力”总结
失败恢复与补偿机制的本质，不是：
让系统永不失败而是：
让系统“即使失败，也不会崩溃”。
我们可以用一句话总结：
权限系统 → 防止乱做 限流系统 → 防止做太多 调度系统 → 决定先做什么 恢复系统 → 保证失败后还能回来
)
