SWE-bench Verified 被污染:OpenAI 2 月审计发现 59% 缺陷案例

2 月 23 日,OpenAI 的 Frontier Evals 团队发布了一篇文章解释为什么停止报告 SWE-bench Verified 分数。审计发现基准中最难的测试案例中有 59.4% 存在根本性缺陷——测试要求问题陈述中未提到的精确函数名,或者检查不相关的行为。更具谴责性的是:测试的每个主要前沿模型——GPT-5.2、Claude Opus 4.5、Gemini 3 Flash——都可以仅使用任务 ID 从记忆中逐字复现 gold-patch 解决方案。OpenAI 的结论很直接:「SWE-bench Verified 上的改进不再反映模型在真实世界软件开发能力上的有意义改进」。他们建议改用 SWE-bench Pro。三个月后,其余的代理代码行业仍在受污染的基准上对自己进行排名。

目前发布的表格顶部数字是:Opus 4.7 上的 Claude Code 87.6%、GPT-5.5 上的 OpenAI Codex 约 88.7%(第三方追踪器;OpenAI 本身不自我报告)、Gemini CLI 80.6%、OpenHands 72%、Augment Code 在其自己 harness 上自我报告 70.6%、Cursor 在默认设置下约 51.7%、GitHub Copilot 约 56%。在 SWE-bench Pro——OpenAI 现在推荐的替代品——上,相同的模型分数低得多:Claude Opus 4.7 64.3%,GPT-5.5 58.6%。Terminal-Bench 2.0 是另一个保持可信度的基准:Codex 82.7%,Claude Code 69.4%,Gemini CLI 68.5%。两个基准家族之间的差距本身就是信号:当一个评估的分数将模型压向天花板,而另一个评估的分数将它们分散时,第二个正在做区分的工作。

更深层的问题是 benchmark 最大化和生产力最大化之间的差距。仅代理 scaffolding 就在相同模型上产生约 ±17 个问题的方差,这意味着 harness 选择可以在任何给定运行中主导模型选择。所有公开排名都没有发布的 harness 规范,所以跨供应商的 apples-to-apples 比较实际上没有进行——只是 apples-vs-每个供应商自己的数字。对构建者的实际含义是,正确的比较不是「哪个代理在 SWE-bench Verified 上领先」,而是「哪个代理在我的代码库上、用我的 CI 和我的样式约定解决我的任务」。有效的经验方法是从你的真实积压中运行 50 到 100 个任务对抗两到三个候选者,并测量结果而不是分数。

实际符合数据的推荐模式是分层堆栈而不是单一工具押注。终端代理——Claude Code 或 Codex——在多文件重构、架构变更和那种否则会烧掉高级工程师下午的调试上赚回其成本。IDE 扩展——Cursor 或 GitHub Copilot——在内联完成、快速编辑和日常工作期间的环境辅助上赚回其成本。开源代理——Aider、Cline、OpenHands——在你想交换模型、避免平台溢价或端到端审计代理行为时赚回其成本。使用多个不是优柔寡断;这是对专业化的诚实回答。基准方面:SWE-bench Verified 不再是你的朋友。SWE-bench Pro、Terminal-Bench 2.0 和你自己的代码库才是。