AI Agent 停不下来：无限循环为什么会把一次请求放大成成本和风险

很多人第一次使用 AI Agent 时，最关心的是它够不够聪明：能不能规划步骤，能不能调用工具，能不能根据中间结果继续行动。

但当 Agent 真的开始持续行动，一个新问题会出现：它能不能在该停的时候停下来？

arXiv 论文《When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents》正是研究这个问题。论文提出 Infinite Agentic Loops，简称 IALs，用来描述 LLM Agent 在规划、工具调用、状态更新、工作流转移和多 Agent 协作中出现的重复执行问题。

这不是普通程序员熟悉的 while true。它更像一个运行时系统问题：模型觉得还需要继续，工具返回又触发下一轮判断，框架把状态写回上下文，另一个节点再次调用模型，错误处理逻辑又进入重试。每一步看起来都合理，但组合起来，系统停不下来。

为什么 Agent 会停不下来

一个典型 Agent 工作流大概包含几类动作：

• 规划下一步；
• 调用搜索、数据库、浏览器、文件系统、代码执行器等工具；
• 根据工具结果更新状态；
• 判断任务是否完成；
• 如果没完成，继续下一轮。

这个结构本身没问题。Agent 之所以有用，正是因为它可以观察中间结果，然后继续调整行动。

问题出在边界不清。

例如，一个 Agent 被要求“修复这个接口问题”。它先跑测试，测试失败；它修改代码，再跑测试；测试仍失败；它尝试安装依赖；依赖报错；它改配置；配置又触发新的错误；它继续生成修复。每一步都像是在推进任务，但如果没有最大步数、最大成本、最大重试次数和人工确认，它可能一直做下去。

再比如，一个客服 Agent 被要求“帮用户跟进订单”。它查询订单失败，于是重试；重试失败后创建工单；创建工单后发送通知；通知接口返回不确定状态；它再次创建工单或再次发送通知。最后，用户可能收到多封消息，后台出现重复记录，账单里也多了大量模型调用。

Agent 的循环失控通常不是单点错误，而是反馈路径没有被约束。

这和多 PR 风险有什么不同

昨天我们讨论过 AI 编程 Agent 在持久代码库里的长期风险：一个 Agent 可能跨多个 PR 留下看似无害的改动，最后组合成更大的问题。

今天的 Infinite Agentic Loops 是另一类风险。

多 PR 风险发生在代码库演进过程中，时间尺度可能是几天、几周，重点是“改动如何累积”。

无限 Agent 循环发生在运行过程中，时间尺度可能是几秒、几分钟、几小时，重点是“反馈如何反复触发行动”。

两者都说明同一件事：AI Agent 不是一次性回答器。只要它能保存状态、调用工具、继续行动，就必须有对应的审查和边界设计。

论文具体看了什么

论文把 IALs 定义为一类由 Agent 逻辑、框架语义、运行时观察和终止机制共同造成的失败模式。它们可能反复到达昂贵或会增长状态的操作，例如：

• 模型调用；
• 工具调用；
• 工作流节点跳转；
• Agent 之间的 handoff；
• 上下文或记忆写入；
• 外部系统副作用。

作者提出了一个名为 IAL-Scan 的静态分析工具。它先把不同框架、不同写法的 Agent 项目抽象成框架无关的 Agent IR，再构建 Agentic Loop Dependence Graph，用来识别显式或框架诱导的反馈路径。最后，它检查这些路径是否可能在缺少有效边界的情况下反复触达高成本或状态增长操作。

根据论文摘要，IAL-Scan 在 6,549 个 LLM Agent 仓库上报告了 74 个潜在 findings，人工复核确认了 68 个 IAL failures，涉及 47 个项目，precision 为 91.9%。

这些数字不能直接说明所有 Agent 项目都有严重问题，但它们足以提醒工程团队：循环失控不是想象中的边缘情况，而是现实项目里已经能找到的模式。

哪些 Agent 最容易出问题

第一类是自动修复型 Agent。

这类 Agent 会跑测试、读日志、改代码、再跑测试。它最容易把“失败”理解成“继续尝试”，如果没有上限，就会在错误栈、依赖安装、环境配置和测试重试之间来回转。

第二类是多工具办公 Agent。

它可能同时接入邮件、日历、表格、CRM、工单和即时消息。如果某个工具返回不确定状态，或者一个动作触发另一个动作，很容易出现重复通知、重复创建记录、重复修改状态。

第三类是多 Agent 协作系统。

一个 Agent 把任务交给另一个 Agent，另一个 Agent 又因为信息不足交回去，或者继续请求第三个 Agent。handoff 如果没有终止条件，就可能变成系统内部的循环转发。

第四类是带长期记忆或状态更新的 Agent。

如果每一轮都把观察写进记忆，而下一轮又根据记忆继续生成更多观察，系统可能出现上下文持续增长。即使没有外部副作用，成本和延迟也会被放大。

第五类是工作流编排 Agent。

很多企业系统会把 Agent 接到流程引擎里：节点 A 调模型，节点 B 调工具，节点 C 判断状态，节点 D 回到 A。只要条件判断写得不严谨，就可能让整个流程重复跑。

怎么给 Agent 加护栏

最简单的护栏是预算。

每个 Agent 任务都应该有最大模型调用次数、最大工具调用次数、最大运行时间和最大 token 成本。预算不是体验上的限制，而是运行时安全边界。

第二个护栏是超时。

只要任务超过设定时间，就应该进入“暂停并请求人工确认”的状态，而不是继续自动尝试。尤其是修复、部署、外部通知和支付相关流程，不能无限等待和重试。

第三个护栏是幂等和去重。

如果 Agent 会创建工单、发送消息、写数据库或触发 API，就必须有幂等键、重复检测和状态确认。不能因为模型不确定“刚才有没有成功”，就再执行一次外部动作。

第四个护栏是外部副作用确认。

读数据、总结文本、生成草稿可以自动化程度高一些；发送、删除、付款、改权限、部署、批量写入这类动作，应该有人工确认或更严格策略。

第五个护栏是可回放日志。

当 Agent 出问题时，团队需要知道每一轮模型看到了什么、调用了什么工具、工具返回了什么、为什么继续下一步。没有日志，循环失控只能事后猜。

第六个护栏是明确的完成条件。

不要只写“直到任务完成”。要把完成条件具体化：测试通过、某个字段存在、某个状态码返回、某个人确认、某个文件生成、某个指标达标。完成条件越模糊，Agent 越容易把“还可以继续优化”当成“必须继续执行”。

给小团队的一份检查表

如果你的团队正在接入 AI Agent，可以先问下面这些问题：

• 这个 Agent 单次任务最多能跑几步？
• 单次任务最多能花多少钱？
• 哪些工具调用会产生外部副作用？
• 外部副作用有没有人工确认？
• 重试逻辑最多重试几次？
• 如果工具返回不确定状态，Agent 是停止还是继续？
• Agent 是否会把每一轮观察都写进长期记忆？
• 上下文增长有没有上限？
• 多 Agent handoff 有没有最大次数？
• 失败时能不能生成可读的执行报告？

这些问题不复杂，但很多原型项目会漏掉。原因也很简单：demo 阶段大家关心“能不能跑通”，上线阶段才会发现“跑通以后能不能停住”更重要。

普通用户怎么判断一个 Agent 靠不靠谱

普通用户不一定能看到底层代码，但可以观察几个产品信号。

第一，看它是否会在关键动作前确认。

如果一个 Agent 要发邮件、改文件、提交表单、删除数据、调用付费接口，它应该明确告诉你将要做什么，并让你确认。

第二，看它是否会说明执行范围。

可靠的 Agent 会告诉你它会尝试几步、用哪些工具、什么时候停止。只说“我会一直努力直到完成”的 Agent，听起来积极，实际上不够工程化。

第三，看它是否会保留过程记录。

复杂任务完成后，你应该能看到执行摘要：查了哪些来源、调用了哪些工具、遇到哪些失败、最终结果如何验证。

第四，看它失败时是否会停止并解释。

好的 Agent 不应该把每个失败都变成下一轮无休止尝试。它应该在不确定时停下来，说明卡在哪里，需要你补什么信息。

Kunpeng AI 的判断

AI Agent 的下一阶段，不只是更强模型，也不是更多工具，而是更可靠的运行时控制。

一个 Agent 如果没有预算、没有超时、没有终止条件、没有外部副作用保护，就算短期 demo 很惊艳，也不适合处理重要任务。

反过来，一个看起来没那么炫的 Agent，如果能清楚说明执行边界，能在失败时停下来，能让人复查每一步，反而更接近可长期使用的工作系统。

所以，今天这篇论文给普通团队的提醒很朴素：不要只问 Agent 会不会做事，还要问它会不会停下来。

参考来源

• arXiv: When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents
• arXiv HTML: When Agents Do Not Stop: Uncovering Infinite Agentic Loops in LLM Agents
• 相关阅读： AI 编程 Agent 的新风险：为什么只看单个 PR，可能发现不了长期问题
• 相关阅读： HyperTool：AI Agent 调工具，为什么不一定要一步一步来