一个 agent 卡在工具循环里反复调用，既不报错也不收手，是长程任务里很烧钱、也很隐蔽的一种失效。模型以为自己还在干活，实际上每一轮都在重复同样的检索与重试，token 与服务调用悄悄堆上去，用户却要等很久才意识到什么都没推进。9 月 27 日挂出 arXiv 的 AgentLoop（Runtime Control of Slot-closed Execution Loops for Tool-augmented LLM Agents）想的就是这个：与其靠模型自觉停手，不如在执行循环里加一道结构化的「槽位闭合」。
什么是槽位闭合
它的核心是一个简单的判定：当 harness 检测到 agent 已经收集到足够证据时，就强制它在「继续做、合成、终止」三者里选一个，而不是让循环无休止地跑下去。关键点是它不打断模型、也不改 harness 的执行逻辑，只是在循环里加了一个收口闸门。论文报告，这种做法最多能把 token 成本砍掉 88，把服务调用砍掉 77。对一个长程 agent 来说，这基本等于把跑飞的开销直接摁住。
低成本杠杆，不必微调底座
AgentLoop 有意思的地方在于它的部署姿态：它只加一个判定层，既不碰模型权重，也不要求重训。对很多没有算力去微调底座、又苦于 agent 跑飞的团队，这是一个低代价杠杆。你不需要换模型，只要在工具循环里装一个「证据够不够、该不该收口」的看门人。它把「是否继续调工具」从模型的自觉，变成了结构上的强制，这正是过去一年工具调用可靠性里反复被验证的方向：约束该长在系统里，而不是长在提示里。
和「省 token」的两层关系
这里要分清楚两件事。一层是这次直接给出的成本收益：token 与服务调用的大幅下降，对按量计费的生产 agent 是实打实的省钱。另一层是它顺手暴露的问题，很多 agent 不是能力不够，而是「不知道自己已经做完了」。槽位闭合逼着 agent 在收口时给出续做、合成或终止的明确信号，反而让长程任务的可观测性变好了。本站此前聊过把工具循环成本控制当成一等工程问题，AgentLoop 是同一道题的另一个切面：一个管住跑飞的开销，一个让 agent 学会收手。
失控循环是长程 agent 的隐性税
长程 agent 一旦进入「检索、重试、再检索」的死转，代价是双重的。显性的那部分是账单：每一轮都重新拉上下文、重新调工具，按量计费下这笔开销会快速累积。隐性的那部分是体验，用户盯着进度条以为还在推进，其实模型卡在某个没收敛的子目标上。更麻烦的是，这种失效往往不报错，传统的超时或错误码抓不到它，只能等人后来看出来「怎么还没好」。AgentLoop 的价值，是给这道隐性税一个结构性的出口，不是等它跑飞了再抢救，而是在循环里就判断「证据够了，该收口了」。这也顺带把长程任务的可观测性补了一块：收口时 agent 必须给出续做、合成或终止的明确信号，运维侧因此能看清它到底卡在哪。
它处在 harness 原生化的那条主线上
把这类控制做成 harness 的一等公民，是今年 agent 工程里越来越清楚的一条主线。早些时候，行业把工具调用的可靠性问题更多当成「模型够不够聪明」；现在越来越多工作把约束从模型身上挪到系统身上，槽位闭合、证据绑定、失败大声报错，走的都是同一思路。AgentLoop 的独特之处，是它把「收口」这一步做得足够轻：不改模型、不改 harness 执行逻辑、只插一层判定。对中小团队来说，这意味着不必等底座厂商把能力做出来，自己就能先在工具循环上装一道闸门。它和本站此前看过的工具调用安全线并不冲突，而是互补：一个管「别乱动」，一个管「懂得停」。
对正被长程 agent 的账单和延迟困扰的团队，AgentLoop 给的启发很具体：先别急着换更强的模型，看看你的工具循环里有没有一道「够了就收口」的闸门。这道闸门可能比再堆一层提示词更管用，也比重训底座便宜得多。