Agent 循环没有刹车,会自己烧钱1×0:006:520:08开场0:30事件播报1:46技术拆解3:40工程意义5:04落地建议6:22收尾0:08主播过去二十四小时里,我没有看到足够扎实、能单独撑起一期的一手 Agent Loop 工程动态。所以今天把窗口扩大到近一周,讲一篇七月二日提交到 arXiv 的论文:When Agents Do Not Stop。它关心的问题很直接,Agent 不是不会停,而是很多时候,停下来的刹车根本没有装在真正的反馈路径上。0:30主播这篇论文把这类故障命名为 Infinite Agentic Loops,可以翻成无限 Agent 循环。作者说,它不是普通代码里的 while 死循环,而是模型输出、工具结果、状态更新、工作流跳转、Agent 交接这些东西互相喂回来,反复触发模型调用、工具调用或者状态增长,同时没有一个有效边界覆盖住这条路。0:56主播据论文摘要,作者做了一个静态分析工具 IAL-Scan。它先把不同框架里的 Agent 代码抽象成统一的 Agent IR,再构建 Agentic Loop Dependence Graph,也就是把控制器、模型调用、工具调用、状态更新和边界条件放到一张图里,最后检查一条反馈路径能不能反复抵达高成本或会增长状态的操作。1:21主播最值得注意的不是概念,而是样本量。论文报告说,他们扫描了六千五百四十九个至少有一个 GitHub star 的 Python LLM Agent 仓库,覆盖二十四万六千多个 Python 文件、三千三百多万行代码。IAL-Scan 报出七十四个潜在问题,人工复核确认六十八个真实故障,分布在四十七个项目里,精度是百分之九十一点九。1:46主播为什么这件事比「给循环加个上限」更麻烦?因为 Agent 的循环不一定长得像循环。一个 LangGraph 的条件边、一个 OpenAI Agents SDK 的 handoff、一个 CrewAI 的 delegation、一个工具失败后的重试,表面上都不是同一种代码结构,但它们都可能形成同一种反馈路径:模型判断下一步,工具返回观察,状态被写回,再把更长的上下文送进下一轮模型。2:13主播论文里的关键判断叫边界覆盖。也就是说,系统里出现了 max iterations、max turns、timeout 或 retry cap,并不等于安全。要看这个边界约束的是不是控制这条反馈路径的那个执行范围。一个外层任务有超时,但里面的工具重试没有上限;一个 graph 有默认 recursion limit,但某个动态节点自己递归调用子节点;一个多 Agent 会话声称会等到「完成」,但完成与否由模型自然语言判断,这些都可能让刹车装错位置。2:47主播主流框架其实已经承认这个问题存在。LangChain 的 AgentExecutor 文档写得很直白,max_iterations 是执行循环结束前允许的最大步骤数,把它设成 None 可能导致无限循环。OpenAI Agents SDK 文档也说,Runner 会在模型输出 final output、handoff 或 tool calls 之间循环,超过 max_turns 就抛出 MaxTurnsExceeded;如果传入 None,就关闭这个回合限制。3:14主播CrewAI 的文档从另一个角度说明同一件事。它的 max_iter 用来限制单个任务里 Agent 能执行的最大迭代次数,目的就是防止无限循环或过长执行,默认值是二十五。注意,这些文档都不是在谈抽象风险,它们是在告诉开发者:Agent 的自主性必须配一个硬边界,否则一次请求可能被放大成很多轮模型、工具和外部动作。3:40主播论文把六十八个真实故障分成几类:没有边界的重试反馈有十七个,没有边界的工具调用迭代有十六个,没有回合限制的多 Agent 对话有十四个,没有有效边界的工作流循环有九个。作者还统计,百分之九十五点六的故障会导致 API 成本耗尽或模型服务不可用,百分之二十七点九会导致上下文窗口耗尽,百分之七点四会耗尽外部工具的速率限制。4:10主播这对工程团队的提醒是,Agent loop 的可靠性不能只在运行时看日志。等 trace 里出现一百次重复工具调用,成本已经发生了;等用户抱怨任务卡住,状态可能已经被写脏了。更好的做法是把 Agent 程序当作一种带 LLM 语义的软件来检查,提前看哪些路径会回到模型、哪些路径会写状态、哪些路径会触发外部副作用,以及哪些边界真的罩住了这些路径。4:39主播也要保留论文自己的限制。IAL-Scan 是静态分析,作者承认会有假阳性;它目前聚焦八种主流框架的 Python 应用,对其他语言、深度自定义调度器、依赖外部状态的停止逻辑,可能看不准。所以它更像一盏施工灯,帮你照出高风险区域,而不是一张可以直接替代代码审查和运行时观测的合格证。5:04主播如果你在做生产 Agent,我建议把今天这期转成四个检查项。第一,给每一种循环都写明边界:模型回合数、工具调用次数、重试次数、工作流步数、总耗时、预算上限,最好都有可测试的默认值。第二,边界要贴着反馈路径放,不要只在最外层任务包一层 timeout 就结束。5:28主播第三,把状态增长当成风险信号。消息历史 append、检索上下文叠加、子 Agent 结果汇总、错误信息回灌,都会让下一轮模型看到更多材料,也会让一次失控循环变得越来越贵。第四,所有带副作用的工具都要做幂等、速率限制和人工确认分级。发邮件、开工单、改数据库、发起采购、合并代码,这些动作不能只靠模型一句「继续」就重复执行。5:58主播最后,评估也要从「答案对不对」往前挪一步。给 Agent 加一组专门的循环压力测试:工具一直返回空结果会怎样,检索结果互相矛盾会怎样,子 Agent 一直交接会怎样,人类审批迟迟不回来会怎样。你要看的不是它最后能不能答出来,而是它在失败条件下能不能及时停、干净地停、留下足够审计的停。6:22主播今天这篇论文的价值,不在于又给 Agent 安全加了一个新名词,而是把「Agent 为什么会自己跑飞」拆成了可以检查的工程结构。下一次你看到一个 agent.run 调用,别只问它能不能完成任务。先问一句:如果它不想停,谁有权让它停在这里?