异常处理与恢复
让AI智能体在面对意外时依然可靠运行
🎯 核心概念
来源：Agentic Design Patterns - Exception Handling and Recovery
为什么需要异常处理？
定义
异常处理与恢复模式使AI智能体具备管理突发状况、错误和故障的能力，在失败时选择可恢复的继续、降级或明确停止。
现实世界的挑战
| 问题类型 | 具体表现 |
|---|---|
| 工具故障 | API调用失败、数据库宕机 |
| 网络问题 | 超时、连接中断 |
| 无效数据 | 格式错误、损坏文件 |
| 服务不可用 | 第三方服务维护、限流 |
| 意外输入 | 用户输入超出预期 |
异常处理的价值
| 无异常处理 | 有异常处理 |
|---|---|
| ❌ 遇到错误就崩溃 | ✅ 对已建模的故障有处理路径 |
| ❌ 无法完成任务 | ✅ 符合恢复条件时继续，否则明确停止 |
| ❌ 错误信息不友好 | ✅ 优雅地处理问题 |
| ❌ 难以部署关键应用 | ✅ 为关键场景提供可验证的失败边界 |
🔄 三大核心环节
整体流程
① 错误检测 → ② 错误处理 → ③ 恢复
发现问题 应对问题 恢复稳定| 环节 | 核心策略 |
|---|---|
| 错误检测 | 监控输出、检查API响应、超时检测、异常监测 |
| 错误处理 | 日志记录、重试机制、回退方案、优雅降级、通知机制 |
| 恢复 | 状态回滚、诊断分析、自我纠正、上报升级 |
🔍 错误检测（Error Detection）
检测内容
| 检测项 | 说明 | 示例 |
|---|---|---|
| 无效输出 | 工具返回结果格式错误 | JSON解析失败 |
| API错误码 | HTTP状态码指示错误 | 404、500、503 |
| 响应超时 | 服务响应时间异常长 | >30秒无响应 |
| 无意义响应 | 偏离预期格式的内容 | 乱码、空内容 |
检测方式
| 方式 | 说明 |
|---|---|
| 主动检测 | 验证工具输出、检查状态码、设置超时 |
| 被动检测 | 捕获异常、其他智能体监控、专用监控系统 |
⚙️ 错误处理（Error Handling）
五种处理策略
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 日志记录 | 详细记录错误信息便于调试 | 所有错误 |
| 重试机制 | 重新尝试（可调整参数） | 瞬时错误、网络波动 |
| 回退方案 | 使用替代策略或方法 | 主方案失败 |
| 优雅降级 | 维持部分功能运行 | 无法完全恢复 |
| 通知机制 | 向用户或系统发出警报 | 需要人工干预 |
重试策略
重试前先判断“动作是否可能已完成”。读请求超时通常可有界重试；退款请求超时则可能已经扣款，只是响应丢失。此时先用原业务 ID 或幂等键查状态，不能创建新请求盲目重发。
| 错误类型 | 推荐处理 | 禁止混淆的状态 |
|---|---|---|
| 429、临时 5xx、连接失败 | 按服务提示退避，加抖动，限制总时间与次数 | 暂时失败不等于永久失败 |
| 参数 schema 不合法 | 返回字段级错误，允许有限修正 | 更换参数是新提案，不是原动作重试 |
| 权限拒绝、订单不存在 | 停止或澄清 | 不能靠换模型提升权限 |
| 写入超时且结果不明 | 查询执行记录，必要时人工核对 | unknown 不等于 failed |
| 业务前提不成立 | 调整计划或终止 | 不属于网络重试 |
把单次请求超时、重试上限和整个 run 的截止时间分别配置。所有层都自动重试会相乘放大请求量，因此只指定一层负责主要重试；日志带上 run_id、action_id、attempt 和最终状态。
重试方式：
├── 立即重试
├── 指数退避（1s → 2s → 4s → 8s）
├── 带抖动的退避（避免雷鸣效应）
├── 最大重试次数限制
└── 调整参数重试回退方案示例
主方案：调用主模型服务
↓ 失败
回退1：调用通过同任务评测的备用模型
↓ 失败
回退2：使用权限与时效都符合要求的缓存
↓ 失败
回退3：返回明确的不可用或部分完成状态优雅降级示例
智能客服降级：
完整：AI自动回答 + 查询数据库 + 执行操作
部分：AI自动回答 + 查询数据库（操作转人工）
最小：转接人工客服🔧 恢复（Recovery）
四种恢复策略
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 状态回滚/补偿 | 本地事务可回滚；外部已发生的动作需按业务补偿 | 可撤销操作或有明确补偿流程 |
| 诊断分析 | 深入调查错误原因 | 需要找出根本原因 |
| 自我纠正 | 调整计划、逻辑或参数 | 可自动修复的问题 |
| 上报升级 | 交给人类或更高级系统 | 复杂或严重问题 |
恢复流程
检测到错误
│
├─→ 可自动恢复 → 自我纠正 → 重新尝试
│
└─→ 无法自动恢复 → 上报升级 → 人工干预
│
▼
恢复稳定运行🔗 与反思模式结合
异常处理可以与反思模式结合使用：
初次尝试 → 执行失败
↓
反思：分析失败原因
↓
调整：改进提示词/策略
↓
重新尝试 → 成功/继续反思📋 六大应用场景
| 场景 | 错误情况 | 处理方式 |
|---|---|---|
| 客服聊天机器人 | 数据库宕机 | 检测错误 → 告知用户 → 建议稍后再试 → 转人工 |
| 金融交易 | 资金不足/市场休市 | 记录错误 → 停止重试 → 通知用户 → 调整策略 |
| 智能家居 | 网络问题 | 检测故障 → 重试 → 通知用户 → 建议手动干预 |
| 数据处理 | 损坏文件 | 跳过文件 → 记录错误 → 继续处理 → 最后报告 |
| 网页抓取 | CAPTCHA/404/503 | 区分验证、资源缺失和暂时不可用；暂停、有限重试或请求人工处理 |
| 机器人制造 | 抓取失败 | 传感器检测 → 重试 → 提醒操作员 |
恢复演练
用可控的故障注入验证“服务已写入但响应丢失”“工作进程在写入后崩溃”“重复收到同一任务”“取消后仍有迟到结果”。检查是否产生重复副作用，恢复后是否跳过已完成动作，失败能否关联到原始请求。只测试抛异常后的返回文本，不能证明恢复机制有效。
检查点负责保存执行进度，但不自动撤销已发送的邮件或外部系统写入。有关幂等与重放的框架行为，可对照 LangGraph 持久化文档；具体业务仍需自己的执行记录与补偿规则。
💡 核心要点
使用场景
- 部署在动态、真实世界环境
- 可能遭遇系统故障、工具错误、网络问题
- 对操作可靠性要求极高
三大核心能力
| 能力 | 说明 |
|---|---|
| 检测 | 验证输出、检查状态码、超时监控 |
| 处理 | 日志、重试、回退、降级、通知 |
| 恢复 | 回滚、诊断、自我纠正、上报 |
一句话总结
异常处理与恢复模式将AI智能体从脆弱不可靠的系统，转变为强大、可靠、能够在不可预测环境中有效运行的组件。
🔗 相关阅读
参考文献：
- Agentic Design Patterns - Exception Handling
- McConnell, S. (2004). Code Complete (2nd ed.). Microsoft Press.