Benchmark 通胀，SWE-bench 饱和，你的模型多少分？无所谓，反正它已经不能区分任何东西了

BENCHMARK · FORENSICS · 2026

93.9% 之后，SWE-bench 已经死了 编码 Agent 评估的物理上限与下一代范式

OpenAI 官方宣布弃用、METR 发现 50% 的"通过"PR 不会被合并、验证器错误率 32%

—— 当所有模型都考 95 分，考试本身就失去了意义

SWE-bench Verified Benchmark Saturation Terminal-Bench FrontierSWE

阅读对象：使用 LLM 编码工具的工程师、做模型选型的 Tech Lead、关注 AI 评估体系的研究者。你需要知道 SWE-bench 是什么，但不需要知道它的具体题目。

▎ TABLE OF CONTENTS

01 · 饱和时间线：从 3% 到 93.9% 只用了 22 个月

02 · 三重死因：污染 × 偏斜 × 验证器噪声

03 · METR 发现：50% 的"通过"不会被合并

04 · 当前横评：6 个模型 × 5 个 Benchmark

05 · 饱和的数学：为什么 90% 以上没有区分度

06 · 下一代评估：四个候选范式

07 · 对工程选型的实际影响

08 · Checklist：Benchmark 通胀时代的模型选型

2026 年 7 月，SWE-bench Verified 的拥堵分数（congestion score）达到 93.9%。这意味着排名前几的模型在这个曾经被视为"编码能力黄金标准"的基准上，已经几乎没有区分度。OpenAI 在官方博客中正式宣布弃用 SWE-bench Verified，理由是"每一个前沿模型都能逐字复现金标准补丁"——这不是模型太强，是考试泄题了。

更致命的发现来自 METR（Model Evaluation & Threat Research）：他们人工审查了 SWE-bench 上"通过测试"的 PR，发现大约 50% 不会被真实项目的维护者合并。通过了测试 ≠ 解决了问题 ≠ 写出了可维护的代码。Benchmark 在测量一个与现实脱节的信号。

这篇文章做三件事：用数据还原 SWE-bench 从诞生到饱和的完整时间线，拆解饱和背后的三重结构性原因，然后评估四个"下一代"候选基准的物理可行性。不是观点文，是取证报告。

"We found two major issues: every frontier model could reproduce verbatim gold patches, and the verifier has a 32% error rate in DeepSWE's audit." —— OpenAI, "Why We No Longer Evaluate SWE-bench Verified", 2026

01 · 饱和时间线：从 3% 到 93.9% 只用了 22 个月

SWE-bench Verified 是 500 道真实 GitHub issue 修复题的人工验证子集。2023 年发布时，最强模型（GPT-4 + scaffold）的解决率约 3%。到 2026 年中，拥堵分数达到 93.9%。整个生命周期：

SWE-BENCH VERIFIED · 饱和时间线

2023.10 发布，GPT-4 scaffold ≈ 3%

2024.04 Claude 3 Opus + agent ≈ 22%

2024.10 专用 scaffold 优化 ≈ 50% ← 半程

2025.06 Claude Opus 4 + agent ≈ 72%

2026.02 Top-10 均 > 70%，头部 ≈ 77%

2026.05 Claude Opus 4.7 ≈ 87.6%

2026.07 拥堵分数 93.9% ← 饱和，区分度丧失

22 个月，从 3% 到 93.9%。平均每月提升 4.1 个百分点。但注意：这不是线性增长——前 12 个月走了 47 个百分点，后 10 个月走了 44 个百分点。增速并没有放缓，这说明饱和不是"模型进步变慢了"，而是"考试本身被攻克了"。

图 1 · SWE-bench Verified 分数时间线：22 个月从 3% 到 93.9%

02 · 三重死因：污染 × 偏斜 × 验证器噪声

SWE-bench 不是被"更强的模型"杀死的。它是被三个结构性缺陷杀死的。

死因 ① · 数据污染（Data Contamination）

OpenAI 的发现：每一个前沿模型都能逐字复现金标准补丁（gold patch）。这意味着 SWE-bench 的题目和答案已经以某种方式进入了训练数据。500 道题来自公开 GitHub 仓库——这些仓库本身就在训练语料中。当模型"记住"了答案，分数测量的不再是编码能力，而是记忆容量。

死因 ② · 任务分布偏斜（Task Distribution Skew）

500 道题中，大量是"修改 1-3 个文件、改动 < 20 行"的简单 bug fix。真正需要跨文件重构、理解复杂业务逻辑的题目占比极低。当模型掌握了"简单 bug fix"的模式后，分数迅速逼近天花板——不是因为模型真的能处理所有软件工程任务，而是因为 80% 的题目本来就是同一类简单任务。

死因 ③ · 验证器噪声（Verifier Error Rate 32%）

DeepSWE 的审计发现：SWE-bench 的自动验证器（判断 PR 是否"通过"）有 32% 的错误率。也就是说，近三分之一的"通过"或"失败"判定是错误的。当 benchmark 本身的测量噪声是 ±32%，而模型间的分数差只有 2-5 个百分点时，信号已经被噪声完全淹没。

信噪比推导

验证器错误率 ε = 32% → 有效信号 = 1 − ε = 68%

模型 A 得分 87.6%，模型 B 得分 85.0% → Δ = 2.6pp

测量不确定度 ≈ ε × √(p(1−p)/n) ≈ 32% × √(0.87×0.13/500) ≈ ±4.8pp

Δ = 2.6pp < 不确定度 4.8pp → 两模型差异在统计上不显著

结论：在 32% 验证器错误率下，SWE-bench Verified 上 5 个百分点以内的分数差异不具备统计显著性。任何基于这种差异的"模型 A 比模型 B 强"的声明，都是噪声解读。

图 2 · SWE-bench 的三重结构性死因

03 · METR 发现：50% 的"通过"不会被合并

2026 年 3 月，METR 发布了一份关键研究：他们让真实项目的维护者审查 SWE-bench 上"通过所有测试"的 PR，评估这些 PR 是否会被实际合并到主分支。

证据 · METR 2026.03

"We find that roughly half of test-passing PRs would not be merged into main." —— METR, "Many SWE-bench-Passing PRs Would Not Be Merged into Main", 2026-03-10

这意味着什么？SWE-bench 的"通过"标准是"所有现有测试通过"。但真实世界的代码审查标准远不止于此：代码风格、可维护性、是否引入技术债、是否符合项目架构、是否有更好的解法——这些维度完全不在 benchmark 的测量范围内。

用测量学的语言说：SWE-bench 的构念效度（construct validity）出了严重问题。它声称测量"软件工程能力"，但实际测量的是"让现有测试套件通过的能力"。这两个构念之间的相关系数，根据 METR 的数据，最多只有 0.5。

图 3 · "测试通过"≠"可合并"：METR 的 50% 鸿沟

04 · 当前横评：6 个模型 × 5 个 Benchmark

既然 SWE-bench Verified 已经饱和，那当前前沿模型在多个编码基准上的真实分布是什么？

Kimi K3（Moonshot AI, 2026.07）

Terminal-Bench 88.3% FrontierSWE 81.2% BrowseComp 91.2% SWE Marathon 42.0

2.8T MoE / 32B 激活 / 开源权重

Claude Opus 4.7 / 4.8（Anthropic, 2026）

SWE-bench Verified 87.6% SWE-bench Pro 69.2%

闭源 / 编码 Agent 标杆

GPT-5.6 Sol（OpenAI, 2026.07）

AA Coding Index 58.9 Terminal-Bench 85.0% (AA)

闭源 / 官方已弃用 SWE-bench Verified

Claude Fable 5（Anthropic, 2026.07）

AA Coding Index 59.9 SWE-bench Verified ~90%+

闭源 / 最新编码专用模型

关键观察：在 SWE-bench Verified 上，头部模型全部挤在 85-94% 的窄带内（区分度 < 10pp）。但在 SWE-bench Pro（更难的版本）上，最高分只有 69.2%——区分度恢复到 30+ pp。在 Terminal-Bench（真实终端操作）上，分数分布在 70-88%。在 SWE Marathon（长程编码）上，最高分只有 42%。越接近真实工程场景，分数越低，区分度越大。

图 4 · 同一模型在不同 Benchmark 上的分数分布：越难越有区分度

05 · 饱和的数学：为什么 90% 以上没有区分度

Benchmark 饱和不是一个模糊的"感觉"，它有精确的数学结构。

BENCHMARK 区分度的数学定义

区分度 D = (Smax − Smin) / (1 − ε)

其中 Smax, Smin = 头部/尾部模型分数，ε = 验证器错误率

SWE-bench Verified: D = (93.9 − 85.0) / (1 − 0.32) = 8.9 / 0.68 = 13.1

SWE-bench Pro: D = (69.2 − 35) / (1 − 0.10) = 34.2 / 0.90 = 38.0

Terminal-Bench: D = (88.3 − 55) / (1 − 0.05) = 33.3 / 0.95 = 35.1

SWE-bench Verified 的有效区分度只有 13.1，而 SWE-bench Pro 和 Terminal-Bench 分别是 38.0 和 35.1——接近 3 倍差距。当 D < 15 时，benchmark 进入"噪声区"：任何排名都可能是验证器随机错误的产物。

另一个视角：信息论上限。500 道二值题（通过/不通过）的最大信息量 = 500 bits。当模型正确率 > 90%，剩余不确定性 < 50 bits。而验证器噪声引入的不确定性 ≈ 500 × H(0.32) ≈ 500 × 0.90 = 450 bits。噪声信息量（450 bits）远超信号信息量（50 bits）。从信息论角度，这个 benchmark 已经信息性死亡。

图 5 · 区分度 D 随饱和度的衰减：90% 以上进入噪声区

06 · 下一代评估：四个候选范式

SWE-bench 之后，什么能接棒？目前有四个主要候选。

① SWE-bench Pro（OpenAI, 2025）

1,865 道题 / 41 个仓库 / 更难的任务分布。当前最高分 69.2%（Claude Opus 4.8），区分度良好。

物理上限：仍然是"修 bug"范式，仍然用测试通过率做验证。预计 12-18 个月后也会饱和。

② Terminal-Bench（2025–2026）

真实终端环境操作：文件系统、进程管理、网络调试、多步骤 shell 任务。Kimi K3 最高 88.3%。

物理上限：测量"操作能力"而非"设计能力"。能测"会不会用工具"，测不了"架构设计好不好"。

③ SWE-EVO（长程演化任务）

不是修一个 bug，而是在一个代码库上连续完成多个相关任务（feature → refactor → bug fix → test）。测量长程规划和代码演化能力。

物理上限：评估成本高（需要多轮交互），题目数量有限，难以大规模自动化评分。

④ FrontierSWE（前沿级真实任务）

从真实开源项目中提取的高难度任务，需要跨文件理解、架构决策、多步骤实现。Kimi K3 得分 81.2%。

物理上限：题目来源有限（高质量真实任务稀缺），且仍然依赖测试通过做验证。

核心矛盾：所有候选方案都面临同一个物理限制——自动化评分 vs 真实工程质量的不可调和性。测试通过率可以自动化，但代码质量、可维护性、架构合理性无法自动化。任何依赖"通过/不通过"二值信号的 benchmark，最终都会被饱和。真正的解法可能是 LLM-as-judge（用模型评模型）或人工审查抽样，但两者的成本和一致性都是问题。

图 6 · 下一代 Benchmark：难度 × 区分度 × 抗污染能力三维定位

07 · 对工程选型的实际影响

Benchmark 通胀不只是学术问题，它直接影响工程决策。当你看到"模型 A 在 SWE-bench 上比模型 B 高 2 个百分点"时，正确的反应是：忽略它。

在 Benchmark 通胀时代，模型选型的正确姿势：

选型新规则

① 看多个 benchmark 的分布，不看单点分数。如果一个模型在 SWE-bench Pro、Terminal-Bench、FrontierSWE 上都排前列，比只看一个 SWE-bench Verified 93% 有意义得多。

② 看"未饱和区"的分数。SWE Marathon 42%、SWE-bench Pro 69%——这些分数还有 30+ pp 的区分空间，比 93% vs 91% 有意义。

③ 在自己的代码库上跑。任何公开 benchmark 都不如"拿你项目的 10 个真实 issue 让模型修"来得直接。

④ 关注 scaffold 而非裸模型。同一个模型在不同 agent scaffold 下分数差 20+ pp。你用的是 scaffold，不是裸模型。

08 · Checklist：Benchmark 通胀时代的模型选型

BENCHMARK 通胀时代 · 选型 CHECKLIST

☐ 不要基于 SWE-bench Verified 上 < 5pp 的差异做决策（噪声 > 信号）

☐ 至少看 3 个不同维度的 benchmark（编码 / 终端操作 / 长程任务）

☐ 优先参考"未饱和"基准（SWE-bench Pro < 70%、SWE Marathon < 50%）

☐ 检查 benchmark 的验证器错误率（> 10% 的 benchmark 慎用）

☐ 检查数据污染报告（模型是否能复现 gold patch）

☐ 在自己的代码库上建 10-20 道内部测试题（最可靠的 benchmark）

☐ 关注 scaffold/agent 框架的分数，而非裸模型分数

☐ 区分"测试通过"和"代码可合并"（METR 的 50% 鸿沟）

☐ 跟踪 benchmark 的饱和度曲线（当 top-5 分数差 < 5pp 时，该 benchmark 已死）

☐ 每季度重新评估（benchmark 半衰期约 12-18 个月）

KEY TAKEAWAY

当所有模型都考 95 分，考试就死了。 SWE-bench 的三重死因：污染 × 偏斜 × 32% 验证器噪声。

下一代评估必须测量"代码能不能被合并"，而不是"测试能不能通过"。 在此之前，最可靠的 benchmark 是你自己代码库里的 10 个真实 issue。

延伸阅读

[1] OpenAI. "Why We No Longer Evaluate SWE-bench Verified." openai.com, 2026.

[2] METR. "Many SWE-bench-Passing PRs Would Not Be Merged into Main." 2026-03-10.

[3] SWE-EVO. "Benchmarking Coding Agents in Long-Horizon Tasks." arXiv:2512.18470.

[4] Simon Willison. "SWE-bench February 2026 Leaderboard Update." 2026-02-19.

[5] CodingFleet. "SWE-bench Pro Explained: The New Standard." 2026.

#SWEbench #BenchmarkSaturation #CodingAgent #TerminalBench #ModelEvaluation