CodingAgent普遍存在终止延迟现象，宾州州立大学实测，中位60%步骤发生在解题完成后

当一个Coding Agent提交修复补丁后，你是否曾疑惑：它明明已经通过了测试，为何还要反复检查、重跑验证、翻阅无关文件，甚至在最后几步把正确的代码又改错了？宾州州立大学（Penn State）最新发表于arXiv的论文《Termination Lag: Coding Agents Solve Early but Stop Late》（编号2611.14960），首次以实证方式揭示了这一普遍却被长期忽视的现象——“终止延迟”（Termination Lag）。

所谓终止延迟，指从Agent首次生成正确补丁的时刻，到其最终自行停止任务之间所经历的额外步骤数。研究团队通过一套无侵入式日志代理系统，在Agent每次调用大模型间隙自动捕获仓库快照，并在任务结束后离线回放官方测试，从而精确标定“首次正确补丁出现步数”（TTFCP）与“实际自停步数”，进而计算出TL（Termination Lag）及NTL（归一化终止延迟占比）。

该方法的关键在于“事后判卷、过程无感”：Agent全程不知情，行为完全自然，避免了测量干扰。实验覆盖5个主流模型（Qwen3-Coder-30B、Laguna-XS.2、Seed-OSS-36B、Claude Haiku 5.5、GPT-6 Luna）、2个Agent框架（OpenHands为主，mini-SWE-agent用于交叉验证）以及3类基准任务（SWE-bench Verified、Multilingual、SWE-bench Pro），确保结论具备泛化性。

图中清晰呈现Laguna-XS.2在SWE-bench Verified任务中的典型轨迹：灰色曲线代表“首次补丁”出现时间，蓝色曲线为“首次正确补丁”步数，橙色为Agent实际自停点。三者之间存在显著间隔——中位情况下，Agent在第57步即产出正确补丁，却直到第140步才停止，中间浪费了约60%的步骤。阴影区域标注为“Work After the Fix”，即修复完成后的冗余工作。

更值得注意的是，研究发现：在所有成功完成任务的运行中，超过半数的Agent在前35%–60%的轨迹步数内就已达成正确修复；而其中一小部分（尤其在高难度任务中）甚至会在后期“手痒”修改已正确代码，导致最终提交失败。例如，某次运行中Agent在第82步提交了可通过全部测试的补丁，但在第110步又擅自重写了核心函数，致使编译中断——用户不得不重启整个流程。

这暴露了当前评估体系的根本缺陷。主流基准如SWE-bench仅依据最终提交结果打分：只要最后一步补丁通过测试即得满分，无论此前经历了多少无效迭代。这意味着两个能力截然不同的Agent可能获得相同分数：一个精准高效，解完即停；另一个则陷入“自我怀疑循环”，反复验证、探索、重构，成本与风险倍增。

实际上，真实开发场景中，“知道何时收手”比“写出正确代码”更具工程价值。每一次额外的模型调用都意味着上下文膨胀、token消耗上升、延迟增加，且每一步都存在引入新错误的概率。尤其在企业级CI/CD流水线或低延迟响应场景下，这种冗余操作会直接拖累效率与稳定性。

研究进一步通过行为分类统计，揭示了Agent在“解对之后”各阶段动作的分布特征：

以Qwen3-Coder-Verified为例，其63%的后续步骤用于“verify”（运行测试、编写检查脚本等），21%用于“explore”（查看无关文件、搜索历史记录），其余则分散于重写源码、整理收尾等环节。相比之下，Haiku 5.5在Verified任务中“verify”占比高达66%，但“edit the source again”（二次修改）比例达13%，显著高于其他模型，印证了其易将正确代码改错的倾向。

值得注意的是，该现象并非个别模型缺陷，而是跨越开源与闭源、不同规模参数模型的共性问题。Laguna-XS.2与Qwen3-Coder在多语言任务中均表现出相似的延迟模式；即使在更难的SWE-bench Pro上，NTL中位值仍稳定维持在50%左右。这表明问题根源可能深植于当前Agent的设计范式：缺乏对“任务完成状态”的显式判断机制，过度依赖启发式终止条件（如最大步数限制、连续无进展阈值），而非基于语义与测试反馈的动态决策。

目前主流Agent框架（如OpenHands）通常采用固定步长上限或简单超时策略作为终止条件，未整合“修复有效性”的实时感知能力。理想状态下，Agent应在生成补丁后立即触发轻量级验证（如静态检查+最小单元测试），若通过则主动终止；若失败，则进入修正循环。但现有系统多将验证嵌入后续步骤，形成“先行动、后确认”的滞后逻辑。

行业已有初步应对尝试。部分开发者开始手动插入“stop if test passes”指令，或在提示词中强调“一旦修复通过测试，请立即结束任务”。然而，这类干预依赖用户经验，且效果不稳定——模型仍可能因上下文残留的“谨慎偏好”而继续执行。更系统的解决方案需从架构层面入手：例如引入专用的“终止判断模块”，或在训练阶段注入“早期停止奖励”，引导模型学习识别完成信号。

对产品侧而言，这一发现具有直接指导意义。面向开发者的Coding Agent工具若想提升实用性，不能仅追求最终成功率，更应优化“单位步数有效产出率”。用户界面可考虑可视化轨迹进度条，标注“首次正确补丁”位置，帮助用户识别冗余阶段；后台则可部署动态截断策略，在检测到多次验证通过后自动终止会话。

对研究社区而言，Termination Lag提供了一个新的评估维度。未来基准设计应补充过程指标，例如TTFCP/TL/NTL，使榜单不仅反映“能否修好”，更衡量“修得有多高效”。正如论文作者所言：“我们不是在批评Agent太慢，而是在指出——它其实早就完成了任务。”

这项研究并未提出具体改进方案，但其测量框架本身已成为重要基础设施。随着更多团队复现并扩展该方法，Coding Agent的“行为透明度”有望逐步提升，从黑箱操作走向可解释、可优化的工程化系统。