Terminal-Bench 评测全解析：一个用于评测大模型在终端环境使用工具能力的评测基准以及Terminal 1.0与 2.0 的完整对比
477 阅读
加载中...
加载中...
欢迎关注 DataLearner 官方微信，获得最新 AI 技术推送
过去两年，大模型在各种编程评测上一路刷榜：HumanEval、LiveCodeBench、SWE-Bench……成绩越来越好，看起来已经“会写代码”了。但很多团队在真实落地时有一个共同感受：模型在评测里很强，一旦扔进一个干净的 Linux 终端，让它自己从零把环境配好、服务搭起来、脚本跑通，成功率并没有想象中那么理想。
原因并不复杂。传统评测大多停留在“给定输入、生成一段代码、离线跑单元测试”这个层面，很少真正考察模型在真实系统环境里的“执行能力”：会不会用包管理器安装依赖、遇到报错能不能正确读日志和修复、路径错了会不会自己发现、服务没起来能不能一步步排查。这些琐碎但关键的能力，恰恰构成了工程师日常工作的很大一部分。
Terminal-Bench 就是在这样的背景下诞生的。它不是问你“会不会写这个函数”，而是把模型当成一个可以打字的工程师，塞进一个隔离的终端环境里，给出一份任务说明：从零开始，把需求完成。能不能完成、完成得怎么样，用一个标准化的流程来评估。
本文介绍 Terminal-Bench 的设计理念，深入讲解 core、Terminal-Bench Hard 与最新 Terminal-Bench 2.0 的区别，帮助开发者选择合适的 AI 终端评测基准。
要理解后面不同版本的差异，先得看清楚这个评测的基本玩法。
在一轮 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 的新数据集，目标已经不再是“证明这套评测能跑起来”，而是要在未来一段时间里，持续对最强模型保持足够的区分度，尽量贴近真实工程场景。
这三种形态并不是互相独立的“分支”，也不是简单的版本号递增，而是随着使用场景变化、模型能力提升逐步演化出来的。下面就顺着时间线，把它们背后的原因和各自特点说具体一点。
回到最初的 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 是一种“内生的关系”：前者可以看作是后者中最具挑战性部分的提纯版，用来放大差异。
时间来到 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 / Hard / 2.0）、用的是什么 Agent 配置、以及你希望通过这个分数说明的是“模型本身的硬实力”，还是“模型+Agent 的整体系统能力”。只有这样，读者看到那一行分数时，才知道它到底在衡量什么。
从 HumanEval 到 SWE-Bench，再到 Terminal-Bench，其实是一条非常清晰的演化路径：从“能不能写出正确的代码”，到“能不能修好一个真实项目”，再到“能不能在一个干净环境里，从无到有把任务做完”。Terminal-Bench 的三种形态也恰好对应了三个时代的问题：最开始我们问“这套评测框架本身能不能跑起来”，接着我们问“强模型之间到底差多少”，到 2.0 的阶段，问题变成了“在新一代模型面前，什么才是有意义的工程级考验”。
在这个意义上，Terminal-Bench 不仅仅是一个新的 benchmark 名字，而是把“执行任务”这件事，第一次系统性地纳入了模型能力版图之中。随着 AI Agent 应用越来越多，这种“会不会在终端里干活”的能力，可能会比许多传统评测分数更重要。
你后面如果要在 DataLearnerAI 上做模型对比页面，其实完全可以把这套故事浓缩成几句话放在表格或脚注里：说明自己引用的 Terminal-Bench 成绩来自哪个版本、配了什么 Agent、想强调哪一类能力。我也可以帮你把这篇文章拆成适合你网站结构的几个小节，或者配一张“1.0 → Hard → 2.0 的演进示意图”，你要的话直接说。