你的智能体为什么总在原地打转？

一个搜索航班的工具，能让AI调用14次还停不下来——而修复后只需要2次。这不是算法不够聪明，是我们在设计工具反馈时，埋了一个自己都没意识到的陷阱。

847步推理，每分钟烧掉47美元

Particula社区去年记录了一个极端案例：某智能体执行了847步推理，每分钟成本47美元，最终没有输出任何答案。它不断精炼逻辑、质疑结论、请求更多数据，陷入死循环。

CodiesHub年底的分析指向同一个根源：模糊的工具反馈。当工具返回"可能还有更多结果"这类开放式提示，智能体会将其解读为"再试一次就能更好"，于是用相同参数重复调用。

问题不在于智能体"想太多"，而在于它接收的信号没有明确的终止边界。每一次"再试一次"的决策，在当时看来都是合理的局部最优。

Strands的拦截方案：在调用发生前刹车

Strands Agents提供了一套生命周期钩子（Hook）机制。Debounce Hook监听BeforeToolCallEvent事件，在工具实际执行前检测重复调用：

具体实现上，系统会检查当前调用与近期调用是否在参数、工具类型、上下文状态上高度重合。如果判定为无效重复，直接拦截并返回预设的终止信号，而非让智能体继续消耗token。

这套模式不绑定特定框架。LangGraph、AutoGen、CrewAI等支持生命周期钩子的智能体系统，都可以移植相同的逻辑。

从14次到2次：关键在"成功状态"的定义

原文演示了对比实验：模糊工具反馈导致14次重复调用，而明确定义SUCCESS状态后，智能体在2步内停止。

差距不在智能体的推理能力，而在工具接口的设计契约。当"完成"的标准清晰可判定，智能体就不需要靠"再试一次"来确认。

这引出一个被忽视的设计原则：智能体的可靠性，很大程度上取决于它调用的工具是否具备自描述的终止语义。不是告诉它"可能还有"，而是明确"这就是全部"。

框架无关的三层防御

基于AWS提供的开源代码（github.com/aws-samples/sample-why-agents-fail），可归纳出三层通用防御：

第一层，防抖钩子（Debounce Hook）。在工具调用前拦截重复请求，适用于参数级完全重合的场景。

第二层，清晰的工具状态返回。用SUCCESS、FAILED、PARTIAL等枚举值替代自然语言的模糊暗示，消除智能体的过度解读空间。

第三层，硬性的调用次数上限。作为最后保险，无论智能体如何判断，达到阈值强制终止并返回当前最佳结果。

这三层从"预防—信号—保险"三个环节压缩了循环发生的可能性。

为什么这事现在值得重新关注

智能体从demo走向生产环境，token成本从"实验损耗"变成"运营支出"。The Decoder今年1月的研究指出：即便算力无限，过度推理也会导致决策质量下降——每一步额外推理都在放大初始理解的偏差。

这意味着循环问题不只是浪费钱，还会输出更差的结果。一个永远在"再优化一下"的智能体，可能比及时止损的版本给出更离谱的答案。

对于正在搭建智能体系统的团队，工具接口的设计规范可能比选什么模型更影响最终体验。你的工具返回给智能体的，是明确的终点，还是一张无限续杯的邀请函？