To Run or Not to Run：代码智能体到底要不要跑测试？
ISSTA 2026：基于 7,745 条公开轨迹与 3,000 次受控修复实验，分析代码执行的边际收益、成本与适用边界。已更新预印本、正式 DOI 和复现材料。
To Run or Not to Run：代码智能体到底要不要跑测试？
📄 ISSTA 2026（已接收） | 最新 PDF | 论文 DOI | 复现材料
作者：Zhihao Lin*, Junhua Zhu*, Mingyi Zhou, Xin Wang, Zhensu Sun, Renyu Yang, David Lo, Li Li
* 共同一作；Li Li 为通讯作者
2026-09-28 更新：依据最新预印本更新本文与 PDF 附件。论文所列出版信息为 Proceedings of the ACM on Software Engineering, Vol. 3, No. ISSTA, Article ISSTA022，2026 年 10 月，23 页；复现材料获 ACM Artifacts Available 标识。
截至本次更新，论文 DOI 暂未解析，可先下载上方 PDF；复现材料链接已可访问。
一句话概括
在所研究的 SWE-bench 仓库级修复任务中，增加代码执行没有带来稳定的修复率提升，却可能显著增加 token 和时间成本。执行的价值取决于任务、模型和反馈质量，需要按收益分配。
为什么这个问题重要？
现在的 coding agent 很自然地把执行当成默认能力：生成一个补丁，跑测试，看失败日志，再改一轮。这个闭环听起来很合理，也确实是很多系统的核心设计。
但执行不是免费的：
- 它会消耗大量 token，因为 agent 需要生成命令、读取日志、解释输出；
- 它会增加 wall-clock 延迟，因为测试、编译和环境准备都要等；
- 它要求维护可运行的仓库环境，而这在真实项目里经常很脆弱；
- 它可能让 agent 过度相信自己的 validation，而不是官方评测结果。
所以这篇论文问了一个很直接的问题：在 LLM-based program repair 里，代码执行到底什么时候值得？
我们做了什么？
论文分两阶段研究 execution behavior。
第一阶段，我们分析了 SWE-bench leaderboard 里的 7,745 条公开轨迹，覆盖 SWE-agent、OpenHands、LiveSWEAgent、Mini-SWE-agent 四种智能体和 12 个模型，观察执行的频率、时机与结果。
第二阶段，我们在 SWE-bench Lite 和 Verified 按官方顺序各取前 100 个实例，共 200 个任务，使用三组固定配置开展受控实验：Claude Code + Claude Sonnet 4.5、Codex + GPT-5.2（xhigh），以及 OpenCode + Qwen2.5-Coder-32B-Instruct。
实验保持各自的智能体框架与模型不变，只调整执行策略。四类策略展开为五种配置：
| 执行策略 | 具体设置 |
|---|---|
| Prohibited | 提示智能体不运行项目测试或脚本，并且不安装项目依赖 |
| Quota-1 / Quota-3 | 通过提示分配 1 或 3 个预算点；测试框架调用计 1 点，Python 脚本计 0.3 点 |
| Budget-Guided | 允许执行，但提示智能体权衡每次执行的成本 |
| Unrestricted | 不额外限制执行，保留通常的“生成 - 运行 - 修改”循环 |
因此，总规模为 200 个任务 × 3 组配置 × 5 种执行设置 = 3,000 次端到端修复尝试。这里的预算主要是提示层面的约束，不代表智能体严格遵守了调用次数；论文另做了执行合规性分析，并在 Claude Code / Verified 上补充工具层面的强制限制实验。
Prohibited 仍允许搜索、阅读和修改仓库代码。所有模式生成的最终补丁都交给官方 SWE-bench harness，在干净容器中运行评测测试；限制的是修复过程中的执行反馈，最终正确性仍通过测试评估。
关键发现
1. 执行被广泛使用，但行为差异很大。
不同 agent 和模型都会跑测试，平均每个任务约 8.8 次执行；但具体频率差异很大，从每题 2 次到 19 次都有。
对话后期的执行通常比前期更容易成功。不过，某次执行成功只表示该次运行得到成功结果，最终补丁是否修好问题仍需独立评测。
2. 对强商业 agent，禁止执行未必显著降低修复率。
论文表 2 给出了以下修复率。每行在同一组 100 个任务上比较，成功标准为通过官方评测：
| 智能体 | 数据集子集 | Prohibited | Quota-1 | Quota-3 | Budget-Guided | Unrestricted |
|---|---|---|---|---|---|---|
| Claude Code | Lite | 63% | 61% | 62% | 63% | 64% |
| Claude Code | Verified | 64% | 64% | 65% | 67% | 67% |
| Codex | Lite | 74% | 68% | 69% | 71% | 73% |
| Codex | Verified | 73% | 72% | 73% | 71% | 75% |
| OpenCode | Lite | 7% | 14% | 7% | 9% | 6% |
| OpenCode | Verified | 13% | 17% | 11% | 13% | 14% |
商业配置中，Unrestricted 相对 Prohibited 的修复率变化依次为 +1、+3、-1、+2 个百分点，平均净提升为 1.25 个百分点；OpenCode 两个子集上的变化为 -1 和 +1 个百分点，平均为 0。
六组 Prohibited 与 Unrestricted 的配对 McNemar 检验均未发现显著差异（p > 0.05）。这里需要保留统计边界：未检出显著差异不等于已经证明等效。在 ±5 个百分点的等效界限下，正式 TOST 检验仅在 Codex / Verified 上成立；其余五组的点估计虽在界限内，但当前样本量不足以确认等效。
3. 禁止执行能显著降低成本。
在 Claude Code 上，相比 Unrestricted，Prohibited 节省约 56-62% token、48-54% wall-clock time，对应修复率降低 1-3 个百分点。以 Lite 为例，平均输入与输出 token 合计从 158K 降至 69K，耗时从 1,028 秒降至 531 秒（论文表 6、7）。
这种收益不能直接推广到所有智能体。Codex 在 Verified 上禁止执行仅节省约 0.9% token，耗时基本不变；Quota-1 虽能在两个子集上节省约 21-25% token，但修复率也分别从 73% 降至 68%、从 75% 降至 72%。预算选择仍要结合成本与成功率权衡。
此外，修复阶段不依赖项目测试环境，还可以减少每个仓库、每个版本的环境维护工作；这部分工程成本没有在上述 token 和时间节省比例中单独量化。
4. 执行收益是集中的，不是均匀分布的。
商业配置中，54-66% 的修复尝试只有一次代码编辑。在两种模式均成功的子集中，商业配置的文件定位命中率均超过 95%，说明这类任务通过阅读源码已经能够较好定位问题。
另一类轨迹暴露了反馈质量的问题：有些补丁通过了智能体自己选择的测试，却没有通过官方评测。增加执行次数并不自动解决测试覆盖不足，也不保证智能体能根据失败反馈修正根因。
OpenCode 则展示了不同的边界：Quota-1 在 Lite / Verified 上达到 14% / 17% 的修复率，高于 Unrestricted 的 6% / 14%。论文观察到，无限制执行时非空补丁比例下降，并将其与测试输出占用该配置约 65K 的上下文空间联系起来。这提示我们，适量反馈可能有价值，持续增加执行也可能挤占阅读与编辑所需的空间。
我自己的理解
这篇工作让我最喜欢的地方，是它没有简单地说“执行有用”或“执行没用”。更准确的结论是：执行应该被当成有成本的资源，而不是 coding agent 的默认反射动作。
未来更好的 agent 可能不是“能不能跑测试”，而是“什么时候值得跑，跑什么，跑到什么程度就该停”。
这项研究的结论限定于上述三组配置和 200 个 SWE-bench 实例，不能直接外推到所有软件任务。性能优化、动态安全分析等任务可能依赖运行时证据。对工程实践更有用的启发是：先明确一次执行要消除什么不确定性，再判断它返回的反馈是否足以指导下一步修改。
本文依据 2026-09-28 更新的预印本整理；实验设置、完整统计结果与复现材料见文首链接。