基准也是软件：Terminal-Bench 2.1 把维护债补上

基准也是软件：Terminal-Bench 2.1 把维护债补上

E. Kelly Buchanan、Crystal Zhou、Scott W. Linderman、Christopher Ré。斯坦福大学、康奈尔大学。许可证：CC BY 4.0。arXiv:2611.08417，2026 年 11 月 5 日。

编码智能体（agent，能调用工具、在环境里完成任务的程序）是目前大语言模型（LLM，按提示生成文字的模型）经济影响最大的用法之一，所以评测必须可靠。即便发布时仔细校验过的基准，也会变旧。模型变强之后，会找出验证器不认的合法解；评测基础设施一变，写进任务和测试里的假设也会失效。由此积下来的缺陷，本文称为基准维护债（benchmark maintenance debt）：分数和它本来要量的能力之间，缺口越来越大。

本文给出一套面向智能体基准的持续校验流程：社区报告、任务文件、智能体轨迹、自动的参考解检查，以及由人把关的修复。把它用到 Terminal-Bench 2.0 上。这个基准发布前做过大量人工审阅、模型协助审阅和红队测试。审计仍在大约 30% 的任务上发现问题，修复后发布为 Terminal-Bench 2.1。修复改变了评测结果：准确率上升超过 10 个百分点，排行榜名次最多移动 3 位，但总体排序仍然高度相关（Spearman ρ = 0.958）。Spearman ρ 是两组排名的相关，越接近 1 表示名次越稳。

资源分配也会改写结论。固定的墙钟时间和输出 token 预算，会实质改变看起来的表现。例如，放宽时间上限，能把 GPT 5.4 上 20 个百分点的支架差距闭上，并把 GPT 5.4 mini 上 30 个百分点的差距缩到 5 个百分点。支架（harness）是包在模型外面、负责给工具、管上下文的那层程序。基准维护不只是修任务文件：资源预算是测量规格的一部分，必须和任务一起重新校验。

更广地说，维护债不只是积下来的缺陷。基准处在不断变化的依赖、基础设施和智能体生态里，它的假设和资源设置必须随时间重新验证。

1 引言

图 1 画出智能体任务生命周期上的失败面。从编写、执行到验证，每一段都可能引入失败，汇成维护债。颜色对应三类：蓝色是说明与验证不一致，橙色是环境问题，红色是任务漂移。

智能体基准的分数会影响产品声明和研究投入。这些基准不是静止的数据集。随着时间，缺陷把模型分数和基准想量的能力拆开。维护债就是：为了让基准仍然有效，必须修掉或退役的任务侧缺陷积压。它沿生命周期出现，见图 1。设计者会把“智能体将怎样解题”写进假设。智能体一旦走出设计者没料到的合法路径，或者走出能通过测试却没解题的捷径，假设就破了。依赖外部状态（软件包、API、网站）的任务，发布后状态一变就会坏，失败和能力无关。

对智能体基准，有效性要求持续维护。Terminal-Bench 2.0（Merrill et al., 2026）说明了这一点：任务在发布前经过人工审阅、模型协助审计和利用测试（Zhu et al., 2025），几个月内议题跟踪里仍有超过 50 条标成任务缺陷的未关闭报告（Terminal-Bench Team, 2026b；Terminal-Bench Team, 2026a；Zeng et al., 2026），覆盖整条任务栈上的不同假设（图 1）。发布时的充分校验，并不能取消之后的审计和修复。

一条缺陷报告本身不能确定原因，也不能证明某种修法正当。提议的修复需要自己的校验。本文发现，有的提议用澄清任务或修好预言机（oracle，已知正确的参考解）来处理有效性失败；另一些只补了看见的症状，例如放宽一条正则，或放宽接受条件。维护者因此需要一套一致的过程：确认缺陷、审阅改动、检查修复是否保住原意。

资源分配和基础设施差异让这件事更难。时间与内存上限、环境配置、模型或沙箱提供方不同，会使同一任务在不同评测设置里表现不同，既难复现报告的失败，也难验证修复（Anthropic, 2026c；OpenAI, 2025b）。冻结环境是用真实度换可复现；滤掉可疑任务（OpenAI, 2024）是用覆盖换精确；刷新评测集（Jain et al., 2025）能让任务不被模型见过，但修不了发布后才坏的任务。本文做的是一套互补的基准审计工具，用来审任务。把它用到 Terminal-Bench 2.0，把更新发布为 Terminal-Bench 2.1，并检查修订如何影响评测结果。

图 2 是持续校验的智能体流水线。证据收集智能体汇集静态任务文件、以往轨迹和外部报告。审计智能体按规格忠实、测试、资源和风险等原则起草带引用的修复，并对照证据检查。/oracle 重建任务并跑参考解。修复流程可以开出带证据的草稿合并请求，维护者审阅之后才进入已验证的发布。

贡献有三项：

1. 持续校验流程。基准校验本身可以持续：用现在的智能体工具，把社区报告、公开执行轨迹、智能体协助的分诊和人工裁定，收成一套可维护的流程，用来发现、修复、退役并记录基准问题（第 4 节）。
2. 更新后的基准 Terminal-Bench 2.1。把流程用到 2.0，发布 2.1。社区报告、智能体协助审阅和维护者裁定合在一起，大约三分之一的基准有问题。问题归成三类维护债：环境问题、说明与验证不一致、任务漂移（第 5 节）。
3. 修复的效果。在 2.0 和 2.1 上重评 19 个智能体。修复会改变报告的准确率和效率结论，但不会把排行榜整个翻过来。排名仍然高度相关，单个分数会移动不小的幅度（第 6 节）。可行性恢复之后，失败试验里超过 50% 是超时，某些支架上高达约 68%（图 3b）。

2 相关工作

基准审计

已有工作研究评测集被修订时，结论如何变化。Recht et al. (2019) 重抽了 ImageNet 和 CIFAR 的测试集，用新旧测试集的排名相关，看基准量的是不是稳定的构念。本文沿用同一协议，用到另一种失败：可执行智能体基准里的任务侧缺陷。

第二种回应是校验并过滤实例。SWE-Bench Verified（OpenAI, 2024）请职业开发者审计 SWE-Bench（Jimenez et al., 2024），发布一个保守过滤后的子集。WebArena Verified（ServiceNow Research, 2026）对 WebArena（Zhou et al., 2024）做了类似的已验证子集。相关审计还找出答案泄露、薄弱测试套件，以及智能体基准里的任务与结果有效性失败（aleithan2024swebenchplus；Yu and others, 2025；Zhu et al., 2025）。这些做法通常把校验当成一次性筛选，缩小基准，而不是修复它。

第三种回应是给基准加时间窗或刷新。LiveCodeBench（Jain et al., 2025）和 LiveBench（White et al., 2025）持续加入新题，以降低污染和过时。精神上最接近持续校验，但本文修的是已有任务，而不是只过滤。

审计工具

审计靠一套正在变大的操作工具。智能体基准检查清单 ABC（Zhu et al., 2025）给出结果有效性和任务有效性的量表。Docent（Meng et al., 2025）和 LangSmith（LangChain, 2026）把基准轨迹收进来审，使大规模检查可行。互补的对抗工具则搜索：智能体怎样能通过测试却不满足原意。量表规定标准，收集工具收证据，红队找出候选缺陷，人工裁定解决含糊情况。本文把这些材料收成第 4 节的持续校验流程。

智能体评测

可执行的智能体基准不是单独评一个模型：分数还取决于支架、执行环境和资源预算。支架效应已有记录（Yang et al., 2024；Wang et al., 2025）。Merrill et al. (2026) 发现，平均而言选支架不如选模型重要。环境效应受到的注意更少：Anthropic (2026c) 表明，只改基础设施配置就能移动编码智能体分数。本文从两方面延伸：平均数会盖住厂商内部很大的支架差距（某些模型上约 20 个百分点），而这些差距在默认时间预算下，很大程度上反映的是速度。

3 问题设置

每个任务都有失败面。任务是一场计时考试，组成部分是：

• 说明：给智能体看的自然语言题目。
• 环境：带预装软件和给定文件的 Docker 镜像。
• 预言机：已知正确的解。
• 测试：智能体停下之后运行的评分代码。
• 资源：CPU、内存和墙钟预算。

智能体是带工具的模型。支架是给模型提供与环境交互所需工具的系统。一次试验是一个智能体对一个任务的一次独立尝试。智能体 a 在任务 t 上做 na,t 次试验，p̂a,t 是平均奖励。覆盖率，也就是 pass@k，估计至少有一次试验成功的概率。全文使用 Chen et al. 2021 的无偏 pass@k 估计。pass@k 是 k 次独立尝试里至少成功一次的概率。

数据集

使用两套数据。证据数据是基准上收集的外部证据，包括排行榜上的试验，用来找出并修好有缺陷的任务，发布 Terminal-Bench 2.1。评测数据是 19 个智能体在 2.0 和 2.1 上的试验，用来量修复的效果。

为了单独看效率，本文在 2.0 和 2.1 上加了一种故意偏离基准指南的条件：增加资源，给智能体更多时间。因为成本，这一条件只在部分智能体上跑。

4 基准审计流程

目标是审计任务侧缺陷，并产出维护者可以审的候选修复。手头有三股证据：任务规格、以往执行轨迹、网上的社区报告。要把它们编成任务级审计报告：缺陷标签、支持证据，以及能给出时的提议修复。本文定义三条智能体流程：收集证据、审计、核验最终报告。

审计量表

流程的中心要求是量表。没有量表，智能体可以标出可疑行为，但行为不一定一致，也不好读。已有工作做过审计量表（Zhu et al., 2025）。本文沿用这个想法，但改成维护流程。在这个场景里，更有用的是少量、指向可能修复的缺陷标签，而不是宽泛的自由有效性判断。审计者因此指定一个主要的任务侧缺陷类别，适用时再记次要标签。这样报告可以跨智能体比较，维护者也有具体的审阅目标。

主要缺陷类别：

• 未发现缺陷：任务规格清楚，预言机被接受，验证器检查的是原意行为，声明的资源预算足够。
• 说明与验证不一致：说明和验证器互相矛盾。包括说明过少、隐藏约束只出现在测试里，以及测试过严、拒绝了按原文已经满足任务的行为。
• 任务漂移：发布之后任务变了，因为外部状态可变，例如包版本、网络资源、公开 API 或网页内容。
• 环境问题：任务原则上可解，但给定的环境和资源（CPU、内存、存储，或系统与网络配置）使预言机、验证器或合法的智能体解不能可靠运行。

审计流程

流程见图 2。对每个任务，证据智能体产出结构化报告，包含基准、任务规格、轨迹信息和社区报告。它的角色是给下游审计者整理证据，观察和裁定分开。

审计者把量表用到每个任务上。检查任务是否规格清楚、可解、可验证，验证器是否接受合法解、拒绝不合法解。量表遵循 ABC 指南（Zhu et al., 2025），产出任务级报告：主要缺陷标签、短理由、缺陷位置、提议修复。

核验者审阅证据和审计者的标签。加上这一步，是因为只做审计时，试点跑不能可靠抓住任务漂移。核验智能体要跑预言机、质疑提议的标签、指出缺失的证据，并检查提议的修复是否对准了底层缺陷。完整分解见附录 A。

图 3 从三个角度看任务错误从哪来。（a）Terminal-Bench 2.0 里 28 个任务的缺陷类别占比，一个任务可以有不止一类。（b）默认时间预算下，Terminal-Bench 2.1 失败试验里超时的占比，按支架分（每个支架下的智能体集合不同）。（c）在修订过的任务里，参考解或智能体尝试触及 Terminal-Bench 2.0 内存或磁盘上限的份额。

修复约定

缺陷确认之后，修复并不总是机械的，需要人的判断（Zhu et al., 2025）。各类约定是：

• 说明与验证不一致：任何满足原文任务的解都应被接受，不合法的解应被拒绝。
• 任务漂移：尽可能让依赖可复现，并去掉任何使预言机不能可靠运行的依赖。
• 环境问题：设一条可行性底线：已知正确的预言机解和验证器，应在基准预算内可靠运行。

资源问题

对资源相关的失败，把起约束作用的资源轴（墙钟时间、内存或 CPU 数，有时不止一条）调到最接近原提议的倍数，或至少调到预言机解和验证器观察到的需求的 1.5 倍。

这个约定有两个目的。第一，避免基础设施噪声造成的假失败：正确解不该因为验证器或预言机刚刚卡在预算边上而失败，但要留出足够余量让题可解。第二，资源设定了题目难度，这里尽量贴近原贡献者的意图。

另一种做法是按任务调预算。那需要对每种资源反复扫描，并往流程里再加一个主观设计选择。可行性规则偏保守，但是可审计的约定。

共同的修复规则

任务依赖活的 API 时，审计之后难度仍可能变。修复改变难度时，按专家指南把变化记下来，而不是把任务调回以前的通过率。

流程评估

在流程设计的场景里评估它：发布后的基准维护。维护 Terminal-Bench 2.0 时用它找出候选缺陷、附上证据、为维护者审阅提出修复。被接受的修复随后作为 2.1 发布。

从三方面评估。第一，流程是否与具体智能体无关：同一量表下，不同审计者给出的缺陷标签是否相近。第二，换成更便宜的审计模型，这种一致是否还在。第三，把它当作有维护者在环里的分诊系统，把它的标记和人工裁定的修复集比较。

如前所述，智能体把任务分到缺陷类别。类别根据 Terminal-Bench 2.0 的 15 个任务试点子集，以及大约 1,500 次 2.0 执行试验来定。试点只固定类别定义，不固定每题标签。

为看流程是否与智能体无关，用两类审计者来跑。托管的编码助手 Claude Code（Opus 4.6）和 Codex（GPT-5.4），在全部 89 个 2.0 任务上，对主要缺陷类别（含“无缺陷”）的一致是 κ = 0.80。κ 是扣除偶然一致后的一致程度。

更便宜的 API 审计者，在同样 89 个任务上，对二元分诊（标出对干净）的一致是 κ = 0.55 到 0.77（表 1），但归因更差：分类别一致（一对其余，因为一题可以有多个标签）上，说明与验证不一致为 κ = 0.60，环境问题为 κ = 0.59，任务漂移只有 κ = 0.21 到 0.41。因此检测漂移靠确定性的预言机检查，而不是审计者标签。重跑参考解，有助于发现打乱参考执行或其验证的漂移。

这些结果说明：能力强的审计者在分诊和归因上大体与具体智能体无关；便宜的审计者适合分诊，归因仍要预言机检查和维护者审阅。一致量的是稳定性，不是正确性。扩展分解见附录 A。

为防止流程本来就要消费的社区报告泄露进评测，所有评估运行都关掉审计者的网页搜索；部署时搜索保持打开。

对照最终的 2.1 发布，流程达到 57.1% 的精确率和 71.4% 的召回率。因为流程参与构造了修复集，这些指标量的是与发布的事后一致，不是独立发现缺陷。流程最好被看成维护者审阅之前的分诊工具。

5 从 Terminal-Bench 2.0 到 2.1

把审计流程用到 2.0 上，28 个任务有问题，大约是基准的三分之一。其中合并了先前审计的缺陷：Terminal-Bench Verified 标出的 11 个任务（Z.ai, 2026，对照见 A.3），以及各公开议题和合并请求里处理过的另外 5 个（Terminal-Bench Team, 2026b；2026a），再加上本次审计新认定需要修的 14 个。两个任务可以出现在不止一个来源里，合计 28 个。

图 3 给出这 28 个任务的缺陷构成。最常见的是说明与验证不一致（出现在 57% 的任务里）。例如 query-optimize 上，验证器要求数据库文件逐字节保持不变，原说明里没有这条。修复把这条限制写明（aleithan2024swebenchplus；Yu and others, 2025）。

第二常见的是任务漂移（43%）。依赖包版本、公开 API 和网页内容的任务，发布后状态一变就坏。修复是能去掉依赖就去掉，否则钉住版本（见附录 A）。

第三类是环境问题（29%），来自资源预算。2.0 里，贡献者按自己的资源用量给每题设 CPU、内存和时间。这些估计有时过紧（图 3c）：预言机、验证器或智能体触及内存或磁盘上限，试验会因为资源而失败，不是因为解错了。执行后端（Docker、Daytona）在文件系统隔离、内存限制、智能体与验证器之间的网络上也不同。审计把起约束的预算提高，使预言机在每一项上至少有 1.5 倍余量，恢复可行性底线。

这么大的审计有风险：如果修复重排了排行榜，先前关于相对表现的说法就要重看。下一节直接检验这一点。

6 结果

智能体的表现是模型、支架和资源的乘积（Yang et al., 2024；Kapoor et al., 2026；Merrill et al., 2026）。通常比较的是模型和支架，这里也给出资源的影响。用 2.1 问：这套测量栈一变，哪些结论还稳。第一，在默认协议下比较 2.0 和 2.1，看修复是否改变准确率和排名。第二，改变时间预算，看修复是否改变效率前沿：哪些智能体能解题，以及需要多少预算。第三，固定预算下的支架差距，有多少能用超时之内的速度来解释。单一排行榜把基准版本、支架和资源预算折成一个数，这些区别就被藏起来了。

6.1 审计提高准确率，并改动接近的名次

图 4：Terminal-Bench 2.1 对不同智能体的准确率提升不均匀。19 个智能体上 Spearman ρ = 0.958，任务自助法 95% 置信区间为 [0.881, 0.979]。

评测来自多个提供方的 19 个智能体，比较 2.0 和 2.1 的准确率，见图 4。相关很高（Spearman ρ = 0.958），普通最小二乘拟合为 TB2.1 = 2.1 + 1.04 · TB2.0。提升不均匀：Claude Code 加 Claude Opus 4.6 比拟合线高出 7 个百分点以上，并上升 3 名；Codex 加 GPT 5.4 落在拟合线下面。2.0 上准确率低于 40% 的两个最弱智能体，都落在拟合线下面，并在 2.1 上掉了准确率。这和被修任务的难度一致：28 个被修任务里 19 个难、7 个中、2 个易。让难题变得可解，对很少解出它们的智能体帮助不大。

最大的增益集中在说明与验证不一致的任务上。2.1 里有 5 个任务，修复前通过率至多 15%，围绕验证器的修复之后超过 50%，约占被修改任务子集上绝对通过率变化总量的 62.7%（完整分解见附录 C）。这些任务属于说明与验证不一致：智能体常常已经给出合法解，2.0 却认不出来。其余 23 个被修改任务的变化更小，方向也有正有负。有些情况下，审计去掉了假阳性得分，或收紧了原意规格，使 2.1 的通过率低于 2.0。

6.2 审计可以移动效率前沿

给可执行智能体基准设资源并不简单。任务分数不只取决于能不能解，还取决于能不能在给定资源内解开。图 3b 显示，失败试验里超过 50% 以超时结束，从 claude-code 的 68% 到 gemini-cli 的 18%；对最弱的智能体与模型组合，超时占主导（C.2）。

图 5：审计前后，考虑成本的有效性会移动。资源预算增加时，覆盖率上升。

图 6：支架差距主要是时间预算效应。Codex 和 Terminus-2 在标准分配时间，以及把超时放到 32 倍时的 2.1 准确率。延长预算，大部分 Codex 与 Terminus-2 的差距会闭上。

因此评测这些模型的测试时缩放。对每个智能体与模型组合，把墙钟预算加到原任务超时的至多 32 倍，看随着预算增加解开多少题。这个更大的预算是上限：智能体做完就可以退出，不必用完分配。除了纳入的小模型（Qwen 3.5），最大预算下剩下的超时很少，所以多数剩余失败不是超时伪影：在所测配置下这些题仍然没解开。

图 5 给出六对智能体与模型的覆盖率：五对用 Terminus-2，GLM 5.1 配 Claude Code 作为参照，因为它落在效率前沿上。实线是 2.1，虚线是 2.0。每条曲线要按两种方式读。左右位置表示效率：更早升起的曲线，用更少时间或更少输出 token 就能解题。最终高度是最大预算下的覆盖率：如果曲线在 1.0 以下变平，再给预算也救不回剩下的题。

第一，智能体的效率差很多。GLM 5.1 在小得多的预算上就达到高覆盖，曲线更靠左。GPT 5.4 最终覆盖也高，但花费更多 token。较小的开放模型，包括 Qwen 3.5 9B、Qwen 3.5 27B 和 Gemma 4 31B，预算增加时能解开不少题，但曲线在更低的覆盖率上变平。因为墙钟扫描对大多数组合几乎消掉了超时，剩余失败不是超时伪影。

第二，审计对这些曲线的改变不均匀。GLM 5.1 在 2.1 上多解开 8 题，并超过 GPT 5.4，而 GPT 5.4 的覆盖几乎不变。Qwen 的两对上，2.0 和 2.1 的曲线几乎不变。所以效率排名也会被基准版本影响。

支架差距取决于时间预算

已有工作表明支架和智能体与计算机的界面会影响表现（Yang et al., 2024；Kapoor et al., 2026；Merrill et al., 2026）。本文问：固定预算下的支架差距，在较慢的支架沿效率前沿移动之后，有多少会消失？

图 6 用同一厂商内部的支架对调做诊断。默认时间下，对 OpenAI 模型，Codex 的分数远高于 Terminus-2。支架选择使 GPT 5.4 的准确率移动约 20 个百分点，和模型之间的差距同一量级。但给任务更长预算之后，大部分支架差距会回来，说明这更像速度，而不是能力。

这些结果说明：固定资源预算是一个任意的工作点，而且这个选择并非无害，它能改变单个模型的效率结论。这支持先设一条有原则的底线，并检验对预算的敏感，而不是按某一组智能体和模型来校准。

7 外部有效性：审计 Harbor-Index v0.1

为看流程能否迁出 Terminal-Bench，把它用到 Harbor-Index v0.1 开发期间 80 题快照里随机抽的 34 题。快照来自 29 个源基准，领域和评测程序都不同（Shi et al., 2026）。许多任务被重写成统一格式，说明、环境和评分逻辑上多了出错机会。

Harbor 团队人工审了全部 34 题，包括流程没标出的。流程标出 14 题，人工确认其中 12 题有缺陷（精确率 86%）。发现包括说明与验证不一致、基础设施失败，以及对可变外部状态的依赖。例如若干 GAIA2 任务因为辅助评分服务在错误条件下被调用，拒绝了正确的参考解。在 GSO 里，说明漏了评分器要求的一个条件。

人工审阅还找出流程漏掉的缺陷：Lab-Bench 里一个错误的参考答案，QCircuitBench 里不确定的评分，以及 HLE 的说明允许两个都说得通的正确答案。共享评分代码里另外两个缺陷影响 13 个任务，和已经因其他缺陷被标出的任务有重叠：GSO 评分器把智能体产出的程序执行了两次，GAIA2 评分器没处理好特殊字符。

结果表明流程能在 Terminal-Bench 之外找出缺陷。漏掉的情形说明还要研究基准专用检查、重复执行和领域知识。Harbor-Index 团队随后用轨迹级裁判和更多轮审阅与修复扩展了校验，细节见 Shi et al. (2026)。

8 讨论

持续校验

审计流水线在 2.0 上找出 28 个任务侧缺陷，其中包括 12 个发布后漂移。漂移按定义会反复出现：从投稿到发表，还会有更多依赖腐烂。

因此需要的是版本控制，而不是一次性校验：每次发布都应是带编号的数据集，钉在任务级摘要上，并公开记录改了什么。LiveCodeBench（Jain et al., 2025）已经为控制污染这样做；同一纪律也适用于任务侧缺陷。

修复之下的排名稳定性

19 个智能体上，2.0 与 2.1 的排名仍然高度相关（Spearman ρ = 0.958），单个分数最多移动 12 个百分点，名次最多移动 3 位。所以这些修复下，大的排序是稳的，但绝对表现估计，以及相近智能体之间的比较，可以取决于基准版本。

最大增益集中在最常见的缺陷类：说明与验证不一致。审计也表明，效率结论对设计选择敏感，而设一条可行性底线是付得起的修复。

总起来，这项工作提供：（i）一套能找出并修复基准缺陷的审计方法；（ii）2.1 这一产物，说明审计驱动的修复可以保住智能体的名次顺序，同时移动绝对分数；（iii）在 2.1 上，任务定义和资源预算都会塑造公开发布的分数，而当前的报告实践没有控制这两点。因为这条流水线可以持续跑，Terminal-Bench 2.1 是一个检查点，不是终态。

可复现性声明

Terminal-Bench 2.1 公开在 https://github.com/harbor-framework/terminal-bench-2-1 。任务修订和讨论记录在 https://github.com/harbor-framework/terminal-bench-2/pull/53 。

审计流程见第 4 节，附录 A 给出持续校验检查。评测设置见附录 B，包括模型（B.1）、支架（B.2）和每个智能体的配置（B.3）。2.0 到 2.1 的逐题通过率变化见 C.1。

流程也已放进 Terminal-Bench 正在进行的任务审阅，文档在 https://github.com/harbor-framework/terminal-bench/blob/main/docs/TASK_REVIEW_AUTOMATION.md 。这个实现会随维护者和社区继续变，可能和本文评测的版本不同。

项目网站 https://ekbuchanan.com/terminal-bench-2-1-paper/ 提供本文所报告的流程、提示和结果的快照。

致谢

作者感谢 Terminal-Bench 团队和社区在公开 GitHub 仓库里报告问题，并致谢 NIH、NSF、DARPA、斯坦福 HAI、Marlowe 计算平台及文中列出的产业成员。文中观点属于作者，不必然代表资助方。美国政府被授权为政府目的复制和分发重印本，不受文中版权标记限制。

参考文献

正文引用的主要文献包括：Merrill et al. 2026（Terminal-Bench 2.0）；Zhu et al. 2025（ABC）；Recht et al. 2019；OpenAI 2024（SWE-Bench Verified）；Jimenez et al. 2024（SWE-bench）；Zhou et al. 2024（WebArena）；Jain et al. 2025（LiveCodeBench）；White et al. 2025（LiveBench）；Chen et al. 2021（pass@k）；Yang et al. 2024；Wang et al. 2025；Kapoor et al. 2026；Anthropic 2026c；Shi et al. 2026（Harbor-Index）；Z.ai 2026（Terminal-Bench 2.0 Verified）。完整题名以 arXiv 页面的参考文献为准。

附录 A 审计流程细节

A.1 持续校验流水线

证据、审计、核验三段如第 4 节。有一种只提议、不直接合并的模式：修复以带证据的草稿合并请求交给维护者。漂移不靠审计者标签，而靠重跑参考解。

便宜审计者在 89 题上的分诊一致如下。

A.2 审计流程评估

按错误类别，说明与验证不一致 16 题，环境问题 8 题，任务漂移 12 题。说明与验证不一致的任务包括：adaptive-rejection-sampler、build-pmars、caffe-cifar-10、configure-git-webserver、filter-js-from-html、fix-git、hf-model-inference、install-windows-3.11、mteb-leaderboard、mteb-retrieve 等。

资源与检查落点（✓ 表示该轴被标出）节选如下，完整 28 行与原文表一致：

其余被标任务还有 build-pov-ray、compile-compcert、configure-git-webserver、extract-moves-from-video、filter-js-from-html、financial-document-processor、fix-git、gpt2-codegolf、hf-model-inference、install-windows-3.11、make-doom-for-mips、mcmc-sampling-stan、mteb-leaderboard、mteb-retrieve、overfull-hbox、polyglot-rust-c、protein-assembly、rstan-to-pystan、torch-pipeline-parallelism、torch-tensor-parallelism。各列勾选与原文附录表一致，不在这里改写。

A.3 与 Terminal-Bench 2.0 Verified 的比较

Z.ai 发布了更早的公开审计 Terminal-Bench 2.0 Verified（Z.ai, 2026）。它做两类改动。第一，对全部 89 个任务做环境修复，使任务镜像能在 Claude Code 运行时下跑：例如安装 procps，缺了它智能体会崩溃；并限制 caffe-cifar-10 可见的核数，免得并行构建把内存用完。Z.ai 报告，仅这些修复就把 Claude Opus 4.5 从 52.4% 提高到 57.9%，说明移动排行榜的不只是题目内容，还有环境缺陷。第二，说明修复改正了 11 个说明与测试不一致的任务。

Terminal-Bench 2.1 修了这 11 个任务，并在其中 4 个上采用了 Verified 的修法。

两点核心差别。第一，说明和测试不一致时，Verified 改说明去说出测试在查什么；2.1 更多是改测试，使任何正确解都被接受。把评分器的期望写进说明，等于把一部分解告诉智能体；放宽评分器，则把难度留在贡献者原来的意图上。第二，Verified 把任务镜像适配到特定支架，并在 5 个任务上注明不要用 Read 工具直接读图像或 PDF，因为没有多模态能力。2.1 不加支架专用改动，所以每个智能体评的是同一道题。

附录 B Terminal-Bench 评测设置

B.1 评测的模型

B.2 支架

ReAct 是“推理、行动、再看观察”的循环。

B.3 智能体配置覆盖

相对支架默认值的覆盖：claude-code 上的 Opus 4.6 与 Sonnet 4.6 为 reasoning_effort=high；GLM 5.1 为默认。codex 上的 GPT 5.3 Codex、GPT 5.4、GPT 5.4 mini 为 reasoning_effort=xhigh；GPT 5.5 另加 temperature=1.0。gemini-cli 上的 Flash 3 与 Pro 3.1 为默认。terminus-2 上：Opus 4.6 与 Sonnet 4.6 为 reasoning_effort=high、T=1；GLM 5.1 为 T=1.0 且打开思考；GPT 5.3 Codex、GPT 5.4、GPT 5.4 mini 为 reasoning_effort=xhigh 且 use_responses_api=True；GPT 5.5 另加 T=1；Gemini Flash 3 与 Pro 3.1 为 reasoning_effort=high；Gemma 4 31B 为 T=1.0 且交错思考；Kimi K2.6 为 T=0.6 且交错思考。开放权重模型另有钉版本的配置块，见原文。

附录 C 补充结果

C.1 逐题通过率（2.0 到 2.1）

C.2 智能体失败分解

智能体评测的基础设施仍在完善：运行器失败、提供方中断、认证错误、沙箱崩溃和准备超时，都可能发生在智能体给出任务级结果之前。为避免把这些和模型行为混在一起，分析用保守的白名单。只保留终态可以解释为智能体结果的试验：通过、做完但答错，或 AgentTimeoutError。超时试验仍按智能体留下的状态评分，被评分的超时里有 11.8% 通过。其他上游基础设施错误在分解之前滤掉。这些被滤掉的基础设施试验大约占上游试验的 27%。

图 7 把每条白名单试验分成互斥的三类：通过（reward=1）、做完但错误（reward=0）、智能体超时。固定预算下，最弱的智能体由超时主导，而不是由已评分的错答主导。这种超时主导出现在 terminus-2 配 Qwen 3.5 9B、Gemma 4 31B、Kimi K2.6 和 GPT 5.4 mini 上。这些格子里，许多运行在智能体做完之前就结束。这促使第 6.2 节做预算扫描。

出处：E. Kelly Buchanan，Crystal Zhou，Scott W. Linderman，Christopher Ré，Benchmarks as Software: Terminal-Bench and the Case for Continuous Benchmarks，2026-11-05，https://arxiv.org/abs/2611.08417，CC BY 4.0。