AI Agent 如何处理失败、重试、循环终止与人工接管？

简化版

Agent 应把执行过程建模为可恢复的状态机，把失败分类（瞬时故障、参数错误、权限拒绝、业务失败）再决定重试、改参、回滚或人工接管。所有循环都要有最大步数、连续失败数、时间和费用预算；写操作只有具备幂等或状态确认机制时才能安全重试。核心——可靠性靠”状态可恢复、错误可分类、副作用可确认、循环有硬上限、必要时能交人”，而不是让模型无限自我纠错。

详细版

可靠运行时要保存任务状态、步骤输入输出、工具调用 ID、副作用、检查点。失败后先分类：瞬时错误有限退避；参数错误让模型修正；权限/策略拒绝直接停止；未知状态先查真实系统，不能立即重复写操作。

终止既含成功条件也含安全失败条件：超预算、重复相同动作、连续无信息增益、关键工具不可用、需要高风险决策时，停止自动循环并提供人工接管所需的摘要与证据。

完整版教学

一、为什么要用状态机

仅靠聊天历史很难判断「动作到底执行了没」。显式状态机把执行过程变成可追踪、可恢复的状态：

pending → running → succeeded
              ↓
           failed → (分类后)重试/改参/停止
              ↓
        waiting_approval → (人工批准后)running
每次关键状态变化【持久化检查点】→ 进程重启后从已确认状态继续（不重放全部对话）

二、错误分类：决定能不能重试

这是核心框架，不同错误处理完全不同：

错误类型	处理	能重试吗
超时/限流/暂时不可用	有限退避重试	能
Schema/业务参数错误	让模型修改参数再试	改参后能
认证/授权/策略拒绝	停止，请求正确权限	不能
业务终态失败	记录原因，不盲目重试	不能
响应丢失/结果未知	先按请求 ID 查执行状态	先查再定

关键：错误码应来自工具，不让模型仅凭错误文本猜类别。

三、写操作与补偿（防重复副作用）

写操作（创建/付款/发信）用幂等键：
  Agent 重试 → 服务端识别同一 idempotency_key → 返回首次结果，不重复执行

跨服务流程无法用单一事务时：为已完成步骤设计【补偿动作】（如"退款"补偿"扣款"）
  ⚠️ 补偿不一定完全恢复原状（如已发的邮件收不回），可能需人工审批
  ⚠️ 回滚本身也是副作用操作，不能默认安全

四、循环检测：Prompt 说”别循环”不管用

除最大步数外，还要主动检测停滞：

检测信号：连续相同工具+参数、状态哈希无变化、重复错误码、单位成本的信息增益趋近 0
检测到停滞 → 缩小任务/切换策略一次 → 仍不行则转人工

记忆钩子：只在 Prompt 里要求”不要重复”无法提供硬保证——循环必须靠运行时的硬性检测和上限兜底。

五、人工接管：交接要给什么

适合接管的情况：不可逆动作、权限升级、证据冲突、预算耗尽、低置信度高影响决策。交接材料要完整：

原始目标 + 当前状态 + 已执行的副作用 + 关键证据 + 失败原因 + 待批准动作
人工批准要【绑定具体参数和有效期】；参数改了要重新审批

可观测与演练：记录完整轨迹（脱敏），统计成功率、恢复率、平均重试次数、循环率、人工接管率。用故障注入测试超时、重复响应、部分成功、进程重启，验证能否安全恢复。

六、恢复策略怎样用数字验收

可靠性不能只看最终成功率，还要区分“首次成功、重试后恢复、人工恢复”和“带副作用失败”。例如 1000 个任务中，850 个首次成功，80 个经重试恢复，30 个由人工完成，40 个最终失败，则自动成功率是 (850+80)/1000=93%，端到端完成率是 96%；若其中有 2 个任务产生重复扣款，即使完成率很高也必须阻止发布。

auto_success_rate = (850 + 80) / 1000 = 93%
recovery_rate = 80 / (80 + 40) = 66.7%   # 进入自动恢复流程后的恢复比例
unsafe_side_effects = 2                   # 独立安全门，不能被成功率平均

回归测试应注入“请求已执行但响应丢失”这一类不确定状态，验证 Agent 会先按请求 ID 查询，而不是再次扣款。还要统计每类错误的重试次数、恢复耗时、补偿成功率和接管等待时间；把权限错误重试到成功，可能意味着权限边界被绕过，并不属于可靠性提升。

七、常见误区与追问

• 误区：让模型自己无限纠错就能可靠。 可靠性靠状态机+错误分类+硬上限+人工接管，不是模型自我纠错。
• 误区：所有失败都能重试。 只有瞬时故障能退避重试，权限拒绝/业务终态失败不能，未知状态要先查。
• 误区：写操作直接重试安全。 会重复副作用，必须幂等键；补偿和回滚本身也是副作用不默认安全。
• 误区：Prompt 写”不要循环”能防死循环。 无硬保证，要运行时检测（相同动作/状态哈希/重复错误码）+ 最大步数。
• 追问：为什么用状态机？ 聊天历史难判断动作是否执行，显式状态 + 检查点可恢复、可校验前置条件。
• 追问：错误怎么分类处理？ 瞬时（退避重试）、参数错（改参重试）、权限拒绝（停止）、业务终态（不重试）、未知（先查状态）。
• 追问：响应丢失怎么办？ 不能立即重试写操作，先按请求 ID 查真实执行状态，用幂等键防重复。
• 追问：什么时候该人工接管？ 不可逆动作、权限升级、证据冲突、预算耗尽、低置信高影响决策，交接给完整状态和证据。

八、加强记忆

Agent 可靠性记「状态可恢复、错误可分类、副作用可确认、循环有硬上限、必要时能交人」：用状态机 + 检查点（可恢复，不重放全对话）、错误分类（瞬时退避/参数改/权限停/终态不重试/未知先查）、写操作幂等键（防重复副作用，补偿和回滚也是副作用）、循环硬检测（相同动作/状态哈希/重复错误码 + 最大步数，Prompt 说”别循环”不顶用）、人工接管（给完整状态证据、批准绑定参数和有效期）。用故障注入演练验证能安全恢复。

项目实战落地

项目里怎么做的

《AI Agent 智慧医院智能导诊就诊系统》的分诊 Agent 把失败处理收在一个出口，原则是「失败不污染业务」：

• 任何一步失败都走 failRun：运行记录置为「运行失败」，失败原因写进 error_message（写库前截断到 500 字），预问诊会话保持「进行中」，患者补充描述后可以在同一段会话里再点一次「发起智能分诊」；
• 工具失败即运行失败：工具执行器捕获异常后，先把这一步的步骤记录回填为「运行失败」并写上原因、推进运行的步数，再把异常抛给编排层统一收尾；
• 开跑前能拦的先拦：工具中心一个启用的工具都没有时，直接报错并提示去工具中心启用；
• 失败的运行留着：失败记录不删，和之后成功的那次一起留在运行列表里，可以对照复盘；种子数据里就有一段「刚才分诊没有成功，再帮我看看该挂哪个科」的会话，对应一条失败、一条成功的运行。

《AI Agent电商平台导购与运营增长系统》的导购也坚持如实失败：未配置模型或模型报错时，这次运行记为失败并把原因写进运行记录，不拿一段假的推荐顶上；模型提交的商品落地时一件可买的都没有，任务同样置为失败并清空旧推荐。

《AI Agent岗位匹配与求职规划系统》在开跑前先做就绪检查，六项都满足才启动 Agent：能力画像已生成并启用、目标岗位 JD 已结构化、岗位样本库有启用数据、求职知识库有已向量化的切片、启用了对话模型、启用了向量模型；缺哪项就把对应提示拼起来报错。运行中任何一步抛异常（包括工具执行失败），都由 failRun 把运行记录和分析任务一起置为「运行失败」，失败原因截到 500 字，用户处理完再点启动即可重跑。

《AI 多 Agent 长租公寓智能合租匹配平台》把失败都收进运行记录：后台执行时调度图抛出的业务异常，原因原样写进运行记录；没预料到的异常只写「调度过程中出现未预期的错误。请稍后重试……」，不把英文原文放进结论。进程被关掉、机器断电时，运行记录会一直停在「运行中」，服务启动时 recover_unfinished 把这些运行和对应的任务统一改为「运行失败」，原因写「服务重启，这次运行已经中断，请重新发起匹配」。

《AI Agent智能教务排课与教学质量分析系统》启动排课前先把一定会失败的情况拦下：任务没选模型配置或 Prompt 模板、必需工具没启用、模型配置没填全，都在清空上一次的排课明细之前报错。代码注释写明，这一步必须放在清空旧课表之前，否则「Key 没填」这种一定会失败的情况会把上一次排好的课表白白删掉。执行中任何异常都把任务置为「执行失败」，失败原因写进任务的排课方案字段，页面上看得到。

为什么这样取舍

• 会话保持进行中：失败只影响这一次运行，患者的描述还在，改完描述就能重试，不用重新开一段会话。
• 失败原因写成中文：停用聊天模型再发起分诊，页面弹的是中文错误，运行记录里出现一条「运行失败」并记下原因，恢复配置后即可重试。

面试官还会追问

• 模型给工具传了一个查不到的患者档案 ID，工具是抛异常中断，还是返回别的东西？为什么？
• 推荐科室核验通过了，但这个科室近期一个有余号的排班都没有，这次分诊怎么收尾？
• 分诊 Agent 一个工具都没调就给出了结论，系统会怎么处理？

学完《AI Agent 智慧医院智能导诊就诊系统》，上面这些追问你都会迎刃而解。