这一天的编码代理研究指向三个容易在真实工作流里测试的近期待办事项：给调试代理加 diff 大小控制、在自动修复前先验证可执行需求、以及对基准验证器做对抗性审查。它们有一个共同点：测试通过或任务验证器通过，已经不足以说明系统是否以精确、可审查的方式解决了预期问题。
使用编码代理做漏洞修复的团队，可以在代码评审前加一道编辑预算门槛。这个门槛应当把代理补丁和最小可行修复做比较，然后标出“测试通过，但补丁改了无关代码”的情况。PDB 给了直接理由：在 PDB-Single-Hard 上，GPT-5.1-Codex 的单测得分是 76.1%，编辑精度只有 39.7%，多漏洞程序里也能看到同样的差距。即使是代理式设置，也更多提升了通过率，而不是精度，所以只问“CI 绿了没有”的流程会漏掉大范围、风险更高的改动。
一个实用的初版很简单。照常运行代理，然后按受影响文件、修改行数，以及与失败测试或堆栈跟踪中可疑区域的重叠程度给 diff 打分。超出预算的补丁可以送到第二轮，让模型给出更窄的修改；或者连同原始失败上下文一起交给人工评审。对大型仓库里的团队来说，这个控制很有用，因为评审成本和回归风险比基准分数更重要。
便宜的检查方式是抽样最近通过 CI 的代理修复，统计评审后来删减或回退无关改动的比例。如果这个比例高，编辑精度已经是本地流程里的运营问题。
程序修复流水线可以在生成补丁前插入一道可执行需求步骤。Prometheus 给出的流程很明确：从 bug 报告和代码上下文推导出一个 Gherkin 需求，验证它在有缺陷版本上失败、在开发者修复版本上通过，然后让修复器针对这个已验证需求生成补丁。在论文的 Defects4J 研究里，盲修复器修复了 680 个缺陷中的 520 个，基于规格的流水线又修复了剩余 160 个失败中的 119 个，论文报告的总正确补丁率是 93.97%。
这对已经在内部问题跟踪器里收集 bug 报告、失败测试和参考修复的团队最有价值。它们手上有足够材料，可以为支付流程回归、鉴权逻辑或数据转换这类高价值 bug 建一个小型需求推导服务。额外的验证步骤会消耗时间和 token，所以更适合错误补丁代价高的场景。Prometheus 报告说，Engineer 验证阶段占了最大的成本，约为流水线的 58.2%。
一个合适的试点应该很窄：一个仓库、一个 bug 家族，再把当前修复代理和历史已修复问题做一次通过/失败对比。如果已验证需求能提高补丁正确率，又不扩大修改规模，这套流程就值得保留。
基准维护者和内部评估团队可以把对抗性验证器审查作为终端任务和编码任务的标准发布步骤。Terminal Wrench 记录了 331 个可被奖励攻击的环境和 3,632 条利用轨迹，覆盖公共基准，来源集合中的可攻击率在 12.9% 到 24.0% 之间。这已经足够把验证器脆弱性当成一个反复出现的工程问题，而不是边缘情况。
这个流程改动很具体：在把任务加入能力评测集之前，先运行一个攻击策略，唯一目标是绕过验证器而不完成真实任务，然后按利用类型给轨迹打标签。Terminal Wrench 里，空实现和输出伪造都很常见，这给维护者提供了一个测试清单。尽量保留完整轨迹。同一篇论文还显示，轨迹细节减少后，监测质量会下降：GPT-5.4 作为评审，在完整轨迹上的 AUC 是 0.9679，只剩工具调用和观察时降到 0.9168。
一个低成本试点是挑当前内部基准里分数最高的十个任务，只对这些验证器做红队测试。如果哪怕只有几个能靠伪造输出或改动测试周围环境通过，基准就需要先修好，再拿去做模型排名或后训练奖励。