Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces

Paper: arXiv:2601.11868 Code: harbor-framework/terminal-bench Code reference: main @ 1a6ffa9 (2026-01-21) Experiment configs: laude-institute/terminal-bench-experiments — main @ 0433864 (2026-01-14)

1. Motivation（研究动机）

Terminal-Bench 这篇论文要解决的核心问题不是“再做一个 coding benchmark”，而是把 agent 真实使用终端时会遇到的长程、混杂、可验证任务做成一个足够难、足够现实、又能规模化运行的评测框架。现有 benchmark 大致有几类短板：SWE-Bench 等偏软件补丁修复，WebArena / OSWorld 等偏网页或桌面交互，函数调用 benchmark 偏 API 调用正确性，传统代码生成 benchmark 又常常停留在单函数、短上下文、离线判题。它们都能测一部分能力，但很难覆盖工程师在 terminal 里真正做事时的混合流程：安装依赖、读文件、编译、调试、跑测试、查资料、修改配置、处理超时、恢复上下文、发现验证不足，最后让一个真实环境达到目标状态。

论文强调 terminal 是一个特别重要的 agent interface：它足够通用，几乎所有工程、数据、系统、科学计算工作都能落到 shell/container 中；同时它又足够危险和混乱，错误命令、环境漂移、包版本、权限、网络、日志解释都会影响结果。一个 agent 如果只会写一段代码，却不能在受限容器中反复探索、修复、验证，就离“自动完成有价值任务”仍然很远。因此 Terminal-Bench 的评测对象是 outcome，而不是轨迹；它要求 agent 把容器最终状态变成满足 tests 的状态，而不是复现作者预期命令序列。

这篇论文的现实动机可以拆成三层。第一层是 benchmark 难度：作者认为 frontier agents 已经能在很多公开 benchmark 上接近饱和，继续用过易任务会掩盖能力差距；Terminal-Bench 2.0 选出的任务让最强组合也低于 65% resolution rate。第二层是任务真实性：任务来自开放贡献者和专家工作流，覆盖从机器学习训练、Linux/source 构建、逆向工程、COBOL 重写、异步 Python 清理逻辑到权限/系统配置等不同类型，而不是合成 toy problems。第三层是诊断价值：仅给一个总分不够，作者还做了 trajectory-level 和 command-level error analysis，把失败归到 execution、coherence、verification 等类别，为后续 agent scaffold、模型推理、验证策略改进提供方向。

Figure 2 解读：这张图展示了 Terminal-Bench task 的最小单元：instruction、Dockerfile、tests、oracle solution，以及运行时把 tests 拷入 agent 容器后执行验证。关键点是 tests 检查 final container state，而不是检查 agent 是否运行了某条命令；这使 benchmark 更接近真实工作，因为真实用户关心服务是否配置好、程序输出是否正确、数据是否恢复，而不是 agent 走了哪条路径。

更细地说，Terminal-Bench 把“任务难”定义为 agent 需要在一个真实 shell 中完成多步状态变换。这个设计避免了很多 benchmark 的过拟合点：如果只测最终文本答案，模型可以猜；如果只测代码 patch，任务常常被 repository context 限制住；如果只测浏览器或函数调用，底层系统能力被隐藏。终端任务则把所有这些能力混在一起：模型必须理解 instruction，发现环境结构，选择工具，编辑文件，运行测试，解释失败，再决定下一步。论文的贡献就在于把这种混合流程做成可复现、可审核、可扩展的数据集和 harness。

2. Idea（核心思想）

核心思想可以概括为：用真实 Docker/container 终端任务作为 agent benchmark 的基本单位，用人类 oracle solution 和自动化 tests 保证可验证性，用多轮人工审核保证任务不是脏数据，并用统一 Harbor harness 把不同 agent/model 组合放到同一 outcome-driven 评测协议下。Terminal-Bench 不假设 agent 必须是某种固定工具调用形式；Claude Code、Codex CLI、Gemini CLI、OpenHands、Mini-SWE-Agent 和 Terminus 2 都可以接入。对 agent 来说，任务就是一个 terminal environment；对评测者来说，唯一重要的是最后 tests 是否通过。

与 SWE-Bench / WebArena / OSWorld 的根本差别在于，Terminal-Bench 把“真实终端状态转移”作为核心对象，而不是“代码仓库 issue 修复”“网页操作”“桌面 GUI 操作”中的某一种。它也不同于 Bash command translation benchmark：Terminal-Bench 不是让模型生成一条 shell 命令，而是让 agent 在可能持续几十分钟、几百次 API call、上千万 token 的交互过程中解决完整问题。论文中最能体现这个想法的例子是：有任务要求正确处理 Python asynchronous jobs 在 keyboard interrupt 时的 cleanup；另一个任务要求把 COBOL 程序改写成 Python，并通过输入输出等价测试。这类任务需要语言理解、系统知识、调试策略和验证意识同时工作。

本文的创新点不在于提出新模型或新 loss，而在于 benchmark engineering：作者将任务构造、任务审核、执行 harness、agent scaffold、结果统计、错误 taxonomy 和开源发布连成一个闭环。Terminal-Bench 2.0 的 89 个任务来自 93 位贡献者提交的 229 个任务，经过作者难度判断和三位有经验 reviewer 的质量评估筛选；每个任务有 oracle solution，用于证明 solvability；每个任务有 tests，用于判断 final state；每个任务还经过 no-op/dummy agent 等自动检查，减少“假任务”或 reward hacking 空间。

Figure 3 解读：这张图是 benchmark 质量控制的关键。任务进入项目 GitHub 后先跑自动 workflow，包括 oracle solution 是否能通过 tests、dummy/no-op agent 是否应该失败、常见 task 文件是否完整；随后贡献者自查；再经过多轮人工 review。论文报告每个任务三轮 review 合计平均约 3 小时，这解释了为什么 Terminal-Bench 强调“hard but verified”，而不是只靠自动采集扩规模。

从 agent 研究角度看，Terminal-Bench 的一个重要 insight 是把 scaffold 和 model 的影响分开观察。论文承认二者很难完全解耦，因为很多 agent scaffold 是为特定模型习惯优化的，甚至会把复杂工具安装到容器里；所以作者额外设计了 Terminus 2，一个极简、相对中立的 scaffold：单一工具是 headless terminal，模型只能输出 Bash/keystrokes，通过 tmux 执行后拿回输出。这样可以更接近“同一 terminal interface 下模型本身如何表现”的问题，而不是只比较不同产品化 agent 的工程堆料。

Figure（Adapters）解读：附录的 adapters 图说明 Terminal-Bench 的任务格式不是只服务本论文 89 个任务，而是可以把其它 benchmark/任务源转换到 Harbor/Terminal-Bench 格式中。论文正文提到这种灵活 task specification 已经使 26 个 preexisting benchmarks 能被适配进同一格式；这让 Terminal-Bench 更像一个 terminal-agent evaluation substrate，而不是一次性排行榜。

3. Method（方法）

3.1 Task formulation：用 final state tests 定义成功

每个 Terminal-Bench task 由五个核心元素组成：instruction、Docker image / Dockerfile、tests、example/oracle solution、time limit。Instruction 描述 agent 需要完成的目标；Docker image 提供隔离环境；tests 检查最终状态；oracle solution 是人类写的可执行工作流，用来证明任务可解；time limit 防止 agent 无限探索。作者明确说 tests 不评判 agent 的 commands 或 console output，而是验证 instruction 中要求的 outcomes 是否已经实现。这个设计让 agent 可以自由选择路径：它可以编辑文件、运行 Bash、安装包、写脚本、调用外部资源，只要最终容器满足 tests。

这种 outcome-driven verification 的直觉是：真实任务中用户通常不会要求 agent “按标准轨迹行动”，而是要求“系统真的修好”。如果 tests 直接绑定轨迹，benchmark 会变成模仿人类 solution；如果只判定自然语言答案，又无法覆盖真实文件系统状态。Terminal-Bench 选择 final container state 作为评测目标，正好把二者分开：任务可以很开放，但评测必须可重复。缺点也很明显：tests 必须足够完备，否则 agent 可能通过弱验证；因此论文把 specificity、solvability、integrity 作为人工审核核心标准。

Figure 4 解读：任务类别图显示 Software Engineering 是最大类，但不是多数类；其余任务分布在系统工程、数据处理、机器学习、优化、游戏/规划、个人助理等多个方向。这个分布支持作者的 claim：Terminal-Bench 不是单纯 coding benchmark，而是用 terminal 统一承载多种 real workflow。

3.2 Dataset construction：从开放贡献到 89 个 verified tasks

数据构造流程先开放征集，再筛选。论文报告 93 位 contributors 创建了 229 个候选任务；每个贡献者需要给出 expert time estimate 和 junior-engineer time estimate。作者再根据任务作者的 difficulty assessment 和三位 experienced human reviewers 的 quality assessment，选出 Terminal-Bench 2.0 的 89 个任务。正文和摘要反复使用 89 tasks 作为数据集规模；但附录 detailed results 的表注写到 token counts are for running all 74 tasks，且 Table 1 的 time buckets 加总也是 74。笔记中保留这个 paper-level discrepancy：主文贡献按 89 个任务理解，部分实验统计/表格似乎基于 74 个运行任务或子集，论文没有在相邻文本中充分解释这个差异。

时间估计显示任务确实偏长程：expert 估计中，36 个任务（48.6%）少于 1 小时，35 个（47.3%）在 1 小时到 1 天，3 个（4.1%）在 1 天到 1 周；junior 估计中，只有 6 个（8.1%）少于 1 小时，53 个（71.6%）在 1 小时到 1 天，12 个（16.2%）在 1 天到 1 周，3 个（4.1%）超过 1 周。论文特别提到 fix-ocaml-gc：该任务要求修复一次失败优化后的 OCaml garbage collector，expert 约 24 小时，junior 约 240 小时。这类任务给出了 benchmark 的长程上限，也解释了为什么有 trial 会持续接近 2 小时并消耗极多 tokens。

3.3 Verification：specificity、solvability、integrity

作者把 verified task 的标准拆成三项。Specificity 要求 instruction 和 tests 对“正确终态”的覆盖一致：tests 应该 pass 当且仅当容器处在可接受状态。Solvability 要求存在 oracle solution，可以从初始环境出发使所有 tests pass。Integrity 要求 agent 不能用真实部署中不存在的 shortcut reward-hack，例如如果任务是修改某个 commit 的 repo，未来 commits 需要从 history 中移除，否则 agent 可以偷看未来状态。每个任务进入 GitHub 后，自动 workflow 运行 oracle solution、检查 dummy agent 应该失败、验证常见文件和 task spec；之后再走人工 review。

这个 verification 体系的价值在于给 outcome-driven benchmark 补上可信度。Outcome-driven tests 的最大风险是 tests 过窄：agent 可能只写死测试、修改测试、伪造数据、删除约束，或者走某条不真实 shortcut。Terminal-Bench 通过 oracle solution + dummy failure + reviewer checklist + multiple review rounds 尽量降低这些风险。它不能完全消除 benchmark leakage 或测试不足，但比单纯 scrape GitHub issue 或自动生成任务更可控。

3.4 Harness：Harbor 格式、Docker sandbox 和并发 trials

实验部分使用 Harbor 运行 Terminal-Bench 2.0。论文写到 Harbor 是作者发布的 agent evaluation framework；Terminal-Bench tasks 以 Harbor task format 实现，通过 Harbor harness 执行；Terminal-Bench 2.0 分发在 Harbor registry，可用 harbor run -d terminal-bench@2.0 运行。实验配置代码库 terminal-bench-experiments/configs/tb2 显示核心设置包括 n_attempts: 5、timeout_multiplier: 1.0，并按 agent 类型设置并发：例如 terminus-closed.yaml 用 n_concurrent_trials: 100，proprietary.yaml 和 mini-swe-agent.yaml 用 64，openhands.yaml 用 32，terminus-open-fireworks.yaml 用 8。论文正文也说实验使用 Daytona，并行运行 32 到 100 个 containers。

released code 中，terminal_bench/harness/harness.py 的 Harness 类是执行主干。_execute_tasks() 为 dataset 中每个 task 和 attempt 提交 trial，使用 ThreadPoolExecutor 并发执行；_run_trial() 为单次 attempt spin up terminal/container，保存 pre-agent pane，运行 agent，保存 post-agent pane，再运行 tests；_setup_test_env() 把 run-tests.sh 和 tests/ 复制到 container 的 test 目录；_run_tests() 调用 test 脚本并处理 test timeout；_parse_results() 用 task parser 从 post-test pane 解析 pass/fail；最后 _write_results() 写出 benchmark results。这个流程与论文 Figure 2 的抽象一致：agent 先自由修改环境，tests 后置进入容器执行，结果由 parser 解析。

3.5 Terminus 2：一个尽量中立的 terminal-only scaffold

Terminus 2 的方法动机是降低 scaffold bias。论文指出 Claude Code、OpenHands、Gemini CLI 等 agent 常有专门文件编辑、命令执行、下载等工具，有些 agent 还会把复杂工具安装到容器中，这会让“模型能力”和“agent 工程能力”混在一起。Terminus 2 则只给模型一个 headless terminal：模型产生 keystrokes/commands，tmux 在 Docker container 内执行，输出再回到模型。它仍然不是纯 Bash 单命令；模型可以打开 editor、滚动、用方向键、起额外 shell、安装依赖和调用 API，但接口上只有 terminal。

代码中 terminal_bench/agents/terminus_2/terminus_2.py 的 Terminus2 类体现了这个设计。_run_agent_loop() 按 episode 循环，先检查 tmux session 是否存活，再在接近 context limit 时主动 summarization，随后 _handle_llm_interaction() 调用 LLM 并解析输出中的 commands 和 completion flag；_execute_commands() 用 session.send_keys() 把 keystrokes 输入 tmux，返回增量输出；如果模型声明完成，Terminus 2 需要 double confirmation，第一次只是提示确认，第二次才真正 break。_check_proactive_summarization() 在 free tokens 小于 8000 时调用 _summarize()，这对应论文附录 F 中“context summarization module 可以让 agent 处理需要 millions of tokens 的 extended tasks”。

Terminus 2 的直觉很重要：它不试图成为最佳生产 agent，而是成为可解释的评测 scaffold。因为它只有 terminal 工具，失败更容易归因到模型如何计划、如何读输出、如何验证，而不是归因到某个复杂编辑器工具或专有 planner 的隐藏机制。相应代价是 Terminus 2 可能不如产品 agent 高效，例如写大文件、结构化 patch、文件搜索都要靠 shell 完成；但作为 benchmark 的中立 baseline，这个 tradeoff 是合理的。

3.6 Code mapping（基于 released code 的论文概念对齐）

Code reference: main @ 1a6ffa9 (2026-01-21); experiment configs main @ 0433864 (2026-01-14)

Paper Concept	Source File	Key Class/Function
Harbor/Terminal-Bench dataset loading	terminal_bench/dataset/dataset.py	DatasetConfig, Dataset.from_config(), Dataset._init_dataset(), Dataset.task_ids
Task specification and output paths	terminal_bench/handlers/trial_handler.py	Task.from_yaml(), TaskPaths, TrialPaths, TrialHandler.instruction
Benchmark execution harness	terminal_bench/harness/harness.py	Harness.run(), _execute_tasks(), _execute_single_trial(), _run_trial()
Test injection and verification	terminal_bench/harness/harness.py	_setup_test_env(), _run_tests(), _parse_results(), _is_resolved()
Terminal-only scaffold	terminal_bench/agents/terminus_2/terminus_2.py	Terminus2._run_agent_loop(), _handle_llm_interaction(), _execute_commands()
tmux terminal backend	terminal_bench/terminal/tmux_session.py	TmuxSession.send_keys(), capture_pane(), get_incremental_output()
Experiment attempts/concurrency	terminal-bench-experiments/configs/tb2/*.yaml	n_attempts: 5, n_concurrent_trials: 8/32/64/100, model-agent lists
CLI entry and user-facing run command	README.md, terminal_bench/cli/tb/runs.py	tb run --agent ... --model ... --dataset-name terminal-bench-core ...

伪代码（由 Harness、TrialHandler、Terminus2 和 TmuxSession 的 released code 抽象）：

def run_terminal_bench(dataset, agents, models, n_attempts):
    results = []
    for task in dataset:
        for attempt in range(n_attempts):
            trial = TrialHandler(task, attempt)
            with spin_up_terminal(task.docker_env) as terminal:
                pre_agent_pane = terminal.capture_pane()
                agent = create_agent_for_task(task, agent_name, model_name)
                agent.perform_task(
                    instruction=trial.instruction,
                    session=terminal.tmux_session,
                    logging_dir=trial.paths.agent_logging_dir,
                )
                post_agent_pane = terminal.capture_pane()
                copy_to_container(task.run_tests_sh, CONTAINER_TEST_DIR)
                copy_to_container(task.tests_dir, CONTAINER_TEST_DIR)
                test_failure = run_tests_with_timeout(terminal, task.max_test_timeout_sec)
                parsed = task.parser.parse(terminal.capture_pane())
                results.append(resolve(parsed, test_failure))
    return aggregate_resolution_rates(results)
 
def terminus2_loop(instruction, session, chat):
    prompt = build_initial_prompt(instruction)
    pending_completion = False
    for episode in range(max_episodes):
        if not session.is_session_alive():
            break
        if free_tokens(chat) < 8000:
            prompt = summarize_context(chat, instruction, session)
        response = chat.chat(prompt)
        commands, is_complete, parser_feedback = parse_response(response)
        if parser_feedback_is_error(parser_feedback):
            prompt = parser_feedback
            continue
        timed_out, terminal_output = execute_keystrokes_in_tmux(session, commands)
        if is_complete:
            if pending_completion:
                break
            pending_completion = True
            prompt = ask_for_completion_confirmation(terminal_output)
        else:
            pending_completion = False
            prompt = terminal_output

论文公式与 released code 实现差异：本文不是训练算法论文，基本没有 loss/formula 与 released code 需要逐项对齐；需要注意的差异主要是 paper-level count/reporting：摘要和正文称 Terminal-Bench 2.0 有 89 tasks 并在 89 tasks 上 benchmark，但 appendix detailed results 的表注写 token counts are for running all 74 tasks，且 time-estimate table 加总为 74。released repo 当前 original-tasks/ 又包含 241 个 task directories，说明公开代码库是持续演化的完整任务仓库，不等同于论文实验冻结子集；复现实验应以论文链接的 Harbor registry / experiment configs 为准，而不能直接把当前 repo task count 当论文数据规模。

4. Experimental Setup（实验设置）

实验评估六个 agents 和十六个 frontier/open-weight models。agents 包括三个常见 command-line agents：Claude Code、Codex CLI、Gemini CLI；以及三个开源 software engineering agents：OpenHands、Mini-SWE-Agent、Terminus 2。models 包括 GPT-5.2、GPT-5-Mini、GPT-5-Nano、Claude Opus 4.5、Claude Sonnet 4.5、Claude Haiku 4.5、Claude Opus 4.1、Gemini 3 Pro、Gemini 3 Flash、Gemini 2.5 Pro、Gemini 2.5 Flash、Grok 4、Grok Code Fast，以及 open-weight GPT-OSS 120B/20B、Llama 4 Maverick、Qwen 3 Coder 480B、Kimi K2 Instruct、Kimi K2 Thinking、GLM 4.6、MiniMax M2 等。论文正文概括为 16 frontier models，具体模型列表在不同 agent 兼容性下展开。

每个 supported model-agent combination 至少运行五次，论文报告总计 32,155 trials；每个 trial 是一个 agent 对一个 task 的一次 attempt。模型接入方式分两类：Claude/Gemini/Codex CLI 使用各自公司模型；closed-source models 走 first-party APIs；open-weight models 走 Together.AI API。对于可配置 reasoning effort 的模型，论文采用 provider default（Anthropic/OpenAI 为 medium）。实验不是单机串行跑，而是通过 Harbor + Daytona 并发运行 32 到 100 个 containers；released experiment configs 也显示不同 agent 配置有不同 n_concurrent_trials。

Figure 5 解读：Pareto frontier 图把 resolution rate 和运行成本放在一起，说明 Terminal-Bench 不只测“谁最高分”，也揭示“高分要花多少钱”。论文写到运行 Terminal-Bench 2.0 的成本可从一美元到一百美元级别变化，取决于模型价格；许多 trial 少于 20 分钟，但极端情况下可接近 2 小时、数百次 API call、接近 1 亿 tokens。这个图对实际选型很重要：高性能 agent 可能并不处于成本最优点。

数据集指标包括任务类别、expert/junior 估计时长、empirical difficulty、resolution rate、95% confidence intervals、token usage、execution time、API/model call 数（Terminus 2 runs）、trajectory-level failure modes、command-level failure modes。resolution rate 是主指标：任务是否被解决，由 tests/parser 判断；confidence intervals 反映多次 attempt 的不确定性。作者还用 human-predicted difficulty 与 empirical difficulty 比较，empirical difficulty 由 Terminus 2 在 frontier models 上的平均 pass rate 定义：大于等于 66.7% 为 Easy，33.3% 到 66.7% 为 Medium，小于 33.3% 为 Hard。

Figure 7 解读：difficulty heatmap 表明 human-predicted difficulty 与 empirical difficulty 有正相关（r = 0.436, p < 0.001），但并不一致。论文指出人类标 hard 的任务中 93.3% 对模型也 empirical hard；最大错位是人类标 medium 而模型觉得 hard（54.5%）。这说明人类估计可以粗略筛选，但 agent 的困难点与人类工程师不同：人类可能觉得环境配置常规，agent 却会卡在验证、上下文、命令错误或工具使用上。

实验配置的一个重要 caveat 是 agent-model coupling。论文没有声称所有模型都在完全同一 scaffold 中公平比较；相反，它承认现实 agent 产品与模型深度绑定，故 leaderboard 分数反映“模型 + agent scaffold”的组合能力。Terminus 2 的存在是为了提供更中立的模型比较视角，但最高分仍可能来自更工程化的 Codex CLI / Claude Code 等产品 agent。因此解读结果时应同时看“best harness per model”和“Terminus 2 within-model comparison”。

5. Experimental Results（实验结果）

主结果：Codex CLI + GPT-5.2 获得最高平均 resolution rate，论文正文写约 63%；appendix detailed table 给出 62.9% ± 3.0%，token counts 为 137.5M input / 2.3M output。第二梯队是 Terminus 2 + Claude Opus 4.5：57.8% ± 2.5%，3.9M input / 1.3M output；Terminus 2 + Gemini 3 Pro：56.9% ± 2.5%，5.1M input / 2.2M output；GPT-5.2 + Terminus 2：54.0% ± 2.9%，12.4M input / 2.6M output。Claude Opus 4.5 + Claude Code 为 52.1% ± 2.5%，但 input token 统计高达 256.9M，显示产品 agent 可能通过大量上下文/工具交互获得能力。

Figure 6 解读：随模型发布时间变化的性能图显示新模型整体更强，GPT-5.2、Claude Opus 4.5、Gemini 3 Pro/Gemini 3 Flash 位于前列。作者的结论不是“已经解决 terminal work”，而是“能力正在接近能自动化这些工作的一部分”：最强组合仍低于 65%，说明大量任务仍需更好的规划、验证、环境调试和长上下文管理。

中高分结果还包括 Gemini 3 Flash + Terminus 2：51.7% ± 3.1%；GPT-5 + Codex CLI：49.6% ± 2.9%；Claude Sonnet 4.5 + Terminus 2：42.8% ± 2.8%；Claude Sonnet 4.5 + Mini-SWE-Agent：42.5% ± 2.8%；GPT-5 + OpenHands：41.5% ± 2.8%。开源/开放权重模型中，Kimi K2 Thinking + Terminus 2 约 35.7% ± 2.8%，是 open-weight 组中最突出之一。正文指出 proprietary models 占据 top 13 positions，而 Terminus 2 + Kimi K2 Thinking 是 open-weight models 中表现最好的组合，平均解决约 36% tasks。

agent scaffold 的影响显著，但通常小于模型选择。正文给的例子是：Codex CLI 使用 GPT-5.2 相比 GPT-5-Nano resolution rate 增加 52 个百分点；Gemini-2.5-Pro 配 Terminus 2 相比 OpenHands 增加 17 个百分点。这说明同一个 agent scaffold 换强模型可以带来巨大提升；同时同一模型在不同 scaffold 中也会变化，尤其当 scaffold 提供更好的文件编辑、上下文管理或验证策略时。对实际应用而言，Terminal-Bench 更像“系统能力”评测，而不是纯模型评测。

错误分析是论文的重要结果。Trajectory-level error analysis 以 Terminus 2 为一致 scaffold，对每个模型抽样失败 trials，用 Docent 和自定义 pipeline 做 annotation；taxonomy 简化为 Execution、Coherence、Verification 三个大类及子类。论文报告校准子集 20 trials 上 annotators 达到高一致性（93%）；Figure 8 显示闭源 frontier models 的错误 profile 类似，Opus 4.5 和 GPT-5.2 的 execution errors 占主导，而 coherence 与 verification 较低；Qwen Coder 则更均衡，说明较弱模型不仅会执行命令错，也更容易任务偏航、上下文丢失或验证不足。

Figure 8 解读：这张图按模型展示 failure modes，核心结论是最强闭源模型的失败更偏 execution：它们大体知道要做什么，但在具体命令、环境、依赖、脚本、验证细节上出错。相对较弱模型则更容易出现 coherence / verification 问题，例如 task derailment、context loss、premature termination、no or incorrect verification。对 agent 工程来说，这意味着提升不只来自更强模型，也来自更好的命令执行反馈、自动验证策略、错误恢复和上下文压缩。

Command-level error analysis 进一步把每条命令输入输出对拿出来判断是否出现失败。论文用 GPT-5 medium reasoning 作为 LLM judge，对 66 对由三位 annotators 标注的样本达到 92.4% majority-vote agreement；再用 GPT-5 high reasoning effort 对 command failures 做 taxonomy classification，agreement 为 82.0%。命令错误率从 Grok 4 的 9.2% 到 GPT-OSS-120B 的 26.7% 不等。这个分析很有价值，因为很多 terminal agent 失败不是宏观计划错，而是某一步命令返回错误后没有读懂、没有修复、或继续基于错误状态行动。

Figure 9 解读：command failure 的环形图把失败按大类和子类分布展示。论文正文强调小于 5% 的类别归入 Other，小于 3% 的子类也合并。这里的重点不是某个子类的绝对比例，而是说明 Terminal-Bench 能把“没过测试”进一步拆成可行动的工程问题：是命令语法、module not found、路径/文件缺失、app failure、环境/网络，还是 REPL/interactive 状态处理错误。这样的诊断粒度比单一 pass@1 更能指导 agent 改进。

结果的另一个反直觉点是：更多交互不等于更高成功率。附录 G 分析 episode count 与 success rate，相关系数 r = -0.028，p = 0.916，几乎没有相关；output tokens 与 success rate 也只有弱负相关 r = -0.170，p = 0.515。论文用 GPT-5 Codex、Claude Sonnet 4.5、GPT-5 等例子说明，有的模型用较少 episodes 就能达到较高成功，而 Qwen 3 Coder 480B 和 GLM 4.5 Air 等可能消耗更多 episodes 但成功率较低。这支持一个判断：terminal task 的关键不是“尝试次数”本身，而是每次观察、命令、验证之间的决策质量。

局限性方面，论文很直接。第一，Terminal-Bench 允许 agent 访问 internet 以安装 packages 或查询资料，因此理论上 agent 可能找到公开 dataset 和 oracle solutions 作弊；作者说在数万条 trajectories 中没有观察到这种行为，但 benchmark 使用者仍要警惕。第二，模型开发者可能把数据集纳入训练；作者在 repo 文件中加入 Big-Bench canary string 帮助 decontamination，但无法阻止有意污染。第三，Docker images、package versions、外部网络资源和 API 都可能随时间变化；作者通过 pin versions、pre-built Docker images、Docker context 中包含依赖来增强 reproducibility，但 internet access 仍会带来漂移。第四，Terminal-Bench 只覆盖终端中的 outcome-driven tasks，不覆盖需要真实用户偏好、开放式写作、不可自动验证的工作。

综合来看，Terminal-Bench 的结论是：当前 frontier agents 已经能解决相当一部分真实终端任务，但离稳定自动化 expert/junior 工程工作仍有明显差距；差距主要不在单点代码生成，而在长期交互中的环境理解、命令执行、错误恢复、验证覆盖和上下文管理。对后续研究，最直接的方向是：更可靠的 self-verification、更好的 terminal state abstraction、可恢复的长程 planning、更强的环境/依赖错误诊断，以及能把失败轨迹转化为训练数据的 agent learning pipeline。

6. 复现与使用建议

如果要复现论文结论，不应只 clone 当前 harbor-framework/terminal-bench 后统计 original-tasks/，因为当前 repo 已经包含 241 个 task directories，明显超过论文冻结实验集。更可靠的路径是使用论文中的 Harbor registry dataset 版本和 terminal-bench-experiments/configs/tb2 中的配置，记录 exact dataset version、agent version、model version、container image digest 和 API 参数。尤其是 Terminal-Bench 这种动态依赖较多的 benchmark，复现报告必须保留：任务列表、attempt 数、timeout、并发、sandbox provider、是否允许 internet、模型 reasoning effort、agent scaffold commit。

使用 Terminal-Bench 评价自研 agent 时，建议同时报三类结果：一是 overall resolution rate 与 confidence interval；二是 per-category / per-difficulty breakdown，防止总分掩盖系统工程或数据处理短板；三是 failure taxonomy，不要只说“失败了”，而要标出 command failure、weak verification、context loss、premature termination 等具体模式。对于生产 agent，额外要看 cost/performance Pareto：一个分数高但消耗数亿 input tokens 的配置，未必适合实际部署。

我对这篇论文的判断是：它的主要价值在 benchmark design 和 released harness，而不是单个排行榜数字。排行榜会随模型更新快速变化，但任务格式、审核标准、outcome-driven verification 和 failure analysis pipeline 会继续有用。尤其是对于命令行 agent，Terminal-Bench 提供了一个比简单 coding benchmark 更接近真实工作流的压力测试：只要 agent 不能稳定完成 install-debug-edit-test-verify 的闭环，就会在这里暴露。