感谢与更新：使用回合级滑动窗口哈希修复CrewAI中的代理重试循环

几天前，我在论坛上发帖询问大家如何捕获陷入重试循环的代理，以免它们耗尽整个API预算。特别感谢所有提供宝贵见解的朋友们。基于这些反馈，我对TokenShield（我的开源FastAPI网关代理，位于LLM客户端与提供商之间）进行了重构。为了测试更新，我运行了一个本地CrewAI测试脚本，该脚本中一个代理在失败的数据库工具上陷入循环（max_iter=10），非常顽固。在没有防护的情况下，代理盲目地连续10次调用该工具。由于每次重试都会将聊天历史追加到提示上下文中，提示token从第1轮的约139个token膨胀到每轮近600多个token——在死胡同执行中浪费金钱。以下是更新后的网关流程现在在网络层处理这种情况的方式： 每回合哈希窗口：它严格在当前回合内跟踪标准化签名（去除时间戳和UUIDS噪声），从而完全避免误报阻塞后续的合法重试。 第一层软引导：如果检测到停滞，它会注入系统重新规划指令，然后才终止请求。 第二层硬停止：如果代理仍然坚持，它会触发干净的429截断，立即停止令牌流失。 对于在CrewAI或其他框架中运行多代理工作流的任何人而言，将哈希作用域限制在每回合，可以使断路器保持锐利，同时在大额账单到来前切断失控的token计数。如果你想查看源代码、日志或自行测试，我已在评论区放上了GitHub链接，以保持本帖整洁。很想知道是否有人在使用复杂代理图的滑动窗口时遇到过其他边界情况。