Claude Code或智能体给每个工具调用设明确的失败路径，很重要！
「让 agent 自己决定怎么重试」是生产环境最危险的设计。如果你一个小功能执行了很长时间，浪费了很多token，大概率就是在无效重试了。这本质上是因为没有给失败定义出口。

1. 重试循环是最隐蔽的死亡模式
最常见的 agent 特有失败模式：工具调用报错 → agent 原样重试 → 还是报错 → 再重试。整个过程 agent 不说话，任务返回看起来像在跑，实际上它在用完全相同的参数一遍遍重复同一个失败的调用。
通常要等到账单来了才会发现，或者几小时后下游任务给出错误结果时才察觉——而这时候已经连续失败了几十次了。

2. 四个必须在架构层定义的机制
1）每个 tool call 必须有重试上限 + fallback 行为，而不是开放式循环。重试 3 次还没成功，就触发 fallback（降级处理、跳过、或转为人工审批），而不是继续重试。
2）熔断器（Circuit Breaker）：连续 N 次违规（报错/超时/超 token）后，自动停止所有 LLM 调用，等人工来 reset。这是防止花费大量token 的最后一道防线。开源库 agent-cost-guardrails 就是做这个的，纯 Python，零基础设施，可以直接挂进 CrewAI / AutoGen / LangGraph。
3）Human-in-the-loop 关卡要提前定义，不能让 agent 自己判断「这件事要不要问人」。正确做法是：列出哪些操作类型必须经过人工确认（比如写入生产数据库、发送外部通知、超过一定金额的操作），在架构里硬编码这些关卡。
4）每个 agent 的决策要可追溯：哪个 agent、调用了哪个工具、传了什么参数、返回了什么、为什么做这个决定——完整的 trace。如果你做不到这一点，生产环境 debug 就是考古——找到一堆 error log，但不知道哪个是根因。

3. 核心设计原则
1）不要让 agent 决定如何从自己的错误中恢复。这是一个没有出口的控制循环。
2）重试、路由、失败恢复——这些逻辑必须在 agent 上层的 orchestration 层实现，不能依赖 agent 自己判断。agent 只负责执行，异常处理交给架构层管。

#HOW I AI# #程序员#