一、一个刷了屏的数字和它三周后的下修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 把这笔复利账算清楚。先交代背景。METRModel 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.1Opus 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 的趋势加上新一代模型的评测结果。下表把几个有公开来源的坐标点摆在一起加速段的斜率变化一目了然。模型公布时点50% 时间地平线备注GPT-22019 年约 2 秒指数曲线起点o32025 年初约 110 分钟论文主报告值Claude Opus 4.52025 年末约 5 小时当时最长记录Claude Opus 4.62026 年 2 月初测14.5 小时CI 6–98 小时TH1.1 套件Claude Opus 4.62026 年 3 月修正约 12 小时建模 bug 修复后把这条曲线放进更大的评测图景里看它的稀缺性在于还没饱和。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 还是 12Opus 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_days123): 按翻倍周期外推 days 天后的 50% 地平线小时 return h0_hours * (2.0 ** (days / doubling_days)) if __name__ __main__: # 1) 一个 12 小时任务约 500 个原子步骤单步 99% 时整体只剩不到 1% print(p0.99, n500 整体成功率: %.4f % overall(0.99, 500)) # 2) 要让 500 步任务整体达到 50%/80%/95%单步门槛分别是多少 for t in (0.50, 0.80, 0.95): print(n500 整体 %.0f%% 需要单步: %.5f % (t * 100, required_step(t, 500))) # 3) 单步 99% 配 3 次重试看有效成功率与 500 步整体成功率的变化 eff with_retry(0.99, 3) print(p0.99 重试3次后单步: %.6f, n500 整体: %.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 有意义。模型能力每四个月翻一倍的背景下工程方法论才是那个不过时的变量。
一、一个刷了屏的数字和它三周后的下修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 把这笔复利账算清楚。先交代背景。METRModel 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.1Opus 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 的趋势加上新一代模型的评测结果。下表把几个有公开来源的坐标点摆在一起加速段的斜率变化一目了然。模型公布时点50% 时间地平线备注GPT-22019 年约 2 秒指数曲线起点o32025 年初约 110 分钟论文主报告值Claude Opus 4.52025 年末约 5 小时当时最长记录Claude Opus 4.62026 年 2 月初测14.5 小时CI 6–98 小时TH1.1 套件Claude Opus 4.62026 年 3 月修正约 12 小时建模 bug 修复后把这条曲线放进更大的评测图景里看它的稀缺性在于还没饱和。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 还是 12Opus 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_days123): 按翻倍周期外推 days 天后的 50% 地平线小时 return h0_hours * (2.0 ** (days / doubling_days)) if __name__ __main__: # 1) 一个 12 小时任务约 500 个原子步骤单步 99% 时整体只剩不到 1% print(p0.99, n500 整体成功率: %.4f % overall(0.99, 500)) # 2) 要让 500 步任务整体达到 50%/80%/95%单步门槛分别是多少 for t in (0.50, 0.80, 0.95): print(n500 整体 %.0f%% 需要单步: %.5f % (t * 100, required_step(t, 500))) # 3) 单步 99% 配 3 次重试看有效成功率与 500 步整体成功率的变化 eff with_retry(0.99, 3) print(p0.99 重试3次后单步: %.6f, n500 整体: %.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 有意义。模型能力每四个月翻一倍的背景下工程方法论才是那个不过时的变量。
