1.1.1 · 状态依赖与有效跨度

2025 年上半年到年中，我对大模型的体感发生过一次明显变化。Claude 3.7 Sonnet 在 2025 年 2 月 24 日发布，同时带来了研究预览阶段的 Claude Code；Kimi K2 则在 2025 年 7 月进入公众视野，模型与技术报告把重点明确放在 agentic intelligence 和工具使用上。发布日期是可核验事实；「模型从会回答问题走到聪明、基本可用」是我的个人判断。它不是一条学界公认的分界线，也不表示此前模型不能做 Agent，更不表示此后模型已经可靠。

这条主观分界有用，是因为它改变了我追问能力提升的方式。单轮问答继续变强当然重要，但当模型已经能写出像样的代码、选择工具并依据执行结果再行动，下一段差距越来越多地出现在连续工作中：它能否记住用户真正要什么，分辨自己声称完成与环境实际完成，发现早期判断错误后撤销受污染的工作，并在上下文换页、进程重启或用户改需求以后继续推进。唐杰在 2026 年关于 AGI 路线的论述中把「长程任务」列为关键方向，并以跨越数周、数月乃至数年的规划和执行说明其尺度；LongHorizon-Harness 则把问题收紧到持续推理、工具使用、修订以及许多相互依赖步骤中的状态维护。前者说明为什么值得追，后者给出可研究的系统问题。

但「长」仍然不是定义。一个模型连续输出两万 token 很长，一个任务等待构建两小时也很长，一百次互不相关的搜索也很多。这三种情况都可能昂贵，却不一定要求系统跨越很远的因果依赖。这里采用下面的工作定义：

Long-Horizon 能力，是模型与其 Harness 组成的系统，在一条持续变化且具有跨步依赖的任务轨迹中，维持目标、约束和事实的一致性，依据新观测修订计划，并在延迟反馈揭示错误后，从仍可信的状态继续完成任务的能力。

这里有三个限定。第一，能力属于「模型—Harness—环境」整体，不能只归给模型权重。第二，horizon 由依赖结构和恢复难度刻画，不由 token、动作数或墙钟时间单独决定。第三，完成意味着外部可验证的终态满足目标，而不是模型在文本里宣布完成。

1. 状态与有效长度

严格定义需要同时回答两件事：任务在每一步保存什么，以及相隔多远的决策仍然互相依赖。前者给出状态边界，后者给出有效长度。

状态转移刻画任务如何推进；依赖图、验证距离和传播范围则把表面时长转换为可计算口径。

把任务写成状态转移，设第 $t$ 步的任务状态为

S_t=(G_t,C_t,E_t,B_t,P_t,V_t,K_t). \tag{1}

$G_t$ 是当前目标及版本， $C_t$ 是必须持续成立的约束， $E_t$ 是环境事实， $B_t$ 是系统当前相信的内容， $P_t$ 是尚待执行的计划， $V_t$ 是已经通过检查的结果， $K_t$ 是可恢复点及其元数据。把这些量拆开，可以避免把目标等同于计划、把环境事实等同于系统信念、把动作完成等同于结果有效。

模型说「文件已修改」只进入 $B_t$ ；重新读取文件并通过测试后，相应结论才能进入 $V_t$ 。用户把「只改前端」改成「后端接口也可以调整」，变化发生在 $G_t$ 与 $C_t$ ，旧计划 $P_t$ 不能原样沿用。保存了一段对话摘要也不等于保存了 $K_t$ ；真正的恢复点还要对应环境版本、文件状态、进程状态和未提交副作用。

Agent 根据当前可见信息选择动作：

a_t\sim \pi_\theta(\cdot\mid O_t,M_t,P_t), \tag{2}

其中 $O_t$ 是当前观测， $M_t$ 是从工作记忆和外部记忆中取出的信息。环境执行动作后给出新状态和观测：

(E_{t+1},o_{t+1})=T(E_t,a_t). \tag{3}

状态管理器再完成

S_{t+1}=U(S_t,a_t,o_{t+1},q_{t+1}), \tag{4}

$q_{t+1}$ 是测试、规则检查、人工确认或其他验证器返回的证据。式 (2) 回答「下一步做什么」，式 (3) 回答「动作实际改变了什么」，式 (4) 回答「哪些变化可以成为后续决策的依据」。多数长程失败不发生在某一次生成，而发生在三者边界被抹平：动作意图被当成执行结果，执行结果被当成目标已经满足，旧环境中的事实被当成新环境仍然有效。

一个可以跟算的例子，考虑一次数据库迁移： $a_1$ 设计新字段， $a_2$ 写迁移脚本， $a_3$ 转换旧数据， $a_4$ 修改读路径， $a_5$ 做灰度验证。初始目标是「无停机迁移」，约束包括旧客户端仍可读、迁移可回滚。若 $a_1$ 把时间戳误选成精度不足的类型，局部 schema 检查可能通过，直到 $a_5$ 才在真实数据上发现排序碰撞。

在第 2 步结束时，系统最多能写入「迁移脚本按当前 schema 运行成功」。它不能写入「迁移正确」，因为决定正确性的证据尚未出现。用集合表示，令 $V_2={v_{\text{script}}}$ ，而「时间顺序保持」仍属于待验证命题 $U_2={u_{\text{order}}}$ 。到第 5 步，验证器返回 $q_5(u_{\text{order}})=0$ ，状态更新器应把依赖该命题的 $a_2,a_3,a_4$ 标成受影响，并重跑所有受影响的检查；单独重跑末次测试无法覆盖传播链。

这说明长程系统需要保存的不只是聊天历史，还要保存「结论依据什么证据」「哪些动作依赖该结论」。自然语言摘要可以承载说明，但若没有版本、来源和依赖关系，它很难支持精确回滚。

1.1. 五种常被混为一谈的「长」

现象	直接测到的量	它不能单独证明什么
长输出	单次生成 token 数	不能证明发生过环境交互和状态修订
长上下文	一次可读取的 token 数	不能证明旧约束被正确检索，也不能解决版本冲突
长运行时间	墙钟时间	不能区分等待与有依赖的决策
多工具调用	动作数与工具种类	不能区分并行独立动作与串行因果链
多步骤任务	轨迹长度	不能证明早期状态会约束远期选择

长上下文最容易造成错觉。假设窗口能容纳整条轨迹，系统仍需判断两条冲突信息哪条较新、一次工具调用是否真正生效、某个用户约束是否被后续消息替换。窗口容量解决「能否放入」，检索与状态更新解决「该相信什么」。另一方面，窗口较短也不必然阻止长程工作：只要外部状态具有明确 schema、证据可追溯、checkpoint 可恢复，系统可以跨多个上下文继续同一任务。

长运行时间也只是代理量。下载依赖等待 90 分钟，只有一个动作和一个结果；10 分钟内连续修改五个相互依赖的模块，可能形成更深的 horizon。唐杰用数周、数月说明最终希望达到的任务尺度，可以作为方向判断；工程评测仍要把时长拆成等待、有效行动、验证和恢复，否则数字无法解释能力来自哪里。

有效 Horizon 可以由依赖图定义。把一条轨迹写成有向无环图 $D=(N,L)$ ，节点可以是动作、观测、被确认的事实或验证事件；若节点 $j$ 的正确执行需要节点 $i$ 的结果，就连边 $i\rightarrow j$ 。最长依赖路径定义为

H_{\mathrm{dep}}=\max_{p\in\mathcal{P}(D)}(|p|-1). \tag{5}

这里减一是把路径中的节点数换成依赖边数。若 100 次搜索彼此独立，根节点分别连向 100 个结果，最长路径只有 1；若 10 个迁移动作首尾相接，最长路径为 9。动作数相差十倍，后者却要求早期状态穿过更多转移。

再看延迟验证。动作 $a_i$ 在第 $v(i)$ 步第一次得到可靠判定，则

H_{\mathrm{val}}(i)=v(i)-i. \tag{6}

在前面的迁移例子中， $a_1$ 到 $a_5$ 才暴露问题，所以 $H_{\mathrm{val}}(1)=4$ 。若每次修改后都有精确测试，距离可能降到 1。这个量回答的是「错误要潜伏多久」，不是任务总共多少步。

第三个量是错误传播范围。记节点 $i$ 的所有后继为 $\operatorname{Desc}(i)$ ，令

R_i=\sum_{j\in\operatorname{Desc}(i)}w_j, \tag{7}

$w_j$ 表示后继节点的重要性。若只计节点数，取 $w_j=1$ 。迁移任务中，错误 schema 被脚本、数据、读路径三项使用，至少有 $R_1=3$ 。式 (7) 没说这些后继必然错误，只表示一旦前提失效，需要重新审查的影响面。

为了把三者合成分桶指标，可以定义一个归一化难度：

H^*=\alpha\frac{H_{\mathrm{dep}}}{H_{\max}}+ \beta\frac{\overline{H}_{\mathrm{val}}}{V_{\max}}+ \gamma\frac{\overline{R}}{R_{\max}}, \qquad \alpha+\beta+\gamma=1. \tag{8}

这不是自然常数，也不应跨数据集直接比较； $alpha,\beta,\gamma$ 和三个上限都由评测协议声明。它的作用是强迫实验者公开「长」来自深依赖、迟验证还是广传播。正式报告仍应同时给出三项原始量，不能只剩一个总分。

难度维度与系统能力，依赖深度仍不足以解释全部难度。状态规模、动作可逆性和环境变化会决定同样长的链条是否容易维护与修复。

能力也不只属于模型权重。恢复成本和系统组成需要进入定义，任务是否具有长程属性则由后面的操作条件判断。

状态规模、可逆性与环境变化，相同依赖深度还可能难度悬殊。第一项差别是状态规模。若每一步只需记一个整数，深链可以很长却很容易；若状态包含数百个文件、运行进程、凭证、用户约束和多个并行分支，即使链较短，保持一致也更难。可用有效状态量近似表示：

I_t=\sum_{x\in X_t}\ell(x)\,r(x), \tag{9}

$X_t$ 是仍会影响未来决策的状态项， $\ell(x)$ 是表示它所需的信息量， $r(x)$ 是在未来被调用的相关权重。式 (9) 只是评测设计用的近似，不要求精确计算信息熵；它提醒我们不要把无关日志长度当成状态规模。

第二项差别是可逆性。修改未提交文件通常容易撤销，发送邮件、删除生产数据或公开发布则可能不可逆。设从错误状态 $S_t'$ 回到最近可信状态 $S_k$ 的代价为

C_{\mathrm{rec}}=c_{\text{detect}}+c_{\text{rollback}}+c_{\text{replay}}+c_{\text{external}}. \tag{10}

四项分别对应发现错误、撤销内部变化、重放有效步骤和处理外部影响。一个系统即使最终成功，若每次出错都从头重来，长任务成本也会随 horizon 急剧上升。因此 Long-Horizon 能力必须包含恢复，而不能只看一次无误执行。

第三项差别是环境非平稳。文件可能被其他进程更新，网页内容会变化，令牌会过期，用户也会追加或替换要求。若环境转移写成 $T_t$ 而非常数 $T$ ，则相同动作在不同时刻可能得到不同结果。系统读取旧记忆时必须核对时间、版本和来源；「当时正确」不等于「现在仍可执行」。

1.2. 能力属于系统，不属于单个模型分数

同一个基础模型放进不同 Harness，表现可能完全不同。Harness 决定工具 schema、上下文如何组织、事实写到哪里、何时压缩、怎样触发验证、失败后从哪里恢复。模型参数决定动作策略的重要部分，却不独占整个闭环。因此更完整的策略写成

\Pi=(\pi_\theta,\mathcal{M},\mathcal{P},\mathcal{V},\mathcal{R}), \tag{11}

$\pi_\theta$ 是模型策略， $\mathcal{M}$ 是记忆， $\mathcal{P}$ 是计划控制， $\mathcal{V}$ 是验证器， $\mathcal{R}$ 是恢复机制。评测只报告模型名而不报告 Harness、工具权限、上下文预算和重试规则，结果就无法复现。

这也解释了模型变强以后，能力提升为何越来越显出 Long-Horizon 的形状。更强的单步策略会提高每一步正确率，却不会自动消除误差累积。若每一步独立成功率为 $p$ ，简单链条连续 $n$ 步全部正确的概率是

P_{\text{all}}=p^n. \tag{12}

取 $p=0.98$ ， $n=10$ 时约为 $0.817$ ； $n=50$ 时约为 $0.364$ 。真实任务的步骤并不独立，验证和恢复也能阻断错误，所以式 (12) 不用于预测性能；它展示单步可靠率沿长链相乘后的快速下降。验证、隔离和恢复能够切断这种裸乘法，避免系统依赖每一步都绝对正确。

一项任务何时可以称为 Long-Horizon，可操作的判定至少检查五件事：任务是否存在跨步依赖；目标或环境是否会在执行中变化；关键动作是否存在延迟验证；早期错误是否会污染多个后继；系统是否需要跨上下文、跨会话或跨进程恢复。满足一项并不足以自动归类，满足得越多，长程属性越强。

反过来，有三种常见假阳性。第一，用大量无关步骤填充轨迹，动作数很大但依赖深度很浅。第二，把单次长文本生成称为长任务，期间没有环境反馈和状态更新。第三，把等待时间计入 horizon，却不报告有效动作和环境变化。评测协议应同时公开动作数、依赖深度、验证距离、状态规模与恢复代价，让读者能看出任务究竟长在哪里。

跨度层级与失效机制，任务会跨越单一窗口、多个会话，甚至多个相互关联的任务。跨度扩大后，记忆的写入、失效和恢复都必须有明确规则。

三个执行层级对应不同的状态跨度；目标漂移、事实漂移、计划僵化与完成幻觉都可以落到前面的状态变量上。

2. 三个跨度层级

依赖结构回答「为什么难」，执行跨度回答「状态要穿过哪些边界」。可以把任务粗分为三个层级。H1 是单一工作上下文内的长轨迹：任务在一次会话和一个可见窗口内完成，但包含多轮工具反馈与计划修订。H2 跨越上下文或会话：系统必须压缩历史、持久化状态，并在新上下文中恢复未完成工作。H3 跨越多个任务或长期目标：今天完成的结果会成为下周任务的前提，用户偏好、环境和技能也可能持续变化。

这三个层级不是按 token 设置的固定档位。同一个任务在大窗口系统里可能属于 H1，在小窗口系统里需要两次压缩而成为 H2；若 Harness 把完整状态外置，跨窗口也未必困难。层级描述的是运行边界，不代替依赖深度。一个 H2 任务可能只是把简单清单分两次做完，一个 H1 任务也可能包含很深的编译、测试和回滚链。报告时应把「跨度层级」与「结构难度」分成两列。

H3 还引入了经验更新问题。一次任务结束后，哪些内容能成为下一次任务的记忆？用户临时要求不应固化成永久偏好，某个仓库版本下正确的命令也不能无条件迁移。若长期记忆项 $m$ 带有来源 $s(m)$ 、生效范围 $d(m)$ 、记录时间 $t(m)$ 和置信度 $c(m)$ ，读取条件至少应检查

\operatorname{valid}(m,E_t,G_t)= \mathbf 1[s(m)\text{ 可追溯}] \mathbf 1[d(m)\text{ 覆盖当前任务}] \mathbf 1[m\text{ 未被新证据推翻}]. \tag{13}

式 (13) 没有把置信度直接当真值。置信度只决定是否值得取回或复核，不能让一条高置信旧记忆越过环境检查。跨任务的 Long-Horizon 因而既包含记住，也包含遗忘和失效。

四种典型失败怎样落到状态式上，第一种是目标漂移。系统在长轨迹中逐渐把手段当成目的，例如原目标是修复登录错误，执行中却把「重构认证模块」当成必须完成的主任务。形式上，计划 $P_t$ 与当前目标 $G_t$ 的对应关系断开。检查时让每个关键子任务引用目标版本，并验证它对验收条件的贡献；询问模型是否还记得目标无法提供同等证据。

第二种是事实漂移。环境已经变化，内部认知 $B_t$ 仍引用旧状态。例如测试是在提交 A 上通过的，随后文件被改到提交 B，系统却继续使用「测试已通过」这一结论。修复需要让验证结果 $V_t$ 绑定环境指纹。若结果 $v$ 依赖文件集合 $D(v)$ ，任一文件变化时， $v$ 应从有效变为待复核：

\operatorname{fresh}(v,t)= \prod_{f\in D(v)} \mathbf 1[h_f(t)=h_f(t_v)], \tag{14}

$h_f(t)$ 是文件在时刻 $t$ 的哈希， $t_v$ 是验证发生时间。实际系统不一定逐文件计算哈希，也可以用提交号、构建 ID 或数据库版本；核心是结论必须绑定它所验证的状态。

第三种是计划僵化。系统在开头生成完整计划，之后不顾新证据机械执行。计划是对未来动作的暂定排序，不构成不可修改的承诺清单。若新观测使某一步成功概率、成本或前置条件变化，就应重新求解剩余部分。可以把下一动作选择写成

a_t^*=\arg\max_{a\in\mathcal A(S_t)} \left[\mathbb E\,\Delta V(a\mid S_t)-\lambda C(a)-\mu R(a)\right], \tag{15}

$\Delta V$ 是预期有效进度， $C(a)$ 是成本， $R(a)$ 是不可逆风险。式 (15) 用于说明动作集合和排序都依赖当前状态，无须假定真实系统能够精确估值；新观测应覆盖旧计划中的失效假设。

第四种是完成幻觉。模型根据自己生成的代码或解释宣布任务完成，却没有获取终态证据。状态式中的错误是把 $B_t$ 直接复制进 $V_t$ 。可靠终止条件应由验收谓词决定：

\operatorname{done}(S_t)= \mathbf 1[Q(E_t,G_t)=1] \mathbf 1[\text{硬约束全部成立}] \mathbf 1[\text{无待确认高风险副作用}]. \tag{16}

自然语言任务不总能完全程序化，但这不等于可以省略证据。无法自动检查的部分可以由人工或经校准的 judge 判断，并保存依据；可执行部分仍应由环境验证。

比较与边界，定义最终要能区分表面长度相同、结构难度不同的任务。一个完整手算可以检验各个量是否真的可用。

同时还要说明定义不包含哪些相邻概念，避免把自主性、持续学习与通用智能全部折叠进 Long-Horizon 一个标签。

2.1. 一次完整手算：长度相同，难度为何不同

设任务 A 有 8 个搜索动作，每个动作独立产生一个结果，任务结束时把结果并列汇总。依赖图从根节点分出 8 条边，再汇入汇总节点。最长路径包含「根—搜索—汇总」两条边，所以 $H_{\mathrm{dep}}=2$ 。每次搜索返回后立即检查，平均验证距离为 1；任一搜索错误只影响自身和汇总中的一项，取单位权重时传播范围约为 1。

任务 B 也有 8 个动作：选 schema、写迁移、转换数据、改写入、改读取、部署灰度、观察指标、切换流量。它们首尾依赖，所以 $H_{\mathrm{dep}}=7$ 。若 schema 精度问题到观察指标时才出现，第一步的验证距离是 $6$ ；其后 6 个动作都需要复核，传播范围是 $6$ 。两项任务动作数相同，按式 (8) 且取 $H_{\max}=7,V_{\max}=6,R_{\max}=6$ 、三项等权，任务 A 的近似分数为

H_A^*=\frac13\left(\frac27+\frac16+\frac16\right)\approx0.206, \tag{17}

任务 B 为

H_B^*=\frac13\left(\frac77+\frac66+\frac66\right)=1. \tag{18}

这个计算没有宣称任务 B 恰好难五倍。权重和归一化上限都是人为协议，换数据集就要重定；它只展示为什么「都是 8 步」不足以比较。若任务 A 的搜索网站持续变化，或汇总存在严格全局约束，它的状态与恢复难度还会增加，必须另列相应变量。

再比较两种系统。系统 X 每步成功率较高，但不保存 checkpoint；系统 Y 单步略弱，却每两步验证一次并能从最近可信点重放。无故障短任务中 X 可能领先，随着验证延迟和错误传播扩大，Y 的恢复成本优势才会出现。Long-Horizon 评测因此不能只挑一组最长任务，也要画难度增长曲线，观察系统从哪个区间开始失稳。

定义不包含什么，Long-Horizon 不是自主程度的同义词。系统可以在关键动作请求人工批准，同时仍需长期维护状态；也可以完全自动地执行一百次无关请求，却没有长程依赖。自主性描述谁作决定，horizon 描述决定之间隔了多远的有效依赖。

Long-Horizon 也不等于持续学习。一个系统可以在任务内更新记忆而不修改参数，完成后恢复原状；持续学习则要求经验改变未来任务的行为。两者在 H3 层级相交，但任务内状态维护不自动推出模型学会了新技能。

它还不等于通用智能。一个针对数据库迁移设计的系统可以在狭窄领域稳定执行深依赖任务；通用 Agent 可能在许多领域做短任务，却在长链中迅速漂移。定义应允许我们独立测量领域宽度与 horizon，而不是把所有能力压进一个标签。

Long-Horizon 的关键在于：早期状态穿过很长的依赖链后仍然有效；状态失效时，系统能根据证据找到影响面并继续完成。 这个定义还需要落实为可标注的维度，才能进入任务分桶、过程测量和系统诊断。

从标量长度走向 Horizon 向量，单个步数很适合做横轴，却很难描述长任务的结构。同样是 100 次工具调用，100 个彼此独立的搜索与一条 100 层迁移链，失败传播完全不同。更稳妥的表示是一组维度：

\mathbf H(T)= (D, V, S, I, X, R), \tag{19}

$D$ 表示依赖图最长路径， $V$ 表示验证距离， $S$ 表示必须持续维护的状态规模， $I$ 表示不可逆动作的风险质量， $X$ 表示跨越的上下文或进程边界， $R$ 表示发生故障后恢复到可信状态的最小代价。这里没有把六项强行加成一个总分，因为它们的量纲不同：依赖深度按边数计，验证距离可以按有效动作计，恢复代价则可能包含 token、墙钟时间和人工操作。

若排行榜确实需要排序，可以先按任务集给每项做分位数归一化，再公开权重：

H_w(T)=\sum_{j=1}^{6}w_jF_j(H_j(T)), \qquad \sum_jw_j=1. \tag{20}

$F_j$ 是该任务集上的经验分布函数。这个分数只适合在同一任务集内比较，换一批任务后分位数和权重都要重算。公开向量比只报总分更重要，因为两个 $H_w$ 相同的任务，可能一个难在深依赖，另一个难在不可逆副作用；它们需要的系统能力并不相同。

墙钟时间可以很长，horizon 却很短。提交一个训练任务后等待八小时，期间若系统不观察、不决策、不维护新状态，那么关键路径仍可能只有「提交—读取结果」两步。反过来，一个十分钟的数据库迁移可能连续经过 schema、备份、灰度、校验与切流，任何早期错误都会影响后续。真正需要计入有效长度的是产生状态变化或维持依赖的动作，而不是等待本身。

可以把事件序列 $e_1,\ldots,e_n$ 投影到有效动作集合：

\mathcal A_{\mathrm{eff}}= \{e_t:\Delta E_t\ne0\;\lor\;\Delta B_t\ne0\;\lor\;\Delta V_t\ne0\}, \tag{21}

其中 $\Delta E_t$ 是环境变化， $\Delta B_t$ 是系统认知变化， $\Delta V_t$ 是新验证证据。纯等待、重复输出同一状态和没有增加信息的轮询不会增加有效动作数；一次只读检查虽然没有修改环境，只要产生新证据，仍属于有效动作。

等待也不能完全丢掉。若等待期间环境可能漂移，系统需要保存订阅、超时和恢复条件，这部分属于状态跨度 $X$ ；若外部结果只能在数小时后验证，等待扩大了验证距离 $V$ 。因此报告中应把「Agent 活跃执行时间」「外部等待时间」「跨等待保存的状态」分开，避免把延迟直接包装成能力。

2.2. 因果链与表面步骤

依赖图中的边要表达真实因果。动作 B 在日志里排在动作 A 后面，不代表 B 依赖 A。若删掉 A 后 B 的合法性、输入或验收结果都不变，这条时间邻接不应计入依赖深度。可以用反事实标准判断一条边：

A\rightarrow B \quad\Longleftrightarrow\quad P(B\text{ 可正确执行}\mid do(A)) \ne P(B\text{ 可正确执行}\mid do(\neg A)). \tag{22}

真实系统通常无法精确估计两个概率，但可以用输入版本、数据流、显式前置条件和故障注入近似判断。把某个上游产物替换成错误版本，若 B 的检查稳定失败，就有较强证据支持依赖边；若 B 完全不受影响，图中可能只是把日程顺序误写成因果。

这一区分也能识别 benchmark 注水。把一个五步任务拆成五十个同义确认，不会让因果链变深；把十个独立任务串在一份提示里，增加的是批量规模。Long-Horizon 的难处来自早期决定对远端动作仍有约束力，步骤标签越多并不能凭空制造这种约束。

验证距离的两种算法，验证距离可以按动作数，也可以按图距离计算。若动作 $a_i$ 产生事实 $f$ ，第一次能够可靠判定 $f$ 的验证节点为 $v(f)$ ，序列距离为：

V_{\mathrm{seq}}(f)=\operatorname{index}(v(f))-i. \tag{23}

图距离则只计算因果路径：

V_{\mathrm{dep}}(f)= \operatorname{dist}_{G}(a_i,v(f)). \tag{24}

两者差异能暴露调度浪费。假设写配置后做了八个无关搜索，第十步才运行配置检查，序列距离为 9，图距离可能只有 1。系统的结构风险并不高，调度却让错误晚了很久才暴露。若两种距离都大，说明验证本身依赖许多后续步骤，例如模型训练结束后才能发现数据格式在早期就错了。

任务级验证距离可以报告中位数、P90 和按传播范围加权的均值：

\bar V_w= \frac{\sum_f w_fV(f)}{\sum_fw_f}, \qquad w_f=1+|\operatorname{desc}(f)|. \tag{25}

影响后继越多的事实权重越大。平均距离很短却有一个高传播事实延迟极长，仍然可能让整条任务链在末尾崩掉，P90 与加权均值能把这种尾部风险显出来。

不可逆性怎样量化，「不可逆」也有层次。本地文件有版本控制时通常可恢复；云资源删除可能依赖备份和保留期；邮件发送后无法收回，只能补发；资金转移还涉及权限和法律后果。可将动作 $a$ 的风险写成：

I(a)=p_{\mathrm{err}}(a) \bigl(C_{\mathrm{undo}}(a)+C_{\mathrm{res}}(a)+C_{\mathrm{ext}}(a)\bigr), \tag{26}

$C_{\mathrm{undo}}$ 是撤销成本， $C_{\mathrm{res}}$ 是无法撤销时的补偿成本， $C_{\mathrm{ext}}$ 是对外部主体的影响。概率与成本很难精确估计时，也可以用低、中、高三级，但分级依据必须公开。

不可逆动作会改变合理的 Harness。风险低时，执行后验证即可；风险高时，需要在动作前核对目标版本、权限与幂等键，必要时请求人工批准。于是 horizon 不只描述任务有多长，也描述错误能走多远、回头有多贵。

3. 系统能力的边界曲线

一个系统没有脱离任务分布的固定 horizon。更合理的结果是一条条件成功曲线：

p(d,v,i,x)=Pr(\text{success}\mid D=d,V=v,I=i,X=x). \tag{27}

实验可以固定其中三项，只增加依赖深度；也可以固定深度，增加验证延迟或跨会话次数。若所有维度一起上升，最终下降仍然真实，却无法知道瓶颈在哪里。边界曲线还能解释两个系统的交叉：模型更强但没有 checkpoint 的系统可能在浅任务领先，带验证与恢复的系统则在 $V$ 和 $X$ 增大后反超。

报告 horizon 时还要给可靠率。50% 边界适合观察能力趋势，生产系统可能关心 80%、95% 甚至更高。METR 的 time horizon 也明确把 50% 与 80% 分开：它们表示在人类完成时间这一难度轴上，拟合成功概率与指定可靠率的交点，并不等于 Agent 能连续自主运行同样长的墙钟时间。Long-Horizon 研究若采用类似术语，也应明确难度轴、任务分布、可靠率和 Harness 配置。

一套任务标注协议，给真实任务标 horizon，最好由任务作者与独立复核者分别画依赖图。作者列出目标、关键状态、动作、验收条件和不可逆副作用；复核者从干净环境实际完成一次，删掉纯粹因为作者习惯而加入的步骤，再补上作者遗漏的隐含前提。两张图合并时，每条边都要能回答「上游变化为何会影响下游」。

标注表可以只保留七列：节点 ID、动作或事实、输入版本、输出版本、前驱、首次验证位置、失败后的补偿方式。由这张表直接计算依赖深度与验证距离，不需要标注者凭感觉给「长、中、短」。状态规模 $S$ 也不按对话字数计算，而是统计完成任务所需的独立状态项；同一句话里可能包含五个约束，十段日志也可能只重复一个结果。

两个标注者对边集合的差异可以用 Jaccard 相似度表示：

J(E_1,E_2)=\frac{|E_1\cap E_2|}{|E_1\cup E_2|}. \tag{28}

假设两人分别标了 12 与 14 条边，其中 10 条一致，则 $J=10/16=0.625$ 。这个一致度不算高，适合回到分歧最大的节点做故障注入。若删掉某个上游产物后下游仍能稳定通过，那条边很可能只是时间顺序；若下游立即失败，依赖证据更强。

任务还应标出最小可信完成路径。Agent 允许走不同路线，但参考路径提供了依赖深度、必要验证和恢复成本的下界。Agent 用更多步骤完成并不自动增加任务 horizon，只能说明其策略效率较低；Agent 找到更短的合法路径，则应更新任务理解，而非判它偏离参考答案。

动态环境的标注，网页、在线服务与多人仓库会在执行期间变化，静态依赖图需要增加外部事件节点。每个外部事件记录可观察信号、影响范围和有效期。例如登录会话过期会影响所有后续写操作，商品价格变化只影响引用该报价的决策。系统没有触发这些事件，却必须识别并吸收它们。

对第 $k$ 类外部事件，可以报告发生后的检测延迟 $L_k$ 、受污染动作数 $N_k$ 与恢复成本 $C_k$ 。动态 horizon 的难点由事件频率和影响范围共同决定。变化很多但彼此无关，系统只需局部刷新；变化很少却触及根目标，会迫使整个计划重算。

环境不可冻结时，评测至少记录开始时间、关键资源版本与外部响应。两套系统若在不同日期访问不同网页，结果差异未必来自 Agent。能使用快照或模拟服务时优先使用；必须访问实时环境时采用配对、交错运行，降低时间漂移对比较的影响。

从任务定义到系统诊断，Horizon 向量最终要指导系统设计。 $D$ 高而 $V$ 低，说明依赖链深但每步可及时检查，计划与状态版本最重要； $V$ 高时需要 checkpoint、冗余验证和保守提交； $I$ 高时加强权限、人工确认与幂等； $X$ 高时优先解决持久状态和恢复； $R$ 高则要缩小故障影响域。

这套映射不保证某个组件一定提高分数，它把失败归到可以实验的方向。若系统在高 $D$ 桶下降，增加上下文却无效，问题可能出在依赖追踪；若高 $X$ 桶下降而单会话稳定，就该检查压缩与恢复。Long-Horizon 作为定义的价值，正在于把「Agent 做久了容易坏」拆成这些能够单独测量的条件。

3.1. 用生存分析描述「能坚持多久」

只报告固定长度上的成功率，会隐藏失败发生在轨迹哪里。把首次不可恢复错误发生的步数记为随机变量 $T_f$ ，生存函数为

S(t)=\Pr(T_f>t).

$S(t)$ 表示系统执行到第 $t$ 步仍保持可恢复状态的概率。相邻区间的风险率

h(t)=\Pr(T_f=t\mid T_f\ge t)

回答「已经走到这里以后，下一步失效的条件概率」。两个系统在 100 步任务上的最终成功率相同，生存曲线仍可能完全不同：一个在前十步暴露大量计划错误，幸存轨迹随后稳定；另一个前期很好，却随上下文累积在末段迅速崩溃。前者需要改进任务理解，后者更像状态维护或恢复能力不足。

任务正常结束与预算耗尽要按删失处理。轨迹在 200 步上限停止，只能说明 $T_f>200$ 或尚未完成，无法把它当作第 200 步失败。环境崩溃、网络断开和人工中止也要单独标记；若困难轨迹更容易触发环境故障，直接删除这些样本会高估生存率。

风险率还可按事件而非绝对步数对齐。工具写入、上下文压缩、用户改目标、checkpoint 恢复和跨 agent 交接都是状态突变点。令 $e_t$ 表示事件类型，可估计

h(t\mid e_t,\mathcal H_t),

比较某类事件是否显著提高后续错误概率。若压缩后的前三步风险突然上升，问题不一定来自任务更长，可能是摘要丢失了约束；若外部写入后风险上升，则需要加强读回验证与幂等语义。

生存曲线不能替代最终任务质量。系统可能通过极端保守、很少执行动作来避免犯错，从而维持较高 $S(t)$ ，却始终不接近目标。因此应同时记录验收条件完成量 $P(t)$ 。理想系统在保持高生存率的同时让 $P(t)$ 单调增长；高生存、低进展属于停滞，低生存、高短期进展属于激进但脆弱。

部分可观测性与信念状态，长任务环境往往不能一次读完。网页只显示当前页面，数据库查询只返回局部结果，异步任务的真实状态可能暂时未知。Agent 看到的是观察 $o_t$ ，外部真实状态为 $s_t$ ，因此更接近部分可观测决策过程：

s_{t+1}\sim P(s_{t+1}\mid s_t,a_t), \qquad o_{t+1}\sim O(o_{t+1}\mid s_{t+1}).

系统维护的是基于历史 $h_t=(o_1,a_1,\ldots,o_t)$ 的信念 $b_t(s)=\Pr(s_t=s\mid h_t)$ ，而非完整 $s_t$ 。工具调用既可以改变环境，也可以纯粹获取信息。读取文件、查询远程任务和运行测试通常属于后者；它们没有直接推进产物，却减少状态不确定性，为后续写入提供依据。

这给「有效进展」增加了第二种形式。除了让验收条件更接近完成，动作还可以带来信息增益

\operatorname{IG}(a_t)= H(b_t)-\mathbb E_{o_{t+1}}H(b_{t+1}).

一个诊断命令若能在两种修复路径间消除歧义，即使没有改文件，也可能比立即尝试其中一条更有价值。反过来，反复读取同一状态而没有新观测，信息增益接近零，只是在消耗轨迹长度。

模型生成的总结不能直接当作信念状态的权威更新。观察可能不完整，工具也可能超时；「没有看到错误」与「错误不存在」对应不同后验。状态记录应保留已验证、明确否定、未知和存在冲突等取值，并把来源与时间绑定。二值完成标记会把未知过早压成真或假。

长时域能力因此包含主动观测策略。系统要知道什么时候直接行动，什么时候先获取证据，什么时候因风险过高而请求授权。高副作用动作应要求更高状态置信；可回滚、低成本动作可以容忍更多不确定性。评测若只给完全可观测模拟器，会低估真实任务中这部分难度。

依赖深度、墙钟时间与动作数，「任务很长」至少有三个不同来源。动作数 $N_a$ 多，说明需要大量工具交互；依赖深度 $D$ 大，说明关键路径上必须顺序完成许多决策；墙钟跨度 $T_w$ 长，说明任务包含等待、异步反馈或跨日变化。三者可以独立变化。

批量重命名一万个互不依赖的文件有很大 $N_a$ ，依赖深度却很小，可以并行和机械验证。证明一个复杂定理或逐层调试协议栈，动作数可能不多，后一步却依赖前一步的精确结论， $D$ 很大。等待模型训练八小时的任务有很大 $T_w$ ，期间主动决策很少，但恢复时必须确认外部状态是否变化。

给任务依赖图 $G=(V,E)$ ，理论最短串行轮数至少是最长路径

D(G)=\max_{p\in\mathcal P(G)}|p|.

无限并行资源也无法突破这个下界。实际系统轮数还包括观测、验证、失败重试和资源冲突。用总 token 或总步骤衡量 Long-Horizon，会把大量独立重复工作误认为深层推理，也会漏掉动作稀疏但跨很长时间维护状态的任务。

依赖宽度同样重要。某一层有很多独立节点时可以并行，但合并结果需要版本一致和交界面验证。并行执行体越多，协调状态越大；当合并成本超过节省的关键路径时间，增加并发反而延长任务。Long-Horizon 评测应报告关键路径深度、最大可并行宽度和实际采用的并发，而非只报 agent 数量。

等待阶段还会引入环境漂移。外部任务开始时的依赖版本、权限和用户目标，完成时可能已经改变。恢复动作需要先重新观测，再判断旧结果能否提交。把八小时等待压成模拟器里的一个立即返回，可以测计划逻辑，却测不到跨时间有效性维护。