news 2026/7/1 17:31:46

Agent死循环了怎么办?

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
Agent死循环了怎么办?

如果你的 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_method="force"强制停止(不是让 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 调了工具、得到了结果,但这个结果对最终答案没有任何信息增益(工具结果没有任何作用)。这种循环从结构上看完全合法,但本质上是空转。

为了解决这个问题,我们可以利用以下三层来做循环检测:

  1. 动作 key 哈希(结构层):f"{tool_name}:{json.dumps(params, sort_keys=True)}",用 deque 保留最近 5 步。5 步全等 → 死循环。

  2. 状态哈希(语义层):把当前 message 列表做 hash 跟上一轮对比。一致 → 空转,强制终止。这一层比动作哈希更宽松但更准。

  3. LLM 自身反思(语义层兜底):每 5 步问一次 LLM"你觉得自己是不是在循环?",让 LLM 自己判断。但 LLM 这层不可靠,必须有上面两层兜底。

deque(maxlen=5)加动作哈希是最小实现,能盖住 60% 场景。剩下 40% 要靠状态哈希 + LLM 反思。

推荐做法

  1. always 设early_stopping_method="force"。超过了阈值直接熔断

  2. 路由函数用 Pydantic 解析 + 字段判断。不要用字符串匹配、不要用正则截取 JSON。这条单独写进团队的 code review checklist。

  3. 加 Budget Circuit Breaker。熔断逻辑放在 Agent 进程之外,监控告警不能当拦截。

  4. 动作哈希 + 状态哈希双层循环检测。结构检测 F1 太低,单用没用。

  5. log every iteration。Agent 死循环的事故复盘 90% 的价值来自日志——能看清每一步的 action、参数、返回结果。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/7/1 17:28:50

盘锦一年级近视防控先问清什么

一年级刚开学不久,很多盘锦家长会发现一个变化:孩子写作业时头越来越低,看绘本离得很近,偶尔还会揉眼、眯眼;有的孩子放学回家说“黑板有点看不清”,家长心里一下就紧张了。这个阶段,孩子学习用…

作者头像 李华
网站建设 2026/7/1 17:26:51

参考平面分割对模拟信号叠加畸变影响与整改规范

混合信号四层板、六层板设计中,大量模拟信号叠加失真、噪声异常问题,根源并非外部干扰,而是地平面、电源平面不合理分割造成回流路径断裂,信号回流被迫绕行拉长环路面积,催生额外感应噪声并与原始信号叠加,…

作者头像 李华
网站建设 2026/7/1 17:26:46

C++ SOLID 原则(下):接口隔离与依赖倒置

C SOLID 原则(下):接口隔离与依赖倒置 承接上文,我们将深度解析SOLID原则的最后两个核心支柱——接口隔离原则(ISP) 和依赖倒置原则(DIP)。 如果说SRP(单一职责&#x…

作者头像 李华
网站建设 2026/7/1 17:25:37

企业微信响应时效优化:基于SCRM超时提醒机制的自动化预警方案

在企业微信私域运营与客户服务架构中,“响应时效性”是决定流量转化率的核心指标。然而在实际业务中,常因高并发咨询、消息被顶或员工忙碌等原因导致回复延迟,造成商机流失。传统的人工抽查与主管催办模式效率低下且难以形成闭环。本文基于一…

作者头像 李华
网站建设 2026/7/1 17:25:29

机制一:边界守卫(Guardrails)——让 AI 在正确阶段做正确的事

在 AI 工作流中,很多人最容易忽略的一个问题是:AI 太“积极”了。你问它一个问题,它往往会立刻给出答案;你提出一个想法,它马上开始补方案;你随口问一句“这个功能大概怎么实现”,它可能下一秒就…

作者头像 李华
网站建设 2026/7/1 17:24:38

WorkshopDL:革命性Steam创意工坊下载器的技术架构与实战指南

WorkshopDL:革命性Steam创意工坊下载器的技术架构与实战指南 【免费下载链接】WorkshopDL WorkshopDL - The Best Steam Workshop Downloader 项目地址: https://gitcode.com/gh_mirrors/wo/WorkshopDL WorkshopDL作为一款专业的Steam创意工坊下载工具&#…

作者头像 李华