凌晨两点收到告警：Agent 一夜之间跑了 4000 多步，账单从每天十几块跳到三百多。打开日志一看，它从晚上十点开始反复调用同一个查询接口，参数一模一样，只是因为接口返回了一条它「不太满意」的数据。这不是模型变笨了，而是整套链路里没有一个地方负责说「停」。
死循环是 Agent 上线后最常见、也最贵的一类事故。它不像报错那样显眼——报错会中断，死循环会一直「看起来在努力工作」。本文把这件事拆成四步讲：先认清死循环长什么样，再做循环检测，然后设预算熔断，最后补终止条件和降级兜底。
死循环长什么样：四种典型形态
形态一：工具重试循环。同一个工具、同一组参数被反复调用。根因通常是工具报错后无脑重试，或者返回结果不满足模型的预期，模型就换个说法再试一次，而实际上参数没变、结果也不会变。
形态二：状态漂移循环。Agent 在 A 和 B 两个状态之间来回横跳：查了库存去查价格，查完价格又回查库存，每一步都合情合理，合起来就是原地转圈。这类循环最难发现，因为它每一步看起来都在做正事。
形态三：自我否定循环。模型对自己的输出不满意，反复重写；或者带着一堆「上次做得不够好」的反思重新执行，但没有客观判据，于是永远不满意。这在加了反思机制的 Agent 上特别常见。
形态四：多 Agent 互相等待。拆分任务的多个 Agent 之间，谁都以为对方在做，或者互相 ping 个没完。这类坑在站里 多 Agent 协作避坑清单 里有更细的展开，核心原因是「任务归属」没写清楚。
为什么会有死循环：三个根因
把上面四种形态往回推，根因就三个：没有终止条件（没人定义什么叫「做完了」）、没有幂等保证（重试一次就多一次副作用，出错了只能再试）、没有预算上限（跑多久、花多少钱没人管）。三个根因对应三层防线，缺一层都不安全。
第一步：循环检测——给每一步打指纹
检测的核心思路是：把「刚才做过的事」压缩成一个指纹，每走一步就和历史指纹比一次。三层手段从粗到细：
精确指纹——用「工具名 + 参数序列化后的哈希」做指纹。连续两次完全一致就记账，连续三次就直接拦下。这一层能抓住绝大多数工具重试循环，实现成本最低，务必先做。
状态指纹——不只比单步，比「整体进度」：把「任务目标 + 已完成的子任务集合」做哈希。如果这个哈希重复出现，说明 Agent 在同一个进度上打转，属于形态二。这一层比精确指纹更有效，因为它能识别「换了说法但没换事」的循环。
语义指纹——把相邻几步的动作描述做一次相似度比较，超过阈值就算重复。这一层抓形态三，成本最高，通常只在长任务上开。
检测到之后别直接杀进程，按「第一次告警、第二次强制换策略、第三次终止」的阶梯处理。第一次可能是偶发，直接终止会误杀正常任务。
第二步：预算熔断——四道闸门
检测是「发现问题」，熔断是「兜住下限」。四道闸门都要设，任何一道先到就先熔断：
步数上限——按任务类型给值：单轮问答类 5-10 步，检索整理类 20-30 步，长流程自动化 50-100 步。超过上限 1.5 倍不告警，超过 2 倍直接停。时间上限——单次任务 10 分钟、单日累计 2 小时这类硬上限，防止定时任务串起来互相拖。Token 与金额上限——按单任务和单日两个粒度设，金额上限比 Token 上限更直观，具体算法和节省手段见 AI Agent 成本控制清单。高危工具调用次数上限——发邮件、下单、删文件这类有副作用的工具，单独限死次数，比如每次任务最多 3 次。
熔断不等于硬停。硬停会让任务半途而废、留下一堆中间状态；正确做法是走降级阶梯（见第四步）。
第三步：终止条件——三个判据缺一不可
大多数死循环的真正源头不是检测没做，而是从来没写过「什么算完成」。终止条件必须写三条：
成功判据——什么状态算做完了。要可验证，比如「订单状态字段等于 shipped」，而不是「任务处理得比较好」。失败判据——什么情况算做不成，比如「连续三次工具报错」「关键字段缺失」；失败判据触发后按 AI Agent 失败升级规则 决定重试、暂停还是转人工。放弃判据——到达预算上限就放弃，并且要明确放弃后输出什么（一份说明现状的报告，而不是一句「我失败了」）。
这三条判据和 AI Agent 长时任务设计 里讲的检查点是一套东西：长任务必须在每个检查点明确「继续还是收工」，否则越跑越远。
第四步：降级兜底——熔断之后怎么办
熔断后按阶梯降级，每一步都比上一步更保守：换策略重试——同样的目标、换一条路径（换工具、换参数粒度、拆成更小的子任务），只允许一次；换模型再试一次——用推理更强的模型重新规划一次，只允许一次；冻结并转人工——把任务挂起，生成一份「卡在哪、试过什么、需要人做什么」的说明，投进 转人工队列。
无论走到哪一步，都要保留完整现场：每一步的输入输出、工具返回、指纹记录、熔断原因。这就是 AI Agent 证据包 的价值——事后复盘时，你需要的不是最后那段漂亮的总结，而是「它究竟在第几步开始打转」。日志本身的结构和字段怎么设计，参考 审计查询字段设计 和 OpenClaw 日志与排错。
一套可直接落地的组合方案
把四步串起来就是一条完整的防线：入口处写清三条终止判据；每一步算精确指纹，每三步算一次状态指纹；计数器同时盯着步数、时间、Token、金额和高危工具次数；触发任一上限就走「换策略 → 换模型 → 转人工」的降级阶梯；全程落盘指纹、日志和证据包。上线前按 AI Agent 质量门禁 的方式，用一组「故意会失败」的测试任务压一遍，确认熔断真能触发、降级真能走通。
五个常见坑
坑一：只在工具层设了重试上限。工具重试三次就放弃，但 Agent 层可以继续发起新的重试，总次数照样爆炸——两层都要设。坑二：没有幂等，重试产生副作用。重试是循环控制的常用手段，但如果发邮件、下单这类动作不幂等，重试一次就多一次真实后果。工具设计时就要考虑幂等，参见 AI Agent 工具怎么设计。坑三：把步数上限当万能药。有些任务两步就能烧掉大钱（比如每步都在读一篇长文档），只盯步数没用。坑四：日志不留指纹。事后翻日志只能看到一堆调用记录，看不出「哪一步开始重复」，等于没留证据。坑五：检测到循环却没人知道。没有告警通道，循环还是靠自己发现——要接到监控里，具体做法见 OpenClaw 怎么监控服务器。
适合人群
适合：正在跑定时任务、长流程自动化的开发者；被 Token 账单教育过一次的团队；以及负责给 Agent 定运维规则的负责人。不适合：只做单轮问答、没有任何工具调用和循环结构的场景——那连循环都没有，不需要这套东西。
总结
AI Agent 死循环治理，一句话记法：先写终止判据，再算循环指纹，然后设四道预算闸，最后备好降级阶梯。核心心法：死循环不是模型的锅，是工程约束没铺到位——模型只会一直尝试，是「人」需要告诉它什么时候必须停。把这条防线建起来，你省下的不只是钱，还有半夜被账单叫醒的那种心情。
