Terminal-Bench: 在命令行界面中对智能体执行困难、真实任务的基准测试 Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces
提出Terminal-Bench 2.0基准，89个CLI任务揭示前沿模型解决率不足65%
前置知识
AI Agent（AI智能体）
AI智能体是指能够自主感知环境、制定计划并执行操作以完成目标任务的系统。在本文的语境中，智能体通过命令行接口（CLI）与容器化的Linux环境交互，使用shell命令（如grep、find、cat）或更复杂的工具来编辑文件、运行代码、安装软件包等。与简单的问答式LLM不同，智能体需要进行多轮交互、维护上下文、处理错误并调整策略，这要求模型具备长程推理和自主决策能力。例如，Claude Code、Codex CLI、Gemini CLI等商业智能体已广泛用于软件开发，Anthropic声称Claude Code驱动了10亿美元的年化收入。
本文的核心就是评测这类智能体在真实命令行任务中的表现，理解智能体的概念是理解整个研究动机和评估框架的基础。
Docker容器化环境
Docker是一种操作系统级虚拟化技术，允许将应用程序及其所有依赖打包在一个轻量级、可移植的容器中。每个Terminal-Bench任务都在独立的Docker容器中运行，容器由Dockerfile定义，预装了相关软件包和文件。这种设计确保了任务环境的隔离性、可复现性和一致性。容器还支持快照和回滚，方便评测框架管理任务的初始状态和最终状态。任务的评估方式是检查容器最终状态是否满足测试条件，而非检查智能体的具体操作。
Terminal-Bench的每个任务都运行在Docker容器中，理解容器化技术是理解任务架构和评测方法论的前提。
Benchmark（基准测试）
基准测试是一组标准化的评测任务和评估方法，用于客观比较不同系统或模型的性能。在AI领域，基准测试通常包含一组精心设计的任务、明确的评估指标和可复现的实验设置。一个好的基准测试应当具备任务的真实性和多样性、评估的客观性和公平性、足够的难度来区分不同能力水平的系统。Terminal-Bench在ABC（Agentic Benchmark Checklist）框架评估中得分0.896，在现有基准中排名第二，体现了其评估的严谨性。
理解基准测试的设计原则和评估方法论是理解本文贡献和局限性的关键。
SWE-Bench及相关基准
SWE-Bench是评估AI智能体解决真实GitHub issue能力的基准测试，已成为软件工程领域智能体评测的重要参考。类似的基准还包括HumanEval（代码生成）、WebArena（网页交互）、tau-Bench（工具使用）、OSWorld（计算机操作）等。这些基准各有侧重，但共同面临任务真实性、难度控制和评估可靠性等挑战。Terminal-Bench与这些基准的区别在于任务来自真实工作流而非合成环境，任务类型更多样（14个类别），任务难度更高。
了解现有基准的优缺点有助于理解Terminal-Bench的创新点和定位。
LLM-as-Judge（LLM作为评判者）
LLM-as-Judge是一种使用大语言模型来自动评估或标注数据的方法。在本文中，作者使用GPT-5（高推理模式）作为主要评判者来分类智能体的失败模式。具体流程是先由人工标注者对20个校准样本进行标注，达成93%的Cohen's kappa一致性；然后使用LLM评判者对120个人工标注的轨迹进行评估，达成90%的一致性（92%精确率、90%召回率）。这种方法使得大规模的错误分析成为可能，同时保持了与人类判断的高度一致性。
理解LLM-as-Judge方法有助于评估本文错误分析的可靠性和局限性。
研究动机
当前AI智能体评测面临两大核心问题。首先，现有基准大多无法衡量真实世界的任务。例如，SWE-Bench虽然使用真实GitHub issue，但主要聚焦于代码补丁生成；HumanEval等代码生成基准则过于简单，无法反映专业开发者面临的复杂工作流。其次，现有基准的难度不足以有效区分前沿模型的能力。随着GPT-5.2、Claude Opus 4.5、Gemini 3 Pro等模型的快速发展，许多基准已被或即将被饱和。例如，Claude Code已声称驱动了10亿美元的年化收入，但目前缺乏一个能够真正衡量这些商业级智能体在多样化、长程、高难度CLI任务中表现的基准。此外，现有基准的任务类型单一，大多局限于软件工程的特定子领域，无法覆盖命令行环境中的多样化工作场景，如科学计算、网络安全、系统配置、逆向工程等。
本文的目标是本文旨在构建一个全面、困难、真实的CLI智能体评测基准Terminal-Bench 2.0，具体目标包括：设计89个来自真实工作流的高难度任务，涵盖软件工程、科学计算、网络安全、系统管理等多个领域；确保每个任务都有唯一的容器化环境、人工编写的参考解决方案和全面的测试验证；通过严格的质量控制流程确保任务的正确性和公平性；对16个前沿模型和6个智能体进行大规模评测（共32,155次试验），揭示当前模型的能力边界和失败模式；发布数据集和评估框架，帮助开发者和研究者改进智能体系统。
与已有工作不同的是，Terminal-Bench的独特切入角度体现在三个方面。第一，任务来源的真实性和多样性：89个任务由93位贡献者从真实工作流中提取，涵盖软件工程（最大类别但不占多数）、科学计算、网络安全、文件操作、调试、数据处理、模型训练等14个类别。第二，任务难度的极端性：任务作者估计专家完成时间从不到1小时到超过1天不等，初级工程师则可能需要数天到数周。例如，fix-ocaml-gc任务（修复OCaml垃圾收集器）专家需要近24小时，初级工程师需要10天。第三，评估框架的严谨性：每个任务经过三轮人工审查，平均每个任务约3小时的审查时间，总计数百人时的审查投入，加上对抗性智能体的漏洞检测，这在现有基准中极为罕见。
核心方法
Terminal-Bench的整体思路是构建一个端到端的智能体评测框架，将真实世界的CLI任务标准化为可自动评估的测试用例。从直觉上讲，就像给一个软件工程师分配任务一样：给他一个装好环境的电脑（Docker容器）、一份任务说明、一个时间限制，然后通过运行测试来检查他是否完成了任务。技术路线包括三个核心组件：任务规范（每个任务包含指令、Docker镜像、测试集、参考解决方案和时间限制，这种四元组规范已被证明可以适配26个其他现有基准）；评估框架（基于Harbor框架，支持Claude Code、Codex CLI、OpenHands、Mini-SWE-Agent等多种智能体，并集成了Daytona容器沙箱，可并行运行32到100个容器）；质量控制（通过自动化CI检查、LLM辅助审查、人工审查和对抗性测试四层保障任务质量）。整个系统采用结果驱动的评估方式，只检查容器的最终状态是否满足测试条件。
Terminal-Bench的核心创新在于将真实世界的专业技能工作标准化为可评测的任务。与现有基准的本质区别体现在：任务粒度不是简单的代码生成或bug修复，而是完整的端到端工作流，如从源代码构建Linux系统、实现完整的物理渲染器、进行FEAL差分密码分析等，这些任务需要深度领域知识和长链式依赖操作；评估方式采用黑盒测试，只检查最终状态，不限制解题路径，这比白盒评估更贴近真实场景；质量保障采用三层审查机制加上对抗性测试，确保任务的正确性和防作弊性。
方法步骤详情
Terminal-Bench的评测流程包括以下步骤。任务准备阶段，贡献者创建任务，包括编写Dockerfile定义环境、编写task.yaml描述任务、编写tests/定义测试用例、编写solution.sh提供参考解决方案。质量控制阶段，首先运行自动化CI检查（金丝雀字符串检查、Dockerfile引用检查、权限检查等），然后使用LLM辅助工具检查任务描述与测试的一致性、防作弊措施、依赖版本固定等。接着由经验丰富的审查者进行人工审查，确保任务满足特异性、可解性和完整性三个标准。对抗性测试阶段，运行对抗性智能体，尝试通过作弊方式通过测试，以发现设计漏洞。正式评测阶段，使用Harbor框架并行运行多个智能体，每个任务至少运行5次，共32,155次试验。结果分析阶段，通过运行测试用例判定任务是否完成，计算解决率，并进行轨迹级错误分析和命令级错误分析。
技术新颖性
Terminal-Bench的技术新颖性主要体现在以下几个方面。任务规范的灵活性：每个任务由指令、Docker镜像、测试集和参考解决方案四元组定义，这种规范已被证明可以适配26个其他现有基准。评估框架的中立性：作者开发了Terminus 2作为中立的测试平台，它只有一个工具（无头终端），仅使用Bash命令完成任务。错误分析的系统性：基于MAST发展出终端智能体分类法（TAT），将失败模式分为执行、连贯性和验证三大类，并使用LLM-as-judge进行大规模标注。难度评估的客观性：引入了基于模型表现的经验难度指标，将任务分为简单、中等和困难三个等级。时间维度的分析：展示了模型性能随发布时间的增长趋势，8个月内最佳解决率从约35%提升到63%。
实验结果
本文的核心发现可以归纳为以下几点。第一，前沿模型的表现远未饱和：GPT-5.2（Codex CLI）以63%的解决率位居榜首，其次是Claude Opus 4.5（Terminus 2）的58%和Gemini 3 Pro（Terminus 2）的57%。闭源模型占据了排行榜前13位，开源模型中表现最好的Kimi K2 Thinking（Terminus 2）仅为36%，GPT-OSS-20B（Mini-SWE-Agent）仅为10%左右。第二，模型选择比智能体框架更重要：Codex CLI使用GPT-5.2比使用GPT-5-Nano的解决率提高了52%，而Gemini-2.5-Pro使用Terminus 2比使用OpenHands的解决率提高了17%，表明模型能力是性能的主要决定因素。第三，任务难度与人类直觉高度一致：93.3%被人类评为困难的任务在经验难度上也被评为困难，相关系数r=0.436（p<0.001）。但54.5%被人类评为中等的任务被模型评为困难，这些任务通常需要创造性或对抗性推理。第四，执行错误是主要失败模式：对于Claude Opus 4.5和GPT-5.2，执行错误占主导地位。相比之下，开源模型Qwen Coder 480B的错误分布更均衡。第五，命令级错误分析显示，调用未安装或不在PATH中的可执行文件是最常见的命令失败类型（占24.1%），其次是运行可执行文件时的失败（占9.6%）。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Terminal-Bench 2.0 整体解决率 | Resolution Rate | GPT-5.2 (Codex CLI): 63% | Claude Opus 4.5 (Terminus 2): 58% | GPT-5.2比最佳开源模型Kimi K2 Thinking (36%)高出27个百分点 |
| 模型选择 vs 智能体框架影响 | Resolution Rate差异 | GPT-5.2 vs GPT-5-Nano (Codex CLI): 52%提升 | Gemini-2.5-Pro (Terminus 2 vs OpenHands): 17%提升 | 模型选择的影响是智能体框架影响的约3倍 |
| 人类预测难度 vs 经验难度对齐 | 相关系数r | r = 0.436, p < 0.001 | 93.3%人类困难任务也被评为经验困难 | 困难端高度对齐，但中等难度存在54.5%的分类差异 |
| 命令级错误率 | Command Error Rate | Grok 4: 9.2% | GPT-OSS-120B: 26.7% | 最佳模型命令错误率仅为最差模型的约1/3 |
| 模型性能随时间增长 | Resolution Rate增长 | GPT-5.2 (2026年1月): 63% | Gemini 2.5 Pro (2025年4月): ~35% | 8个月内最佳解决率近乎翻倍 |
局限与改进
本文的局限性可以从作者承认的和我自己的观察两个角度来分析。作者承认的局限性包括：作弊风险——由于允许智能体访问互联网以安装包和查询信息，理论上智能体可以定位数据集并阅读参考解决方案，尽管在数万次试验中未观察到这种行为；数据污染风险——所有任务都托管在公开的GitHub仓库中，尽管包含了Big-Bench金丝雀字符串来阻止训练数据污染，但这主要是象征性的防护；可复现性挑战——虽然通过固定包版本、提供预构建Docker镜像等方式提高可复现性，但互联网访问引入了外部依赖。我自己的观察包括：任务分布的代表性不均衡（软件工程有26个任务，而个人助手、视频处理等只有1-2个任务）；评估的静态性（未深入分析任务间的相关性）；成本效益分析的不足（未提供每次成功解决的成本等指标）；对抗性测试的覆盖范围有限（未评估数据污染的影响）。
独立分析的弱点
基于对论文的独立分析，我识别出以下几个主要弱点及其改进方向。第一，任务覆盖的不均衡性：14个类别中，软件工程有26个任务，而个人助手、视频处理等类别只有1-2个任务。改进方向是增加代表性不足类别的任务数量，或在报告结果时按类别进行分层分析。第二，评估的静态性：当前评估只报告平均解决率和置信区间，未深入分析任务间的相关性。改进方向是引入任务聚类分析，按失败模式对任务进行分组。第三，成本效益分析的不足：虽然展示了性能与成本的权衡图，但未提供每次成功解决的成本等指标。改进方向是引入cost per resolved task等指标。第四，对抗性测试的覆盖范围有限：对抗性智能体主要用于检测设计漏洞，但未评估数据污染的影响。改进方向是引入更系统的数据污染检测方法。
未来方向
本文为未来研究指明了多个方向。作者明确提出的方向包括：持续更新基准——随着新模型的发布，将继续评估并在tbench.ai上发布结果，同时计划发布新的挑战性任务集；私有测试集——作者认为开发私有测试集超出了本文范围，但建议未来工作考虑这一选项。基于成果可延伸的方向包括：多模态扩展——当前基准仅测试CLI交互，未来可以扩展到图形界面、Web界面等多模态环境；协作任务——当前基准测试单个智能体，未来可以引入多智能体协作任务；长期任务——当前任务的专家完成时间从不到1小时到超过1天，未来可以引入需要数周甚至数月的长期任务；领域专业化——可以针对特定领域开发专门的子基准。
复现评估
从复现性角度来看，Terminal-Bench 2.0具有较高的可复现性。数据和代码方面，数据集和评估框架已发布在GitHub和Harbor注册表，可以直接运行。任务环境方面，每个任务的Docker镜像都预构建并固定了依赖版本，确保了环境的一致性。评估方法方面，详细的评估协议、LLM评判者的提示词和失败模式分类法都已在论文中公开。然而，复现仍面临一些挑战：算力需求（运行32,155次试验需要大量计算资源和API调用费用）；模型访问（闭源模型需要API访问权限）；时间成本（完整运行一次基准可能需要数天时间）；外部依赖（互联网访问引入的外部依赖可能导致结果随时间变化）。
论文图表
