如果你的 Agent 死循环了第一反应是加个最大迭代次数那这篇可能会给你一些帮助。大多数循环不是工具调用失败——是终止条件没设计对。下面三个反模式出现的频率最高。反模式 1用字符串匹配代替语义判断验证 Agent 路由函数用正则is_pass: true匹配模型输出里有没有这个字符串——只要匹配上就跳出循环。这个反模式会导致死循环。触发原因是模型输出前面有一段参考文本里面恰好也包含一个{is_pass: true, ...}的 JSON 块。路由函数截到了前面那块判为通过模型又生成一段包含is_pass: false的真实判断路由函数又判为不通过。Agent 在两个状态之间反复横跳跑多少次都没收敛。更隐蔽的同类问题是用正则匹配模型输出里的 JSON 字符串然后塞给路由函数。我自己在第一次做 ReAct Agent 的时候就这么干过——匹配第一个{到最后一个}的内容看起来很稳但模型经常在前面加好的结果如下或者输出里夹杂嵌套 JSON。修复的方向很明确用 Pydantic 解析 字段值判断。先json.loads再读is_pass字段值Pydantic 解析失败的统一走兜底分支重试或熔断绝不能让字符串匹配当路由依据。反模式 2单 Agent 步数限制 ≠ 跨 Agent 总步数在mutil-agent架构中每个sub Agent 都设了最大迭代次数50看起来很安全。但 A2A 协议下 A → B → C 的递归调用不共享步数计数器——系统实际跑了 150 步还没收敛。多 Agent 协作下最大迭代次数膨胀了。修复方式是在 Agent 逻辑之外记录总步数、总 token、总 API 成本任一指标超阈值就熔断整个调用链。LangChain AgentExecutor 提供一个更朴素的实现early_stopping_methodforce强制停止不是让 LLM 自己决定停止。这个配置项我每次写 Agent 都会设——它的作用是达到最大迭代次数后不再让 LLM 做决定直接抛出超时错误避免 LLM 在最后一刻自我赦免继续调用。但这只解决单 Agent 内的步数。跨 Agent 的真正解法是Budget Circuit Breaker——一个独立于 Agent 进程之外的、无法被业务代码绕过的成本边界比如按美元计费或者按 token 计费。反模式 3只用结构检测不用信息增益检测IBM 团队 ICPE 2026 论文把循环检测分成三类结构检测当前 action 字符串是否等于上一个F1 0.08。几乎没用。语义检测当前 action 的 embedding 与前 N 个 action 的相似度F1 0.28。混合检测结构 语义 状态哈希F1 0.72。结构检测为什么这么差因为 Agent 经常在看似不同实则相同的工具间反复横跳——比如web_search(Cybertruck 续航)→web_search(Cybertruck 电池容量)→web_search(Cybertruck range)三个 action 字符串完全不同但语义上都在搜索同一个东西。结构检测一个都抓不到。更主要的问题是信息熵没变化——Agent 调了工具、得到了结果但这个结果对最终答案没有任何信息增益工具结果没有任何作用。这种循环从结构上看完全合法但本质上是空转。为了解决这个问题我们可以利用以下三层来做循环检测动作 key 哈希结构层f{tool_name}:{json.dumps(params, sort_keysTrue)}用 deque 保留最近 5 步。5 步全等 → 死循环。状态哈希语义层把当前 message 列表做 hash 跟上一轮对比。一致 → 空转强制终止。这一层比动作哈希更宽松但更准。LLM 自身反思语义层兜底每 5 步问一次 LLM你觉得自己是不是在循环让 LLM 自己判断。但 LLM 这层不可靠必须有上面两层兜底。用deque(maxlen5)加动作哈希是最小实现能盖住 60% 场景。剩下 40% 要靠状态哈希 LLM 反思。推荐做法always 设early_stopping_methodforce。超过了阈值直接熔断路由函数用 Pydantic 解析 字段判断。不要用字符串匹配、不要用正则截取 JSON。这条单独写进团队的 code review checklist。加 Budget Circuit Breaker。熔断逻辑放在 Agent 进程之外监控告警不能当拦截。动作哈希 状态哈希双层循环检测。结构检测 F1 太低单用没用。log every iteration。Agent 死循环的事故复盘 90% 的价值来自日志——能看清每一步的 action、参数、返回结果。