从0打造编码Agent 岔路阅读 + 实验 ≈ 25 分钟页内实验 ×3

A9 评测:怎么知道它好不好? 岔路课

能力在按什么速度增长?

能力在按什么速度增长

平均分有天花板:METR 的任务集上,Claude Opus 4.6 到 Mythos Preview 平均分只多了 0.063,而能以 50% 成功率完成的任务长度从约 12 小时变成约 17 小时。METR 把「成功率」换成「能做多长的活」:对每个模型,按人类专家耗时拟合一条 logistic 曲线,读出成功率 50% 处的任务长度。本课在浏览器里用 METR 公开的原始数据重拟合,23 个模型的 p50 / p80 与发布值相差不到 0.05%;再对发布日期回归,复现它发布的倍增时间 128.7 天(2023 年起)与 187.8 天(全部年份)。这条线怎么画,取决于选哪些点。

❓

本课一问:第 2 课比的是同一时刻的模型。换一个方向:模型的能力在按什么速度增长?用什么量才不会被「满分」卡住?

这一课先不碰:本课自己的 agent(它不在 METR 的数据里,也没法放进去);METR 任务集的逐个任务;「按这个速度外推,几年后会怎样」——本课只复现它发布的数,不做外推。

从已有出发

从已有出发 · 累计数据流点已学环节看它回答什么

每一轮循环都经过

为什么这一课换例子。本课项目只有一个模型、一个时间点,量不出「增长」。这里用 METR(第三方研究机构)公开的原始数据:23 个模型在同一套 228 个任务上的逐任务成功次数。第 1 课留下的那句话在这里用得上:每个任务有自己的成功率——METR 正是按任务的难度(人类专家要做多久)把它们排开的。

先自己设计:用平均分看增长

最直觉的做法:同一套题,每个模型算一个平均分,按发布日期连起来。

① 朴素方案
② 它在哪失败
③ 改进方案

朴素方案按发布日期画平均分

METR 任务集上的平均分,按发布日期排开

数据:METR《Task-Completion Time Horizons of Frontier AI Models》页(metr.org/time-horizons,最后更新 2026-05-08)提供的 benchmark_results_1_1.yaml 与 task_results_1_1.yaml(METR-Horizon-v1.1),2026-09-27 抓取。第三方研究机构的一手数据;拟合与回归都在浏览器里现算,和 METR 发布的数逐项对照。

改进:一个模型的时间跨度是怎么拟合出来的

第三方数据 · METR task_results_1_1.yaml(2026-09-27 抓取)· 拟合在浏览器里现算

一个模型的 50% 时间跨度是怎么算出来的:任务成功率 × 人类耗时 → logistic 拟合

🎯

试三件事:① 默认是 Claude 3.7 Sonnet:实线(METR 发布的系数)和虚线(浏览器重拟合)几乎重合,p50 读出 1.0 小时;② 去掉「按任务权重加权」:同一个任务族里的任务很多时,不加权会让这个族说话太大声,p50 会移动;③ 换成 Claude Opus 4.6:点在右侧稀疏,95% 区间变成 5.3 小时到 60.6 小时——长任务太少,曲线的尾巴没几个点撑着。

极小真数字:从系数读出 p50

Claude 3.7 Sonnet:P(成功) = σ(b0 + b1 · log2(人类分钟))

👆 公式里带下划线的每一项都可以点——点哪项，讲哪项。

23 个模型全部重拟合,p50 / p80 与 METR 发布值的最大相对误差 0.048%(test_a09_pure.mjs);差来自发布系数只保留三位小数。

p50 是一个对任务长度的读数,不是「能连续干多久」。同一个 Claude Opus 4.6,p50 是 12.0 小时,p80 只有 1.2 小时——要 80% 的把握,任务得短一个数量级。

改进二:按发布日期回归,读出倍增时间

第三方数据 · METR benchmark_results_1_1.yaml · 回归在浏览器里现算

按发布日期排开:同一批模型,用平均分看 vs 用时间跨度看

🎯

试三件事:① 默认三个勾都在(SOTA、2023 年起、p50 ≤ 16 小时):倍增时间 128.7 天,就是 METR 发布的 128.744 天;② 去掉「只用 2023 年起」:187.8 天,就是 METR 的「全部年份」187.778 天;③ 去掉「只用 SOTA」:125.0 天——同一批数据,选哪些点,倍增时间就不同。

METR 2025 年 3 月的博客写的是「doubling time of around 7 months」 ;现在的 v1.1 数据给出全部年份 187.778 天(约 6.2 个月)、2023 年起 128.744 天(约 4.2 个月,95% 区间 104.428–158.012 天)。

⚠

常见误解一:「p50 = 12 小时,就是它能独立干 12 小时的活。」

p50 的意思是:在人类专家要做 12 小时的任务上,它一半能做成。要稳一点(80%),任务长度就降到 1.2 小时(Claude Opus 4.6)。而且区间很宽:这个模型的 p50 在 5.3 小时到 60.6 小时之间。

⚠

常见误解二:「上下文在 25–30 次工具调用后开始退化」是 METR 的结论。

调研时在聚合搜索结果里看到过这类说法,找不到 METR 的一手出处,不能归到 METR 名下。METR 发布的是这一课里的时间跨度与倍增时间。

📏

和本课的任务放在一起看(只能粗对照):TB 2.0 的任务作者给本课 5 个任务估的专家耗时是 fix-git 5 分钟、regex-log 45 分钟、log-summary-date-ranges 75 分钟、openssl-selfsigned-cert 20 分钟、cobol-modernization 20 分钟(拟合图下方的红三角)。这些估时和 METR 的人类耗时不是同一套方法,本课的 8B 模型也不在 METR 数据里——所以不要从这张图读出「它应该能做几分钟的任务」。

证据三问

问	本课的回答
① 它解决什么问题?	平均分有天花板;换成「能以 50% 成功率完成的任务长度」,增长不会被满分压扁
② 数学上为什么可行?	若成功率随 log(任务长度) 单调下降,logistic 拟合就能把一条曲线压成一个读数
③ 实验上呢?	浏览器用公开原始数据复现了 METR 发布的 p50 / p80 与两个倍增时间

演进地图:你在这里

这条岔路挂在第 2 课(统一 harness)旁边:METR 的数据也是在它自己的 scaffold 上测的——YAML 里每个模型都记着用了哪些 scaffold。

评测的演进:每一步都被上一步的真数字逼出来

起点跑一次,看成败

最直觉的做法:一个任务、一次运行、一个布尔值

解决了最省事:修好了就说「会修」,没修好就说「不会」。

卡在同一套配置只换 seed:pd-v2-unlimited 的 s1 / s2 / s3 是 ✗ ✓ ✓;同为 seed 1、只多了一个没碰到的轮数上限的 pd-v2-cap20-s1 又是 ✓。只跑一次,结论取决于你碰上了哪一次。
第一步重复 k 次:pass@k 讲能力,pass^k 讲可靠

Anthropic《Demystifying evals for AI agents》· Harbor 的 -k 与 pass_at_k.py

解决了同配置的 7 次运行过了 6 次:p̂ = 0.857,pass@3 = 99.7%,pass^3 = 63.0%;T6 的 3 次重复全过。

卡在拿全体平均成功率套公式:TB 4.0 官方榜第一行(Codex + GPT-6 Astra,max)pass@1 为 58.18%,公式给 pass@5 = 98.7%,榜单实测 71.2%:每个任务的成功率不一样。而且重复再多次,也分不出分数里哪部分是 harness。
第二步统一 harness,才能比模型你在这里

Vals 统一用 Terminus 2 复测 TB 4.0 · SWE-bench 官方 bash-only 榜统一用 mini-SWE-agent

解决了同一个模型换 harness 的差距摆上桌:Fable 5.1 在 Claude Code 上 57.88%、在 Terminus 2 上 49.49%;GLM-5.3 41.82% → 25.25%。

卡在分数只告诉你成没成:本课 agent 在 TB 2.0 上 0 / 15,15 次失败各是各的样子,一个数看不出为什么。
第三步读轨迹,给失败打带步号的标签

Harbor 的 ATIF 轨迹 · Anthropic 工程博客的四类失败 · 本章写明的标签规则

解决了15 次失败都落到了带步号的标签上:改完 / 跑完不回头查 7 次,撞上输出上限 4 次,明确声称完成 5 次、5 次没过。

卡在标签分不清是 agent 错还是环境错:第一次 oracle 冒烟 0 / 5,原因是容器里的 DNS;arm64 探测里 qemu-startup 连参考解也拿 0 分(verifier 现装 curl 时 404)。
第四步先用参考解确认环境,再接自己的 agent

Harbor v0.23.0:-a oracle 冒烟 → -a module:Class -k

解决了参考解 5 / 5 通过、环境就绪之后,再跑自家 agent:5 个任务 × 3 次。

卡在k = 3、单一 8B 本地模型、5 个任务、amd64 镜像靠 qemu 模拟:结论只在这个规模成立。(→ 课程终点:回到 A0,哪些任务值得用 agent?)

数字口径:本课项目 T6(Harbor 0.23.0 + Terminal-Bench 2.0,本机 Qwen3-8B-MLX-4bit,录制于 2026-09-26)与 A1 的同配置运行;TB 4.0 官方榜(更新于 2026-09-21)与 Vals(更新于 9/22/2026),均于 2026-09-27 抓取;由 a09-eval.json 与 a09-public-2026-09-27.json 构建时现算。

一句话

📌

把「能不能做」换成「能做多长的活」,增长才不会被天花板压扁。

回主线

分数告诉你成没成,为什么失败要看什么? → 第 3 课:它失败了,失败在哪一步、属于哪一类?

你可能会问

「倍增时间能拿来预测吗?」 本课只复现,不外推。第二个 🎯 已经看到:换一种选点方式,倍增时间就从 125 天变到 188 天。
「为什么排除 p50 超过 16 小时的点?」 YAML 里的注释写着倍增时间「excludes points with central estimate p50 > 16 hrs」;METR 的任务集里这么长的任务很少,读数不稳。去掉那个勾可以看它对结果的影响。
「本课的 agent 能测出一个时间跨度吗?」 需要在同一套覆盖几秒到几十小时的任务上跑、并且每个任务跑多次;本课只有 5 个 TB 任务 × 3 次,而且全部没过——拟合不出曲线。