Agent 调用工具失败或陷入循环，应该如何处理？
这道题考的是 Agent 在实际生产环境中的容错能力。说白了就是：工具调用挂了，Agent 不能卡死在那反复重试把系统搞崩，更不能无脑重试把成本烧穿。
核心要掌握三点：分层保护机制、结构化错误分类、成本感知的断路器设计。
重试风暴的代价——为什么不能盲目重试
先搞清楚一件事：Agent 重试消耗的 Token 成本可能远超成功执行本身。
想象一下：用户点网页按钮没反应，狂按刷新。结果服务器收到 10 个重复请求，处理了 10 次，其中 9 次是无效的。Agent 的工具调用也是这样——第一次失败后自动重试，如果网络抖动 3 秒后才恢复，这 3 秒内 Agent 可能已经重试了 5 次。每次重试都是一次 LLM 调用加上工具执行的消耗。
一次不稳定的工具调用，可能烧掉正常执行的 200 倍费用。这不是危言耸听，重试风暴就是这么可怕。
三层防护体系——工具层、Agent层、编排层
应对工具调用失败，不能只靠单一手段。要像保险丝一样，设计逐级熔断的防护机制。
第一层：工具层重试限制
工具本身要具备重试能力，但要严格限制：
- 最多重试 3 次，不能无限重试
- 指数退避策略：1秒→2秒→4秒，给服务恢复留出时间
- 遇到 5xx 错误才重试，4xx 直接失败不用重试
第二层：Agent 层累计失败追踪
Agent 要有"失败预算"的概念：
- 追踪单次任务中累计失败次数达到 5 次，就升级处理
- 升级方式：换工具、换策略、或者直接告诉用户"这个任务暂时无法完成"
- 不能换参数无脑重试，那只会进入死循环
第三层：编排层限流和背压
系统整体要有保护机制：
- 对同一个工具的并发调用数量设上限
- 检测到大量失败时触发背压，暂时拒绝新请求
- 用队列削峰，避免瞬时流量冲垮下游服务
结构化错误分类——让 Agent 知道何时该放弃
Agent 收到工具返回的错误，不能只看"失败"两个字就决定下一步。要让工具返回结构化的错误码，让 Agent 具备"知道何时放弃"的元认知能力。
错误码设计分四类：
RETRY_LATER（可重试）
像是医生说"观察等待"。网络超时、服务器临时过载，这种情况等一等再试可能就成功了。配合指数退避，不要立刻重试。
INVALID_PARAMS（换参数重试）
像是医生说"换个药方"。参数格式错了、权限不足，修复参数后可以再次尝试。但不能一直重复同一个错误参数。
PERMANENT_FAILURE（永久失败）
像是医生说"宣告不治"。资源不存在、逻辑错误，无论怎么重试都不会成功。Agent 应该立即停止，汇报给用户。
BUDGET_EXCEEDED（预算耗尽）
像是医生说"建议转院"。已经花了很多代价但没成功，继续尝试的边际收益太低。Agent 要有"止损"意识。
可量化的监控指标——用数据驱动决策
光有防护机制还不够，要用监控指标来验证防护是否有效。核心看三个指标：
重试率
健康工具的重试率应该低于 10%。如果超过这个值，说明要么工具不稳定，要么重试策略太激进。
浪费性 Token 占比
因为重试、失败、中断而消耗的 Token，应该低于总支出的 5%。这个指标直接反映了成本控制的效果。
级联深度
单次用户请求触发的事件链长度。如果一个操作失败导致一连串重试，级联深度超过 3，说明存在系统性问题，需要排查根因。
面试怎么答
基础版（100-200字直接背）：
处理 Agent 工具调用失败，核心是分层保护加成本感知。工具层限制单次重试不超过 3 次，用指数退避 1s/2s/4s 策略；Agent 层追踪累计失败，达到 5 次就升级处理，不能换参数无脑重试；编排层实施并发限制和背压机制。关键是把错误分类为 RETRY_LATER、INVALID_PARAMS、PERMANENT_FAILURE、BUDGET_EXCEEDED 四类，让 Agent 知道何时该放弃。
加分版（展示深度理解）：
我要强调"以美元计价的断路器"设计理念——当单次工具调用的重试花费超过 0.50 美元时，必须停止重试。另外要区分工具层重试和 Agent 层重试的本质差异：工具重试是确定性调用，参数不变重试同一操作；Agent 重试是 LLM 概率决策，可能生成不同的调用参数。还要通过级联深度监控来发现系统性问题，深度 ≥3 就说明防护机制存在漏洞。
一句话总结
工具调用失败处理的核心是：分层保护控制范围，结构化错误引导决策，成本感知决定何时止损。
