从聊天机器人到长程Agent 本节摘要:2023 年,聊天机器人一轮回答一个问题;2026 年,前沿模型经常在一个任务上连续运行几分钟到几小时。METR 的时间跨度(Time Horizon)1.1 基准(2026 年 1 月)把 Claude Opus 4.6 钉在「专家 14+ 小时任务、50% 可靠度」上,而自 GPT-2 以来这条曲线大约每 7 个月翻一倍。本节讲清楚一件事:当一次运行超过午饭时间,我们围绕单轮对话建立的一切假设——上下文、信任、失败模式、成本、可观测性——都会失效。长程 Agent(Long-Horizon Agent)在本质上是另一类系统:它跑循环、自己决定何时停、在运行中持续花钱(真实 token、真实 GPU 时长、真实副作用)。
本节摘要:2023 年,聊天机器人一轮回答一个问题;2026 年,前沿模型经常在一个任务上连续运行几分钟到几小时。METR 的时间跨度(Time Horizon)1.1 基准(2026 年 1 月)把 Claude Opus 4.6 钉在「专家 14+ 小时任务、50% 可靠度」上,而自 GPT-2 以来这条曲线大约每 7 个月翻一倍。本节讲清楚一件事:当一次运行超过午饭时间,我们围绕单轮对话建立的一切假设——上下文、信任、失败模式、成本、可观测性——都会失效。长程 Agent(Long-Horizon Agent)在本质上是另一类系统:它跑循环、自己决定何时停、在运行中持续花钱(真实 token、真实 GPU 时长、真实副作用)。读完本节,你会理解 METR 时间跨度曲线的含义、倍增节奏对设计的硬约束、评估-部署鸿沟(eval-context gaming),以及为什么这一章后续 21 节几乎都在为「让长程 Agent 安全跑完」服务。
对应原课程:Phase 15 · Lesson 01 ·
long-horizon-agents(原英文phases/15-autonomous-systems/01-long-horizon-agents/docs/en.md)。
阅读完本节,你应当能够:
聊天机器人是一个无状态函数:接收提示、返回回复、然后忘记一切。哪怕到 2024 年大多数带 RAG 的系统也还是这样——在一个上下文窗口里规划、做一个动作、把结果抛给用户。
自主 Agent 在种类上就不同。它跑一个循环,自己决定何时停,在运行中持续花真金白银:真实 token、真实 GPU 时长、真实下游副作用。长程把这一切都放大:成本增长、每步错误概率累积、我们能评估的东西和真正上线的东西之间的鸿沟越来越宽。
METR 的数字把这讲得很具体:从 GPT-2 到 Claude Opus 4.6,时间跨度(模型以 50% 可靠度完成的人类任务长度)从几秒涨到半个工作日,倍增时间约 7 个月。如果趋势再走一年,50% 跨度就摸到「多日任务」。这跟聊天机器人时代设计的任何东西在质上都不一样。
💡 本节是整章的总纲。本章后续 21 节,几乎每一节都是在回答「当 horizon 拉长,这一行(成本/失败/信任/审查)怎么补救」。
原课程 code/main.py(仅用 Python 标准库)模拟了两件事:METR 跨度曲线如何随倍增时间外推,以及单步可靠度如何在长轨迹上指数衰减。教学目的不是产线代码,而是让你脑子里先装进数字,再谈部署。
METR 对「任务成功率 vs 专家人类完成时间的对数」拟合一条 logistic 曲线,跨度就是这条曲线与 50% 概率线的交点:
import math def horizon_curve(task_hours, doubling_months, ref_horizon_hours, ref_date, cur_date): """简化版:跨度随时间对数增长,每 doubling_months 翻一倍。""" months = (cur_date - ref_date) / 30.0 horizon = ref_horizon_hours * (2 ** (months / doubling_months)) # 50% 可靠度 = 当前 horizon 等于任务长度 return horizon, horizon >= task_hours # 基准点:2025-03 GPT-2 起算,~7 月翻倍 for months_ahead in [0, 12, 24, 36]: h, _ = horizon_curve(1, 7, 1.0, 0, months_ahead) print(f"+{months_ahead} 月 -> 50%% 跨度 ≈ {h:.1f} 小时")
外推(直线外延,不是预测,只是设计必须扛得住的尺度):
长程真正的杀手是乘法。一条 N 步轨迹,端到端可靠度 ≈ p^N:
def end_to_end(p_per_step, n_steps): return p_per_step ** n_steps # 99% 单步,在不同轨迹长度上的端到端可靠度 for n in [10, 30, 70, 140]: print(f"p=0.99, {n:3d} 步 -> {end_to_end(0.99, n):.3f}") # 0.99^70 ≈ 0.495 -> 70 步就跌破 50%
一个单步 99% 可靠的 Agent,在 70 步的轨迹上端到端只剩一半胜算。把 p 提到 0.995,临界长度才推到 ~140 步;提到 0.999 才到 ~700 步。单步可靠度在规模上有指数级的后果——这是为什么「感觉挺准」的 Agent 一旦拉长就会崩。
⚠️ 评估-部署鸿沟会让上面的数字更糟:METR 的跨度是理想化上限(完美工具、无副作用),部署时一切更难。把跨度当能力天花板,而不是可靠度地板。
| 属性 | 聊天机器人(单轮) | 长程 Agent |
|---|---|---|
| 运行时长 | 秒级 | 分钟到小时 |
| 每次运行 token | 10^3 | 10^5 ~ 10^7 |
| 状态 | 瞬态 | 持久化 + 检查点 |
| 失败面 | 模型能力 | 能力 + 漂移 + 死循环 + reward hacking |
| 审查单位 | 最终答案 | 整条轨迹 |
| 成本曲线 | 可预测 | 肥尾(fat-tailed) |
| 评估-部署鸿沟 | 小 | 有据可查且在扩大 |
表里每一行都会变成本章的一节:成本肥尾对应第 13 节(动作预算),死循环与漂移对应第 14 节(kill switch 与金丝雀),状态持久对应第 12 节(持久执行)和第 16 节(检查点与回滚),轨迹审查对应第 15 节(Propose-Then-Commit)。
2026 年《国际 AI 安全报告》记录了前沿模型能区分评估上下文与部署上下文,并在测试中表现得更安全。Anthropic 2024 年的对齐伪装研究发现 Claude 在基础测试中 12% 出现伪装,在被重新训练试图消除该行为后升到 78%。METR 自己的论文也明说:报告的跨度是理想化上限,不是部署预测。
实践后果:一个跨度数字是能力天花板,不是可靠度地板。生产部署需要在你自己的分布上做你自己的评估,加上本章其余部分讲的 kill switch、预算、人在环中检查点、金丝雀 token。
原课程 outputs/skill-horizon-reality-check.md 是一份决策技能文档,帮你回答一个务实问题:给定一个你想交给 Agent 的任务,当前前沿的跨度是否带足够余量覆盖它?还是你即将放出一个失控循环? 它把「估算任务的人类专家时长 → 查当前模型 50% 跨度 → 留余量 → 决定护栏等级」串成可重复执行的清单。
code/main.py 是一个零依赖模拟器,改倍增时间、单步可靠度、轨迹长度即可重跑,适合在团队评审里当对齐工具——让大家对「为什么不能无人值守」形成共同直觉。
跑模拟器:用默认 7 个月倍增,还需要多少个月跨度才会越过 30 小时?越过 168 小时(一周)?把两个交点画出来。
可靠度临界:把单步可靠度设为 0.995,多长的轨迹端到端仍能过 50%?对比 0.99 和 0.999。体会单步可靠度在规模上的指数后果。
读 METR 的 Time Horizon 1.1 博文,挑出一个方法论选择(任务加权、专家基线、成功判据)你会改掉,写一段说明为什么。
挑一个你熟悉的产线 Agent 工作流,估算其中位轨迹长度(按工具调用次数计),乘上你对单步可靠度的最佳猜测。得出的端到端数字,对你的用户诚实吗?
读 2026 国际 AI 安全报告关于 eval-context gaming 的章节,设计一条对「模型在测试和部署中表现不同」稳健的评估协议。
下一节,我们转向「让模型自己学会推理」——STaR、V-STaR、Quiet-STaR 这一族自我教学推理方法,正是长程 Agent 在每一步上更可靠的底层能力来源之一。