当 AI Agent 从聊天助手演进为能够自主执行复杂任务的系统时，如何客观衡量其真实能力成为关键问题。传统的代码生成评测如 SWE-Bench 聚焦于代码片段的产出质量，但忽视了 AI 在完整工作流中与环境交互、执行多步骤指令、处理错误和恢复状态的能力。Terminal-Bench 2.0 正是为填补这一空白而生 —— 它构建了一套基于真实命令行环境的评测基准，让 AI Agent 在隔离的容器中完成从软件工程到系统运维的各类复杂任务，并以结果导向的测试验证其完成度。
任务设计：从 229 个候选中筛选的 89 个真实场景
Terminal-Bench 2.0 的核心资产是 89 个经过精心筛选的 CLI 任务。这些任务并非人为构造的玩具题，而是来源于真实工作流中的痛点场景。研究团队收集了 229 个候选任务，涵盖软件工程、遗留系统配置、科学计算等多个领域，最终通过多轮专家评审保留了 89 个「困难且可验证」的任务。每个任务包含四个核心组件：自然语言指令描述目标、Docker 镜像提供一致的运行环境、自动化的测试套件验证结果、以及一个人类编写的 oracle solution 用于证明任务可解。这种设计确保了任务的可审计性 —— 评测时不关注 Agent 采用了何种路径，只关注最终是否达成目标。
任务筛选过程本身也值得深入了解。平均每个任务耗费约三小时的人工审查时间，评审者包括领域专家和验证系统。团队还引入了对抗性测试环节，专门训练「作弊 Agent」去寻找任务的漏洞或捷径 —— 例如通过查看 git 未来的 commit 来「预知」答案。这种机制有效提升了基准的鲁棒性，防止模型通过记忆而非真正的问题解决能力来通过测试。
评测架构：Docker 隔离与 Harbor 执行框架
为了让评测具备可重复性，Terminal-Bench 2.0 完全基于 Docker 容器构建。每个任务对应一个预构建的镜像，其中包含任务所需的所有依赖、文件和工具。Agent 被放置在一个「头戴式」终端环境中 —— 它只能通过 Bash 命令与系统交互，没有图形界面，也无法直接访问外部文档或搜索引擎（尽管可以通过 curl 等工具自行获取信息，但这本身就是一种考察）。这种设计模拟了真实场景中工程师面对未知问题的状态：没有提示，只能依靠自身知识和工具探索。
执行层面采用了名为 Harbor 的任务运行框架。Harbor 负责并行调度大量评测任务、管理容器生命周期、收集执行日志，并自动运行测试套件判定成功与否。团队选择 Daytona 作为默认的容器沙箱提供商，但 Harbor 的设计支持多种后端，以便在不同基础设施上复现结果。这种解耦思路体现了评测框架的可移植性追求 —— 基准本身不应与特定云服务绑定。
性能真相：前沿模型仍未突破 65% 的天花板
在 16 个前沿模型和 Agent 组合上的大规模评测揭示了当前技术的真实边界。最高分由 GPT-5.2 配合 Codex CLI 取得，仅为 63% 的任务解决率。这意味着即便最强组合也难以完成近四成的任务。更令人警醒的是，小型开源模型的表现普遍在 15% 到 36% 之间，与闭源前沿模型存在显著差距。
评测还暴露了一个重要的成本维度：性能与支出之间存在明显的 Pareto 前沿。某些模型虽然便宜，但任务完成率极低；另一些模型能力强劲，但单次运行的 token 消耗和 API 费用可能高达数十美元。团队在评测中发现，部分任务需要 Agent 持续运行近两小时、进行数百次模型调用才能完成或失败。这种长时序、高交互的场景对现有 Agent 的规划和推理能力提出了严峻考验。
值得注意的是，模型能力呈现明显的上升趋势。在约 8 个月的评测周期内，新模型的表现几乎翻倍。这既验证了 AI 能力的快速进步，也意味着当前的基准可能在不久后被「刷爆」，需要持续引入更难的任务以维持区分度。
错误分析：执行失败与 PATH 问题占据主导
Terminal-Bench 2.0 的独特价值不仅在于评测本身，还在于其深入的失败模式分析。团队使用 LLM-as-judge 方法对数万条失败轨迹进行了自动标注，将错误归纳为三大类别：执行错误、连贯性错误和验证错误。
执行错误是最主要的失败来源，其中最频繁的问题是「命令所调用的可执行文件未安装或不在 PATH 中」。这一类型占据了全部失败的 24.1%，远高于其他类别。这揭示了当前 Agent 的一个关键盲点：它们往往假设环境中存在特定工具，却缺乏对依赖状态的主动检查和安装能力。其次是运行时错误，占比 9.6%，涉及命令执行过程中的各类异常。
连贯性错误表现为 Agent 在多步骤任务中丢失目标、步骤顺序混乱或重复无效操作。验证错误则指 Agent 虽然完成了表面工作，但未真正理解任务结束的条件，导致测试失败。这些错误分布为 Agent 改进指明了方向：增强环境感知和依赖管理能力、强化长期规划与状态追踪、提升结果验证意识。
工程启示：从基准到实践的路径
Terminal-Bench 2.0 对工业界的启示是多层面的。对于企业采购 AI Agent 用于运维或开发自动化场景，基准提供了客观的模型对比依据。安全团队可以引入对抗性测试流程，参照基准的作弊检测机制来评估 Agent 的行为边界。平台团队则可以基于 Harbor 格式构建自己的领域特定评测集 —— 例如金融数据处理、CI/CD 流程验证等 —— 以标准化内部 Agent 能力的评估。
对于 Agent 开发者而言，基准揭示的技术瓶颈直接对应着工程改进方向。针对 PATH 问题的工具，可以在 Agent 骨架中集成环境探测和按需安装模块；针对连贯性问题，可以引入显式的目标状态追踪和回溯机制；针对验证问题，可以在任务拆解阶段强制要求 Agent 生成自验证检查点。这些改进并非空想，而是基于数万次真实评测数据的实证结论。
局限性与未来演进
任何基准都有其适用范围。Terminal-Bench 2.0 目前仅限于 Linux 容器环境，未覆盖 Windows/macOS 场景或多 GPU 分布式任务。所有任务均为英文指令，对多语言能力的考察不足。评测采用二元判定（通过或失败），无法捕捉部分完成的情况。此外，任务池的代表性仍存在改进空间 ——89 个任务虽经过筛选，但与真实行业中无穷尽的工作负载相比仍显单薄。
团队已在论文中列出了详细的改进路线图：引入私有测试集以防止基准泄露、扩展到非 Linux 平台、加入分级评分机制、增加多 Agent 协作场景等。随着模型能力的持续提升，基准本身也需要不断进化才能保持衡量价值。
资料来源：Emergent Mind 论文《Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces》(2601.11868)