一、一个刷了屏的数字，和它三周后的下修

2026年2月20日前后，METR 公布了 Claude Opus 4.6 的 50% 时间地平线测量结果：约 14.5 小时，95% 置信区间从 6 小时一直拉到 98 小时。这个数字的含义是，在一套以人类专家完成时间标定的软件任务上，这个模型面对"熟手工程师要干 14 个半小时"的任务，能有一半的把握独立做完。消息一出，"Agent 已经能连续工作一个完整工作日"的说法在各家技术媒体刷了屏，不少人直接把这个点位当成了可以写进排期表的能力承诺。

三周之后的 3 月 3 日，METR 自己修正了建模中的一个 bug，把同一个模型的同一项指标下修到约 12 小时——TH1.1 套件上的原始数据估算是 50% 水平 11 小时 59 分，80% 水平只有约 1 小时 10 分。从刷屏到修正，中间没有任何新模型发布，没有任何任务重跑，变的只是拟合代码。一个被广泛引用的能力数字，仅凭建模修复就缩水了 17%，这件事本身比 14.5 这个峰值更值得工程团队看明白。

本文做三件事：先把"时间地平线"这个指标的测量方法拆开，看它到底度量的是什么、不度量什么；再复盘 14.5 小时为什么会被下修，逻辑斯蒂拟合在什么条件下会失真；最后把指标折算成工程上真正有用的东西——单步成功率、任务切分和检查点设计，并用一段纯标准库的 Python 把这笔复利账算清楚。

先交代背景。METR（Model Evaluation & Threat Research）是一家专注于前沿模型能力评估的研究机构，方法论特色是不看静态跑分，而是用"人类完成同类任务需要多久"给模型能力定标尺。这套时间地平线指标自 2025 年 3 月论文发表以来，已成为讨论 Agent 自主续航时引用最多的量化框架，也是 AI 2027 等预测情景的关键输入变量。读懂它的口径与误差结构，是正确使用它的前提。

二、时间地平线到底在测什么

时间地平线（time horizon）的定义是：在固定成功率下，模型能完成的任务所对应的人类完成时长。METR 在 2025 年 3 月的论文里把它操作化为 50%-task-completion time horizon——找到模型成功率恰好降到 50% 的那个任务时长点。任务的人类时长用多位领域熟手的基线完成时间的几何均值来标定，而不是某一个人的单次成绩，更不是任务设计者拍脑袋的估计。

任务套件由三部分拼成：HCAST 系列软件任务、RE-Bench 里那批需要数小时的开放式研究与工程任务，以及 66 个专门补充的短任务。短任务从几秒钟到几分钟不等，长任务最长延伸到 8 小时以上，合起来拼出一条从秒级到十小时级的难度轴。2026 年 1 月 29 日，METR 又发布了修订版任务套件 Time Horizon 1.1，Opus 4.6 的全部读数都来自这个新套件。

有了每个任务的人类标定时间和模型在各任务上的通过情况，接下来是拟合一条逻辑斯蒂曲线：横轴是人类任务时长取对数，纵轴是模型成功概率。曲线与 50% 水平线的交点就是 50% 时间地平线，与 80% 的交点是 80% 地平线。论文报告 80% 地平线的数值大约是 50% 地平线的五分之一，而两者的翻倍速度基本一致——这个五倍关系后面折算工程口径时会直接用到。

人类基线为什么取几何均值而不是算术均值？因为完成时间在人与人之间近似对数正态分布，快的人和慢的人可以差出三四倍，算术均值会被个别特别慢的基线明显拉偏。几何均值等价于在对数空间取平均，找到的是"典型熟手"而不是"平均倒霉蛋"，这让任务时长标定在基线样本不多的情况下依然稳健，也让不同难度任务之间的时长比值更有意义。

这个设计里最不容易被注意到的一点，是任务阈值的设定方式：模型在每个任务上的连续得分，要按任务各自的阈值切成"通过"与"不通过"，而阈值对齐的是人类表现水平。换句话说，整套指标从根上就是"以人为尺"的。它回答的问题不是模型跑分有多高，而是"把这件事交给一个熟手工程师要做多久"的那个时长上，模型能不能接住。

还要明确地平线不是什么。它不是"模型能完成的最长任务"，而是一个统计意义上的位置参数。一个 50% 地平线为 12 小时的模型，完全可能偶尔完成 20 小时的任务，也可能在 2 小时的任务上翻车。它描述的是成功率随任务长度衰减这条曲线的中点位置，不是能力的硬边界，更不是任何单一任务的交付承诺。

三、六年曲线：从 2 秒到 12 小时

把 2019 到 2025 年的各代前沿模型都放回这套任务上，METR 得到一条相当干净的指数曲线：50% 时间地平线每 207 天翻一倍，95% 置信区间 166 到 240 天。GPT-2 的地平线约 2 秒——它只能完成人类眨一下眼就能做完的事；到 2025 年初，o3 的地平线是 110 分钟，六年间跨了大约三个数量级，而且全程没有明显的减速迹象。

2024 年之后的数据点显示出加速迹象：只拟合这一段，翻倍周期缩短到 118 天左右。AI Futures Project 在 2026 年一季度的更新里，也把原先的 5.5 个月翻倍假设修订为 4 到 4.5 个月，理由正是 METR v1.1 的趋势加上新一代模型的评测结果。下表把几个有公开来源的坐标点摆在一起，加速段的斜率变化一目了然。

把这条曲线放进更大的评测图景里看，它的稀缺性在于"还没饱和"。MMLU、HumanEval 这类静态榜单早已被顶穿，SWE-bench Verified 头部模型的分差压缩到两分以内，而时间地平线因为锚定开放式长任务，天花板随任务长度自然抬高。它因此成为 2026 年少数还能拉开模型差距的公开尺子，也是各家发布会引用越来越频繁的原因。尺子越稀缺，读数被过度解读的风险就越高。

按 123 天翻一倍外推，METR 研究员 Ajeya Cotra 在 3 月 3 日的复盘文章里给出年底 100 小时以上的预测，并承认 Opus 4.6 当时约 12 小时的实测值已经超过了她 1 月份对 2026 年底的预测中位数。她在分析里特别提到一个技术细节：短任务一端已经接近饱和，模型对一分钟以内的任务几乎满分通过，这给长任务端的估计引入了额外噪声。这句话是理解下修事件的钥匙。

四、14.5 小时为什么变成 12 小时

下修的官方说法是建模 bug 修复。3 月 3 日之前，Opus 4.6 在 TH1.1 上的 50% 地平线估算是 14.5 小时；修复之后变成 11 小时 59 分。同一套原始跑分数据，同一批任务，同一个人类基线，只是拟合代码改了，指标就缩水 17%。这说明在十小时量级的测量里，拟合方式本身就是误差的一大来源，点位的第二位小数没有任何意义。

误差的第一层来源是置信区间的天然宽度。即使是初测的 14.5 小时，95% 置信区间也是 6 到 98 小时，上下界相差 16 倍；修正后的区间约 5.3 到 66 小时，宽度依然超过一个数量级。地平线是从有限任务样本上拟合出来的统计量，而且任务抽样误差在不同模型之间相关——同一批难任务对所有模型都难。结果就是，单个模型的点位精度远低于整条曲线斜率的精度，207 天翻倍这个斜率的置信区间反而只有几个月宽。

误差的第二层来源是长任务样本稀疏。TH1.1 里人类标定 8 小时以上的任务只有 19 个，Opus 4.6 通过了其中 14 个。每一个长任务的通过与否，对曲线右端位置的拉扯都很大：过 14 个还是过 11 个，对应的地平线估算可能差出好几个小时。样本这么少，逐点抖动不可避免，而恰恰是这几个点决定了被媒体引用的那个数字。

外部评论者把失真机制讲得更直白：当模型对 1 小时以内的短任务成功率接近满分时，逻辑斯蒂曲线的左端被钉在 100% 附近，整条曲线只剩右端几个点来决定形状。此时只要模型碰巧解决两三个 8 小时级的 RE-Bench 任务，拟合出的 50% 交点就会被拖进 10 小时以上的区域。718 分钟（约 12 小时）这个数字，很可能建立在两三个长任务通过的基础上，而不是"模型在一大批 12 小时任务上稳定过半"。左端饱和越严重，右端外推越脆弱。

METR 自己在 3 月 10 日发布的另一项研究，从侧面印证了"跑分高估实战"：在 SWE-bench 上被判通过的补丁里，约一半放到真实开源维护者的评审标准下不会被合并。基准的"通过"阈值与生产的"接受"阈值之间存在系统性差距。地平线指标继承了这层差距——它度量的是"在基准判定下完成"，不是"交付即可用"。这层折损与统计折损叠加，才是工程团队面对的真实数字。

需要说明的是，下修并没有推翻"加速"这个大结论。无论取 14.5 还是 12，Opus 4.6 相对半年前 Opus 4.5 的 5 小时都是一倍以上的跃升，翻倍周期仍然显著短于 2019 到 2025 年的 207 天基线。变的是点位的精确值，不变的是斜率的方向。这也是为什么跟踪趋势比争论点位更有工程价值。

五、读这个指标时该打的几层折扣

第一层折扣是成功率口径。50% 地平线对应的是"做两次成一次"的可靠性，这在绝大多数生产场景里不可接受。80% 地平线只有前者的五分之一左右——Opus 4.6 修正后的 80% 地平线约 1 小时 10 分。也就是说，当你需要"十次成八次"的交付质量时，2026 年初最强模型的自主续航大约是一小时量级，而不是十二小时。媒体标题里的那个数字，和你可以依赖的那个数字，差着五倍。

第二层折扣是任务分布。METR 的任务来自软件工程与研究工程领域，时长标定基于外部熟手。换成你公司业务里的具体任务——依赖内部系统、需要大量隐性上下文、验收标准模糊的那一种——人类基线和任务分布全都变了，公开地平线只能当量级参考。把别人的 50% 地平线直接当成自己的 SLA 写进合同，是这个指标最常见的误用，没有之一。

第三层折扣是评审口径。上一节提到的 SWE-bench 补丁研究说明，基准"通过"与维护者"接受"之间隔着一道真实存在的门槛。业务场景里的验收只会更严：代码风格、团队约定、合规要求、与现有架构的契合度，都不在基准判定范围内。每一个额外的验收维度，都在等效地缩短模型的可用续航。

把三层折扣叠起来，一条合理的经验读法是：把公开的 50% 地平线先除以五拿到 80% 口径，再按任务分布差异和验收口径差异各打一个主观折扣，剩下的才是可以进排期表的自主工作时长。对 12 小时这个数，务实的落点在一小时上下——这与 80% 口径的实测值恰好互相印证。这个折算规则粗糙但方向正确，远比直接引用峰值数字安全。

还有一种更保守的读法值得并列：直接读 80% 口径的点位，而不是对 50% 点位做折算。论文数据显示两种口径的翻倍速度一致，差异只在绝对水平。对容量规划来说，80% 口径点位乘以自家任务集的校准系数，比任何围绕 50% 点位的修辞性引用都更接近可承诺的数字。指标发明者的初衷也是如此——50% 只是曲线的中点坐标，用来对齐不同模型，从来不是推荐的工作点。

六、把地平线折算成单步可靠性：一笔复利账

长任务成功率为什么随长度指数衰减？一个够用的心智模型是把任务拆成 n 个顺序步骤，每步成功率 p，前一步失败就导致整体失败，那么整体成功率就是 p 的 n 次方。12 小时的任务按一到两分钟一个原子操作估算，就是几百上千步的链条。p 要离 1 多近，整体才能保住 50%？这正是把媒体数字翻译成工程语言的关键一步。

下面这段代码只用 Python 标准库，把四个工程上常用的换算一次算清：给定单步成功率和步数算整体成功率；反过来，给定整体目标解出需要的单步成功率；带重试机制时单步有效成功率的提升；以及按 123 天翻倍周期外推未来某个时间点的地平线。代码可以直接保存运行，不依赖任何第三方包。

import math def overall(p, n): """n 个顺序步骤、每步成功率 p 时的整体成功率""" return p ** n def required_step(target, n): """要在 n 步任务上达到 target 整体成功率，每步至少要多高""" return target ** (1.0 / n) def with_retry(p, k): """每步最多尝试 k 次（假设各次独立）后的单步有效成功率""" return 1.0 - (1.0 - p) ** k def horizon_after(h0_hours, days, doubling_days=123): """按翻倍周期外推 days 天后的 50% 地平线（小时）""" return h0_hours * (2.0 ** (days / doubling_days)) if __name__ == "__main__": # 1) 一个 12 小时任务约 500 个原子步骤，单步 99% 时整体只剩不到 1% print("p=0.99, n=500 整体成功率: %.4f" % overall(0.99, 500)) # 2) 要让 500 步任务整体达到 50%/80%/95%，单步门槛分别是多少 for t in (0.50, 0.80, 0.95): print("n=500 整体 %.0f%% 需要单步: %.5f" % (t * 100, required_step(t, 500))) # 3) 单步 99% 配 3 次重试，看有效成功率与 500 步整体成功率的变化 eff = with_retry(0.99, 3) print("p=0.99 重试3次后单步: %.6f, n=500 整体: %.4f" % (eff, overall(eff, 500))) # 4) 从 12 小时按 123 天翻倍外推一年后的量级 print("一年后 50%% 地平线外推: %.1f 小时" % horizon_after(12, 365))

跑出来的数字相当冷峻。单步 99%、500 步的任务，整体成功率不到 1%；要让 500 步任务整体过 50%，单步成功率要到 99.861%；要到 95%，单步得 99.990%。这就是"12 小时地平线"在工程上的真实含义：它不是说模型能稳定交付半天的活，而是说模型的单步可靠性已经高到能在几百步的链条上偶尔跑通一半。两件事听起来相似，对架构设计的要求天差地别。

重试机制的收益同样可以用这段代码量化。单步 99% 配 3 次重试，有效成功率升到 99.9999%，500 步整体成功率从不到 1% 跳到 99.5% 上下，跨越了从"不可用"到"接近生产"的整条鸿沟。但重试有效有两个前提：每步的失败是可检测的，且各次尝试之间近似独立。幻觉型错误——模型信誓旦旦地给出错误结果并继续推进——恰恰破坏第一个前提，这也是长任务工程里验证器比执行器更值钱的根本原因。

验证器的成本账也值得算一次。如果每步校验本身花掉执行时间的十分之一，500 步任务的校验总开销相当于 50 步的执行量，换来的是整体成功率从不到 1% 到接近可用的跃升。在任何严肃的 Agent 流水线里，这都是一笔稳赚的交易。行业里"评估器与执行器分离"的架构共识，本质上就是在给 p 的 n 次方这堵墙上开检查点的门——用确定性的校验成本，对冲指数级的可靠性衰减。

步数估算口径也需要交代清楚。上文把 12 小时折成约 500 个原子步骤，用的是每个原子操作一到两分钟的经验值：读一段代码、写一次编辑、跑一条命令、看一段输出。真实项目里步骤数会因任务类型上下浮动数倍，但幂次关系本身不变——步数翻倍，只要求单步成功率再向 1 靠近一小截。结论对具体步数假设不敏感，这正是这个心智模型在工程估算中的用处。

指数外推那一行给出的是一年后的量级参考：按 123 天翻倍，12 小时一年后会到 90 小时上下。是否采信取决于你是否相信加速段会持续。2019 到 2025 的 207 天基线与 2024 年后的 118 天并存，两边都有完整的论文支撑。谨慎的做法是同时跟踪两条曲线，用较保守的那条做容量规划，用较激进的那条做技术预研，而不是把赌注压在其中任何一个点位上。

七、对工程团队的三个落地推论

第一，任务切分比模型选型更能决定交付可靠性。整体成功率是单步成功率的幂次，把一个 500 步的流程切成 10 个 50 步、各自带独立验收的子任务，整体可靠性会获得数量级改善。地平线数字翻一倍要等四个月，而切分设计的收益当天就能拿到。在模型能力快速爬升的阶段，等待更强模型几乎永远不如重排任务拓扑划算。

第二，检查点与回滚是长任务架构的必选项，不是可选项。p 的 n 次方模型假设前步失败即整体失败，而检查点把"失败半径"从整个任务压缩到相邻两个检查点之间。上文的重试计算成立的前提——失败可检测——在工程上就落实为每一步的显式校验：编译通过、测试通过、模式校验通过，而不是"看起来做完了"。没有可检测性的重试，只是把同一个错误以更高成本重复三遍。

第三，把地平线指标当监测信号，不当验收标准。它告诉你这一代模型的单步可靠性量级到了哪里，适合用来做"该不该把某类任务交给 Agent"的粗筛；但具体任务的放行标准，必须来自你自己流水线里的成功率先验。公开榜单的点位带十几倍宽的置信区间，你自己的实测数据才是唯一能进评审会的数字。

落地实测的做法可以很轻量：从真实工单里抽 30 到 50 个有代表性的任务，按人类完成时间分桶，每桶至少跑 5 次，画出自己这条成功率随任务时长衰减的曲线。这条曲线不需要发表在哪个榜单上，它只需要回答一个问题——在你的任务分布上，从哪个时长开始成功率掉到不能接受。这个拐点，就是你该放人工兜底的位置，也是你每季度复测时要盯住的唯一数字。

回头看这次 14.5 到 12 小时的下修，最有价值的不是修正后的数字本身，而是它展示的事实：在任务样本稀疏、短任务饱和、置信区间十几倍宽的现状下，任何单点地平线读数都带着浓重的统计噪声。读曲线的斜率、读可靠性复利的结构、读自己流水线里的实测数据，远比争论某个点位是 12 还是 14.5 有意义。模型能力每四个月翻一倍的背景下，工程方法论才是那个不过时的变量。