2026 年 9 月 1 日，Anthropic 发布 Claude Fable 5.1 与 Mythos 5.1，官方公布的 Terminal-Bench 4.0 成绩为 Fable 5.1 拿 55.8%、Mythos 5.1 拿 60.9%、GPT-5.6 Sol 拿 37.3%。同一天，GitHub 上的 harbor-framework/harbor 与 harbor-framework/terminal-bench 两个仓库都有代码推送。巧合背后是同一件事的两面：厂商在榜单上给出分数，而产出这些分数的任务与框架本身是开源的。本文讲后半件事——怎么用这套开源工具链跑出属于你自己的数字，把厂商宣称的分数从"只能引用"变成"可以复核"。发布本身见Claude Fable 5.1 与 Mythos 5.1 发布解读，跑起来之后的账单见缓存优先架构下的 agentic 成本账横评。
一、厂商分数为什么不能直接拿来用
先看那组官方数字的共同点：由厂商自己跑、自己公布，跑在同一套基准上，用的是厂商自己的 agent 配置。三条里任何一条成立，数字就只是信号，不是结论。
自评口径。分数由发布方公布，第三方很难完整复现：跑分用的 harness 是什么、系统提示写了什么、允许模型调哪些工具、最多走多少步、失败后重不重试，这些细节通常不会逐条写进公告。缺了这些，你拿到的只是一个结果数字，无法判断它是模型能力的上限，还是某套精心调过的配置的产物。
生产环境的安全防护。厂商线上普遍挂着权限边界、危险命令拦截、输出过滤一类的防护层，而评测到底是在带防护的状态下跑的还是放开限制跑的，公告往往不说清。这两者的差距不在小数点后一位：一个被拦住的危险操作，计分上是失败，在真实业务里却可能是正确行为。
harness 不透明。同一模型在不同 agent 框架下跑同一任务，分数可以差出一大截——工具集不同、步数上限不同、上下文管理策略不同、是否开启并行工具调用不同。这也解释了为什么跨厂商分数不能直接比：比的其实不是模型，而是"模型加它那一套外部配置"这个整体。
结论不是分数没用，而是分数要在你自己的口径下复跑一次，才有决策价值。
二、Harbor 与 Terminal-Bench 是什么关系
据仓库描述与主页信息：harbor-framework/harbor 的自我描述是「Framework for evaluating and improving agents」，即评估与改进 agent 的框架；harbor-framework/terminal-bench 的描述是「Measuring and evolving with the frontier of agent work」，主页指向 tbench.ai。二者同属一个组织，从描述看构成上下游：Harbor 是评估与改进 agent 的框架与工具链，Terminal-Bench 是跑在这套框架上的任务与基准套件。官方未用一句话明确定义二者的调用关系，以上为据仓库描述与主页信息推断。
打个比方：Harbor 更像跑道、计时器与成绩记录系统，负责把"跑一次评测"这件事标准化；Terminal-Bench 更像考题与评分标准，负责定义"考什么、什么算通过"。换模型、换 agent 框架、换提示词时，跑的是同一套考题，计时方式也一致，分数才有可比性。
这个分工决定了自建评测时该改哪一部分。要横向比较模型，就固定考题只换被测对象；要验证自己的 agent 有没有变好，就固定被测对象只改 agent 配置。两件事一起改，跑出来的数字没有任何解释力。
三、仓库地图：四个仓库与一次更名
动手前先把仓库认全。有一处更名必须知道：原 laude-institute/terminal-bench 已 301 更名为 harbor-framework/terminal-bench-1，组织也从 laude-institute 迁移到 harbor-framework。你在旧文档、旧脚本、旧博客里看到的 laude-institute/terminal-bench 链接，现在会跳转到 terminal-bench-1，而不是当前最活跃的那个 terminal-bench。
| 仓库 | 星数 | fork | 语言 | 许可证 | 创建时间 | 最近 push |
|---|---|---|---|---|---|---|
| harbor-framework/harbor | 4872 | 1705 | Python | Apache-2.0 | 2025-08-04 | 2026-09-01 |
| harbor-framework/terminal-bench | 594 | 434 | Python | Apache-2.0 | 2026-01-25 | 2026-09-01 |
| harbor-framework/terminal-bench-1 | 2559 | 567 | Python | Apache-2.0 | 2025-01-17 | 2026-07-11 |
| harbor-framework/terminal-bench-2 | 393 | 112 | Shell | Apache-2.0 | 2025-09-25 | 2026-04-30 |
四行数据里有三个坑。第一，星数最高的不是还在更新的那个：terminal-bench-1 有 2559 星但最近 push 停在 2026-07-11，terminal-bench-2 有 393 星、停在 2026-04-30，反倒是 594 星的 terminal-bench 在 2026-09-01 还有推送。星数是历史积累，push 时间才是当前活跃度。第二，terminal-bench、terminal-bench-1、terminal-bench-2 是三个不同仓库，别当成同一个东西的新旧版本，更别拿其中一个的分数去对另一个。第三，四个仓库的许可证均为 Apache-2.0（以 GitHub API 返回为准），不是 MIT，写内部合规材料时别想当然。
实践上的处理建议：脚本里凡硬编码了 laude-institute/terminal-bench 的地址，一次性替换成迁移后的仓库；引用历史分数时把"哪个仓库、哪个版本、哪天取的"一并记进评测报告，否则三个月后你自己也分不清那个 55.8% 究竟是谁跑出来的。
四、4.0 重新标定：老分数不能和新分数比
Terminal-Bench 4.0 是 Anthropic 用于评测 Fable 5.1 的基准之一。这一版做了一件对分数解释极其重要的事：重新标定了每项任务的时间、CPU 与内存配额，同时移除 8 个任务、修复 19 个任务。官方因此明确，4.0 的分数与早期版本不可比。
配额变了意味着什么？agentic 任务的通过率对资源配额极其敏感。给一个任务的时间从宽裕改成紧张，模型可能不是不会做，而是没做完；内存卡紧一点，某些依赖较重的任务直接起不来。这类改动改变的是考题的完成条件，不是模型能力。所以当你在不同时间看到同一个模型在"Terminal-Bench"上的两个分数，先问一句是哪一版。
另一组可以对照的数字是 Terminal-Bench-Science 0.1（科研向任务）：Fable 5.1 得 52.6%，Fable 5 得 24.7%。这是一个全新基准，代际差距在量级上是明显的。但同样地，它是 0.1，本身也会变。把这类数字当成"能力在涨"的证据可以，当成"我的场景也会涨这么多"的证据不行。
对自建评测的直接启示：把基准版本号写进评测配置，并和结果一起归档。版本号是分数的单位，没有单位的两个数字不能做减法。
五、自建评测的四步路径
下面四步不依赖任何未核实的具体命令，安装与运行方式请以仓库 README 与官方文档为准。
第一步，先写自己的任务，别一上来跑全套。公开基准的任务分布和你的业务分布几乎不可能重合。合理顺序是先挑十到三十个你线上真实出现过的任务做成私有集，把流程跑通；再接公开基准做横向校准。私有集负责回答"我的场景行不行"，公开集负责回答"和业界比在什么位置"，两个问题不要混为一谈。
第二步，把 harness 配置写进版本库。凡是会影响分数的东西都必须版本化：模型标识、系统提示、工具清单、步数上限、超时与重试策略、沙箱资源配额、是否开启并行工具调用。任何一次配置改动都要能追溯到某次评测结果，否则分数漂移时你没有任何线索。
第三步，重复跑，报分布不报单点。agentic 任务有真实的随机性，单次通过率可能刚好落在好运气或坏运气上。同一配置重复若干次，记录通过率的区间而不只是一个数，同时记录每次的耗时与成本。重复几次取决于你能承受的评测预算，原则是定下来之后不要每次改。
第四步，把成本与时长列为一等公民。只看通过率的评测会奖励"不计代价把任务做完"的策略。一张完整的评测表应该长这样：
| 维度 | 怎么测 | 为什么必须有 |
|---|---|---|
| 通过率 | 重复跑，取区间而非单点 | 单次结果受随机性影响，无法判断真假提升 |
| 单次耗时 | 记录端到端墙钟时间与任务内步数 | 决定能不能放进交互式链路 |
| 单次成本 | 按 token 与工具调用口径汇总 | 通过率提升可能只是烧钱换来的 |
| 失败模式分布 | 按超时、工具误用、上下文耗尽、环境异常分类 | 不同失败模式的修法完全不同 |
| 降级行为 | 触发降级与不触发降级两种状态各跑一遍 | 线上多数时间跑的未必是最优链路 |
最后一行最容易被漏掉：你的线上系统相当一部分时间可能跑在降级链路上，评测却只测了最优路径。降级架构本身留待后续单独成文。
六、六类坑与避坑清单
-
把基准分数当服务承诺。公开基准的分数是在固定任务集、固定配额下的一次测量，既不代表在你的任务分布上的表现，也不构成任何 SLA。
-
忽略 harness 差异。换模型时顺手换了 agent 框架或提示词，分数变化就无法归因。每次只改一个变量。
-
只跑一次。见第五节第三步，单次结果无法区分真实提升与运气。
-
不锁版本。任务套件会改——4.0 就移除了 8 个任务、修复了 19 个；框架会改；模型标识也会变。上线前锁版本，升级时当成一次变更来评测，而不是顺手更新一下。
-
把迁移的破坏性变更排除在评测之外。模型侧的 API 变更会直接改变 agent 行为，尤其像降级时丢失推理链这类问题，评测里不构造降级路径就永远发现不了。细节见Claude Fable 5.1 API 迁移 SOP。
-
只测能力不测成本。通过率涨了但单次成本翻倍，账上可能是净亏损。成本口径的对照见缓存优先架构下的 agentic 成本账横评。
七、适合谁，局限在哪
适合三类人：需要在多个模型之间做选型、又不想只信厂商公告的团队；已经在生产环境跑 agent、需要按周或按版本做回归的团队；以及需要向内部解释"为什么这个模型在我们的场景里不如榜单上好看"的人。对这三类人，这套工具链的价值在于把讨论从"谁的分数高"拉回"我们自己的数字是多少"。
局限同样要说清。第一，自建评测的成本不低：写私有任务集、固定 harness、重复跑，都要人力和算力。小团队可以先做十到三十个任务的最小集，不必一上来追求覆盖度。第二，本文对两个项目的能力边界描述以仓库自述与主页信息为准，具体 API、安装方式与配置项请以官方 README 与文档为准；本文未给出任何未经核实的操作命令。第三，也是根本的一条：自建评测解决的是"口径"问题，不是"模型能力"问题。它能告诉你一个模型在你的任务上表现如何，不能让一个不行的模型变行。
厂商公布的 benchmark 分数是起点，不是终点。终端里的 agent 到底行不行，最终只由你自己的任务、你自己的 harness、你自己的账单说了算。先把这套工具链接上，跑十到三十个真实任务，把分数变成你自己复现得出来的数字——这一步做完，选型讨论会安静很多。
参考来源
- GitHub REST API 实测数据（2026-09-02 取）：harbor-framework/harbor（4872 星 / 1705 fork / Python / Apache-2.0 / 创建 2025-08-04 / 最近 push 2026-09-01 / 主页 https://harborframework.com/）、harbor-framework/terminal-bench（594 星 / 434 fork / Python / Apache-2.0 / 创建 2026-01-25 / 最近 push 2026-09-01 / 主页 https://tbench.ai）、harbor-framework/terminal-bench-1（2559 星 / 567 fork / Python / Apache-2.0 / 创建 2025-01-17 / 最近 push 2026-07-11 / 主页 https://www.tbench.ai）、harbor-framework/terminal-bench-2（393 星 / 112 fork / Shell / Apache-2.0 / 创建 2025-09-25 / 最近 push 2026-04-30，无描述）。
- 仓库更名事实：原 laude-institute/terminal-bench 现已 301 更名为 harbor-framework/terminal-bench-1，组织由 laude-institute 迁移至 harbor-framework（GitHub REST API 实测，2026-09-02）。
- Anthropic 官方公布（2026-09-01 发布）：Terminal-Bench 4.0 成绩 Claude Fable 5.1 为 55.8%、Mythos 5.1 为 60.9%、GPT-5.6 Sol 为 37.3%；Terminal-Bench 4.0 重新标定了每项任务的时间/CPU/内存配额，移除 8 个任务、修复 19 个任务，分数与早期版本不可比。具体公告 URL 未确认。
- Anthropic 官方公布：Terminal-Bench-Science 0.1 成绩 Claude Fable 5.1 为 52.6%、Claude Fable 5 为 24.7%。具体公告 URL 未确认。
- Harbor 与 Terminal-Bench 的关系定位为据仓库描述与主页信息推断，官方未以一句话明确定义，已在正文标注。
- 除上述条目外，本文其余内容为工程建议与推断，已在正文逐处标注，不属于官方来源。
常见问题
Q1：Harbor 和 Terminal-Bench 是同一个东西吗？ A1：不是，是两个仓库，同属 harbor-framework 组织。据仓库描述与主页信息，Harbor 的自我描述是评估与改进 agent 的框架，Terminal-Bench 是任务与基准套件，前者提供跑评测的工具链，后者定义考什么、什么算通过。官方未用一句话明确定义二者的调用关系，这是据描述作出的推断。
Q2：为什么我按旧教程里的 laude-institute/terminal-bench 地址操作会对不上？ A2：因为那个仓库已经 301 更名为 harbor-framework/terminal-bench-1，组织也一并迁移。旧地址会跳转，但跳转后的仓库最近一次 push 是 2026-07-11，与当前最活跃的 harbor-framework/terminal-bench（最近 push 2026-09-01）不是同一个。脚本里硬编码的地址建议一次性替换，引用分数时把仓库名与取数日期一并记录。
Q3：厂商公布的 55.8% 和 60.9%，我能在自己环境里复现吗？ A3：大概率不能，也不必强求。这组数字由厂商在自己选定的 harness、任务配额与防护配置下跑出，而这些细节通常不会完整公开。自建评测的目标不是复现厂商的数字，而是在你自己的任务集与配置下得到一个可重复、可归因、能追踪变化的数字。
Q4：Terminal-Bench 4.0 比老版本难了还是简单了？ A4：这个问题问法本身不成立。4.0 重新标定了每项任务的时间、CPU 与内存配额，移除 8 个任务、修复 19 个任务，官方因此明确分数与早期版本不可比。配额变化改变的是考题的完成条件，不是模型的绝对能力。看到任何跨越版本的分数对比，先确认两边版本号是否一致。
Q5：小团队想自建评测，最小可行集是什么？ A5：十到三十个你线上真实出现过的任务；固定一套 harness 配置并写进版本库；同一配置重复跑若干次取区间；每次记录通过率、耗时、成本与失败模式分类四项。先把这四件事做扎实，再考虑扩大任务集与接入公开基准做横向校准。