编程 agent 早就做对了却停不下来，网关看到的也比你以为的少
编程 agent 常常第一刀就改对了，然后又多跑了三分之一的流程。这是《Termination Lag》（https://arxiv.org/abs/2611.14960 ）的核心发现。11 月 13 日周五这批 arXiv 里有两篇 agent 论文，说到底讲的都是钱和控制权，这是其中一篇。作者用五个模型、两套框架、三个 SWE-bench 数据集，把 agent 一路上产出的每个不同补丁都记下来逐个测试。
成功的运行里，有 38% 到 82% 第一次改源码就已经对了。之后的全是拖延。在 SWE-bench Verified 和 Multilingual 上，解出来之后的步骤，Qwen3-Coder 占整条流程的中位数 35% 到 37%，Laguna-XS.2 是 54% 到 60%。多出来的步骤大多在验证和东翻西找。更糟的是，1% 到 8% 的情况下 agent 会把自己改对的补丁撤掉，最后交了个错的。也就是说，多花的 token 不光白花，有时还帮倒忙。要是单任务成本才是该看的数，学会什么时候停，比换一个更聪明的模型便宜得多。
第二篇 guardscope（https://arxiv.org/abs/2611.15223 ，代码 https://github.com/VulcanLab/guardscope ）问了一个每个部署 agent 网关的团队都该问的问题。一个 agent 有 15 条动作路径，运行时管控只能看到经过它所在位置的那几条。guardscope 先从源码预测覆盖范围，再对照内核级的真实记录，把每个实际执行的动作归成已检查、被绕过、被拦截三类，测了八种部署拓扑。测试对象包括微软的 agent 治理工具包和 agentgateway。它的主张是，厂商该公布一个经内核验证的覆盖率，而不是一张功能清单。
两篇放一起，是从两头说同一件事。光告诉 agent 该停了、别越界，不够，得在模型外面放一个可度量的检查。一个是有测试撑腰的停止规则，一个是有内核撑腰的覆盖率数字。agent 本身往往不是最弱的一环，套在它外面的那个循环才是。
← 返回所有文章
成功的运行里，有 38% 到 82% 第一次改源码就已经对了。之后的全是拖延。在 SWE-bench Verified 和 Multilingual 上，解出来之后的步骤，Qwen3-Coder 占整条流程的中位数 35% 到 37%，Laguna-XS.2 是 54% 到 60%。多出来的步骤大多在验证和东翻西找。更糟的是，1% 到 8% 的情况下 agent 会把自己改对的补丁撤掉，最后交了个错的。也就是说，多花的 token 不光白花，有时还帮倒忙。要是单任务成本才是该看的数，学会什么时候停，比换一个更聪明的模型便宜得多。
第二篇 guardscope（https://arxiv.org/abs/2611.15223 ，代码 https://github.com/VulcanLab/guardscope ）问了一个每个部署 agent 网关的团队都该问的问题。一个 agent 有 15 条动作路径，运行时管控只能看到经过它所在位置的那几条。guardscope 先从源码预测覆盖范围，再对照内核级的真实记录，把每个实际执行的动作归成已检查、被绕过、被拦截三类，测了八种部署拓扑。测试对象包括微软的 agent 治理工具包和 agentgateway。它的主张是，厂商该公布一个经内核验证的覆盖率，而不是一张功能清单。
两篇放一起，是从两头说同一件事。光告诉 agent 该停了、别越界，不够，得在模型外面放一个可度量的检查。一个是有测试撑腰的停止规则，一个是有内核撑腰的覆盖率数字。agent 本身往往不是最弱的一环，套在它外面的那个循环才是。
评论