性能优化基准真能测准编码Agent吗

arXiv:2607.01211

核心摘要

性能优化类基准（GSO / SWE-Perf / SWE-fficiency）这两年成了各家编码 Agent 刷分的主战场，排行榜上"X 模型又涨了 N 分"的新闻一波接一波。问题在于——这些分数真能反映 Agent 能力进步吗？这篇来自新加坡管理大学 + 上海交通大学的审计论文（Zhi Chen、Zhensu Sun（通讯）、Yuling Shi、David Lo、Lingxiao Jiang）泼了一盆冷水。他们把 740 个官方参考补丁放到 4 种不同云服务器上重放，发现只有 39/102 个 GSO、11/140 个 SWE-Perf、411/498 个 SWE-fficiency 任务能在所有机器上保住原基准的有效性规则；再把 8 个公开提交分别按 GSO 和 SWE-fficiency 的官方规则排序，28 对两两对比里 9 对结果相反；进一步看 SWE-fficiency 的调和平均打分法，最差的 10 个任务可以贡献 58.5%–82.8% 的分数权重。最后，把每个任务上的 10 个公开提交并起来看，450 个可重放任务里 384 个已经有提交追平或超过参考补丁——剩下的真"难"任务数量其实没想象中多。这是一篇审计型论文，不是新方法，但它指出的东西挺重要：排行榜分数更像"参考补丁稳不稳 + 评分规则怎么算 + 还有几个任务没人做过"这三件事的混合体，不能直接当 Agent 能力的读数。

论文信息

  • 标题：Are Performance-Optimization Benchmarks Reliably Measuring Coding Agents?
  • 作者：Zhi Chen、Zhensu Sun*（*通讯）、Yuling Shi、David Lo、Lingxiao Jiang
  • 机构：Singapore Management University、Shanghai Jiao Tong University
  • arXiv：2607.01211（cs.SE，2026 年 7 月 1 日提交）
  • 实验规模：740 个参考补丁 × 4 种 Google Cloud 机型 × 3 轮 = 12 种机器-轮次组合
  • 机型：Intel Cascade Lake、Intel Emerald Rapids、AMD Milan、AMD Turin，均为 64 vCPU + 256 GB
  • 数据截止：2026 年 4 月 30 日
  • 核心问题：参考补丁的跨机器有效性、评分规则对排名的影响、公开任务还剩多少"未解决"

这是一篇让人清醒的审计论文

先说清楚一点——这篇不是讲"我发明了个新方法把 Agent 提升 X 个点"的那种论文。它干的活是去挑现有基准的毛病。

你可能没留意到，但过去一年里各家新模型在 SWE-Bench Verified 涨不动以后，开始转向"性能优化类基准"作为新的跑分场。你在 Twitter 上看到的"SWE-fficiency 第一"、"GSO 涨 10 分"那种标题，比比皆是。

问题来了。SWE-Bench Verified 衡量的是"修没修对 bug"，是个相对干净、相对稳定的二元判断——要么测试通过，要么不通过。性能优化基准测的是运行时，而运行时是个非常娇气的东西：CPU 调度、缓存状态、内存带宽、机器微架构、还有进程邻居，都能让同一个 patch 测出完全不同的数字。Georges 那篇 OOPSLA 2007 的统计严谨 Java 性能评估里早就讲过这事——Mytkowicz 2009 那个著名的"不做任何明显错误操作也能产生错误数据"也是同一类问题。

所以作者要问的"灵魂三问"是：

  1. 参考补丁（reference patch）本身在跨机器下还稳不稳？ 基准假设官方参考优化在合理机器差异下都能复现并保持加速，这个假设经不经得起检验？
  2. 评分规则怎么把成百上千个任务压成一个分数？ 这个压法对排名的影响有多大？
  3. 多智能体（multi-agent）workflow 时代，看一个 leaderboard 提交还有没有意义？ 把每个任务的 10 个公开提交并起来看，难度分布到底是什么样？

我先放一张全文最让我皱眉的图在下面，它把 RQ1 的核心结论讲清楚了：

Figure 1：跨机器重放后，三大基准的参考补丁有效性大幅下降。GSO 从 102 个官方任务锐减到 39 个原始规则有效；SWE-Perf 从 140 个暴跌到 11 个；SWE-fficiency 从 498 个降到 411 个。SWE-Perf 的有效率只有 8%，是三者中最脆弱的。

图 1：跨机器重放后，三大基准的参考补丁有效性大幅下降。GSO 从 102 个官方任务锐减到 39 个原始规则有效；SWE-Perf 从 140 个暴跌到 11 个；SWE-fficiency 从 498 个降到 411 个。

第一眼看到这个数我愣了一下——SWE-Perf 的 140 个官方任务里，跨机器重放后只剩 11 个满足基准自己定的有效性规则。换算一下，92% 的任务在换台机器跑就不可信了。这就不是"参考补丁偶尔飘一下"的问题了，是基准在结构上对机器噪声很敏感。

下面我们就顺着 RQ1 → RQ2 → RQ3 一层层聊。

先认识下三个被审计的基准

基准 任务数 收录会议 核心规则（基准自己定义的）
GSO 102 NeurIPS 2025 同一工作负载下，参考 patch 相比 base 程序的 speedup ≥ 1.10×
SWE-Perf 140 ICML 2026 假设检验 \(p < 0.05\)，且运行时下降 ≥ 5%
SWE-fficiency 498 ICML 2026 speedup 在 40%–60% 区间（不同类型任务区间略不同），\(p < 0.05\)

数据来源：论文 TABLE I，机器型号来自 TABLE II（4 套 64 vCPU + 256 GB 的 n2 系列，仅处理器微架构不同）

三个基准都用了重复试验、离群值过滤、统计检验、参考补丁、负载选择规则，听着都很像正规军。但"正规军"和"扛得住跨机器审计"之间还差一截，作者要做的就是测这一截。

RQ1：参考补丁的"金标准"含金量到底有多高

RQ1.1：能跑起来 ≠ 能信

先看一个宽松的问题——参考补丁能不能在所有目标机器上重放？

答案是绝大多数可以。GSO 只有 4 个任务无法重放：1 个功能等价失败、1 个外部数据依赖缺失、1 个图像解码失败、1 个 x86_64 CPU 指令不可移植。SWE-Perf 只有 2 个失败，原因是评估镜像里的依赖缺失。SWE-fficiency 在作者的 4 套机器上零失败。

这部分其实不是痛点。可重放性更多是工程问题，修了依赖就能解决。

RQ1.2：跑得起来 ≠ 跑得对

真正让人警觉的是 RQ1.2。作者对每个参考 patch 跑两套检查：

  • Faster than base：参考 patch 在所有 12 轮机器-轮次组合里都比未优化版本快
  • Original-rule valid：参考 patch 在所有 12 轮里都满足基准自己定的有效性规则（speedup 阈值 + 统计显著）
基准 官方任务 Faster than base Original-rule valid
GSO 102 91（89%） 39（38%）
SWE-Perf 140 48（34%） 11（8%）
SWE-fficiency 498 470（94%） 411（83%）

看到 SWE-Perf 那 8% 没？92% 的官方参考 patch 在跨机器时连"显著比 base 快"都不能保证。

RQ1.3：SWE-Perf 为什么这么脆

第一种直觉解释可能是"SWE-Perf 的运行时噪声特别大"。作者直接测了噪声水平，结果不是这样——SWE-Perf 的中位任务内标准差只有 1.41 个百分点，比 GSO 和 SWE-fficiency 还低。

真正的问题是信号太弱。SWE-Perf 参考 patch 的中位运行时变化只有 −0.03%——几乎就是没动。101/138 个 SWE-Perf 任务的中位运行时变化在零的 5 个百分点以内晃悠。下面这张图把这个差异讲得最清楚：

Figure 2：参考补丁运行时变化分布。GSO 和 SWE-fficiency 的分布重心明显偏向负值（更快的方向），意味着参考 patch 真的带来了可观的加速；而 SWE-Perf 的分布几乎贴着 0% 这条线，正负 5 个百分点内堆了大部分任务。换言之，运行时噪声的量级接近甚至超过信号本身。

图 2：参考补丁运行时变化分布（4 种机型 × 3 轮 = 12 条曲线）。SWE-Perf 的分布几乎贴着 0% 这条线——信号量级跟噪声一个量级。

我个人读到这其实挺有感——之前在做性能优化相关项目的时候，最怕的就是这种"测出来比 base 快 1%，但你多跑两轮就分不清是真的快了还是机器抖了"的情况。SWE-Perf 把 5% 作为统计显著的下界，本意是想过滤掉噪声，但当参考 patch 的中位加速都只有 0.03% 时，这个门槛基本是设给空气的。

而 GSO 和 SWE-fficiency 之所以稳一些，作者在 RQ1 总结里给了一个工程上很扎实的解释：

SWE-Perf 把性能检查嫁接在仓库已有的 unit test 上，而 GSO 和 SWE-fficiency 用的是更显式面向性能的工作负载或自动生成的压力测试。前者的负载压力不够强，信号容易被运行时噪声淹没。

这是基准构建上的根本差异，不是机器噪声多少的问题。

RQ1 带给读者的直接含义

  • 任务在原机器上能跑≠ 任务在另一台机器上还快
  • 评分时只看到"通过/不通过"，看不到这个任务在跨机器下还稳不稳
  • 一个 Agent 提交即使在所有 4 套机器上都得了 0 分，也可能只是因为它碰到的 task 的"参考信号"在跨机器下本来就不存在

RQ2：评分规则是怎么"选美"的

光看 RQ1 你可能觉得"那我按基准官方排名看就行了"。RQ2 告诉你：官方排名本身也是被规则设计影响的。

两套规则，长得完全不一样

GSO 的 OPT@1：每个任务只有"成功/失败"两种状态（提交的 patch 是否达到或超过参考 patch 的 speedup）。最终分数 = 100 × 成功数 / 任务数 N。在 102 个任务下，1 个任务成功 ≈ 0.98 分。

\[\mathrm{OPT@1}(m) = 100 \cdot \frac{\#\text{reference-level successes}}{N}\]

这个规则非常"一视同仁"——一个任务 1 分，没有放大效应。

SWE-fficiency 的 SpeedUp Ratio (SR) + 调和平均：每个任务算一个 SR（提交 patch 的 speedup / 参考 patch 的 speedup），然后用调和平均聚合：

\[\mathrm{HM}(m) = \frac{N}{\sum_i 1/\max(\mathrm{SR}_{m,i}, 0.001)}\]

其中 \(SR_{m,i} = \mathrm{speedup}_{m,i} / \mathrm{speedup}_{ref,i}\)。

这个调和平均是后文所有"魔幻结论"的源头。简单一句话概括：调和平均对极小值非常敏感，因为每个任务进入分母时是 \(1/\max(SR, 0.001)\)。SR 越小，分母贡献越大。

28 对里 9 对排名反了

作者把 GSO 和 SWE-fficiency 共同拥有的 8 个公开提交拿出来对比——这 8 个提交两两配对能凑出 \(\binom{8}{2} = 28\) 对，官方 GSO 和官方 SWE-fficiency 的排名在 9 对上完全相反。其中 GPT-5 标签的提交在两个榜单上挪动了 5 个位次。

这意味着：同一个 Agent 在两个不同基准上"谁更强"这个结论，可能有三分之一是反的。你以为你看到的是模型能力差异，其实你看的是评分规则的差异。

把规则一换，相关性立刻变

作者还做了个更狠的实验——把同一份任务级输出，用另一个基准的规则重新打分：

  • 把 SWE-fficiency 的任务输出用 GSO 风格的"参考级通过率"重打分：Spearman 秩相关从 0.452 升到 0.762，discordant pairs 从 9 对降到 6 对
  • 把可获取的 GSO 任务输出用 SWE-fficiency 的调和打分法重打分：Spearman 秩相关只剩 0.238，反而有 11/28 对反转了，比官方对比还糟

这个方向上的反转是论文最想强调的"谐波打分"问题——它本身就是非常敏感的。

SWE-fficiency 的"最差 10 个任务"挑大梁

为了让"谐波打分到底敏感到什么程度"具象化，作者画了一张非常震撼的图：

Figure 3：每个提交最差 1、5、10 个任务对 SWE-fficiency 总分权重的累计贡献。橙色是 worst 5、绿色是 worst 10。Opus 4.5、GPT-5 这些"高分选手"的 worst 10 任务贡献了 70% 以上的分数权重——这意味着这个榜单的分数绝大部分由那 10 个最慢的任务决定。

图 3：每个提交最差 1、5、10 个任务对 SWE-fficiency 总分权重的累计贡献。worst 10 任务贡献了 58.5%–82.8% 的分数权重。

具体数字是：

  • Worst 1 任务贡献 6.3%–33.6% 的分数权重
  • Worst 5 任务贡献 31.4%–73.1%
  • Worst 10 任务贡献 58.5%–82.8%

举一个特别极端的例子：Claude Opus 4.5 上有个任务的原始 SR 是 0.00134（接近下限 0.001）——这一个任务就承担了它总分权重的 33.6%。

这是什么意思呢？SWE-fficiency 的"总分"更像是"最差 10 个任务的加权平均"，而不是"全部 498 个任务的总表现"。你看到的分数排名变化，很大程度上反映的是这个提交在那一两个极差任务上的"幸存情况"。

一个简单诊断：把下限从 0.001 提到 0.5

作者做了个bounded-penalty diagnostic：保留调和平均，但把 SR 的下限从 0.001 抬高到 0.5——也就是说，单个任务最多让分母增加 1 个单位（相对于 SR=1 任务），无法再用 999 个单位去淹没全局。

结果呢？8 个提交里有 6 个排名变了，28 对里有 8 对翻盘了。Opus 4.6 和 GPT-5.2 排到了 Opus 4.5 上面，GPT-5 反而掉下去了。

改一个地板常数就翻盘的排名，能信吗？ 我觉得作者这一问打到了点子上。

RQ3：剩下的难任务，到底有多难

光批评基准不够，RQ3 提了个相当重要的问题——假设多智能体 workflow 是新范式，那如果每个任务都让 10 个公开提交各跑一次，覆盖率会是什么样子？

这里只统计 RQ1 里"跨机器有效"的任务：39 个 GSO + 411 个 SWE-fficiency = 450 个（SWE-Perf 的 11 个有效任务没有可对比的公开 agent 数据，所以排除）。

跨 10 个提交看，任务覆盖率惊人

Figure 4：跨 10 个公开提交看，450 个跨机器有效任务的覆盖率。所有 450 个任务至少有 1 个通过测试的 patch；449/450 至少有一个 patch 跑得比 base 快；只有到"匹配或超过参考 patch"这一关，覆盖率才掉到 86%（SWE-fficiency）和 77%（GSO）。

图 4：450 个跨机器有效任务在 10 个公开提交并集下的覆盖率。

关键数据：

  • 100% 的任务（450/450）至少有 1 个公开 patch 通过测试
  • 99.8%（449/450）至少有 1 个公开 patch 跑得比 base 程序快
  • 85.3%（384/450）至少有 1 个公开 patch 匹配或超过参考 patch
  • 剩下的 66 个任务（9 个 GSO + 57 个 SWE-fficiency）是"被 10 个提交都没追上参考"的任务

注意一个反直觉的点：这些"难"任务里，65/66 都有比 base 快的 patch。也就是说"难"不是因为做不出来，而是因为没有做到参考 patch 那么快。

剩下的 66 个，离参考 patch 还差多远

Figure 5：66 个未达参考 patch 速度的任务里，"最好的公开 patch"相对参考 patch 的速度比。SWE-fficiency 57 个任务里 27 个已经达到参考速度的 90–100%，8 个在 10–50%；GSO 9 个里 6 个在 50–90%。多数任务离参考 patch 不远，主要问题在"最后一公里"。

图 5：66 个未达参考 patch 速度的任务里，最佳公开 patch 相对参考的速度分布。

GSO 最佳 patch 中位达到参考速度的 85.3%（要追平还需要 1.17 倍加速）。SWE-fficiency 最佳 patch 中位达到 87.9%（需要 1.14 倍加速）。一句话——任务不是"完全没做出来"，是"做出来但差最后一截"。

不是策略问题，是落地深度问题

论文最后一段还做了一个相当聪明的实验：把每个任务的"最佳公开 patch"和"参考 patch"做优化策略分类（沿用 Peng et al. 的高阶分类体系），看是不是"策略选错了所以追不上"。

结果是：

  • 66 个任务里 32 个用的策略类别跟参考 patch 一样
  • 剩下 34 个策略不同的任务里，11 个还是达到了参考速度的 90–100%
策略对齐情况 任务数 中位最佳/参考速度比
同类策略 32 89.8%（需要 1.12×）
不同策略 32 81.1%（需要 1.23×）
差距在 50% 以下 4（同）+ ?（不同） —

下面这张箱线图把分布差异画得最清楚：

Figure 7：66 个任务的最佳公开 patch 相对参考 patch 的速度比，按策略对齐分组。同类策略的中位稍高（90% 线附近），但两组分布大幅重叠——11 个不同策略的 patch 仍然达到 90%–100%，4 个同类策略 patch 反而掉到 50% 以下。

图 7：按策略对齐分组的最佳/参考速度比。重叠区显示策略不是核心决定因素。

结论：策略选择只解释了一小部分差距。更多时候，Agent 找到了一个有效的优化方向，但落地不够深、不够细致——比如少改了几条代码路径、没有把所有 hot call site 都替换、没有把对应的单元测试补上。

下面这张堆叠条形图把类别对齐下的速度比分布画得最直观——同类策略 32 个里 16 个达到参考的 90–100%，但也有 4 个掉到 50% 以下；不同策略 32 个里 11 个也达到了 90–100%。策略是不是选对，不是决定性变量。

Figure 6：按高阶类别对齐分组的最佳/参考速度区间分布。同类策略 32 个里有 16 个落在 90–100% 区间（蓝色），但也有 4 个掉到 10–50%；不同策略 32 个里仍有 11 个达到 90–100%。两组分布大幅重叠。

图 6：按高阶类别对齐分组的最佳/参考速度区间分布。两组都横跨从 10% 以下到 100% 附近的全谱。

我自己读到这里有一种"啊原来如此"的感觉——真正难的性能优化工作不是"找到那个聪明的 trick"，而是"把这个 trick 在整个 codebase 里彻底铺开并保证正确"。这跟实际工程经验是吻合的。

我的判断

把这三个 RQ 放一起看，这篇审计讲的是三件事：

  1. 参考补丁本身不稳——尤其 SWE-Perf 那种 8% 有效率的，你看到任务通过不一定能推出"这个 patch 真优化了"
  2. 排名规则本身不中立——SWE-fficiency 的谐波打分让 10 个最差任务决定一切，跟 GSO 那种"一视同仁"的规则根本不是同一种测量
  3. 榜单第一不一定是 Agent 真的强——多 Agent 协作时代，看一个提交能解释一半的故事；看一组提交并起来，难度版图完全不一样

我个人觉得这篇审计最重要的贡献不是新方法，而是它给基准使用者立了一个新的阅读姿势：

  • 别只看"提交 X 排名第一"——要看它在跨机器有效任务上得多少分
  • 别只看总分——要看每个任务在总分里的权重，看是不是被一两个极差任务拉下来
  • 别把"通过率"当"能力读数"——要分清楚"修对了"、"比 base 快"、"比参考快"这三件事

这些原则的工程价值在于：以后再看到"Agent X 在 GSO 上又涨 5 个点"这种新闻，先别急着发朋友圈。

几个我还存疑的地方

第一， 作者的 cross-machine 重放只覆盖了 4 套 Google Cloud 机型。真实生产环境的硬件差异可能更大（比如不同 NUMA 拓扑、不同 CPU 频率调度器、不同代工厂的芯片）。所以"92% SWE-Perf 任务失效"这个数可能保守也可能激进——取决于你信哪种推断。

第二， 作者自己承认"我们的 4 机器验证只是 a 步"——他们也只跑了 3 轮而不是 30 轮。这是一个保守的协议；理论上如果你跑足够多轮，"是否显著比 base 快"可能会有不一样的结论。但作者也解释了为什么不做更激进的统计：怕 runtime noise 变本加厉。

第三， RQ3 的"乐观估计"立场很对——它假设"10 个提交并起来"是合理的代理变量，但真实的多 Agent workflow 不会这样简单并——他们会用更复杂的 voting、reflection、debate 机制。所以 RQ3 给出的是一个上界，不是一个下限。这个上界已经够让人吃惊了：85% 的任务已经被追平了。

第四， 这篇审计对未来基准设计的呼吁我大部分同意——"让 Agent 自己找 hotspot"、"提供模糊的优化目标"、"度量多个资源维度"——但这些要求其实把难度上推了一个数量级。短期内可执行的下一代基准，大概率会先从"参考 patch 设得更高"或"评分规则加更多 robust 聚合"开始。

工程上可以立刻做的事

如果你也在用这些基准评估自己 Agent 的能力，建议至少做下面三件事：

  1. 报告 per-task 分数权重，不要只报总分——尤其是 SWE-fficiency，最差 10 个任务能解释 60%–80% 的总分。这个分布画出来，能看到是不是"一个 task 把总分搞砸了"
  2. 至少在 2 套机器上验证跨机器稳定性——不要只在基准原机器上测。可以用 Google Cloud 的 n2 和 n2d 两套机型，差异不大但够暴露问题
  3. 报告"匹配参考 patch 速度"和"通过测试"两套指标——不要合并成一个数。作者已经证明这两件事在 14.7% 的任务上是分开的

对基准设计者来说，这篇论文的潜台词很明确：谐波平均 + 0.001 下限 + 单变量运行时，已经被审计发现是过度敏感的。下一轮基准如果还是这套规则，迟早会被更强的 Agent 玩坏——就像当年 reward hacking 把 RLHF 玩坏一样。

结语

这篇审计论文给所有"性能优化基准排名"的使用者提了个醒：分数不是"能力"的直接读数，它是"参考 patch 跨机器稳定性 × 评分规则设计 × 任务覆盖度"这三件事的混合产物。

我没在论文里看到什么"惊天大瓜"，但那种"\(X\) 涨 \(Y\) 分"就被当成 Agent 能力进步的认知确实值得冷静一下。GSO 上 38% 的任务在跨机器下失效，SWE-Perf 上 92% 的任务在跨机器下失效，SWE-fficiency 的总分被 10 个最差任务主导 60%–80%——这些数字合起来就是在说：现在这些榜单上能拿第一的 Agent，真不一定比第二强多少；它们和第三、第四的差距，可能只是 1–2 个崩溃任务的幸存率。

下一步基准会怎么演化，我个人比较期待看到"贴近真实性能工程"的下一代——让 Agent 从 profile 出发找 hotspot、给模糊的优化目标、加 latency/memory/CPU 多维度度量、隐藏评测用的 stress test。这条路比"加更多任务"难得多，但可能是把"刷榜"和"真实能力"重新挂钩的唯一办法。

关键数字速查

指标 GSO SWE-Perf SWE-fficiency
官方任务数 102 140 498
可重放任务 98 138 498
跨机器满足 Faster-than-base 91（89%） 48（34%） 470（94%）
跨机器满足原规则有效 39（38%） 11（8%） 411（83%）
跨 10 提交匹配/超过参考 30/39（77%） — 354/411（86%）
跨 10 提交通过测试 39/39（100%） — 411/411（100%）

数据来源：论文 RQ1.2、RQ3.1

附：评分规则敏感性快查

  • 8 个公开提交、28 对两两对比，官方 GSO vs SWE-fficiency 有 9 对排名反转
  • SWE-fficiency 最差 10 任务贡献 58.5%–82.8% 分数权重
  • 把 SWE-fficiency 的下限从 \(f=0.001\) 调到 \(f=0.5\)：6/8 排名变化、8/28 对反转

觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我。