论文导读
威斯康星大学麦迪逊分校、微软研究院、佐治亚理工学院联合提出ExecCritic，把代码测试和源码修复交给两个分别训练的Qwen角色。两者组合在SWE-bench Verified解决72.6%的任务，比原始无测试基线高11.4个百分点；但质量差的测试会把61.2%拉低到57.3%。结论限定于该基准和冻结测试流程。
同一个智能体写补丁又写测试，可能错得很一致
执行测试能告诉代码智能体补丁是否工作，但前提是测试真正覆盖问题描述。如果同一次推理既写源码补丁又写测试，它可能误解需求后同时写出互相配合的错误版本：测试通过了，用户要修的行为仍然没修好。
ExecCritic把工作拆开。Test智能体先阅读仓库和问题，生成项目原生测试；一个“失败即关闭”的执行工具检查测试是否合格，并把它冻结。Repair智能体只能修改源码，不能改测试。测试失败产生的日志用于下一轮修复，测试通过后才允许提交。
图1：论文Figure 1展示独立测试智能体、执行工具和修复智能体的分工，测试一旦合格便被冻结。
Django空列表案例说明测试怎样抓住漏洞
论文用Django问题14765展示完整过程。初始补丁只在real_apps为真值时检查类型，空列表会绕过断言。测试智能体生成一个期待抛出AssertionError的用例，初始补丁执行失败；修复智能体根据反馈把条件改成“不是None”，同一测试随后通过。
图2：论文Figure 3展示初始补丁、生成测试、执行反馈与修复后补丁，测试全程没有被修复智能体修改。
两个角色都以Qwen-3.5-35B-A3B为骨干，但分别训练。测试角色学习区分正确和错误补丁的行为测试，修复角色同时学习直接解题和根据执行反馈修改源码。角色分开后，训练目标更清楚，也更容易判断失败来自测试还是补丁。
错测试拖后腿，好测试才带来72.6%
固定基础Repair智能体时，无测试基线解决率是61.2%。基础Test智能体生成的测试把结果降到57.3%，说明加入执行反馈并不自动有益；GPT-5.6-sol生成的测试把结果提高到65.3%。测试角色经过专门训练后，Base-to-Gold成功率从22.2%提高到62.2%。
图3：论文Figure 5比较无测试、不同测试来源和Oracle反馈下的修复结果，展示测试质量可同时产生增益与损害。
最终，分别后训练的Qwen Test与Repair组合在SWE-bench Verified达到72.6%，比原始无测试基线高11.4个百分点。这个结果没有在评测时使用更强模型或Oracle反馈，但仍是基准仓库中的自动修复，不等于生产代码已经通过人工评审、安全检查和完整回归测试。
下一步是给测试本身建立责任链
企业采用代码智能体时，可以把“谁生成测试、测试何时冻结、哪个日志触发修复”写入审计记录。下一步要评估隐藏测试、跨语言项目和长时间演化仓库，并防止测试为了容易通过而缩小需求。更稳妥的部署方式是让生成测试成为证据之一，再叠加现有CI、静态分析和人工审查；当测试与问题描述冲突时，系统应停下并暴露分歧，而不是继续优化一个错误目标。
参考资料
https://arxiv.org/abs/2609.09133
