Agent循环烧钱，重试上限为何拦不住

Agent 调用持续返回 200 OK，输出格式也合法，API 账单却可能一路上涨。一位 dev.to 作者以标题中约 3000 美元的账单为例，描述了 Agent 重复执行、彼此交接形成循环的问题，并提出在交接层检测消息重复。现有节选能看清方案思路，但不足以验证拦截效果。

目前能确认什么

作者区分了两种循环：单个 Agent 持续重复的 A → A → A，以及两个 Agent 来回交接的 A → B → A → B。模型每次都正常生成内容，框架也可能将交接视为成功，因此错误重试次数未必会增加。

错误重试上限，不能替代任务执行上限。

作者先尝试手动计数，随后提出在交接前序列化消息，用 SHA-256 生成哈希，检查最近三次结果：连续相同用于识别重复，首尾相同、中间不同用于识别往返。他们团队据此开发了 AgentTrafficCop，并宣称提供中断会话、webhook 通知和看板。

哈希适合判断输入是否完全一致，并不能直接判断任务有没有进展。另外，持久化的总执行次数仍可限制调用总量，只是无法单独识别循环类型；节选中的全局变量还存在恢复后计数丢失的问题。

我的判断

对程序员最直接的提醒，是检查「成功请求」有没有持续消耗预算。监控应补上单任务调用量、累计费用和状态推进情况，仅看错误率与服务存活情况不够。

哈希检测可以作为一道防线，但重复消息也可能是正常确认；内容稍作变化的循环，则可能绕过完全相等检查。最近三次记录也不足以覆盖所有更长的循环。

接入前还需确认：哈希包含哪些字段、状态能否跨恢复保留，以及抛出的 422 是否会被编排器再次重试。如果中断信号又触发重试，费用风险就没有真正闭合。