Terminal-Bench 评测全解析：一个用于评测大模型在终端环境使用工具能力的评测基准以及Terminal 1.0与 2.0 的完整对比

过去两年，大模型在各种编程评测上一路刷榜：HumanEval、LiveCodeBench、SWE-Bench……成绩越来越好，看起来已经“会写代码”了。但很多团队在真实落地时有一个共同感受：模型在评测里很强，一旦扔进一个干净的 Linux 终端，让它自己从零把环境配好、服务搭起来、脚本跑通，成功率并没有想象中那么理想。

原因并不复杂。传统评测大多停留在“给定输入、生成一段代码、离线跑单元测试”这个层面，很少真正考察模型在真实系统环境里的“执行能力”：会不会用包管理器安装依赖、遇到报错能不能正确读日志和修复、路径错了会不会自己发现、服务没起来能不能一步步排查。这些琐碎但关键的能力，恰恰构成了工程师日常工作的很大一部分。

Terminal-Bench 就是在这样的背景下诞生的。它不是问你“会不会写这个函数”，而是把模型当成一个可以打字的工程师，塞进一个隔离的终端环境里，给出一份任务说明：从零开始，把需求完成。能不能完成、完成得怎么样，用一个标准化的流程来评估。

本文介绍 Terminal-Bench 的设计理念，深入讲解 core、Terminal-Bench Hard 与最新 Terminal-Bench 2.0 的区别，帮助开发者选择合适的 AI 终端评测基准。

Terminal-Bench 实际在做什么？

要理解后面不同版本的差异，先得看清楚这个评测的基本玩法。

在一轮 Terminal-Bench 任务中，系统会先启动一个全新的 Linux 容器，里面只有最基础的系统环境，不会提前帮你装好各种依赖。然后，它把任务描述发给模型：比如要实现一个命令行工具、要搭一个 HTTP 服务、要写一段脚本处理文件、要完成一段数据处理工作等等。模型不会直接“交一个答案”，而是通过一层 Agent 框架和真实终端交互——它会看到当前目录下有哪些文件，输入命令，收到 stdout 和 stderr，再根据结果决定下一步干什么。

整个过程就像一个远程实习生在你机器上开了个 Shell：
不断敲命令、看输出、改代码、重试，直到它觉得“差不多了”。这时，评测框架会运行事先准备好的测试脚本，检查服务能不能正常响应、文件是否按要求生成、脚本是否能在规定条件下成功执行，最后给出“这道任务是否通过”的结论。多道任务跑完之后，通过率就是模型在 Terminal-Bench 上的成绩。

这种评测方式有两个核心特点：一是环境是真的，容器里的 Linux 就是你线上可能遇到的那种环境；二是过程是交互式的，考察的是“观察—决策—执行—纠错”的完整闭环。这也就是为什么很多人会说，Terminal-Bench 测的是“执行力”，而不是简单的“代码能力”。

为什么会有三个“版本”？先把全貌说清楚

随着这个评测被越来越多团队采用、不断迭代，现在社区在谈到 Terminal-Bench 时，实际上往往指的不是同一个东西，而是三种彼此相关、但侧重点不同的形态：

第一种是最早发布的任务集，常被称为 Terminal-Bench 1.0，技术上对应的是 terminal-bench-core v0.1.1。它是整个体系的起点，承担着“把这套评测方式先做出来”的角色。

第二种是后来由 Artificial Analysis 在自己的评测框架里引入的 Terminal-Bench Hard。它不是一个全新的数据集，而是从 1.0 里挑出了所有难度标记为 hard 的任务，做成一个高难度子集，并搭配统一的 Agent 配置，专门用来拉开模型在“困难终端任务”上的差距。

第三种则是你提到的在 2025 年 11 月推出的 Terminal-Bench 2.0。这是官方在新一代模型出现之后，对整个任务集做的系统级重设计，用的是一个名字通常写作 terminal-bench@2.0 的新数据集，目标已经不再是“证明这套评测能跑起来”，而是要在未来一段时间里，持续对最强模型保持足够的区分度，尽量贴近真实工程场景。

这三种形态并不是互相独立的“分支”，也不是简单的版本号递增，而是随着使用场景变化、模型能力提升逐步演化出来的。下面就顺着时间线，把它们背后的原因和各自特点说具体一点。

从 1.0 到 Hard：先把路铺好，再挑出真正难走的那段

回到最初的 Terminal-Bench 1.0。那时候，研究者的首要目标其实很朴素：先证明“大模型 + 真实终端环境”这种评测范式是可行的。于是就有了 terminal-bench-core v0.1.1 这个任务集。它更像是一块“试验田”——任务覆盖面尽量广，有简单的、有中等的，也有比较复杂的，目的是把各种可能遇到的终端操作场景先挖一遍，看看整体流程到底能不能跑通。

这样的设计在早期非常有价值。论文、内部实验、不同模型的对比，都有了一个统一的参照点。但随着越来越多的模型在这套任务上跑过一遍，人们逐渐发现一个问题：大量简单任务会把整体分数“抹平”，强模型和一般模型在总分上似乎差不太多。你知道它们不一样，但数字未必能很清楚地反映出来。

Artificial Analysis 在做自己的 τ²-Bench 和 Agent 能力评测时，就碰到了这个问题。他们真正关心的是：在那些对工程能力要求高、出错空间大的任务上，模型之间到底差多少？为了解决这一点，他们没有自己重新造一个“类似 Terminal-Bench 的新数据集”，而是直接站在 1.0 的肩膀上，只做了一件事——把其中难度标记为 hard 的那一部分任务单独抽出来。

这样，Hard 子集就诞生了。更进一步，他们还给这套子集配上了统一的运行方式：大家都用同一个 Agent（比如 Terminus 2），同样的交互规则，同样的重试策略。在这种设定下，Terminal-Bench Hard 的分数就更多地反映出“在真正棘手的终端任务上，模型靠自身能力能走多远”，而不是靠 agent 策略堆出来的效果。

从这个角度看，Hard 和 1.0 是一种“内生的关系”：前者可以看作是后者中最具挑战性部分的提纯版，用来放大差异。

从 Hard 到 2.0：当“老题库”开始留不住新一代模型

时间来到 2025 年，新一代通用模型和 Agent 框架密集出现。在很多团队的实际测试中，Terminal-Bench 1.0 里的不少任务，对于这些模型来说已经不是“难题”，而更像是“练习题”。再加上早期任务设计时难免存在一些依赖外部环境、稳定性欠佳的测试项，导致结果偶尔会受网络、第三方服务等因素干扰。

这时候，官方面临的选择其实只剩两条路：
要么继续在 1.0 上打补丁，删删改改、加点任务、调调参数；
要么干脆承认“时代变了”，重新从“现在的模型能力”和“现在的工程实践”出发，再设计一套新的任务集。

Terminal-Bench 2.0 走的就是第二条路。2.0 不再试图兼容 1.0 的任务结构，而是从头规划了一个面向新一代模型的任务体系：哪些场景是真实工程常见的、哪些流程最能考验 Agent 的决策与执行、什么样的任务组合能让最强模型也不至于轻松“做满分”，又能保证测试稳定可复现。这些考虑直接决定了 2.0 的设计风格。

在运行方式上，2.0 也更强调与现代 Agent 框架的配合，例如推荐使用统一的运行框架（如 Harbor 这一类方案），既方便提交结果到官方榜单，也方便企业内部复现实验。简而言之，2.0 不只是“多了一套题”，而是把整套考试体系按今天的标准重写了一遍。

此时再回头看这三种形态，就比较清楚了：1.0 更多是范式的落地、Hard 是从中提炼出的“难度放大镜”，而 2.0 则是面向未来几年重新出的一套“正式卷子”。

用一张表把三者的关系再梳理一下

虽然上面已经从故事线的角度解释了三者的演化，但对于需要做模型对比、写技术分析报告的人来说，一张总览表还是有用的。下面这一张可以当作快速查阅的“备忘录”。

维度	Terminal-Bench 1.0（terminal-bench-core v0.1.1）	Terminal-Bench Hard（Artificial Analysis 子集）	Terminal-Bench 2.0（terminal-bench@2.0）
产生背景	初次落地终端评测范式，需要一套“能跑起来”的完整任务集	在 1.0 上很难拉开模型差距，希望只看高难度表现	新一代模型出现，旧任务难度和稳定性都不再适配
任务来源	官方早期 core 任务库，难度从简单到困难都有	从 1.0 中筛选出所有 hard 标记的任务组成子集	官方重新设计的一套新任务，面向未来几年的模型能力
主要用途	建立统一评测基线，支撑早期论文和内部测试	作为 τ²-Bench 等指标中“终端执行力”的高难度部分	作为官方和社区当前主流的终端评测标准和榜单基础
与 Agent 的关系	Agent 选择自由度高，配置差异较大	强约束：统一 Agent 和配置，突出模型自身硬实力	结合现代 Agent 框架设计，强调“模型+Agent 系统”的端到端能力
在今天的价值	适合做历史对比、复现早期工作	适合做模型“困难终端任务能力”的对比分析	适合作为当前和未来一段时间主力参考指标

如果你在文章、报告或者对比页面里引用 Terminal-Bench 的结果，最重要的就是把这三点说清楚：用的是哪一套任务（1.0 / Hard / 2.0）、用的是什么 Agent 配置、以及你希望通过这个分数说明的是“模型本身的硬实力”，还是“模型+Agent 的整体系统能力”。只有这样，读者看到那一行分数时，才知道它到底在衡量什么。

小结：Terminal-Bench 真正在改变的，是我们看待模型能力的方式

从 HumanEval 到 SWE-Bench，再到 Terminal-Bench，其实是一条非常清晰的演化路径：从“能不能写出正确的代码”，到“能不能修好一个真实项目”，再到“能不能在一个干净环境里，从无到有把任务做完”。Terminal-Bench 的三种形态也恰好对应了三个时代的问题：最开始我们问“这套评测框架本身能不能跑起来”，接着我们问“强模型之间到底差多少”，到 2.0 的阶段，问题变成了“在新一代模型面前，什么才是有意义的工程级考验”。

在这个意义上，Terminal-Bench 不仅仅是一个新的 benchmark 名字，而是把“执行任务”这件事，第一次系统性地纳入了模型能力版图之中。随着 AI Agent 应用越来越多，这种“会不会在终端里干活”的能力，可能会比许多传统评测分数更重要。

你后面如果要在 DataLearnerAI 上做模型对比页面，其实完全可以把这套故事浓缩成几句话放在表格或脚注里：说明自己引用的 Terminal-Bench 成绩来自哪个版本、配了什么 Agent、想强调哪一类能力。我也可以帮你把这篇文章拆成适合你网站结构的几个小节，或者配一张“1.0 → Hard → 2.0 的演进示意图”，你要的话直接说。