网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括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(costTimetimeout){abort();}本质系统必须“知道什么时候放弃”。七、关键设计四Saga 补偿模式这是多步骤 Agent 系统的核心。思路如果步骤 A 成功 步骤 B 失败那么执行 A 的“反向操作”示例扣库存 支付失败 → 回滚库存结构Do ↓ Fail ↓ Compensate本质补偿不是“撤销”而是“反向修正”。八、关键设计五状态机驱动恢复不要用“if else 地狱”。正确方式pending → processing → success → failed → compensating → recovered示例if(statefailed){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 系统真正的设计哲学是失败不是例外而是系统运行的一部分。本质变化从 “避免失败” 变成 “设计失败后的恢复能力”总结失败恢复与补偿机制的本质不是让系统永不失败而是让系统“即使失败也不会崩溃”。我们可以用一句话总结权限系统 → 防止乱做 限流系统 → 防止做太多 调度系统 → 决定先做什么 恢复系统 → 保证失败后还能回来