我重新核对后发现，官方资料里可以被稳定确认的是：

• 官方任务总数是 89。
• 官方任务浏览页支持按 category、tag、difficulty 过滤。
• 论文给出了高层类别分布：软件工程是最大类，同时覆盖 system administration、data science、security、scientific computing、file operations 等类别；论文还明确说，数据集中也包含 personal assistant、video processing 这类非传统“纯软件工程”任务。

但官方并没有在我这次核对的文档里，给出一份与我上一版完全对应的“89 个任务中文重分组清单”。所以继续保留那份清单，只会让文章看起来更完整，却更不准确。

如果你真想逐题看，最稳妥的方法是直接用官方任务页：tbench.ai/benchmarks/terminal-bench-2。它本身就是当前最准确的任务浏览入口。

下面这份表格是我在 2026/04/17 直接从 官网任务页抓取并核对的当前 89 个任务。任务顺序、官方分类和难度以官网为准；中文名和任务内容是基于官网任务卡信息做的中文整理，方便快速浏览。

这也是为什么 Terminal-Bench 对 agent engineering 很有价值。它不是在测“会不会答题”，而是在测“会不会把工作做完”。

根据 Harbor 官方教程，Harbor 是 Terminal-Bench 2.0 的官方运行 harness。如果你今天要跑，请优先按 Harbor 的当前文档来，不要依赖旧博客或旧命令。

uv tool install harbor
harbor --version

先做最小验证：

harbor run -d terminal-bench/terminal-bench-2 -a oracle

然后再跑自己的 agent。这里要分清两件事：官方教程里明确给出的 Claude Code 命令，是 Daytona 版；如果你只是想在本地小并发试跑自己的 agent，可以把并发数调小，但那属于你自己的运行策略，不是官方固定示例。

# 下面这段是本地小并发试跑思路，不是 Harbor 官方教程原文
export ANTHROPIC_API_KEY=<YOUR-KEY>

harbor run \
  -d terminal-bench/terminal-bench-2 \
  -m anthropic/claude-opus-4-1 \
  -a claude-code \
  --n-concurrent 4

这里还有一个容易混淆的小点：我在 2026/04/17 核对时，Harbor 的 “Running Terminal-Bench” 专题教程页使用的是 terminal-bench/terminal-bench-2；但 Harbor 的其他通用 eval 文档里，仍然还能看到 terminal-bench@2.0 这种 versioned 写法。也就是说，这两种写法都出现在官方文档中，只是当前 Terminal-Bench 专题教程页展示的是 slash 这一版。

如果你要上 Daytona 跑更高并发，官方教程给的是：

export DAYTONA_API_KEY="<your-daytona-api-key>"
export ANTHROPIC_API_KEY="<your-anthropic-api-key>"

harbor run \
  -d terminal-bench/terminal-bench-2 \
  -m anthropic/claude-haiku-4-5 \
  -a claude-code \
  --env daytona \
  -n 32

这一部分是我觉得上一版最应该补的。Harbor 官方的 run-jobs 文档已经把 job 和 trial 的基本目录结构写得很清楚了。

jobs/job-name
├── config.json
├── result.json
├── trial-name
│   ├── config.json
│   ├── result.json
│   ├── agent
│   │   ├── recording.cast
│   │   └── trajectory.json
│   └── verifier
│       ├── ctrf.json
│       ├── reward.txt
│       ├── test-stderr.txt
│       └── test-stdout.txt
└── ...

如果你想开浏览器看这些结果，当前文档建议直接运行：

harbor view jobs

Harbor viewer 支持看 job、trial、trajectory、奖励、时长、错误、artifact，属于复盘 benchmark 结果时非常高频的工具。

Harbor 用的是 ATIF，也就是 Agent Trajectory Interchange Format。它不是一份随意日志，而是面向 debugging、trajectory replay、SFT 和 RL 的标准化 JSON 结构。

官方 ATIF 文档里给出的核心字段大致包括：

• 根对象：schema_version、session_id、agent、steps、可选的 final_metrics
• agent：agent 名称、版本、模型名
• steps：按顺序记录每一步交互
• 每个 Step：通常有 step_id、timestamp、source、message
• agent step 还可以带 reasoning_content、tool_calls、observation、metrics
• metrics：prompt tokens、completion tokens、cached tokens、cost 等运行指标
• final_metrics：总 token、总 cost、总 steps 等聚合指标

如果你只把它当“对话记录”，会低估它的价值。更准确地说，它是一份结构化的 agent 运行轨迹：你能看到用户指令、agent 回复、工具调用、环境返回、token 和成本信息，甚至还能做回放和训练数据导出。

Harbor 的 task 文档把这件事写得非常明确：测试脚本必须在 /logs/verifier/ 里产出 reward 文件，否则 verifier 没法判定任务结果。

Harbor 默认会先读 reward.txt，没有的话再回退到 reward.json。官方 task 文档给的示例也很直接：跑测试成功就往 /logs/verifier/reward.txt 写 1，失败就写 0。

#!/bin/bash

uvx pytest /tests/test.py

if [ $? -eq 0 ]; then
  echo 1 > /logs/verifier/reward.txt
else
  echo 0 > /logs/verifier/reward.txt
fi

另外，Harbor 还定义了几个特殊路径：

• /logs/verifier/：reward 和 verifier 日志
• /logs/agent/：agent 运行日志
• /logs/：会在运行后下载回 host，方便调试
• /logs/artifacts/：零配置 artifact 收集目录

如果你的任务会生成模型、输出文件、报告图、日志等需要带出容器的产物，Harbor 官方推荐直接写到 /logs/artifacts/。这样 trial 结束后会自动收集到 host 上。

# Inside the sandbox
echo "result" > /logs/artifacts/output.txt
cp model.pt /logs/artifacts/model.pt

收集后，trial 目录里通常会多出一个 artifacts/ 文件夹，以及对应的 manifest.json：

<trial_dir>/
├── artifacts/
│   ├── manifest.json
│   ├── output.txt
│   └── hello.txt
├── agent/
├── verifier/
├── config.json
└── result.json

这对 leaderboard 提交也很重要，因为 Hugging Face 的官方提交流程明确要求：trial 目录里不能只有 result.json，还需要包含运行产出的其他 artifacts。

这部分官方要求写得相当具体，基本可以直接照着做。

提交仓库是这个 Hugging Face 数据集仓库：

harborframework/terminal-bench-2-leaderboard

官方 README 里给出的提交流程是：

1. Fork 仓库
2. 新建 branch
3. 把提交内容放到 submissions/terminal-bench/2.0/<agent>__<model(s)>/
4. 开 Pull Request

README 里给了一个最小示意结构，但它主要是为了说明提交路径和 metadata.yaml 的位置，不代表 trial 目录里只需要放一个 result.json：

submissions/
  terminal-bench/
    2.0/
      <agent>__<model>/
        metadata.yaml
        <job-folder>/
          config.json
          <trial-1>/result.json
          <trial-2>/result.json
          ...

metadata.yaml 是必需的，README 里要求至少包含：

agent_url: https://...
agent_display_name: "My Agent"
agent_org_display_name: "Org"
models:
  - model_name: gpt-5
    model_provider: openai
    model_display_name: "GPT-5"
    model_org_display_name: "OpenAI"

更重要的是验证规则。要通过自动校验，官方目前要求：

• timeout_multiplier 必须等于 1.0
• 不能覆盖 agent timeout
• 不能覆盖 verifier timeout
• 不能覆盖 CPU / memory / storage 资源
• 所有 trial 目录都必须有合法的 result.json
• 所有 trial 目录都不能只有 result.json，还必须包含其他运行产物
• 每个 task 至少要评估 5 次，README 直接建议用 -k 5
• agent 不能访问 Terminal-Bench 网站或 GitHub 仓库，否则会被判定为 reward hacking

我现在对 Terminal-Bench 2.0 的看法，比上一版更明确了：

• 它最适合拿来检查一套 agent system 是否真的具备“终端里完成工作”的能力。
• 它不适合被二手转述成“某某类别 12 题、某某类别 9 题”的伪精确清单。
• 真正有价值的，是拿官方任务浏览器看任务本身，再用 Harbor 的 job / trial / trajectory / verifier 文件做失败分析。

如果你是自己在做 coding agent，我会建议用下面这个顺序：

1. 先用 Oracle 跑通 Harbor，确认环境没问题。
2. 再小并发试跑自己的 agent，看最基础的成功率和失败簇。
3. 重点读 trial/result.json、trajectory.json、reward.txt、test-stderr.txt。
4. 等单次稳定后，再按 leaderboard 要求做更规范的多 trial 评估和提交。

• Terminal-Bench 2.0 官方任务浏览页：确认当前显示 89 tasks，并提供 category / tag / difficulty 过滤。
• Terminal-Bench 2.0 论文：确认 89 个正式任务、229 个候选任务、93 位贡献者、任务结构与高层类别信息。
• Harbor: Running Terminal-Bench：当前官方运行方式与 dataset 标识。
• Harbor: Run Evals：job / trial 目录结构与结果查看方式。
• Harbor: Tasks：reward.txt / reward.json、/logs/verifier、/logs/agent 等特殊路径。
• Harbor: Agent Trajectory Format (ATIF)：trajectory.json 的结构与用途。
• Harbor: Artifact Collection：/logs/artifacts 与 artifacts/manifest.json。
• Hugging Face leaderboard 提交仓库：metadata.yaml、提交目录和自动校验规则。