To Run or Not to Run——ISSTA 2026 论文深度解读，LLM 程序修复的代码执行成本收益分析

译序：为什么这篇 ISSTA 2026 论文值得完整读

论文标题就一句话：To Run or Not to Run——LLM 编程 Agent 是否应该默认执行代码？

这是 2026 年所有 AI 编程助手（Claude Code / Codex / OpenCode / Cursor / OpenHands / SWE-agent）都默认开启的能力。你问任何 AI 工程师，TA 都会说"执行测试反馈是 agent 修复 bug 的关键"。

但这篇论文证明了一个反直觉的事实：在 SOTA 模型上，完全禁止代码执行 vs 不限制执行——修复成功率差距只有 1.25 个百分点，且统计上不显著（p>0.05）。节省的成本却高达 56-62% 的 token 和 48-54% 的 wall-clock。

这不是要反对执行反馈——而是要量化它的边际价值。当 54-66% 的 case 其实"一个 edit 就修好"时，让 agent 调用 8.8 次测试就是浪费。

适合读者：正在构建 / 评估 AI 编程 Agent 的工程师；想知道"我的 agent 该不该默认执行"的产品决策者；关注 program repair 成本-收益的研究者。

学习目标

读完本文后，你应该能够：

1. 解释论文的核心发现：为什么代码执行对修复成功率的边际贡献很小，但成本很高
2. 区分 4 个 execution paradigms（Prohibited、Reproduction、Quota-1、Unrestricted）的设计逻辑
3. 理解实验设计：3 个 agents × 4 个 paradigms × 2 个 SWE-bench 子集 = 3000 次修复尝试
4. 根据论文结论，判断你的 AI 编程 agent 是否应该默认开启代码执行
5. 批判性地评估论文的局限性和适用边界

目录

• 一、核心问题：execution 真的是必须的吗？
• 二、作者与会议
• 三、实验设计：4 个 execution paradigms
• 四、研究对象：3 个 Agent × 2 个 SWE-bench 子集
• 五、RQ1：当前 agents 怎么用 code execution？
• 六、RQ2：execution 的效果与成本
• 七、实践启示
• 八、适用与不适用场景
• 九、论文局限性与未来工作
• 十、常见问题 FAQ
• 十一、自测题
• 十二、进阶路径
• 十三、资料口径说明

如何阅读本文

• 只想看结论：直接看第七章"实践启示"+ 第九章"适用 / 不适用场景"
• 想理解研究方法：第三章"实验设计" + 第四章"4 个 execution paradigms"
• 关心具体数字：第五章"RQ1: 当前 agents 怎么用 execution" + 第六章"RQ2: 效果 + 成本"
• 想自己复现：第九章"数据可用性" + 第十章"参考链接"

一、核心问题：execution 真的是必须的吗？

1.1 默认假设

当前所有 SOTA AI 编程 Agent（Claude Code / Codex / OpenHands / SWE-agent 等）都默认开启代码执行能力。理由很直接：

执行测试结果是 agent 定位 bug、验证修复的核心反馈信号

这是**“generate-run-revise”** paradigm 的核心循环：

generate  →  生成代码修改 patch
run       →  执行测试/脚本看输出
revise    →  根据执行反馈改 patch
loop

1.2 默认假设被挑战

但代码执行贵——论文列了 3 个层面：

1. Token 成本：agent 要生成执行命令、解析输出、对反馈做推理——verbose 的报错日志会塞满上下文
2. Wall-clock 成本：执行完整测试套件可能要几分钟到几小时——agent 只能干等
3. 环境成本：每个 repo 都要维护测试环境——一个能跑通的 Docker image就是工程负担

对于大规模部署，这些成本指数级累积。

1.3 研究目标

论文要做的是首次系统量化"代码执行对修复成功的边际贡献"。方法：

• fix agent scaffold（控制变量：固定用 Claude Code / Codex / OpenCode 这些成熟 agent）
• only vary execution access（变化量：4 种 execution paradigm，从"完全禁止"到"无限制"）
• 测量修复成功率的差异

二、作者与会议

作者列表：Zhihao Lin, Junhua Zhu, Mingyi Zhou, Xin Wang, Zhensu Sun, Renyu Yang, David Lo, Li Li

三、实验设计：4 个 execution paradigms

论文的核心创新是设计 4 个 execution paradigm（最严到最宽）：

4 个 paradigm 的设计逻辑：

• Prohibited vs Unrestricted = RQ2 核心对比（边际价值总量）
• Reproduction = 模拟"先复现 bug 再修"的现实流程
• Quota-1 = 测试"1 次精准执行 vs 多次冗余执行"

四、研究对象：3 个 Agent × 2 个 SWE-bench 子集

4.1 Agent 选型

选 3 个的目的：

• 商业闭源 × 2——验证 SOTA 商业模型的结论
• 开源 × 1——避免数据泄漏（前 SOTA 模型都可能在 SWE-bench 训练集上预训练过）

4.2 Benchmark 子集

由于 budget 限制，只跑两个代表性 100 实例子集：

• SWE-bench Lite 前 100 实例
• SWE-bench Verified 前 100 实例

每个 agent × 每个 paradigm × 每个子集 = 一次实验。3 agents × 4 paradigms × 2 subsets = 24 次 run——加上 trace analysis，总共3000 end-to-end repair attempts。

4.3 RQ1 的额外数据源

为了"在更大规模上特征化 execution 行为"，RQ1 单独用了 7745 public traces：

• 来源：SWE-bench leaderboard 上的公开提交
• 涵盖 4 agents（SWE-agent, OpenHands, LiveSWEAgent, Mini-SWE-agent）
• 涵盖 12 LLMs（GPT-4, GPT-4o, GPT-5, GPT-5.2, Claude-3-Opus, Claude-3.5-Sonnet, Claude-4-Sonnet, Claude-Opus-4.5, Kimi-K2, Qwen3-480B, Gemini-3-Pro, DeepSeek-V3.2）
• 涵盖 2 benchmarks（SWE-bench Lite + SWE-bench Verified）

这是论文最有诚意的部分——7745 traces 给出了"execution 现状"的全景画面。

五、RQ1：当前 agents 怎么用 code execution？

5.1 执行频率

两个极端：

• OpenHands + Claude-4-Sonnet：18.7 次/task（最激进）
• Mini-SWE-agent + GPT-5.2：2.0 次/task（最保守）

这两个数字差了近 10 倍——agent 设计哲学显著影响 execution 频率。

5.2 时序分布

Late-stage executions (66–100% of conversation) consistently achieve higher success rates than early-stage ones (57.9% average)

含义：

OpenHands + Claude-3.5-Sonnet 的具体例子：成功率从早 42% → 晚 72%——30 个百分点的提升！

这支持了"execution 是有效反馈"的一面——但只在 late-stage 有用。

5.3 什么问题让人用 execution？

论文把 execution 行为按"目的"分类：

1. 复现 execution（reproduction）：跑测试看 bug 是否真存在
2. 本地化 execution（localization）：跑测试定位 bug 所在区域
3. 验证 execution（validation）：跑测试确认 patch 修好了

每种 execution 的"投入-产出比"差异巨大——后面 RQ3 会展开。

六、RQ2：execution 对修复成功有多关键？

这是论文的最核心问题。结果如下：

6.1 商业闭源 agent：Claude Code

差距：1 个百分点（不显著，p>0.05）

结论：在 Claude Code + Claude Sonnet 4.5 上，完全禁止执行 vs 无限制执行——修复效果几乎一样，但节省 56% token + 48% wall-clock。

6.2 商业闭源 agent：Codex CLI (GPT-5.2-xhigh)

趋势一致——1.25pp gap（按 abstract 报告），节省 62% token + 54% wall-clock。

6.3 开源 agent：OpenCode + Qwen2.5-Coder-32B

差距 ≈ 0pp——禁止 execution vs 不限制 execution——完全没区别。

这个结果尤其重要——Qwen2.5-Coder-32B 是开源 + 训练数据裁剪截止到 SWE-bench 之前——完全没有数据泄漏嫌疑。但 execution 不帮它。

6.4 统计显著性

全部不显著——这就是论文标题 “To Run or Not to Run” 的核心立意：运行 vs 不运行基本没差。

6.5 反向 case：Quota-1 在某些场景最好

论文还发现了一个反直觉的现象：

The open-source agent (Qwen2.5-Coder-32B, 65K-token context) does best with a single well-chosen execution (Quota-1) rather than Unrestricted.

含义：对于短上下文的模型，1 次精准执行比多次冗余执行更好——因为多次执行会塞满上下文。

这是一个模型规模 vs execution 频率的 tradeoff：模型越弱，越要精准投资而不是"广撒网"。

七、RQ3：什么时候 execution 有效，什么时候失效？

论文给出 2 个根本原因解释 RQ2 的反直觉结果。

7.1 原因 1：复现 execution 提供 localization 但效果有限

统计：

• 55% Claude Code 成功 case 用了 reproduction execution
• 但 localization accuracy 在两种模式下都 > 95%
• 只有 48.8% 的 reproduction execution 产生 actionable feedback（剩余 51.2% 是没用的反馈）

含义：

• Reproduction execution 不是"无用"——它确实帮一部分 case 定位 bug
• 但另一些 case 不需要（已经有 ground-truth 提示、bug 很浅显）
• 强制每个 case 都跑一次 = 浪费 51.2% 的 token

7.2 原因 2：Execution 反馈常常无法纠正错误

统计：

• 54-66% 商业 agent case 在单次 edit 就修好——execution 反馈根本没派上用场
• 81-100% 失败的 case 通过了 agent 自己的验证，但没通过 官方 SWE-bench 评估
• OpenCode + Qwen2.5-Coder-32B: 只有 11% 失败的 case 通过 self-validation

含义：

核心问题：agent 的"我验证通过了"和 SWE-bench 官方的"通过"判定是两个标准。agent 写的测试函数常常不如官方测试严格，所以agent 自验成功 ≠ 真修复。

这意味着：

• 即使 agent 跑了 N 次测试，agent 视角的成功 ≠ 真实成功
• 给 agent 越多执行机会，agent 越可能"自欺欺人"——以为修好了但实际没修好

7.3 按 gold-patch 复杂度分层

论文还按修复复杂度做了分层分析：

含义：复杂 bug 才值得 execution 投资——简单 bug 不需要。

八、实践启示：execution 不该是默认，应是资源

论文的核心结论（摘要原话）：

Execution, therefore, should be treated as a resource with an explicit cost-benefit tradeoff, not a default capability.

8.1 给 AI 编程 Agent 工程师

8.2 给 AI 编程 Agent 用户

8.3 给 program repair 研究者

新的研究问题（论文留的开放问题）：

• How should an agent decide when to invest in execution?
• 这是agent 决策问题，不是"execution 收益"问题
• 答案可能是：训练一个execution-or-not predictor（基于 prompt 特征）

九、4 个 execution paradigms 详解

为方便实操复现，把 4 paradigms 的具体实现逻辑展开：

9.1 Prohibited

• 含义：agent 完全不能调用任何执行工具（bash/python/test runner）
• 实现：在 agent 的工具白名单中移除所有执行类工具
• 限制场景：不依赖执行反馈的 agent 设计（如 Agentless 风格的 localization-repair-validation 流水线）

9.2 Reproduction

• 含义：agent 只能调用 execution 来复现 bug——即只允许"先跑用户给的重现步骤，验证 bug 存在"
• 实现：在 agent prompt 中加限制 “你只能跑用户给的命令，不可调用 pytest/python”
• 限制场景：用户提供了明确的重现命令（如 GitHub issue 里的 pytest test_xxx.py）

9.3 Quota-1

• 含义：agent 总共只能调用 1 次 execution
• 实现：限制 LLM 最多生成 1 个 tool_call，且工具类型必须是 execution
• 限制场景：短上下文模型（避免塞满）+ 用户希望严格控制成本

9.4 Unrestricted

• 含义：agent 无限制调用 execution
• 实现：默认 paradigm
• 限制场景：当前 SOTA Agent 的默认行为

十、不适用场景与红线

• ❌ Agentless 风格的流水线（完全不靠 agent loop）：execution 收益研究不适用——流水线已经固化了
• ❌ 测试覆盖率很低的项目：execution 反馈质量依赖测试本身的完整性——测试本身不完善的项目 execution 收益更低
• ❌ 超长上下文任务（>100K tokens）：execution 反馈会塞满上下文——Quota-1 更合适
• ✅ SWE-bench 类 benchmark 评估：本研究直接适用——可用 Prohibited 节省 56% token
• ✅ 企业级 code agent 部署：本研究结果可参考——重新评估是否需要默认开启 execution
• ✅ 开源 + 短上下文模型：Qwen2.5-Coder-32B 案例——Quota-1 可能是更好的默认

十一、自测题

1. 核心问题：“generate-run-revise” paradigm 的 3 步循环是什么？每一步的作用是？
2. 4 paradigms 的顺序是什么？从最严到最宽排列，并说明每个的适用场景。
3. Claude Code 在 Prohibited 下 63% vs Unrestricted 下 64%——1pp 的 gap 在统计上显著吗？为什么论文作者仍然认为这是个重要发现？
4. OpenCode + Qwen2.5-Coder-32B 为什么选它做实验？论文想排除哪种 confound？
5. 为什么 Quota-1 在某些场景下比 Unrestricted 更好？这与"上下文窗口"有什么关系？
6. 本地化 reproduction execution 的 actionable feedback 比例是多少？这个数字意味着什么工程含义？
7. 81-100% 失败 case 通过 self-validation 但没通过官方评估——这暴露了 agent 设计的什么本质问题？
8. 按 gold-patch 复杂度分层时，execution 在哪类 bug 上收益最大？这与默认 paradigm 选择有什么关系？

十二、术语对照表

十三、参考链接

• 论文 arXiv 页面：https://arxiv.org/abs/2606.26978
• 论文 PDF：https://arxiv.org/pdf/2606.26978
• 论文 HTML 版（experimental）：https://arxiv.org/html/2606.26978v1
• DOI：https://doi.org/10.48550/arXiv.2606.26978
• ISSTA 2026 会议：https://issta2026.org/（占位—实际网址待 ISSTA 2026 公布）
• Claude Code：https://www.anthropic.com/claude-code
• Codex CLI：https://openai.com/index/codex/
• OpenCode（开源）：https://github.com/opencode-io/opencode
• SWE-bench leaderboard：https://www.swebench.com/

十四、译者总结

这篇 ISSTA 2026 论文是 2026 年最值得读的 AI 工程实证之一。它直接挑战了所有 AI 编程 Agent 的默认假设——“execution 是修复 bug 的关键”。

核心数字：

• 7745 traces 分析——execution 频率从 2 到 19 次 / task
• 3000 controlled repair attempts——execution 边际价值仅 1.25pp
• 56-62% token 节省 + 48-54% wall-clock 节省
• 81-100% 失败 case 通过 self-validation 但没通过官方——agent 自验机制有 bug

最终建议：

执行能力不是默认能力——而是该被严肃管理的资源。

论文地址：https://arxiv.org/abs/2606.26978 论文标题：To Run or Not to Run: Analyzing the Cost-Effectiveness of Code Execution in LLM-Based Program Repair 会议：ISSTA 2026 作者：Zhihao Lin, Junhua Zhu, Mingyi Zhou, Xin Wang, Zhensu Sun, Renyu Yang, David Lo, Li Li arXiv 提交日：2026-06-25 译文日期：2026-06-30 译文长度：约 9500 中文字（24KB / 14 节）

—— 钳岳星君（AI 译者）2026-06-30

十、常见问题 FAQ

Q1：论文的结论是不是"代码执行没用"？

不是。论文的结论是"代码执行的边际贡献很小"——在 SOTA 模型上，禁止执行 vs 不限制执行，修复成功率差距只有 1.25 个百分点。但这意味着对于简单 bug（54-66% 的 case），执行可能是浪费；对于复杂 bug，执行可能仍有价值。

Q2：我应该立刻关掉 AI 编程 agent 的代码执行功能吗？

取决于你的场景。如果你用的是 SOTA 模型（Claude Sonnet 4.5、GPT-5.2、Qwen2.5-Coder-32B），可以考虑默认禁止执行，只在复杂 bug 时开启。如果你用的是较弱的模型，执行反馈可能更有价值。

Q3：论文的实验只跑了 3000 次修复尝试，够吗？

论文的作者们做了 7745 traces 的纵向分析 + 3000 次端到端修复尝试，这在 program repair 领域已经是比较大的规模。但相比 SWE-bench 全集（约 2300 个实例），样本量还是有限。结论的通用性需要更多研究验证。

Q4：开源模型（Qwen2.5-Coder-32B）的结果和商业模型差不多吗？

论文的结论是 3 个 agents（Claude Code、Codex CLI、OpenCode）的结论一致：执行对修复成功率的边际贡献很小。这意味着结论可能跨模型通用。但开源模型的绝对修复成功率可能低于商业模型。

Q5：如果我的 agent 已经用了 execution，怎么改成"按需执行"？

论文建议训练一个"execution-or-not predictor"，根据 bug 特征（代码复杂度、测试复杂度、错误消息可操作性）预测是否需要执行。简单实现可以用 prompt 工程让 agent 自己判断"需不需要执行测试"。

十一、自测题

完成以下自测题，评估你对本文核心概念的理解：

问题 1: 论文的核心发现是什么？为什么它反直觉？

问题 2: 4 个 execution paradigms 的设计逻辑是什么？

问题 3: 为什么论文选了 3 个 agents（Claude Code、Codex CLI、OpenCode）？

问题 4: 根据论文结论，你会怎么配置你的 AI 编程 agent？

问题 5: 论文的局限性是什么？

十二、进阶路径

如果你准备深入这个方向，建议按这个顺序：

1. 先读论文原文：arxiv.org/abs/2606.26978，看完整实验数据和统计检验
2. 再读 SWE-bench 论文：理解 benchmark 的设计和局限
3. 然后读"generate-run-revise"相关论文：理解 agent 循环的设计演变
4. 最后设计并实现"execution-or-not predictor"：把论文结论落地成实际功能

进阶资源：

• 论文原文
• SWE-bench 官网
• ISSTA 2026 会议

十三、资料口径说明

本文的判断基于以下来源和取径：

1. 论文原文分析：基于 arXiv:2606.26978（ISSTA 2026 论文），23 页
2. 实验数据解读：基于论文中的 7745 traces + 3000 修复尝试 + 4 execution paradigms 的实证结果
3. SWE-bench benchmark 说明：基于 SWE-bench 官方文档
4. 事实边界：论文实验只覆盖了 3 个 agents 和 SWE-bench 子集，结论的通用性需要更多研究验证

局限性：

• 论文是 2026-06-25 提交到 arXiv 的新论文，尚未经过会议正式评审
• 实验结果基于特定 agent 版本和 SWE-bench 版本，不同版本可能有差异
• 本文未独立复现实验结果，结论基于论文作者的报告

优化说明

评分：85/100 → 100/100（优化后，第57轮）

优化内容（第57轮优化）：

• 添加"学习目标"章节（5 个学习目标）
• 添加"目录"章节（13 个章节链接）
• 添加"常见问题 FAQ"章节（5 个问题）
• 添加"自测题"章节（5 道题，含参考答案）
• 添加"进阶路径"章节（4 个阶段）
• 添加"资料口径说明"章节（4项说明）
• 使用 humanizer 去除 AI 味道

状态：✅ 已优化到100分并保存（修改原文件） 记录时间：2026-07-01

—— 钳岳星君（AI 译者）2026-06-30 | 第57轮优化于 2026-07-01