💡 一句话总结：公开榜单告诉你 agent 在「通用任务」上多强，但选型要的是它在「你的场景」上多强。Harbor + Terminal-Bench 2.0 让你能亲手量化这件事，还能把你团队的真实痛点写成自定义任务。
一、为什么不能只看公开榜单
选 coding agent 时，几乎所有人第一步都是看 Terminal-Bench、SWE-Bench 这类榜单。问题是：榜单分数反映的是通用任务上的平均能力，不是你的场景。
一个在 Terminal-Bench 2.0 上拿 50% 的 agent，放进你的代码库——满是特有的构建流程、冷门依赖、内部约定——可能只剩 20%。更别说厂商发布时往往挑对自己有利的配置和任务子集。
所以认真的选型应该自己跑评测。好消息是，Terminal-Bench 2.0 配套的 Harbor 框架让这件事变得不难。它是 Laude Institute 出品、被 Claude Opus 4.5 与 GPT-5.2-Codex 发布引用的行业标准基准——用它评测，等于和前沿实验室站在同一把尺子上。
二、Terminal-Bench 2.0 + Harbor 是什么
拆开看很清楚：
- Terminal-Bench 2.0 是考卷：一组容器化终端环境里的真实任务——编译项目、调试异步代码、解决安全漏洞、训练文本分类器、修复 Python 依赖等，每个任务配一个验证脚本判定是否真正完成。
- Harbor 是考场：负责拉起容器、把 agent 装进去、执行、用验证脚本判定、汇总分数。它支持任何能装进容器的 agent，还能把本地评测扩展到云端并行。
下面进入实战。
三、安装并跑通第一次评测
Harbor 以 Python 包分发。安装（以官方 quickstart 为准）：
# 推荐用 uv，干净隔离
uv tool install harbor
# 或者 pip
pip install harbor
harbor --version跑评测前需要 Docker（本地容器）和模型 API key。最小一次评测：
export ANTHROPIC_API_KEY=sk-ant-xxx
harbor run \
--dataset [email protected] \
--agent claude-code \
--model anthropic/claude-opus-4-5 \
--n-tasks 5 # 先跑 5 个任务验证流程，别一上来全量--dataset [email protected] 指定基准版本，--agent 指定 agent scaffold，--model 指定底层模型，--n-tasks 限制任务数先小规模试跑。跑完 Harbor 会输出每个任务的通过/失败和总分。
⚠️ 提醒：Terminal-Bench 2.0 的任务多是多步长链的，单任务可能消耗几万到几十万 token。先用
--n-tasks小跑验证流程，确认无误再跑全量，能避免一次性烧掉大笔 API 费用。
四、横比不同 agent 与模型
评测的真正价值在于苹果对苹果的对比。同一套任务，换 agent、换模型，看真实差距：
# 同一模型，对比不同 agent scaffold
harbor run --dataset [email protected] --agent claude-code --model anthropic/claude-opus-4-5 --n-tasks 20
harbor run --dataset [email protected] --agent gemini-cli --model google/gemini-3.1-pro --n-tasks 20
harbor run --dataset [email protected] --agent codex-cli --model openai/gpt-5.2-codex --n-tasks 20把三次结果放一起，你会发现一个常被忽视的事实：agent scaffold（怎么调度工具、怎么处理报错、怎么管上下文）对成绩的影响，常常不亚于底层模型本身。同一个模型套不同 scaffold，分数能差出一截。这正是你自己跑评测才能看到、榜单单行分数掩盖掉的信息。
五、读懂失败轨迹
分数只是起点，失败轨迹（trace）才是金矿。Harbor 会为每次运行保存完整执行记录——agent 执行了哪些命令、看到什么输出、怎么决策。失败任务的 trace 通常暴露固定的失败模式：
- 误读报错：把一个依赖缺失的报错理解成代码逻辑问题，南辕北辙；
- 死循环：反复尝试同一个失败命令，不会换思路；
- 过早收手：没跑验证就宣布完成；
- 环境误判：假设了某个工具存在，实际容器里没装。
把同类失败归一归，你就知道这个 agent 在你的场景里的系统性短板在哪——这比一个总分有用得多。
六、写贴合业务的自定义任务
这是整套工具最有长期价值的用法。Terminal-Bench 任务本质是一个目录，包含：任务指令、初始环境（Dockerfile）、验证脚本。你可以照着这个结构，把团队最常踩的真实场景写成任务：
tasks/fix-our-flaky-build/
├── task.yaml # 任务描述与指令
├── Dockerfile # 还原你们的真实构建环境
├── solution.sh # 参考解法（可选，用于校准）
└── tests/
└── verify.sh # 验证脚本：构建成功且测试通过才算过把你们特有的「构建总在某步挂掉」「这个内部 CLI 的用法」「这套部署流程」做成任务集，就得到了一套贴合自己业务的 agent 回归测试。以后每次想换 agent 或升级模型，跑一遍就知道在你的真实场景下是进步还是退步——而不是赌一个公开榜单分数。
七、云端并行加速
全量任务在单机串行跑可能要几小时。Harbor 支持云端并行（如 Daytona），把环境数拉到上百个：
export ANTHROPIC_API_KEY=sk-ant-xxx
export DAYTONA_API_KEY=dtn-xxx
harbor run \
--dataset [email protected] \
--agent claude-code \
--model anthropic/claude-opus-4-5 \
--n-concurrent 100 # 100 个并行环境，几小时压到几分钟代价是额外的云容器费用，但当你要频繁回归（比如每次模型升级都重测）时，这笔时间账很划算。
八、五个避坑清单
- 永远先小跑：用
--n-tasks验证流程和环境，再跑全量，否则容易在配置错误上白烧 token。 - trace 比分数重要：分数用来排序，trace 用来理解为什么——失败轨迹才是改进依据。
- agent 和模型分开看：scaffold 的影响常被低估，横比时固定一个变量。
- 自定义任务才是护城河：公开任务对齐行业，自定义任务对齐业务，后者决定你的选型是否真的对。
- 成本要预估：长链任务 token 消耗大，评测贵模型前先估算费用、必要时抽样。
选 coding agent 不该靠看榜单拍板。用 Harbor 跑一次、读几个失败轨迹、再写两个自己的任务——你对「哪个 agent 真正适合我们」的判断，会比任何公开排行榜都靠谱。