Agentic AI 维基
AI 博客 / SWE-bench Verified、SWE-bench Pro、Terminal-Bench 2.1 与 SWE-rebench 之辨

SWE-bench Verified、SWE-bench Pro、Terminal-Bench 2.1 与 SWE-rebench 之辨

这四者各自防的是不同一种腐坏——任务坏掉、答案泄漏、题目集老成了教程——而没有一个能防住全部三种。横跨四者最有用的那个数字并不是排行榜分数：而是 Terminal-Bench 的维护者在发布半年后审了自己那 89 个任务，不得不修掉其中 26 到 28 个。

作者 智能体 AI 维基 23 分钟读完

在 93 位贡献者写出、三位资深评审筛过的 89 个任务发布半年之后，Terminal-Bench 的维护者重新审了一遍自己的基准，不得不修掉其中 26 到 28 个。这是这四个基准里最有用的那个数字，而它不是一个分数：它是一份精心构建的评测集被实测出来的腐坏率，也是你该套到自己那套评测集上的先验。

一览

四者测的大致是同一件事——智能体能不能在一个真实仓库里解决一个真实的软件任务——而它们的差别几乎全在于：各自做了什么来阻止自己的题目腐烂。

基准任务数它防腐坏的手段这手段留下了什么敞口
SWE-bench Verified500一次性的人工可解性筛查：93 位 Python 开发者从 1,699 个候选中过筛。自 2024 年 8 月起冻结；泄漏是外人测的，不是维护者。
SWE-bench Pro公布 1,865（731 公开、858 留出、276 商用）一个私有的镜像集，加上选用传染性开源许可的仓库，作为「对训练收录的法律抑制」。抑制是推理，不是测量；没有持续刷新。
Terminal-Bench 2.189维护者在半年后重审并修复了自己的任务。完全没有任何针对污染的机制。
SWE-rebench挖出 21,336；论文用 294；精选 860持续重新挖掘、按月切片，并按模型发布日期给题目打标。自动挖出的任务没有专家评审；有效性是从「能跑起来」推断的。
Four benchmarks against three kinds of decay A four by three matrix. SWE-bench Verified: task validity screened once in 2024, contamination partly measured at roughly seven per cent leakage by an outside audit, and the item set frozen. SWE-bench Pro: the public split revalidated once from 731 tasks to 642, contamination addressed by choosing copyleft repositories as a legal deterrent, and no ongoing refresh. Terminal-Bench 2.1: task validity strongest, with 26 to 28 of 89 tasks repaired by the maintainers themselves, contamination not addressed, refresh by occasional point releases. SWE-rebench: tasks auto-mined and executable, contamination handled by flagging items created before a model's release date, and refreshed with monthly splits. Legend: strongest on this axis, partial, not addressed. Which decay each one actually fights Tasks still valid? Answers leaked? Items refreshed? SWE-bench Verified Screened once, 2024 Audited at ~7% Frozen at 500 SWE-bench Pro Revalidated 731 to 642 Copyleft deterrent One revision Terminal-Bench 2.1 26 to 28 of 89 repaired Not addressed Point releases SWE-rebench Auto-mined, executable Flagged by date Monthly splits Strongest here Partial Not addressed
每一行最强的那一列都不一样。没有哪一行占满三列。
Three decays and where each benchmark intervenes A top row of three boxes names the ways a benchmark score stops meaning anything: tasks break as dependencies and resource limits drift, answers leak into model weights, and items age into tutorials and leaderboard analyses. A bottom row of four boxes, one per benchmark, names where each one intervenes: SWE-bench Verified screens solvability once by hand, SWE-bench Pro withholds a private mirror set and picks copyleft repositories, Terminal-Bench 2.1 re-audits and repairs its own tasks, and SWE-rebench re-mines continuously and flags items older than a model. A note beneath says no column fights all three, so the version and date of the number matter more than the number. Three ways a score stops meaning anything Tasks break dependencies, limits, instructions Answers leak fixes in the issue, then in weights Items age tutorials and leaderboard analyses Each benchmark intervenes at one or two of them, never all three SWE-bench Verified 500 screened by hand once, in 2024 SWE-bench Pro 858 held back private copyleft repositories Terminal-Bench 2.1 re-audited its own 89 and repaired them SWE-rebench re-mines monthly flags items by date No column covers all three, so a score is only readable with its benchmark version and its date attached. Aggregators that drop the harness disagree on the same benchmark by roughly twenty points.
三种腐坏互相独立。一个基准补上了一种，可能正在另一种上大幅失血。

SWE-bench Verified

那次筛查究竟买到了什么

Verified 是 2024 年 8 月 13 日与 OpenAI 的 Preparedness 团队一起发布的 500 题子集，做法是让 93 位 Python 开发者从 1,699 个候选条目中筛掉两种特定缺陷：题面说明含糊到不可解，以及单元测试范围松到让错误补丁也能通过。那是一次有效性审计——只做过一次，靠人工——而这也是为什么，对它所回答的那个狭窄问题而言，Verified 至今仍是四者中最被信任的。

那次筛查并没有消掉另一种失败。一项外部审计——SWE-bench+ 的工作——发现 Verified 的 500 个条目里有 37 个，约 7%，在题面说明或任务所指向的 GitHub 讨论里就含着解法。那是站得住脚的「按题」比例；更大的数字来自更宽的分母，包括把弱测试与泄漏合并计算后得出的「Verified 中 55% 的修复可疑」——那是在一个更小的「常被解出的 issue」集合上汇总的。如果你只引一个数，就引 7%。

那个排行榜已经变成了另一种东西

有两项变化比榜上任何分数都更要紧。自 2025 年 11 月 18 日起，Verified 与 Multilingual 两个榜只接受有研究论文、且具备学术或研究机构归属的提交——这让这个榜成了一份经过策划的记录，而不是一场开放竞赛。另外，bash-only 的运行是 Verified 榜上的一个筛选视图，而不是一个独立分支；这正是那些引用「SWE-bench Verified」的聚合站之间会差出大约二十分的原因：一个极简 bash 智能体与一套不受约束的商业脚手架测的不是同一个量，而一个没带脚手架的数字根本不算一个数字。

自己跑也不便宜。该仓库建议使用 x86_64 机器，至少 120 GB 空闲存储、16 GB 内存、8 个 CPU 核心，而 arm64 支持仍属实验性。对任何打算不再读排行榜、而是自己复现一次的人来说，这个数字就是诚实的地板。

SWE-bench Pro

把污染当成一个许可证策略

Pro 的差异化动作是结构性的，而不是流程性的。按发布时的说明，它在 41 个仓库上持有 1,865 道题，分为 731 道公开、858 道留出、276 道商用；其中留出集镜像公开集，但取自另外一批仓库，并刻意保持私有，专门用来监控过拟合。公开与留出的仓库都选在传染性较强的开源许可之下，而 Scale 给出的理由是：该许可「起到一种法律抑制作用，阻止这些代码被收进模型训练数据」。

请把这句当成它本来的样子：一个假说。没有人发表过任何测量，来说明 GPL 许可是否改变了最终进入预训练语料的内容；而那些把它升格成「污染在结构上不可能」的二手文章，加了一句 Scale 没说过的话。对这个普遍问题，Scale 在自己的排行榜上倒是直率得令人敬佩：模型「很可能在训练中见过评测代码，这让人难以判断它们是在解决问题，还是在回忆一个背下来的解法」。

公开分支已经变过了

如果你要引 Pro 的数字，先确认你拿的是哪一代。线上的公开数据集如今是经过校验的 V2，共 642 个任务、11 个仓库，而 V1 才是原来那 731 个；此外还并列着一个 HARD-51 子集。论文时代那组 1,865 / 731 / 858 / 276，对论文仍然成立，对下载包则已失准。该仓库自己也留着记录：排行榜存在问题、正在处理，以及结果在「不设上限」的条件下重新发布——这类维护日志应当提高你对这个基准的信心，同时降低你对从它上面读到的任何单个分数的信心。

Terminal-Bench 2.1，以及它底下的 Harbor

唯一一份公开发表的任务有效性自审

Terminal-Bench 2.0 在 2025 年 11 月 7 日与运行它的 Apache-2.0 脚手架 Harbor 一同发布。它的构建筛选得异常严：93 位贡献者产出 229 个候选任务，入选 89 个——通过率 39%——评判依据是作者本人的难度评级，加上三位资深人类评审的质量复核。

然后，在 2026 年 5 月 6 日，维护者发布了 2.1，并写下了这份名单上没有任何其他基准对自己写过的一句话：他们发布 2.1 是「为了修掉 Terminal-Bench 2.0 那 89 个任务中 28 个的问题」。其中九个，是基准构建之后外部依赖变了。八个，是「资源预算不足，至少容不下一条有效解法」——也就是说，任务原则上可解，但在脚手架给智能体的额度之内不可解。还有第三组，该帖没有给出计数：题面说明与它们的测试不对齐。而 2.1 仓库自己的 README 写的是修改了 26 个、不是 28 个，所以请引出这个区间与这处分歧，而不是选边站。

请认真对待这道算术。一个手工构建、专家评审过的 89 题基准，在发布半年之内，大约有 29% 到 31% 已经腐坏或本就表述失当；而维护者之所以发现，只是因为他们去找了。紧随其后的那句主张——「经过这些改动，Terminal-Bench 2.1 中没有任何任务是未被解出的」——正是一个基准在「有人去测量它的天花板、而不是假定它」时该有的样子。

Harbor 改变了「跑任何一个基准」这件事

Harbor 正是这个基准易于重跑、因而易于重审的原因。它能评测任意智能体，包括 Claude Code、OpenHands 与 Codex CLI；它让你发布自己的基准与环境；并且它把一次运行并行铺到各家沙箱供应方上——Daytona、Modal、Blaxel 等——于是「本地 Docker 跑一次」与「云上跑一千个环境」是同一条命令换一个参数。SWE-bench 与 SWE-rebench 都能通过它列出来。一个实务陷阱：两个版本的运行标识不同，terminal-bench@2.0 对 terminal-bench/terminal-bench-2-1，而两者的分数不可互换——因为修复坏掉的任务会把多数智能体往上抬。

SWE-rebench

跑在污染前面，而不是把它过滤掉

SWE-rebench 占了另外三家都没占的那个位置：既然间接泄漏过滤不掉，那就让新题的产出快过旧题的老化。它的自动化流水线从 3,468 个 Python 仓库里挖出 21,336 个可核验任务；论文评测用的是一个固定的 294 题集合、来自 169 个仓库；而经由 Harbor Hub 分发的精选排行榜池是 860 个任务，每个实例都有预构建的容器镜像，按月切片组织，你可以通过筛选 created_at 字段把某个月的子集取回来。

这套污染控制值得精确描述，因为二手摘要常把它说错。它不是一个「只用模型发布之后的任务」的滚动窗口；它是一个标记。凡评测中包含了「issue 创建时间早于模型发布日期」的条目，就在榜上被标为可能受污染，由读者自行判断。这比排除更弱，也诚实得多——因为它在给比较打上标签的同时，保留了比较本身。

你放弃了什么

这条流水线里没有任何一步，去筛 Verified 那 93 位开发者被请来找的那些缺陷。有效性是从可执行性推断的——任务能构建、测试能跑、参考补丁能过——这抓得住坏掉的环境，却完全抓不住一个含糊的 issue，或一个弱到不足以甄别的测试。论文的立项发现是：开源模型在新挖出的任务上得分低于在 SWE-bench Verified 上的得分，而相对排名大体仍然成立；这在方向上就是整个项目的要点，但二手报道里流传的那些具体的逐模型对比数字，可靠度不足以引用。

横向比较：真正把它们分开的三条轴

谁去测天花板

只有 Terminal-Bench 公布过「自己有多少任务不可解」的数字。Verified 的筛查是发布前的一次性过滤，不是一项重复测量；Pro 把公开分支从 731 修订到 642 是一次重新校验，但没有附上缺陷分类；SWE-rebench 的可执行性检查是连续的，但很浅。四者之中，恰好有一个维护团队告诉了你「分母里有多大一块是死的」——而答案是约十分之三。

谁告诉你这个数的方差

SWE-agent 自己的附录是最干净的一手陈述：汇总层面的性能方差相对较低，而逐条目的解出结果在不同运行之间「会有相当大的变化」。SWE-rebench 在解出率与 pass@5 之外还公布标准误，这是四者中唯一由维护方公布的方差数字。第三方世界里所有认真的人，如今都做三到五次重复并打印一个区间。如果你在这些基准上比较两个只差一分的系统，你读的是噪声——那道算术在评测方差与统计功效里。

你被允许是谁

这条轴没人写进对比表，而它决定了这些榜意味着什么。Verified 现在要求有论文与机构归属才能提交。Pro 分别运营公开与私有两个榜，并承认在处理排行榜问题。Terminal-Bench 的分数来自任何人都能跑的脚手架。SWE-rebench 由一家云厂商维护，而它自己的模型也出现在榜上。这些都不构成否决理由，但每一条都会改变你给某一行的权重。

什么时候选哪一个

如果你需要……用理由
与已发表历史作对比SWE-bench Verified，并注明脚手架四年的提交记录、筛过的条目，以及一个你可以据之折价的已知约 7% 泄漏率。
证明模型没背下这套题SWE-rebench，取最新的月度切片题目晚于模型，而那些不晚于的会被标出而非藏起。
长时程、环境吃重的工作经 Harbor 跑 Terminal-Bench 2.1终端任务、重审过的条目，以及一套能大规模廉价重跑的脚手架。
在一个合约期内抵抗过拟合SWE-bench Pro对「厂商冲着你的基准调优」，一个私有留出镜像集是唯一的结构性答案。
一个你真的会据以决策的数字你自己那 100 个任务，外加一次参考解运行公开基准排的是「模型与脚手架这一对」，而且是在别人的仓库上。

第五行才是要紧的那一行；而它的具体做法——怎么测量你自己的天花板，让脚手架腐坏不再被读成模型退步——在参考解运行与不可解任务里。

常见问题

现在这几个里面谁的分数最高？

这个问题没有可搬运的答案，而这本身就是结论、不是闪躲。各聚合站对 SWE-bench Verified 的说法能差出大约二十分，因为有的报的是极简 bash-only 智能体，有的报的是不受约束的商业脚手架。请读你关心的那个基准的官方榜，并且只比较注明了同一套脚手架的行。

那么多任务需要修，是不是说明 Terminal-Bench 2.1 更不可信？

恰恰相反。任何由真实仓库搭出来的基准都会累积同样的缺陷；Terminal-Bench 是去看了、并把数目公布出来的那一个。一个没有修复记录的基准，要么没被审过，要么没告诉你。

SWE-bench Pro 的 GPL 许可真的能防住污染吗？

不知道。那是 Scale 为这个选择给出的理由，不是一个被测出来的结果；也没有任何已发表研究检验过许可条款是否改变了语料构成。无论如何都起作用的，是 Pro 设计里那个私有留出集。

我能把 Terminal-Bench 2.0 的分数和 2.1 的分数对比吗？

不能。修复坏掉与资源不足的任务会抬高多数智能体，所以两个版本是不同的分母。两者的运行标识也不同——这是个有用的意外。

该跑多少次重复？

三到五次，并在均值旁边打印标准误，这是公布方法学的那批人中的通行做法。这些基准的汇总方差偏低，但逐条目的结果会动，所以单次运行用于粗读没问题，用于在两个接近的系统之间做决定则毫无用处。

延伸阅读

本站：

项目来源：