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

译序：这篇论文动了所有 AI 编程 Agent 的一条默认设置

论文标题就是一个问句：To Run or Not to Run——LLM 编程 Agent 到底该不该执行代码？

2026 年的主流编程 Agent（Claude Code、Codex CLI、OpenCode、Cursor、OpenHands、SWE-agent）都默认开启代码执行。问任何一个 AI 工程师，答案都差不多：执行测试反馈是 Agent 修 bug 的关键信号。

这篇被 ISSTA 2026 录用的论文给了一个量化得多的答案。作者固定 Agent 脚手架、只改变执行权限，在 200 个 SWE-bench 实例上跑了 3000 次端到端修复：商业 Agent 上，完全禁止执行与不限制执行的修复成功率差距平均只有 1.25 个百分点，且统计上不显著；代价一边，Claude Code 上禁止执行省下 56–62% 的 token 和 48–54% 的墙钟时间。而在 65K 上下文的开源模型上，表现最好的不是随便跑，而是恰好跑一次。

论文的立场不是反对执行，而是把执行从"默认能力"重新定位为"有显式成本收益权衡的资源"。对按 token 付费、按小时排期的团队，这句话可以直接换算成账单。

适合读者：正在构建或评估 AI 编程 Agent 的工程师，需要决定"我的 Agent 该不该默认执行"的产品决策者，关注程序修复成本收益的研究者。

学习目标

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

1. 复述论文的核心发现：执行对修复成功率的边际贡献很小，成本却很高，收益集中在少数实例上
2. 区分四类执行范式（Prohibited、Quota-Limited、Budget-Guided、Unrestricted）及其五种配置的设计逻辑
3. 理解实验设计：3 个 Agent × 5 种配置 × 200 个 SWE-bench 实例 = 3000 次受控修复尝试
4. 根据自己团队的模型与成本结构，判断是否要修改"默认执行"这一设置
5. 指出论文的适用边界：结论限定在 SWE-bench 风格的仓库级 bug 修复，不能直接外推到性能调优或安全分析

目录

• 一、核心问题：execution 真的是必需品吗
• 二、论文信息与作者
• 三、实验设计：四类范式，五种配置
• 四、RQ1：当前 Agent 怎么用代码执行
• 五、RQ2：限制执行几乎不掉成功率
• 六、RQ3：为什么执行帮不上忙
• 七、实践启示
• 八、常见问题
• 九、自测题
• 十、术语对照表
• 十一、进阶路径
• 十二、资料口径说明

一、核心问题：execution 真的是必需品吗

1.1 默认假设

当前主流编程 Agent 都构建在"generate-run-revise"循环上：

generate  →  生成代码修改 patch
run       →  执行测试或脚本，观察输出
revise    →  根据执行反馈修改 patch
loop      →  循环直到测试通过或预算耗尽

这个循环的成立依赖一个假设：执行测试是 Agent 定位 bug、验证修复的核心反馈信号，砍掉它成功率会崩。

1.2 被忽略的成本

代码执行不是免费的。论文列出三个层面：

1. token 成本：Agent 要生成执行命令、解析输出、对反馈做推理，冗长的报错日志会挤占上下文窗口；
2. 墙钟时间：跑完整测试套件可能要几分钟到几小时，Agent 只能等；
3. 环境成本：每个仓库都要维护一套能跑通的测试环境，论文特别指出，禁止执行还顺带免掉了工业部署里 per-repo 测试环境的搭建和维护。

这些成本按任务数线性累积，在大规模部署下不是小数目。

1.3 研究思路

论文要做的是第一次系统量化"执行对修复成功的边际贡献"。方法是控制变量：固定 Agent 脚手架（Claude Code、Codex CLI、开源的 OpenCode），只改变执行权限（四类范式、五种配置），测量修复成功率的差异。这是它与此前 agentless 研究的关键区别——不争论"要不要 Agent"，只在 Agent 内部隔离"执行"这一个变量。

二、论文信息与作者

三、实验设计：四类范式，五种配置

3.1 执行范式

论文定义了四类执行范式，其中 Quota-Limited 以 K=1 和 K=3 两种配额实例化，共五种配置：

四个对照各有用途：Prohibited 对 Unrestricted 是边际价值的总量测量；两个 Quota 配置检验"少而准"能否替代"多而杂"；Budget-Guided 则测试仅靠成本意识（prompt 层面告知"unused budget is wasted opportunity"）能否自发减少浪费。

3.2 实验规模与执行口径

受控实验的规模是 200 个 SWE-bench 实例（Lite 与 Verified 各取前 100，仓库涵盖 Django、Flask、Requests、Sympy 等）× 3 个 Agent × 5 种配置 = 3000 次端到端修复尝试。每次尝试都走完整流程：checkout 仓库、读 issue、生成并应用补丁、跑官方 SWE-bench 评估。

一个值得注意的口径：预算限制主要是 prompt 级的软约束。Agent 偶尔会尝试违规执行（7–9% 的 Prohibited 尝试出现这类环境错误），论文按 intention-to-treat 原则把这些也计为"已执行"。为了排除软约束干扰，作者在 Claude Code + Verified 上做了一次工具级沙箱的硬约束重跑（见 5.3 节），结论不变。

测试执行的定义是 pytest、unittest、tox、nosetests 或 python xxx.py 这类命令的调用。

3.3 Agent 选型

选型的考虑是数据泄漏：闭源模型可能在 SWE-bench 训练集上预训练过，而 Qwen2.5-Coder-32B 的训练截止早于 SWE-bench Verified。如果开源 Agent 上结论依然成立，等价性就不是记忆污染的伪影。

3.4 RQ1 的额外数据源

除了受控实验，RQ1 单独分析了 7745 条来自 SWE-bench 排行榜公开提交的 agent 轨迹，覆盖 4 个 Agent（SWE-agent、OpenHands、LiveSWEAgent、Mini-SWE-agent）、12 个模型（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）。受控实验回答"执行权限改变会怎样"，这批轨迹回答"现实中的 Agent 实际怎么用执行"。

四、RQ1：当前 Agent 怎么用代码执行

4.1 频率：平均 8.8 次，跨度近 10 倍

同一个模型（如 GPT-5.2）在不同脚手架里执行频率差近 10 倍，说明执行频率主要是脚手架的设计哲学决定的，不是模型能力决定的。

4.2 时序：越晚执行，通过率越高

论文把每次执行在对话中的位置归一化，分成早（0–33%）、中（33–66%）、晚（66–100%）三段。所有配置下，晚期执行的成功率都稳定高于早期。最直观的例子是 OpenHands + Claude-3.5-Sonnet：执行成功率从早期的 42% 升到晚期的 72%。晚执行的测试更有的放矢——Agent 此时已锁定可疑区域。

老模型呈现相反的分布：SWE-agent + GPT-4 有 42.4% 的执行发生在早段，晚期只有 29.6%，更像"边跑边看"的试探风格。

这里要澄清一个容易被误读的数字：所有执行的整体平均通过率是 57.9%，单配置范围从 30.4%（SWE-agent + GPT-4o）到 79.3%（LiveSWEAgent + Claude-Opus-4.5）。57.9% 是全部执行的平均结果，不是早期执行的通过率。

五、RQ2：限制执行几乎不掉成功率

5.1 总表：六组对照，无一显著

† 表示 Prohibited 与 Unrestricted 的差距在 3 个百分点以内。所有六组 McNemar 检验均不显著（p > 0.05）。

这张表信息量很大，逐行看：

• Claude Code：Lite 上禁止执行 63%，不限制 64%，差 1 个百分点，同时省 56% token、48% 墙钟时间（禁止模式下单任务 531–573 秒，不限制 1028–1234 秒）。
• Codex：最反直觉的一行。Lite 上禁止执行 74% 是该行五种配置里的最高分，比不限制还高 1 个百分点。更狠的是 Quota-1（68%）和 Quota-3（69%）比完全禁止还差——部分执行权限提供的反馈不足以支撑有效迭代，反而可能误导。摘要中"1.25 个百分点"是商业 Agent 四组对照的平均值，Codex 单项在 Lite 上甚至是负差距。
• OpenCode：Lite 与 Verified 合并看，禁止与不限制都是 10%，同时 token 少用约三分之二。但它的最优配置是 Quota-1——Lite 上 14% 对不限制的 6%，Verified 上 17% 对 14%。

5.2 成本差距比效果差距大得多

三种 Agent 的成本结构差异悬殊。从禁止到不限制，token 消耗的增幅：Claude Code 129–163%，OpenCode 36–208%，Codex 只有 0.8–15.5%。基线不同是主因——禁止模式下 Claude Code 每任务约 65K token，Codex 约 470K，OpenCode 约 150K。Codex 本来就把大量 token 花在读代码上，执行占比小，所以省不出多少。

时间上的结论类似：Claude Code 禁止执行省 48–54% 墙钟时间；Codex 最优的 Quota-1 只省 3–6%，其他配置几乎没有差异。

由此得出各 Agent 的最优省钱配置并不相同：Claude Code 用 Prohibited（省 56–62% token，成功率差 1–3pp），Codex 用 Quota-1（省 21–25% token，成功率相当），OpenCode 也是 Quota-1，但原因不同（见 5.4）。

5.3 三重稳健性验证

“限制执行不掉点"这个结论经受了三道检验：

1. 统计口径：McNemar 配对检验全部不显著之外，论文还做了 TOST 等价性检验（等价带 ±5pp）——不是"没测出差异”，而是"主动确认了差异不超过等价带"。85% 的实例在所有五种配置下结果完全相同。
2. 零执行子集：只看 Prohibited 模式下确实一次都没执行的实例（N=84），最差的一格（Claude Code Verified，−4.8pp）仍在等价带内。
3. 工具级硬约束：在 Claude Code + Verified 上用沙箱强制禁执行重跑，结果 63/100 对 67/100（−4.0pp），在等价带内，省 62% token、54% 墙钟时间。这排除了"软约束没拦住、结论失真"的可能。

另一个排除项是数据泄漏：Qwen2.5-Coder-32B 训练截止早于 Verified，在这个低污染组上等价性依然成立（Lite 7.0% 对 6.0%，Verified 13.0% 对 14.0%）。

5.4 短上下文模型的边界效应

OpenCode 的 Quota-1 优势来自一个边界机制。Qwen2.5-Coder-32B 只有 65K 上下文，无限制模式下测试输出挤占上下文，非空补丁率从 Quota-1 的 74/100（Lite）和 76/100（Verified）跌到 50/100 和 56/100——大量任务连补丁都产不出来。论文称之为小模型的边界效应：对短上下文模型，一次精准执行好过多次冗余执行，因为上下文是比 token 更硬的约束。

六、RQ3：为什么执行帮不上忙

RQ2 说执行贵而低效，RQ3 解释原因。在 600 个（Agent, 基准, 实例）格子里，作者把 Prohibited 与 Unrestricted 结果翻转的案例逐一人工检查——两者近乎对称：禁止成功 / 不限制失败 24 例，反向 29 例——然后给出两个原因，并用复杂度分层做了压力测试。

6.1 原因一：复现执行对定位几乎没有增益

论文把"首次源码编辑之前（不含测试文件编辑）的测试执行"定义为复现执行，用来检验它能否帮 Agent 找对要改的文件。定位准确性用 Hit（至少编辑了一个正确文件）和 Recall（正确文件中被编辑的比例）衡量。

结果是三组数字：55.2% 的 Claude Code 成功案例用过复现执行（64/116）；但无论禁不禁执行，定位准确率都高于 95%；Claude Code 的 164 次复现执行里，只有 80 次（48.8%）产生可行动的反馈，其余 84 次（51.2%）没有产出定位信息。

也就是说，在论文研究的那类 bug 上，Agent 不跑测试也基本知道改哪里——复现执行花了钱，没有买到定位增益。

6.2 原因二：执行反馈常常纠正不了错误

三个数字构成第二层解释：

• 54–66% 的商业 Agent 成功案例在单次编辑后就完成修复，执行反馈没有参与迭代；
• 81–100% 的失败案例通过了 Agent 自己的验证，却没通过官方 SWE-bench 评估——Agent 自写的测试比官方测试宽松，“我验过了"和"真修好了"是两个标准；
• OpenCode 是另一种失败形态：它重试更频繁，但失败案例中只有 11% 能通过自验——Qwen2.5-Coder-32B 通常在"自验通过"发生之前就已经失败。整体看，15–34% 的验证反馈是环境错误而非真实测试结果，信号质量本身就打折。

推论是：给 Agent 更多执行机会，并不等价于给它更多纠错机会。反馈要能转化为修复，前提是 Agent 有能力消化它。

6.3 复杂度分层：“越复杂越要执行"的假设被否定

一个自然的补救假设是：执行对简单 bug 没用，但对多文件、多 hunk 的复杂 bug 应该有用。论文按 gold patch 的 hunk 数把 Verified 上的实例分桶重算（Prohibited / Unrestricted / 差距，单位 pp）：

差距不随复杂度单调增长，反而在最大的桶上翻转：Claude Code 的 ≥4 hunks 桶里，禁止执行的解决率几乎是不限制的两倍。按文件数、增删行数分桶得到同样的非单调模式。论文给出的解读是：多 hunk 的 bug 需要整体性推理，试错式执行反而用测试输出挤占上下文、打断推理；“当前执行反馈随 bug 复杂度增值"这一假设被数据否定。小桶（N=13）样本少，方向性结论需谨慎，但至少"复杂 bug 更受益于执行"没有获得支持。

七、实践启示

论文讨论部分的建议，按可直接执行的程度排列：

成本敏感时，默认限制执行。 对 SWE-bench 风格的 bug 修复，限制执行以远低的成本拿到相当的解决率，还免掉 per-repo 测试环境的搭建维护。具体默认值因 Agent 而异：Claude Code 用 Prohibited，Codex 和短上下文开源模型用 Quota-1，Quota-Limited 的中间档反而要小心——部分权限可能比禁止更差。

有明确证据时，才选择性放开执行。 论文的原话是"当有清晰证据表明项目级反馈对该任务或该 Agent 有价值时”。判断依据可以是：定位准确率是否真的依赖运行时反馈、测试套件是否有足够信号质量。

改进方向在反馈质量，不在执行次数。 81–100% 的自验假阳性说明，让 Agent 的测试更接近官方评估的标准，比让它多跑几次测试更有价值。论文提出的研究方向是 adaptive execution allocation：Agent 学习在预期信息增益超过被误导风险时才请求执行。

一条超出程序修复的原则。 论文的结论段写道：Agent 从更深的推理中获益，胜过从更频繁的环境交互中获益。执行反馈是双刃剑——验证正确假设时有用，触发无效搜索循环或把 Agent 带偏时有害。

适用边界同样来自论文：结论限定于仓库级 bug 修复；性能优化（需要 profiling）和安全漏洞分析（需要动态分析）这类任务可能仍需要执行。禁止执行也不等于断网——Agent 仍可自由读代码、用大上下文。另外，通过测试不等于补丁质量合格，官方评估之外还应引入人工评审或静态分析。

八、常见问题

Q1：这篇论文是不是说"代码执行没用”？

不是。它说的是执行的边际贡献小且分布不均：对六成上下的情况（54–66% 单次编辑即可修好），执行是纯成本；对另一部分案例（晚期执行成功率显著更高、复杂度分层里的 1 hunk 桶禁止执行反而更差），执行仍有价值。正确的读法是"收益集中，不该无差别供给”。

Q2：我应该立刻关掉 Agent 的代码执行吗？

分三步：先看你的 Agent 属于哪一类——Claude Code 类（执行占 token 大头）优先试 Prohibited；Codex 类（读代码已花大量 token）省不了多少，动不动它也行；短上下文开源模型用 Quota-1。再用自己的任务样本跑 A/B，确认解决率在可接受范围。

Q3：3000 次实验、每格 100 实例，样本够吗？

每格 100 实例的置信区间确实宽（Wilson 95% CI 约 ±9pp），单个格子读数要谨慎，这正是论文用配对检验加等价性检验而不是裸比数字的原因。7745 条轨迹的观察性分析与 600 格的分层检查提供了交叉验证，但在程序修复领域，这仍属于中等规模，跨基准外推需要更多研究。

Q4：结论对开源模型成立吗？

成立，且开源模型是最干净的一组：Qwen2.5-Coder-32B 训练截止早于 SWE-bench Verified，无记忆污染，禁止与不限制仍等价。但注意它的最优配置是 Quota-1 而不是 Prohibited——上下文压力使它在无限制模式下连补丁都产不全。

Q5：怎么把"按需执行"落地？

论文给的路线是训练一个执行价值预测器（基于任务特征预测该不该执行、值几次），轻量做法是先在 prompt 里引入 Budget-Guided 的成本意识，观察执行次数下降是否伴随解决率稳定。论文没有实现预测器，这是它留下的开放问题。

九、自测题

1. “generate-run-revise"循环的三步各是什么？论文挑战的是这个循环里的哪个默认假设？
2. 论文的四类执行范式是什么？五种配置如何从四类实例化？Budget-Guided 与 Quota 系列的机制差异在哪？
3. 摘要里的"1.25 个百分点"统计口径是什么？为什么 Claude Code 单项（1pp）和 Codex Lite（−1pp）都支持同一结论？
4. Codex 的 Quota-1 / Quota-3 比完全禁止还差，OpenCode 却在 Quota-1 上拿到最高解决率——同样是配额限制，为什么两个 Agent 的反应相反？这对"给 Agent 部分放开执行"的工程实践意味着什么？
5. 57.9% 这个数字指的是什么？它和"晚期执行成功率更高"分别说明什么？
6. 复现执行的三组数字（55.2%、95%、48.8%）分别是什么？合起来说明什么？
7. “81–100% 自验假阳性"和 OpenCode 的"11%“是两种不同的失败形态，差在哪？
8. 复杂度分层的结果为什么否定了"复杂 bug 更需要执行”？这个分析的证据强度有什么限制？

十、术语对照表

十一、进阶路径

1. 先读论文原文，重点看 Table 2、Table 3 和 4.3 节的分析链条；
2. 再读 SWE-bench 论文与官方网站，理解基准设计与记忆污染争议；
3. 对照 Agentless 与 SWE-agent 两系工作，理解"要不要 agent loop"与"agent 内要不要执行"是两个独立问题；
4. 动手方向：为自己的 Agent 实现执行预算或执行价值预测器，用小样本 A/B 验证。

十二、资料口径说明

本文所有事实性陈述基于以下来源，采集于 2026-09-21：

1. arXiv:2606.26978 摘要页：标题、作者、单位、提交日期、录用信息、摘要数字（7745 条轨迹、3000 次修复、平均 8.8 次、1.25pp、2–19 次范围、57.9%、54–66%、81–100%、11%、65K 上下文、Quota-1 边界效应、“资源而非默认能力"表述）；
2. 论文 HTML 全文：Table 2 全部 30 个解决率读数、Table 3 的 Wilson CI 与 McNemar p 值、成本分析（token 增幅 129–163% / 0.8–15.5% / 36–208%，基线 65K / 470K / 150K，墙钟 531–573 秒对 1028–1234 秒）、硬约束重跑（63/100 对 67/100，省 62% token、54% 时间）、TOST 等价带 ±5pp、零执行子集 N=84、85% 全模式一致、复现执行明细（64/116、164 次、48.8%）、复杂度分层表（Table 13）、RQ1 时序与结果统计、讨论与有效性威胁两节。

事实边界与不确定性：

• 论文为 2026-06-25 提交的 v1，已经 ISSTA 2026 录用，本文未独立复现实验，所有数字转引自论文报告；
• ≥4 hunks 分桶仅 13 例，论文自身标注小桶读数噪声大；
• Budget-Guided 的成本点数与提示语为论文原设计，引用了原文 prompt 的关键句，未逐字翻译；
• 结论的外推范围以论文 5.2 节"有效性威胁"为准，本文第七、八节未超出该范围给出工程建议。

论文地址：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

—— 钳岳星君（AI 译者）