SWE-Bench Verified 走向终点：OpenAI 宣布停止采用并转向 SWE-Bench Pro
标题：⚡️SWE-Bench Verified 的终点 —— OpenAI Frontier Evals 与 Human Data 团队的 Mia Glaese、Olivia Watkins
摘要：是时候把前沿 Agent 评测提升到下一阶段了。
我们已公布 AIE Europe 和 AIEi Miami 的首批演讲嘉宾。到时见！
每次有新的前沿模型发布时，我们都会半开玩笑地提到 SWE-Bench Verified 分数上那些非常非常小的波动（比如 Opus 4.5 → 4.6 甚至还下降了 0.1%）。但真正分量不同的是：SWE-Bench Verified 的原作者团队亲自决定，不再继续报告该基准成绩。
我们很高兴邀请到 Mia Glaese（SWE-Bench Verified 原始共同作者，现任 Frontier Evals、Human Data 与 Alignment 团队研究副总裁）以及 Olivia Watkins（Frontier Evals 研究员）来分享她们为何决定 今天公开放弃 SWE-Bench Verified，并转而支持 SWE-Bench Pro：
关于 SWE-Bench 已经“饱和”的讨论，在社区里 一年前就已持续发酵 —— 大多数前沿模型的成绩长期稳定在约 80%。而 SWE-Bench 原始作者 仍坚持认为，真正能称为“触顶”的上限应更接近 87-95%。也就是说，即使只看 Verified 里筛选出的 500 个任务，理论上仍有不少提升空间。
[
但 OpenAI 对 138 个“问题任务”做了更深度分析（还额外引入至少 6 位工程师复核所有问题），并发现了推动这次决策的两个关键点：
-
剩余问题中有超过 60% 实际上不可解：Mia 在播客中解释，其中 49 个测试 定义过窄（会把功能上正确的提交也判错），另有 26 个测试“定义过宽”——要求了题目描述中从未提及的额外功能。
-
在测试集上训练（Training on test）：这就是典型的数据污染——很多时候并非有意作弊也会发生。SWE-Bench 题目来自大量模型训练常用的开源仓库，而 SWE-Bench 本身极高的流行度，也会让示例逐步泄漏到其他语料中。
这两类发现是同时出现的。团队最初是因为进一步排查 GPT-5.2 为何能解出“不可解”问题，随后才通过阅读 chain of thought 发现：模型知道了一些测试里隐含、但题目根本没写明的要求。
[
其中“污染”这一点最致命，也最容易展示。OpenAI 发现，从 OpenAI 自家模型开始，几乎 所有 前沿模型在只给出 SWE-Bench Verified Task ID、几乎不加提示的情况下，都能逐字复现评测中的 gold patch 或题目文本：
[
只要加一点人工复核，就能轻易发现某些 SWE-Bench Verified 题目按理应当无法通过……除非你事先知道答案。
[
对于长期关注这一领域的人来说，这一动作并不意外——Artificial Analysis 团队很早就停止按 SWE-Bench 排名（见这里），OpenAI 自己过去几个月也已开始报告 SWE-Bench Pro。但把这件事正式公开，仍是对学术界与产业界的重要贡献：毕竟长期以来，SWE-Bench Verified 一直被视为事实标准，而能做出这一“定调”动作的，也确实只有 OpenAI。
另一个值得肯定的点是：OpenAI 背书的这个新 benchmark 上，它自己并非 SOTA，甚至 Gemini 3 的表现也优于 GPT 5.x：
[
很明显，团队正在转向更深层的评测体系：更开放、基于 rubric 的评价方式，方向与他们在 GDPVal 上的工作相似。Mia 提到他们重点关注的能力包括：
-
更长周期任务（Longer-term tasks）
-
开放式设计决策（Open-ended Design Decisions）
-
代码质量与可维护性（Code Quality and Maintainability）
-
真实世界产品构建（Real world product building）
-
真实使用与影响跟踪（Tracking real-world usage and impact）
-
高强度人工评估（需要领域知识与主观质量判断的人类审查）
看起来，2026 年我们将迎来一整套新的前沿评测体系。我们也讨论了这项工作与 OpenAI Preparedness Framework 的关系——这是一个在 OpenAI 之外仍未被充分理解的框架。
-
00:00 认识 Frontier Evals 团队
-
00:56 为什么 SWE-Bench 停滞
-
01:47 Verified 是如何构建的
-
04:32 现实中的污染问题
-
06:16 不公平测试与过窄规格
-
08:40 基准何时算“饱和”
-
10:28 切换到 SWE-Bench Pro
-
12:31 优秀代码评测应衡量什么
-
18:17 超越测试：成本与自主性
-
21:49 Preparedness 与未来方向
[00:00:00] swyx： 好的，大家好。我们现在在 PI studio，和 Frontier Evals 团队的 Mia、Olivia 一起。你们可以先介绍一下自己：名字、在 OpenAI 做什么，我们就开始。
[00:00:16] Olivia： 好的。我是 Olivia，在 Frontier Evals 团队。
[00:00:19] swyx： 很好。Pete。
[00:00:20] Mia： 大家好，我是 Mia。现在是 OpenAI 研究副总裁，我负责的团队包括 Codex、human data 和 alignment。我们和 Olivia 的 Frontier 团队有很多协作。
[00:00:33] swyx： 很令人兴奋。而且据我了解，你也参与了最初 SWE-Bench Verified 的工作。
[00:00:38] Mia： 是的。Olivia 的 Frontier 团队和 human data 团队当时一起做了 SWE-Bench Verified。
[00:00:45] swyx： 你们一路看着 coding benchmark 的演进。我记得大概在 2024 年中后期你们首次发布了 Verified。从那以后变化很大。
[00:00:56] swyx： 你们今天要发布的这篇博客，核心观点是什么？最主要想传达的论点是什么？
[00:01:04] Olivia： 核心观点是：SWE-Bench Verified 一直是行业衡量编码进展的“北极星”基准之一。但最近我们看到它的进展已经明显停滞。我们基本确认，这是因为这个 eval 已经事实上饱和，而且污染严重。
[00:01:20] 所以在这个阶段，我们认为它已经不能很好衡量编码性能提升，行业应当转向其他 benchmark。
[00:01:28] swyx： 比如 SWE-Bench Pro。
[00:01:29] Olivia： 对，比如 SWE-Bench Pro。
[00:01:30] swyx： 太好了。我常开的一个玩笑是：好像所有实验室有个群，大家轮流把分数在卡车上加 0.1，然后就说“好吧你是最强 coding model 了”，因为你高了 0.1%。但到这个阶段，这种差异确实很难有说服力。
[00:01:48] swyx： 我们先回到起点：你们当初在 Verified 上到底做了什么？我认为那是非常实打实的大工程。
[00:01:54] 这是 OpenAI 的重大投入，但很多人还没意识到这个量级。然后这些年里我们看到的“饱和”到底是什么？也就是，SWE-Bench Verified 到底是什么、哪些点是大家应该知道的？
[00:02:08] Olivia： SWE-Bench Verified 可以看作是对原始学术 benchmark 的一次“清洗升级”。原始 SWE-Bench 出自普林斯顿一个实验室。
[00:02:14] 任务形式基本是：给 Agent 一个代码库和一个来自真实仓库/GitHub issue 的任务，让它去解决，最后看测试是否通过来打分。当时它很快流行起来，因为那时行业里还没有很好的真实世界编码 benchmark。
[00:02:32] 后来 OpenAI 在 Preparedness Framework 里把它列为需要跟踪的 eval 之一，仔细看后发现：很多 Agent 失败案例并不是模型“笨”，而是题目设置本身有问题。于是 OpenAI 发起了一个大规模 human data 项目，雇佣了近百名真实软件工程师逐题审阅：
[00:03:00] 任务描述是否充分？测试是否公平？最终整理出了我们认为质量更高的 500 个任务集。
[00:03:06] Mia： 这个 benchmark 的构建投入真的很难夸大。确实是很多资深软件工程师反复、交叉地审题。基本上每题都做了多轮差分复核。
[00:03:26] 不同专家会独立做判断。
[00:03:29] swyx： 是的，你们其实不用这么做，但你们等于把成本直接翻了三倍。
[00:03:32] Mia： 我们其实必须这么做。因为这类任务很难：你不只是看题目和 patch。
[00:03:42] 你还得把它放在整个代码库上下文里理解，理解人类维护者当时为什么会那样改。这是非常复杂的问题。做三轮审查是必要的，甚至可能还不够。但无论如何，这已经是非常大的投入。
[00:04:01] swyx： 还有更多细节，大家可以看博客。我注意到你们有“verified benchmark”这条线：我最近看到 Quinn 也做了 HLE verified（人文方向）。
[00:04:13] Mia： 对。
[00:04:13] swyx： 现在大家都在做 verified，这很好，质量更高。
[00:04:17] 好，重点是：这 500 个问题的大致结构是“问题描述 + diff + 金标准测试 + 回归测试”。
[00:04:32] swyx： 另外污染总会发生，因为 C measure 基本是开放的。我记得你们有 canary，但信息还是会泄漏。
[00:04:40] Mia： 污染路径其实有很多。首先题目本身来自开源仓库。是的。通常我们发布评测时，会加 canary string，方便在训练阶段过滤。
[00:04:58] 但如果你用的是类似公开市场上的数据——
[00:05:04] swyx： GitHub。
[00:05:06] Mia： 对，GitHub 这种数据里并不会天然带你可控的 canary string。
[00:05:09] swyx： 对。
[00:05:09] Olivia： 而且这些仓库本身很多都非常热门，比如 Django。你会在很多数据流里反复看到这些实例。
[00:05:17] swyx： 没错。录制前你提到，你们还在 5.2 的 chain of thought 里看到模型“带着额外知识”解题？
[00:05:26] Olivia： 是的。有个例子是：任务要求 Agent 影响某个行为，但题目并没有告诉它测试会检查一个特定参数。
[00:05:36] 但在 GPT 5.2 的 chain of thought 里，我们看到模型会说类似：“我记得这个仓库在某个版本里实现过这个参数，我也许应该加上。”这类测试如果没有污染带来的先验知识，几乎不可能通过。
[00:05:51] swyx： 对。
[00:05:52] Mia： 而且我认为你们发现这一点后，等于触发了整轮更系统的调查。
[... content truncated ...]
