运行与否：分析基于 LLM 的程序修复中代码执行的成本效益

  • 关联论文：2606.26978
  • 作者：Tom
  • 更新：2026-07-23

一句话结论

LLM Agent 在 SWE-bench 上禁用代码执行后，修复成功率几乎不变（仅差 1.25pp），但仍平均消耗 8.8 次测试运行；当前 Agent 对执行的使用是「不加区分」的，执行应该被当作有明确成本收益权衡的资源，而非默认能力。

解决什么真问题

基于 LLM 的程序修复 Agent 普遍采用「generate-run-revise」范式：生成补丁 → 运行测试 → 根据结果修订。这个范式已成为 SOTA 系统的标准实践。但执行是有代价的——时间成本、Token 消耗、API 费用。更关键的是：执行在这些 Agent 中是否真的总是值得的？ 还是说 Agent 在很多情况下其实不需要执行就能解决问题，却仍然付出了执行的成本？

这是一个此前被忽视的问题：没有人系统性地衡量过执行行为本身的有效性，以及不同执行策略之间的成本收益比。

核心方法

双阶段实证研究：

Stage 1：大规模行为分析 - 数据来源：SWE-bench leaderboard 提交的 7,745 条 Agent traces - 分析维度：执行频率、时序分布、token 消耗、wall-clock time - 目的：描述真实世界中 Agent 执行行为的整体分布

Stage 2：受控端到端实验 - 实验对象：3 个 Agent（Claude Code、Codex、OpenCode） - 测试集：200 个 SWE-bench 实例 - 总修复尝试：3,000 次 - 4 种执行范式（four execution paradigms）：原文未列出具体是哪 4 种，但从上下文推断应包括：Unrestricted（完全自由执行）、Prohibited（禁止执行）、及两种中间状态 - 测量：resolve rate、token cost、wall-clock cost

关键指标：

late-stage execution = 在对话进度 66%-100% 区间执行的测试
early-stage execution = 在对话进度 0%-66% 区间执行的测试

关键实验与数据

指标 数据
平均测试运行次数 8.8 次/task
执行频率范围 2~19 次/task（因 Agent 和模型而异）
晚期执行成功率 57.9%（平均值，原文未给单 Agent 数据）
早期执行成功率 原文仅描述「晚期 > 早期」，具体数字未明确
Prohibited vs Unrestricted 修复率差距 仅 1.25 percentage points（p > 0.05，统计不显著）
测试模型 Claude Code, Codex, OpenCode

核心发现 3 条： 1. 执行被所有 Agent 不加区分地使用，但执行效益分布不均（concentrated rather than uniform） 2. 在 SOTA 商业模型上禁用执行几乎不影响修复率，但能显著节省 token 和时钟时间 3. 执行的价值主要体现在晚期（66%-100% 进度区间），早期执行往往是无用功

亮点与局限

亮点： - 首个系统性量化「代码执行」在 LLM Agent 程序修复中成本效益的研究 - 双阶段设计兼顾大规模行为描述（Stage 1）和因果性受控实验（Stage 2） - 在 ISSTA 2026 发表，经同行评审

局限： - SWE-bench 是人工精选的高质量 issue/PR 数据集，与生产环境代码库存在分布差异，结论可迁移性需验证 - 仅测试了 3 个 Agent，OpenCode 作为开源基线具体指哪个项目原文未明确 - 4 种执行范式的具体定义原文摘要未列出，细节需要读全文 - 被引为 0（本文为 2026 年 6 月预印本），长期影响待验证

对工程落地的启发

  1. 重新审视「执行即默认」的范式：如果你的 Agent 场景与 SWE-bench 类似（高质量短 issue、人工事先验证过可解），可能不需要那么频繁的执行——Prohibited 模式就能节省大量成本
  2. 执行时机策略：如果要在 generate-run-revise 中加入决策点，应优先在对话晚期（>66% 进度）才允许执行，早期倾向于直接生成
  3. 自适应执行策略：基于问题难度/类型动态决定是否执行，而非一刀切；对简单问题直接跳过执行，复杂问题才动用执行
  4. 成本核算纳入 Agent 框架：Agent 框架（如 LangChain、CrewAI）层面应提供执行成本估算 API，让 Agent 在决策时能参考成本收益

与同方向工作的关系

  • 与 SWE-bench 相关研究（如 [Wang et al., ICSE 2026] 关于 SWE-bench patch 正确性验证）互补：后者关注 patch 质量验证，前者关注执行行为本身
  • 与 Claude Code、Codex 等商业 Agent 的实际部署相关：这些 Agent 默认开启执行，但本文证明了在某些场景下这不是最优选择
  • 与 Agent 效率优化研究（如 Flash Bench 系列）正交但互补：后者关注模型推理效率，本文关注执行行为的决策效率

适合谁读

  • Dev Infra / Platform 工程师：在 CI/CD 中引入 LLM Agent 做自动修复时，需要评估开启/关闭执行的利弊
  • AI 编码工具产品（GitHub Copilot、Cursor 等）：基于本文数据可以设计更智能的执行决策模块
  • LLM Infra 研究者：理解「generate-run-revise」范式中执行资源的真实价值分布
  • 成本敏感的 AI 团队：需要量化 LLM Agent 调用成本的决策者

原文未明确：4 种执行 paradigm 的具体定义；OpenCode 的 GitHub 仓库地址；early-stage vs late-stage 执行成功率的具体数字；晚期执行高成功率（> 57.9%）的具体数字。

工程落地与核查（Jay）

事实核查结果

核查项 结论 备注
arXiv ID 2606.26978 ✅ 确认 ISSTA 2026 accepted paper, 23 pages
7,745 agent traces from SWE-bench ✅ 确认 abstract 直接陈述
3 agents: Claude Code, Codex, OpenCode ✅ 确认 abstract 直接陈述
200 SWE-bench instances ✅ 确认 abstract 直接陈述
3,000 end-to-end repair attempts ✅ 确认 abstract 直接陈述
平均 8.8 test runs per task ✅ 确认 abstract 直接陈述
执行频率 2~19 次/task ✅ 确认 abstract 直接陈述
Prohibited vs Unrestricted gap = 1.25pp, p > 0.05 ✅ 确认 abstract 直接陈述
late-stage 执行成功率 > early-stage ✅ 确认 abstract 直接陈述
"Execution benefit is concentrated rather than uniform" ✅ 确认 abstract 直接陈述
ISSTA 2026 接受 ✅ 确认 abstract Comments 确认
⚠️ 4 种 execution paradigm 具体定义 需 PDF abstract 仅说"four execution paradigms"，未展开
⚠️ early-stage 执行成功率具体数字 需 PDF abstract 仅说"late-stage higher"，未给数字
⚠️ token cost / wall-clock cost 节省具体数字 需 PDF abstract 仅定性说"substantial"，未给绝对值
⚠️ OpenCode 具体指哪个开源项目 需 PDF abstract 未明确，OpenCode 可能是泛指

生产三大坑

坑 1：SWE-bench 分布≠生产代码库——结论不能直接迁移

SWE-bench 的每个 issue 都经过人工筛选且必有一个正确 patch，生产环境的代码问题远更嘈杂（版本冲突、依赖地狱、缺失环境配置、多方贡献的混乱代码库）：

# ❌ 错误：直接拿论文结论在生产 CI 里禁用执行
# 论文在 SWE-bench（高质量精选数据）上测得 1.25pp 差
# 但生产代码库有：
# - 缺失的依赖/版本不兼容
# - 环境配置问题（非逻辑问题，执行才能发现）
# - 真实用户报告的模糊 bug（难以用 prompt 描述清楚）
# → 在这些场景执行的价值可能显著更高

# ✅ 正确：分场景选择性禁用
def should_execute(context: dict) -> bool:
    """
    简单 heuristic：基于问题类型/上下文决定是否执行
    - Bug 描述含具体错误信息 → 执行（环境问题可能性高）
    - Bug 是模糊功能需求 → 不执行（直接生成 patch 更高效）
    - 晚期（已有多轮反馈）→ 执行（信息充分，执行价值上升）
    """
    if "error message" in context["bug_description"].lower():
        return True  # 有具体报错，执行价值高
    if context["round"] > 3:
        return True  # 晚期，执行集中收益
    return False  # 早期模糊问题，减少执行

坑 2：1.25pp 差距是「统计不显著」而非「完全等价」——商业场景仍需谨慎

论文说 p > 0.05，差距统计不显著。但「不显著」≠「等价」：

  • 样本量 200 SWE-bench 实例 × 3 agents = 600 数据点；p > 0.05 可能只是统计功效不足
  • 商业 Copilot 类场景中，1.25pp 在海量调用量下 = 大量真实用户受影响
  • SWE-bench patch 是"有唯一正确答案"的问题；生产环境的 patch 质量评判更主观

建议：不要一刀切禁用执行，而是加执行预算上限（如每问题最多 3 次执行），这样既能省成本又保留执行能力。

坑 3：「晚期执行才有价值」在真实 Agent 中难以实现——进度感知需要显式建模

论文把「对话进度 66%-100%」定义为晚期，但真实 Agent 不知道自己当前在整体进度中的位置：

# ❌ 错误：以为 Agent 有准确的进度感知能力
# 很多 Agent 实现是 while True: generate → execute → revise
# 没有任何机制让它知道"我现在在整体进度的 70% 处"

# ✅ 正确：显式建模执行预算与问题复杂度预估
class ExecutionBudget:
    def __init__(self, max_executions: int = 3):
        self.max_executions = max_executions
        self.execution_count = 0
        self.last_patch_stable = False  # 连续两次 patch 未变 = 收敛信号

    def should_execute(self, patch_changed: bool) -> bool:
        # 预算耗尽 || patch 连续收敛 → 停止执行
        if self.execution_count >= self.max_executions:
            return False
        if not patch_changed and self.execution_count >= 1:
            return False  # 执行没有带来新 patch，继续执行收益递减
        return True

    def record(self, patch_changed: bool):
        self.execution_count += 1
        if not patch_changed:
            self.last_patch_stable = True

当前工程现状（2026）

  • Claude Code / Codex 默认开启执行：两者都是商业产品，默认执行行为无法关闭（Codex via API 可控）
  • SWE-bench 仍是 SOTA Agent 评测基准：2025-2026 年新进的 Agent 评测集（LiveCodeBench、Run-SWE 等）仍以 SWE-bench 为核心子集，结论有一定外推性
  • 执行优化是 2026 Agent 效率研究的热点方向：包括执行预算感知、选择性执行、自适应重试策略等；本文是这一方向的系统性奠基工作
  • 本文局限性补充：作者测试的 OpenCode（开源基线）具体实现不明，不同 OpenCode 实现在工具调用能力、测试框架支持上有巨大差异，可能影响结论可迁移性

工程决策树

你的 LLM Agent 程序修复场景
├── SWE-bench 类（高质量 issue + 必有正确 patch）→ 可考虑禁用执行，节省 8.8 次平均运行
├── 生产 CI/CD（模糊 bug + 环境问题多）→ 不要禁用执行，改为设上限（max 3 次）
├── 简单文本类修复（文档/注释/格式）→ 直接禁用，0 次执行
├── 复杂逻辑 bug（需运行才知对错）→ 全执行，但用进度感知早停
└── 预算极其敏感（大量调用）→ 用 patch 收敛检测替代硬性预算