宾州州立大学团队在 5 个模型、2 个智能体框架和 3 组代码基准上发现：成功修好 Bug 后，中位数 35%—60% 的步骤发生在首个正确补丁之后，值得我们关心的是，编程智能体的效率瓶颈正在从“会不会修”转向“何时停”。

这是什么

论文把“首次产出正确补丁”到“智能体自行停止”之间的距离称为“终止延迟”（Termination Lag，指任务解决后仍继续运行的部分）。研究团队在模型调用之间保存每次代码仓库快照，待任务结束后再用官方测试逐一回放，借此区分“找到答案”和“知道已经完成”两种能力。

结果显示，Qwen3-Coder 在 SWE-bench Verified 上有 82% 的运行第一次修改源码便已正确，Laguna-XS.2 首次正确后仍多走 57 步，相关上下文继续增长 78%。后续动作主要是重复测试和检查，占 48%—63%；真正继续修改源码只占 2%—6%。

行业怎么看

我们的判断是，智能体产品的下一项关键能力将是“可信停止”：给出可验证的完成信号，同时限制无休止的自检和改动。它能直接降低模型调用成本、等待时间与出错概率，对按步骤计费、按任务收费的商业模式尤其重要。

但这项研究也有边界。论文的“理想停止器”是在事后看到正确补丁时才停止，现实产品无法预先知道答案；而且论文主要测试代码修复场景，未必适用于调研、客服等开放式任务。还有风险在于，过早停止可能漏掉边界条件，过度强调速度又会把隐蔽缺陷留在代码中。

对普通人的影响

对企业 IT：企业部署编程智能体时，采购指标应从单一成功率扩展到修复耗时、额外步骤数及回退率，并保留人工审核关键变更。

对个人职场：开发者使用 Claude Code、Cursor 等工具时，设定明确验收条件和变更预算，可能比单纯增加模型额度更有价值；提交前仍应检查测试覆盖与版本差异。

对消费市场：如果工具更早收尾，按次计费、订阅额度和响应速度可能下降，但“看似更快”不等于结果更可靠，消费者仍需关注最终产物能否通过真实测试。