Agent 故障恢复设计：重试、降级和人工接管的执行顺序

Agent 发生失败时，最危险的默认动作是“再试一次”。网络短暂抖动或限流确实值得重试，但参数校验失败、权限被拒绝、工具语义不确定和可能已经写入的超时，重复执行只会放大影响。可靠恢复必须先分类，再选择恢复路径。

可以从四个问题开始判断：错误是否暂时性、外部副作用是否幂等、输入是否仍然有效、继续执行的风险是否可接受。四个答案决定的不是一条重试次数，而是一张有优先级的恢复表。把这张表写在运行时策略中，而不是藏在模型提示词里。

建立可执行的错误分类

一个实用分类包括：TRANSIENT，如连接重置和可恢复的 429；DEPENDENCY_UNAVAILABLE，如下游长期不可用；VALIDATION，如参数不符合工具 schema；AUTHORIZATION，如 scope 不足；AMBIGUOUS_SIDE_EFFECT，如请求超时但无法确认下游是否已写入；以及 POLICY，如超预算或违反合规策略。

其中最需要谨慎的是 AMBIGUOUS_SIDE_EFFECT。不能因为没有收到响应就再发一次创建订单或发送邮件。正确顺序应是先用幂等键、查询 API 或审计事件确认结果；确认成功则推进状态，确认未发生才考虑受控重试，确认不了则升级人工处理。

恢复顺序应从最小风险开始

对于可证明无副作用的瞬时错误，可以采用有限次数的指数退避并加入随机扰动，避免大量 Agent 同时冲击恢复中的依赖。每次重试前重新检查取消标记、预算和租户配额，不能让旧任务在系统恢复后一次性爆发。

若依赖不可用，先降级到缓存结果、只读模式、排队等待或返回部分结论。降级不是把错误藏起来，而是明确告诉调用方哪些部分没有验证。对于检索 Agent，可以返回已有证据并标记新鲜度；对于写操作 Agent，则更应该停止而不是猜测。

参数校验和授权错误通常不该自动重试。它们需要重新规划、补充输入或由有权限的人确认。让模型反复生成同一个非法工具调用会浪费成本并污染上下文。执行器应把确定性错误结构化返回给规划层，例如缺少字段、可选值范围和所需 scope，而不是只返回自然语言报错。

定义明确的人类接管条件

人工接管不应成为所有未知错误的垃圾桶。为它设置可操作条件：副作用状态无法确认、连续失败超过阈值、预算即将耗尽、涉及高风险资源、证据冲突或策略要求人工判断。接管工单应带上运行 ID、最后稳定检查点、已执行副作用、错误分类、建议选项和所需权限。

人工处理完成后，结果也要回写为状态转移，而不是在聊天工具里一句“处理好了”。这样系统才能学习哪些错误经常需要升级，并把可自动化的部分逐步固化为策略。

用演练验证恢复不会伤害用户

预发布环境至少演练四种故障：工具返回 429、工具执行后连接断开、用户权限在等待期间被撤销、模型产生不合法参数。记录每种情况下的重试次数、外部调用次数、最终状态和人工介入时间。成功标准不是任务一定完成，而是在任何失败路径上都没有未解释的副作用。

当恢复策略有数据后，再调整退避、阈值和降级范围。没有观测数据的“自动恢复”常常只是自动重复错误。

让恢复策略有可观测的止损线

每一种错误分类都应有指标：尝试次数、首次失败到恢复的时长、幂等查询命中率、降级比例、人工接管比例和最终副作用确认率。只看“任务成功率”会掩盖大量危险重试，例如一个订单 API 被调用三次但最终只返回一次成功。

对高风险工具设置硬止损：达到最大不确定副作用数、连续策略拒绝数或单租户错误预算后，新的任务只允许进入人工队列。告警内容应携带错误分类、依赖名称、run ID 和最近一次安全检查结果，不能只发一条“Agent 失败”。当团队能从告警直接判断该重试、降级还是暂停，恢复策略才真正减少了事故响应时间。

每次故障演练结束后，把实际路径与策略版本一并归档。只有能复盘“为什么停止”和“谁确认继续”的恢复流程，才值得在更高风险的工具上复用。

延伸阅读

• MCP 超时、重试与幂等
• LLM SLO 监控
• LLM 灾难恢复