好的基准

# 好基准
来源：https://arxiv.org/html/2607.12217
\(2026年7月\)

###### 摘要

好任务是正确的、可解的、可验证的、充分定义的，并且因有趣的原因而困难。最好的任务描述了一个经验丰富的从业者能够识别出的真实问题，使用从业者会使用的语言，并附带能验证结果而非方法的测试。

> 基准是 SOTA 必须证明自己的地方。

这篇文章是关于设计好任务的。例子来自 Terminal Bench[4 (https://arxiv.org/html/2607.12217#bib.bib4)]，贡献者们共同花费了数千小时来开发和审查其中的数百个任务。本文的素材来自与 @kjhennegen (https://x.com/kjhennegen)、@ryanmart3n (https://x.com/ryanmart3n)、@alexgshaw (https://x.com/alexgshaw)、@bla1990so (https://x.com/bla1990so)、@isegal (https://x.com/isegal)、@kexun_zhang (https://x.com/kexun_zhang)、@StevenDillmann (https://x.com/StevenDillmann)、@never_settles_ (https://x.com/never_settles_)、@ekellbuch (https://x.com/ekellbuch)、@LiBoxuan91538 (https://x.com/LiBoxuan91538)、@AllenHa13152844 (https://x.com/AllenHa13152844)、@lschmidt3 (https://x.com/lschmidt3) 以及许多其他 TBench 贡献者的对话。

Terminal Bench 是一个针对智能体的硬基准，我们试图进行现实的任务。以往的评估问的是 AI 是否理解了某件事，或者能否完成一个特定的、明确定义的微任务。智能体的评估要困难得多，无论是从验证的角度，还是从了解一个智能体是否有效所需的计算量来看。

最好的任务描述了一个经验丰富的从业者能够识别出的真实问题，使用从业者会使用的语言，并附带能验证结果而非方法的测试。

## 1好任务是什么

好任务是正确的、可解的、可验证的、充分定义的，并且因有趣的原因而困难。每个任务必须：

1. 1.可验证：任务必须能够通过一个程序来检查，该程序几乎保证能检测到错误，并且几乎保证能接受正确的解决方案。必须能够做出一个可靠的判定，将正确解法与错误解法区分开来。拒绝那些评分是主观的（例如，“让这个游戏更有趣”）的任务。将验证器重复运行数百次后不应出现任何失败（例如，验证器超时时间短、崩溃）。
2. 2.充分定义：问题描述完全描述了正确结果的样子。没有任何含糊之处需要猜测。一个粗略、直观的指南是：如果两位专家阅读了问题描述，一个充分定义的问题应当使得他们都能写出验证算法，以至于任何通过其中一位验证器的人也会通过另一位。
3. 3.可解：问题必须提供一个解决方案，或者一个令人信服的论据证明它是可解的。知道该怎么做的人应该能够在任务的时间和资源限制内解决它。
4. 4.困难：任务应该难以解决。问题可能因多种原因而困难；我们要求它因“好理由”而困难。
5. 5.现实且有价值：存在一个真实的场景，其中有人被付钱做这个工作，并且任务反映了他们实际做的方式。仅仅有趣（例如，一个谜题）是不够的；专业人士必须能认出这是他们的工作。
6. 6.结果验证：我们评分的是结果，而不是达成结果的过程。
7. 7.健壮：任务在不同的时间和任何满足所述资源要求的硬件上表现相同：没有未锁定的依赖项，不依赖实时外部服务。

理想的任务可以用两段话来描述，并迫使智能体在做任何事情之前先思考。一个小的程序，在足够苛刻的要求下，可以和一个大的程序一样困难。最优雅的任务拥有简短、定义明确、不言自明的说明，无需额外文档。想想识字编程。

目标不是让任务变得容易，而是让它毫不含糊。我们想要避免的是那种仅仅因为隐藏了智能体所需的一个提示而变得困难的任务；困难应该是内在的，而不是一个缺失的事实。

## 2从真实工作开始

最初的 Terminal Bench 任务大多是我们中某个人在过去某个时候在工作中必须做的事情，然后转换为适当的格式。没有人真正在寻找现实世界的挑战。这里有一个真实问题。解决我烦人的问题。

Terminal Bench 是一项草根努力。大多数创作者是对该项目感兴趣的个体，大多数人制作了一两个任务。这些任务是由拥有硕士和博士学位的人以及执业工程师构建的。真实的任务，经过非常仔细的筛选。其中一些非常非常困难。有很多同行评审。

## 3困难的实际含义

定义一个困难任务的简单方法是：如果模型做不到，那么它就是困难的。但你可以通过让它变得棘手来使其困难。你可以制作一个带有误导性提示的欺骗性谜题。相对论是困难的。一个棘手的谜题只是棘手而已。

这一直是一个巨大的问题：那些一旦充分定义就变得琐碎的任务。问题在于我们所要求的和实际想要的之间的不匹配；差距在于隐含的东西，那些你在分配任务时认为是显而易见的但未能指定的东西。

很多任务从一个可行的提示开始，然后作者删除标记直到它失败。你基本上从一个可解的任务开始，然后逐步使其变得不那么可解。这有点像反向反向传播/基因表达编程算法来使任务变难。但它并没有真正使其变难。

最难的任务往往在第一次就困难。我们想要避免的是找到一个中等难度的任务，然后进入指令，通过留下一些模糊性来人为地使其变难。任务往往是因为它处于锯齿状前沿之外 (https://arxiv.org/html/2607.12217#bib.bib2) 而困难，而不是因为你给了一半的时间或要求它快两倍。

所以我们回到那些描述直接明了、验证器健壮、但答案困难的任务。

一个因预期输出结构复杂（解释如何形成一个复杂 JSON 对象的长指令）而失败的任务，与一个因某些内在困难而失败的任务之间，存在类别上的差异。如果智能体因为在金额字段中放了一个美元符号（而你想要一个浮点数），或者使用了顶层键（而你想要一个裸数组）而失败，那么你衡量的是格式符合性。这不是一个前沿基准旨在测试的能力。如果一个任务对 SOTA 模型来说很难，那不应该是因为它们不会拼写“strawberry”。一个相关的问题是任务范围太广，要求大量的微小交付物而不是一个具体的大问题。

有些任务是多个任务的串联。走偏轨道的概率更高，但任何单独部分可能并不难。其他时候，多个任务之间的协调才是你要解决的问题。这时，将整个过程维系在一起并推动它走向终点才是关键。

有时智能体差点成功。它完成了 90 个子目标，但错过了 5 个。如果那 5 个是困难的部分，任务能不能只关注它们？如果差点成功是一个单一的定量阈值，那么解决方案是在同一领域内提出一个新的概念挑战，而不是收紧阈值。

在修复任务中的错误后，任务有时会从非常难变得非常容易。这是一个理由去更仔细地审视最初是什么让它困难。

## 4关注结果

最好的指令是简短的，一开始就陈述最终目标，并给智能体自由空间来实现目标。列举智能体必须遵循的一长串步骤或过程的指令通常规格过高。保持清晰，但不要冗余。不要告诉智能体它将如何被测试，但要告诉它你期望的最终结果是什么，其中指令的规格要足够充分，以至于满足它们就意味着通过测试。

即使指令是人类编写的，它们也常常是规定性的。作者告诉智能体如何解决问题，而不是最终状态应该是什么。这太文书化了，是一组特定的步骤，而不是一个目标。更好的做法是描述系统应该如何工作，然后让智能体自行解决其余部分。你不需要说明事情可能如何失败：假定一位经验丰富的工程师会理解你的意思，并期望智能体具备同样的理解。

我们把每个词都视为一个可能错误地引入歧义的机会，或者创造一个测试可能遗漏的规范细节的机会。如果任务要求毫不含糊且完美验证，那么简洁就是一个关键绩效指标。

一个有用的启发是：尽可能宽泛，必要时才具体，因为人类实际使用指令的方式就是如此。当一条指令足够宽泛，允许几种合理的方法时，验证器要么必须接受所有这些方法，要么指令需要收紧。否则，智能体会因为猜错了惯例而失败。收紧指令通常是更简单的修复方法，因为验证器是困难的部分。

在实践中，很少有人会在把任务交给智能体之前手写一整页精确的需求。当任务确实附带了一页需求时，它通常是 AI 生成的，没有人审核具体细节，所以指令可能完美地定义了但仍然错误。

## 5证明任务可解

提交的解决方案应该以智能体的方式解决问题。硬编码一个暗示了指令中不显而易见的答案的解决方案没有帮助：你做出了指令没有说明的假设，因此任务规格不足，直到你阅读解决方案时才意识到这一点。

一个合适的诊断任务的神谕会质询系统。它会运行一系列命令来找出问题所在，然后才产生解决方案。如果解决方案直接跳到了答案，没有任何探索步骤，它可能做出了不公平的假设：作者知道真实情况，所以解决方案不是在调查问题，而只是写出已知问题的答案。

更深入的测试是，作者能否给出从指令到验证答案的完整、独立的路径：每一步，达到其领域中可接受的详细程度，最终以验证器接受的答案结束。他们必须做过这项工作才能首先编写验证器；如果他们现在无法产出，他们可能不理解这个任务。而且如果你不能确认解法是正确的，你就不能信任验证器，特别是当它检查精确值时，一个基本正确但有一个符号错误的解法仍然是错误的。

很多这些规格不足的任务是某人与 AI 协作构建，然后删除解决方案的某些部分的结果，没有证据表明被删除的部分可以从剩余部分重构出来。

## 6构建受控环境

任务应在任何满足所述资源要求的硬件上随时间保持一致的行为。没有未锁定的依赖项，没有对实时外部服务的依赖。

环境必须包含智能体解决任务所需的一切，并且神谕必须从相同的信息出发。它不能依赖关于任务的特权信息。这在合成任务中很常见，其中信息被扰乱或损坏，智能体必须恢复它。

然后问环境是否可被破解 (https://arxiv.org/html/2607.12217#bib.bib1,3 (https://arxiv.org/html/2607.12217#bib.bib3),5 (https://arxiv.org/html/2607.12217#bib.bib5))。你能在不完成任务的情况下获得奖励吗？轨迹是破解的一个实例，但你仍然需要解释是什么使环境可破解。是测试吗？是环境的设置方式吗？为什么智能体能够产生破解，以及你将如何缓解它？

弱点可能属于某个任务，也可能是一些关于框架的基本问题，影响了构建于其上的所有任务。修复后，再次运行正常的解决方案。一个修复者也可能使任务变得不可能。

## 7让验证器有意义

测试应该验证结果，而不是实现。当任务从未要求时，为什么要检查 Pandas 是否已安装？通过字符串比较来评估源代码是脆弱的，你应该在提供给智能体的例子之外进行测试。

那些检查特定库而不是正确输出，或者与神谕解法耦合得如此紧密以致任何其他正确方法都会失败的测试很常见。根本原因通常是验证器与作者自己的解决方案共同设计：从一个答案反向构建，而不是从指令推导出来，因此它不够灵活，无法接受其他有效的答案。

当你从一个问题开始时，它往往很直接。验证器很棘手，因为可能有多种方式达成解决方案。你持续运行智能体，看到它们尝试这个又尝试那个。也许它们都失败了，但你必须保持开放，欣赏有其他方式可以达成解决方案。验证器必须接受那些其他正确的路径。对我来说，这是一个发现过程。

这一点在合成数据中尤其容易被忽略。当你从一个假设生成数据时，验证器可能会悄悄地编码一个只有你持有的假设：它对你的公式有效，但对其他公式无效。这就像发明一个看起来简单但实际上不可能的密码，因为只有你知道你围绕它构建的答案。

一种检查验证器是否公平而非与单一答案共同设计的方法：临时过度指定指令（命名方法，添加提示），并确认一个引导良好的智能体能产生验证器接受的答案。如果能，那么困难在于选择方法，而不是一个任意的验证器，并且该验证器在方法条件下是公平的。如果引导良好的智能体仍然失败，则更仔细地审视验证器。

至于 LLM 作为评审？LLM 评审会发现一些问题，但不是所有问题。在真正困难的任务上，我们见过评审说指令不足，因为一个测试假设一个人身高小于三米。这是一个完全合理的假设。截至现在，仍然需要人类查看轨迹并找出错误是什么。

对结果评分，而不是过程。解决方案应该是确定性的，但问题仍然可以是动态的。人们往往在一个问题上产生分歧：AI 应该给你答案，还是给你一个能产生答案的软件？后者往往更可验证、更可测试。一个任务不能说“使用 emacs 编辑文件”；允许使用 vim。证明过程约束合理的一个地方是作为防作弊措施。

## 8运行任务并观察其失败

当我们调试陷入困境时，我们用神谕运行任务，与容器交互，运行测试，看看会发生什么。如果失败来自智能体解决方案，则将智能体日志转换为另一种解决方案并逐步执行。

查看试图解决任务的智能体的日志，尤其是失败日志，并找出原因。它们是因为困难而失败，还是因为不公平？因为指令不足，还是测试过于严格？或者因为它们真的不知道该怎么做？

你必须说服自己失败并非来自任务的缺陷。你可能会怀疑一个 SOTA 模型在一个看起来简单且一次性的任务上失败，所以以 5 个为一组进行试验，使用你的框架的调试工具深入挖掘，看看这些失败有什么共同点。这些是你通过观察轨迹获得的洞察。

并检查核心对齐：是否你认为的