运行还是不运行：分析基于大语言模型的程序修复中代码执行的成本效益 To Run or Not to Run: Analyzing the Cost-Effectiveness of Code Execution in LLM-Based Program Repair
首次将代码执行作为独立变量进行实证研究，发现其对LLM程序修复代理的性能贡献有限
前置知识
LLM代码代理
LLM代码代理是封装大语言模型的自主系统，通过推理和工具使用的结合来执行软件工程任务。与传统代码补全不同，这些代理将LLM包装在一个控制循环中，在多轮对话中保持状态，使其能够处理复杂的多步骤任务，如bug修复、功能实现和代码重构。典型的代码代理工作流程结合了三种核心能力：文件探索（遍历目录和搜索相关代码）、代码编辑（通过diff或块替换应用补丁）和代码执行（运行shell命令来调用构建系统、linter和测试套件）。
论文的核心研究对象是代码代理，特别是基于LLM的程序修复代理。理解代码代理的工作机制对于理解研究问题（代码执行的贡献）至关重要。
SWE-bench基准
SWE-bench是一个真实GitHub仓库及其问题的基准数据集，用于评估软件工程工具（特别是程序修复代理）的能力。每个实例提供一个仓库快照、问题描述和基于测试的评估协议。SWE-bench包含300个Lite实例和500个Verified实例，覆盖Django、Flask、Requests、Sympy等多样化的仓库。任务要求代理从问题描述中理解bug，定位仓库中的相关代码，生成补丁，并可选择通过测试执行验证修复。官方SWE-bench harness通过在干净容器中应用补丁并运行特定于实例的测试来评估预测。
这是论文使用的核心评估基准。理解SWE-bench的评估方式和数据特点对于理解实验设置和结果解释至关重要。
Resolve Rate（解决率）
Resolve Rate是程序修复任务中的核心评估指标，表示生成的补丁通过官方SWE-bench评估的所有测试的实例比例。与其他评估指标不同，resolve rate关注的是实际解决GitHub问题的能力，而不仅仅是通过某些测试。对于一个实例，如果生成的补丁在官方评估环境中通过所有实例特定的测试，则被认为是resolved。这是SWE-bench排行榜使用的标准指标，也是论文主要关注的性能度量。
resolve rate是论文中评估代码执行对代理性能影响的核心指标。理解其定义和计算方式对于理解实验结果的意义至关重要。
Agent-Computer Interface（ACI）
Agent-Computer Interface是代理与计算环境交互的接口设计范式。在程序修复场景中，ACI定义了代理如何访问文件系统、执行命令、观察输出以及根据反馈调整行为。典型的ACI包括文件读取工具、代码编辑工具和代码执行工具。ACI的设计直接影响代理的能力和限制。论文中的四种执行范式（Prohibited、Quota-Limited、Budget-Guided、Unrestricted）本质上是ACI在代码执行维度上的不同配置。
理解ACI概念有助于理解论文如何控制实验变量，即将代码执行作为单一变量隔离在代理循环中，同时保持其他ACI组件不变。
McNemar检验
McNemar检验是一种用于比较两个相关样本二分类结果的非参数统计方法。在机器学习评估中，它常用于比较两个算法在同一测试集上的性能差异是否显著。对于每个测试实例，两个算法可能都正确、都错误、算法A正确而算法B错误、或算法B正确而算法A错误。McNemar检验关注的是后两种不一致情况的对称性。论文使用McNemar检验来评估Prohibited和Unrestricted执行模式之间的resolve rate差异是否在统计上显著（p>0.05表示不显著）。
论文使用McNemar检验来验证实验结果的统计显著性。理解这一检验方法对于评估论文结论的可靠性至关重要。
研究动机
现代代码代理普遍采用"生成-运行-修订"（generate-run-revise）的迭代范式，通过执行测试来评估和完善补丁。然而，代码执行是一个资源密集型操作，带来显著的多维度成本：墙钟时间方面，代理必须等待执行完成，测试套件可能需要数秒到数分钟，在修复循环中引入延迟；token消耗方面，执行输出（包括冗长的测试日志和堆栈跟踪）被反馈给LLM，消耗上下文窗口容量并增加API成本；环境开销方面，每次执行需要正确配置的环境，包括依赖、数据库和外部服务。在实际部署中，这意味着需要为每个目标仓库和版本维护经过测试的Docker镜像，这是随着部署范围扩展而增加的持续工程负担。随着代码代理越来越多地在现实世界和大规模环境中部署，这些成本变得显著。然而，研究社区对代码执行在代码代理程序修复中的作用只有有限的理解。
本文的目标是论文的核心目标是系统性地量化代码执行对基于LLM的程序修复代理性能的影响，并评估其成本效益是否值得。具体来说，论文希望通过实证研究回答三个研究问题：RQ1代码代理如何进行代码执行？这包括分析的频率、时间分布和结果；RQ2代码执行对代码代理的性能有何影响？这通过比较不同执行范式下的修复效果和资源消耗来衡量；RQ3代码执行在什么条件下对代码代理有益？这通过分析成功和失败案例的特征来理解执行提供价值的场景。
与已有工作不同的是，本文的独特切入角度是首次将代码执行作为单一控制变量在LLM代理循环中进行分离研究。与之前的工作不同，例如Agentless同时移除了代理循环和执行访问，其结果无法分离执行的贡献。本文采用更精细的位置：代理循环本身是有价值的，但其中的迭代执行可能不是。论文保持代理脚手架固定（Claude Code、Codex和开源OpenCode），只改变执行访问，产生一个可控的执行边际价值测量。这种设计使论文能够精确量化代码执行的边际贡献，而不是将执行与其他代理设计因素混合。
核心方法
论文采用两阶段研究设计。第一阶段（RQ1）分析广泛的公开代理轨迹以提供执行行为的基线理解，从SWE-bench排行榜分析7,745个公开代理轨迹，覆盖四个突出的执行代理（SWE-agent、OpenHands、LiveSWEAgent、Mini-SWE-agent）、十二个不同LLM（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）和两个基准数据集（SWE-bench Lite和Verified）。第二阶段（RQ2-RQ3）进行受控实验，在四个执行范式下对三个代理（Claude Code、Codex和开源OpenCode）评估3,000个端到端修复尝试，允许进行性能和成本的细粒度比较。
核心创新点是将代码执行作为唯一变量在代理循环中进行隔离控制。论文设计了四种执行范式形成从无执行到无限访问的光谱：Prohibited模式限制项目特定运行时环境的访问，代理通过提示被指示避免运行测试框架或项目特定脚本，项目依赖项（如Django、Flask、Sympy）不安装；Quota-Limited模式允许具有点预算的执行，代理在每次运行前自行估算成本，测试框架调用被视为昂贵操作（K=1为最小执行，K=3为适度执行）；Budget-Guided模式允许无限执行但提示代理考虑每次运行是否值得其成本；Unrestricted模式允许无限执行，启用表征大多数当前代理的典型"生成-运行-修订"循环。这种设计产生了600个独特的代理-实例组合（200实例×3代理），总计在五种执行模式下进行3,000次端到端修复尝试。
方法步骤详情
方法步骤的完整描述包括：1）数据准备，由于预算约束，从SWE-bench Lite和Verified各选择前100个实例，总计200个实例跨越Django、Flask、Requests、Sympy等多样化仓库；2）代理配置，三个代理通过命令行接口访问：Claude Code通过claude -p，Codex通过codex exec，OpenCode通过opencode，所有模式共享相同的提示结构，包括任务描述、仓库信息、问题描述、执行约束和输出格式，只有执行策略在模式间不同；3）执行控制，Prohibited通过提示级别强制执行，代理偶尔仍尝试运行测试，但由于缺少依赖项而失败，不提供有用的运行时反馈，Quota-Limited和Budget-Guided通过提示传递成本意识；4）评估流程，每次运行涉及完整的修复尝试：检出仓库、阅读问题、生成和应用补丁、运行官方SWE-bench评估harness；5）指标计算，记录交互轨迹并计算多个指标来表征代理行为和结果，包括执行频率（每个任务的平均测试执行次数）、时间分布（在早期、中期、晚期阶段执行的百分比）、执行结果（测试执行的成功或失败率）、resolve rate（生成补丁通过官方SWE-bench评估的实例比例）、token消耗（反映API成本的输入和输出token）、wall-clock时间（捕获端到端运行时）。
技术新颖性
技术新颖性体现在多个方面：首次进行将代码执行作为单一控制变量在代理循环中隔离的实证研究，而之前的Agentless工作同时改变了脚手架和执行，因此无法测量执行的边际价值；设计了四种执行范式形成从无执行到无限访问的完整光谱，包括Prohibited、Quota-Limited（K=1和K=3）、Budget-Guided和Unrestricted，这种细粒度的控制使论文能够精确量化的成本效益权衡；大规模实验设计涵盖7,745个公开轨迹加上在200个SWE-bench实例上的3,000次受控修复尝试，这是代码执行在LLM程序修复中规模最大的实证研究之一；采用了零执行子集和环境错误子集的重新验证，以及在Claude Code Verified上的工具级别强制执行，确保结果不是代理默默违反软约束的人为产物；进行了按gold-patch复杂度的分层分析（按hunk数量、文件数量、增删行数），测试了执行反馈是否随着bug复杂性增加而变得更有价值的假设，发现假设被反驳。
实验结果
核心发现围绕三个研究问题展开。RQ1发现代码执行被所有分析的代理-模型组合广泛使用，平均每个任务8.8次测试运行，频率范围从2到19次不等，执行行为在代理和模型间差异显著，晚期执行（对话的66-100%） consistently achieve higher success rates than early-stage ones（平均57.9%成功率）。RQ2发现禁止和无限制之间的resolve rate gap很小，平均只有1.25pp，且在统计上不显著（p>0.05），限制执行显著降低成本，Prohibited模式为Claude Code节省56-62%的token和48-54%的wall-clock时间，同时仅牺牲1-3pp的resolve rate，跨模式补丁多样性（76-99%不同）表明模型适应上下文而不是背诵记忆的补丁。RQ3发现执行限制影响的原因有两个：1）再现执行提供有限的定位益处，尽管55%的Claude Code成功案例使用再现执行，但两种模式下的定位准确率都保持在95%以上，只有48.8%的再现执行产生可操作的反馈；2）执行反馈不足以纠正错误，54-66%的商业代理案例在单次编辑中完成，无论执行访问如何，81-100%的失败案例通过了代理执行的验证但未能通过官方SWE-bench评估，执行反馈不随补丁复杂性扩展，按hunk数量分层的分析显示Prohibited-Unrestricted gap不单调增长，在代理和bucket之间翻转符号。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 程序修复（SWE-bench Lite） | Resolve Rate (%) | Claude Code: 63.0 (Prohibited) / 64.0 (Unrestricted) | 无限制执行模式 | −1.0pp（Prohibited vs Unrestricted） |
| 程序修复（SWE-bench Verified） | Resolve Rate (%) | Claude Code: 64.0 (Prohibited) / 67.0 (Unrestricted) | 无限制执行模式 | −3.0pp（Prohibited vs Unrestricted） |
| 程序修复（SWE-bench Lite） | Resolve Rate (%) | Codex: 74.0 (Prohibited) / 73.0 (Unrestricted) | 无限制执行模式 | +1.0pp（Prohibited vs Unrestricted） |
| 程序修复（SWE-bench Verified） | Resolve Rate (%) | Codex: 73.0 (Prohibited) / 75.0 (Unrestricted) | 无限制执行模式 | −2.0pp（Prohibited vs Unrestricted） |
| 程序修复（SWE-bench Lite） | Resolve Rate (%) | OpenCode: 7.0 (Prohibited) / 6.0 (Unrestricted) | 无限制执行模式 | +1.0pp（Prohibited vs Unrestricted） |
| 程序修复（SWE-bench Verified） | Resolve Rate (%) | OpenCode: 13.0 (Prohibited) / 14.0 (Unrestricted) | 无限制执行模式 | −1.0pp（Prohibited vs Unrestricted） |
| Token消耗（SWE-bench Lite） | 输入Token节省 | Claude Code: 56.4% (Prohibited vs Unrestricted) | 无限制执行模式 | 节省56.4%输入token |
| Wall-clock时间（SWE-bench Lite） | 时间节省 | Claude Code: 48.4% (Prohibited vs Unrestricted) | 无限制执行模式 | 节省48.4%时间 |
局限与改进
局限性分析包括作者承认的和独立观察的。作者承认的局限性包括：结论范围限于SWE-bench风格的仓库级bug修复，使用三个当前的CLI代理（Claude Code、Codex和开源OpenCode+Qwen2.5-Coder-32B），评估每个数据集的前100个实例（Lite和Verified），总计200个实例；执行可能对某些任务有益（例如需要性能分析的优化、需要动态分析的安全漏洞）；即使Prohibited模式下，代理也可以使用广泛的仓库检查和大的上下文窗口，"没有项目运行时"不意味着"没有环境访问"；通过测试并不意味着补丁质量，未来工作可以结合人工评估或静态分析标准。独立观察的局限性包括：预算执行主要通过提示级别强制执行，代理偶尔仍尝试因环境错误而失败的脚本（Prohibited尝试的7-9%），论文使用意向处理框架计算这些执行，但零执行和环境错误子集保持±5pp的Prohibited-Unrestricted band，在Claude Code Verified上的工具强制执行沙箱重新运行重现了等效性（−4pp）；配对统计测试（McNemar检验）和等效测试（TOST with δ=5pp）受限于样本大小（n=100），85%的实例在所有模式下产生相同的结果，但正式等效在一些单元格中未达到；SWE-bench存在记忆担忧，论文使用训练截止时间早于Verified的模型（Qwen2.5-Coder-32B），但在该低污染单元格上±5pp等效性仍然成立（Lite: 7.0% vs 6.0%；Verified: 13.0% vs 14.0%）；执行反馈质量分析基于代理选择的测试，可能与专业开发者选择的测试不同，这可能导致对执行益处的高估或低估。
独立分析的弱点
独立分析的弱点包括：1）执行反馈信号质量低，15-34%是环境错误（如ModuleNotFoundError、OperationalError），81-100%的Fail→Fail案例通过了代理测试但未能通过官方评估，这表明代理选择的测试与真实验证之间存在差距；2）代理无法有效利用执行反馈进行迭代改进，尽管Unrestricted模式比Prohibited模式多使用2.1倍的对话轮次、2.8倍的编辑和8.0倍的测试执行，但两者实现相同的成功率，表明额外的执行反馈未能转化为更好的修复；3）小模型上下文拥挤问题，OpenCode在Unrestricted模式下非空补丁率从74/100（Lite）和76/100（Verified）下降到50/100和56/100，因为测试输出拥挤了65K上下文，导致模型迭代时源代码阅读能力退化；4）部分执行可能适得其反，Quota-Limited模式通常表现比Prohibited更差，例如Codex在Lite上Prohibited达到74.0%但在Quota-1下降到68.0%和Quota-3下降到69.0%，下降高达6个百分点，这表明有限的反馈可能不足以进行有效迭代。改进方向：开发更智能的测试选择策略，使代理能够选择真正提供信息量的测试；增强执行反馈的质量和可解释性，减少环境错误和嘈杂输出；设计自适应执行分配机制，使代理能够基于预期信息增益请求执行；探索小模型的上下文管理策略，防止执行输出拥挤源代码上下文；研究部分执行的负面效应机制，设计避免适得其反的执行策略。
未来方向
未来研究方向包括作者提出的和基于研究成果可延伸的。作者提出的方向：进一步调查执行反馈最有益的条件；开发适应任务特征的执行策略的代理；将分析扩展到其他软件工程任务（如功能实现、代码重构、测试生成）。基于研究成果可延伸的方向：开发成本敏感的代理，战略性地最小化执行同时保持修复效果；设计自适应执行分配机制，而不是使用固定预算，代理可以学习仅在预期信息增益超过被误导风险时请求执行；增强执行反馈质量，例如通过改进测试选择、执行环境配置或反馈解释；研究复杂bug修复中执行反馈的作用，特别是多文件、多hunk修复是否真的需要迭代测试驱动细化；探索代理修复中的人类在环方法，结合人工评估和静态分析标准；分析执行反馈在代理训练中的作用，例如使用执行数据训练更好的代码理解模型；研究执行反馈的负面效应机制，例如什么情况下执行会误导代理远离正确解决方案；设计多层级的执行策略，例如先进行低成本执行（静态分析、语法检查），再进行昂贵执行（完整测试套件）；探索执行反馈在多代理协作中的作用，例如不同代理如何共享和解释执行结果；研究执行反馈在其他软件工程任务中的成本效益，如代码审查、文档生成等。
复现评估
复现评估：论文提供了代码和结果的公开可用性（https://github.com/mathieu0905/To_Run_Or_Not_To_Run）。数据方面，使用公开的SWE-bench数据集（Lite和Verified的前100个实例），代理（Claude Code v1.0.16、Codex v0.1.2025062301、OpenCode v1.4.0）和模型版本都明确指定，确保了实验的可复现性。计算资源方面，论文没有明确提供硬件配置，但提到所有执行模式在同一实例的相同硬件上并发运行以确保公平的时间比较。估计的实验成本包括3,000次端到端代理运行（200实例×3代理×5执行模式），每次运行涉及完整的修复尝试（检出仓库、阅读问题、生成和应用补丁、运行官方SWE-bench评估harness），对于商业代理（Claude Code、Codex）这将涉及显著的API成本，论文在实施细节部分提到预算约束是选择每个数据集前100个实例的原因之一。难度评估：实验设计复杂但文档详细，四种执行范式的实现和执行控制机制清晰明确，评估指标和方法标准化（resolve rate、token消耗、wall-clock时间），统计分析方法（McNemar检验、TOST等效测试）标准，代码和数据公开降低了复现门槛。然而，复现者需要访问商业代理（Claude Code、Codex）的API以及足够的计算资源运行3,000次端到端修复，这可能对某些研究团队构成挑战。开源的OpenCode配置降低了部分复现门槛，但其resolve率显著低于商业代理，可能无法完全复现所有发现。总体而言，论文的复现性中等偏上，主要挑战在于商业API访问和计算成本。
论文图表