AI Agent 死循环怎么测：重复工具调用、状态停滞和预算上限要分开防

Agent 的失败不一定是异常退出。更危险的情况是它一直“正常”运行：反复搜索同一个关键词、对同一份文件重复修改、在两个工具之间来回切换，或者不断生成新计划却没有改变任务状态。只设置最大步数，能限制损失，却不能解释为什么卡住。

先定义什么叫没有进展

可以把一次工具调用拆成工具名、归一化参数、目标资源、返回摘要和状态变化。连续多次调用的这组信息高度相似，且任务状态没有新增事实、文件没有变化、审批没有推进，就应标记为状态停滞。对会自然重复查询的任务，不能只看工具名，需要加入时间窗口、结果哈希和业务进度字段。

一个实用的状态指纹包含当前任务节点、最近几次工具调用、关键资源版本和待办集合。指纹连续重复时触发软警告；重复达到阈值后暂停自动执行，让系统先总结当前状态。这样比直接杀掉进程更容易保留可恢复证据。

四道保护要分层

第一道是单步预算，限制一次请求最多消耗多少 token、工具次数和时间。第二道是任务预算，防止 Agent 通过新建子任务绕过单步限制。第三道是循环检测，识别重复和来回振荡。第四道是熔断与人工接管，保存最后状态、已执行动作和下一步建议。

测试时要专门制造空结果、矛盾结果、权限拒绝、工具超时和返回格式变化。好的系统不只是停止，还应说明触发了哪条规则、哪些动作已经完成、是否可以安全重试。

如果需要在多个模型上复现同一组 Agent 行为，可以让 top-api.cc 统一路由和记录请求摘要，再把工具调用状态指纹放在业务执行器中。这样能区分模型策略变化和执行器本身没有推进的问题。

测评指标

• 循环发现时间和误报率；
• 已产生的 token、工具次数和费用；
• 熔断后状态是否可恢复；
• 重试是否会重复执行副作用；
• 人工接管时能否看懂上下文；
• 不同模型和温度下规则是否稳定。

GitHub 上的 loopbuster 等项目把循环检测、预算上限、状态停滞和断路器作为独立能力，说明这个问题不应只交给提示词解决。生产系统仍应按自己的工具和状态模型设计阈值。

参考资料：loopbuster 项目、OWASP 关于过度代理权限的风险说明。循环检测日志应避免保存不必要的敏感正文。

要把循环样本变成跨模型回归测试，可以从 top-api.cc 的统一 API 入口开始，给每次执行绑定任务 ID 和预算记录。