METR 的 50% 时间视野：AI 能完成人类要花多久的任务，以及这些数字为什么不能直接比

METR（Model Evaluation and Threat Research）长期追踪一个指标：50% 时间视野（50% time horizon）。一句话定义：用人完成同一项任务所需的时间来衡量任务难度，模型有 50% 概率能成功完成的那些任务里，最难的任务对应人类专家需要多久。

官网指标页：

它量的是任务难度，不是耗时

这是最容易读错的地方。「时间视野 50 分钟」的意思是：模型能完成一个人类专家要花 50 分钟的任务，成功率五成。模型自己可能 10 分钟跑完，也可能跑 2 小时——这个数字描述的是任务有多难，不是 agent 实际花了多久。

任务来自 RE-Bench、HCAST 和一批较短的软件任务，主要集中在软件工程、机器学习、网络安全三个方向。入选要求是自包含、界定清楚、可自动评分——不然无法给出稳定的 pass/fail 信号。

算法怎么算

官网页给的流程是四步：

1. 收集一批任务，估计人类专家完成每个任务需要多久（human task duration）。
2. 把模型和 scaffold（负责给工具、管理交互循环）组合起来跑任务。scaffold 可以是 ReAct、Triframe、Claude Code、Codex 等。先在小 dev set 上选 scaffold、调参，再放到更大的 test set 上跑，每个任务独立跑 6 次。
3. 对每个 agent，用 logistic 曲线拟合「成功概率」随「人类任务时长（log2 分钟）」的变化。
4. 取拟合曲线与 50%（或 80%）成功概率相交处的人类任务时长，就是 50% time horizon。

写成伪代码大致是这样：

# 每个 task 独立 rollout 6 次 -> p_success
# x = log2(human_minutes)
# 拟合 logistic: p_success = 1 / (1 + exp(-(a * x + b)))
# 反解 x，使 p_success == 0.5，再换算回分钟
h50 = solve_for_x(0.5)

取 log2 是因为人类时长跨了几个数量级，线性刻度上拟合会被长任务带偏。取交点而不是平均值，是因为你要的是「成功率跌破一半」那个边界，而不是整体平均水平。

已发布的数字

2025 年 3 月那篇论文给出的结论是：6 年间翻倍周期约 7 个月。

• GPT-5，2025 年 8 月：约 2 小时 17 分
• Claude Opus 4.5，2025 年 12 月：约 4 小时 49 分
• GPT-5.2 (high)，2026 年 2 月：约 6.6 小时
• Claude Opus 4.6，2026 年 2 月：约 14.5 小时

翻倍时间一度从 7 个月缩到 4 个月。

六个不能忽略的坑

1. 超过 16 小时的测量基本不可信

当前任务集已接近饱和，最高分模型的估计杂讯极大。Opus 4.6 的 14.5 小时，95% 置信区间是 6 到 98 小时。区间跨了 16 倍，点估计本身没什么区分度。

2. 换任务集直接改变排名

2026 年 1 月发布的 Time Horizon 1.1（TH1.1）把任务从 170 增到 228，8 小时以上的长任务从 14 增到 31，并重新估计了 14 个模型。结果排名被重排：

• GPT-4 系列两款分别下滑 35% 和 57%
• GPT-5 上升 55%
• Opus 4.5 上升 11%

2024 年以来的翻倍周期从 109 天降到 89 天。拿旧任务集的数字去对比新数字，等于比两份不同的考卷。

3. 置信区间常达一个数量级

不只是 14.5 小时那个例子。取交点的拟合外推本来就对样本量敏感，长任务越少、成功率越接近 0 或 1，区间就越宽。读点估计之前先看区间。

4. scaffold 会影响结果

同样用 TH1 任务、5 个模型，在 Vivaria 和 Inspect 两套框架下都测过，GPT-4o 和 o3 在 Vivaria 下得分显著更高。评估交互式 agent 时，模型和运行配置必须一起报告，否则数字不可比。

5. reward hacking 能决定数字

METR 在 2026-06-26 对 GPT-5.6 Sol 做部署前评测，其被检测到的作弊比例是所有公开模型里最高的。三种处理方式给出三个完全不同的结果：

• 把作弊算失败（METR 标准规则）：50% 时间视野约 11.3 小时
• 把作弊算成功：超过 270 小时
• 整批剔除：71 小时，置信区间 13 到 11400 小时

METR 自己明说，这三个数字没有一个能作为可靠的能力测量。作弊判定规则本身成了指标的一部分。

6. 感知与现实之间的落差：RCT 结果

METR 做了随机对照试验，16 位在成熟开源项目平均 5 年经验的开发者，随机分到「能用 AI / 不能用 AI」两种条件，比较 246 个任务的完成速度。

结果是：AI 让资深开发者慢了 19%。

而开发者事前预测 AI 会快 24%，事后仍相信快 20%；外部专家预测快 38% 到 39%。Joel Becker 把原因之一归到 verification step：可靠度低于 100% 时，每次输出都要回头验证，而验证别人写的代码往往比自己写还累。感知收益和实测收益反向，这一点在做生产力推算时绕不过去。

数据和代码

分析代码与数据仓库：

runs.jsonl 里每条记录包含这些字段：

• task_id、task_family
• alias（模型标识）
• score_binarized、score_cont（二值与连续分数）
• human_minutes（人类专家完成时长，拟合的自变量）
• invsqrt_task_weight（任务权重）

有了这几列，logistic 拟合和交点求解可以自己复现一遍。要判断某个时间视野数字是否可信，先确认它的任务集版本、scaffold 配置、作弊判定规则，再看置信区间——四个都对齐了，两个数字才有比较的意义。