1 · 定义与评测: Long-Horizon 到底长在哪里

Long-Horizon 很容易被一句「让 Agent 连续工作更久」带过去. 这句话听起来没错, 实际上没有给出可以研究和评测的对象. 程序等待下载两小时也算运行很久; 模型一口气生成两万 token 也算输出很长; 工具型 Agent 连续搜索一百次也算动作很多. 这些现象会增加成本, 却不必然要求系统跨越很远的因果依赖. Long-Horizon 能力指系统在一条持续演化的任务轨迹中, 长时间维护目标、事实状态与约束, 依据新证据修订计划, 并在延迟反馈到来后定位和修复早期错误的能力.

这一定义把研究对象放在「任务状态怎样演化」上. 设第 $t$ 步的任务状态为

S_t=(G_t, E_t, B_t, P_t, V_t),

其中 $G_t$ 表示当前生效的目标与约束, $E_t$ 表示从外部环境读取的事实状态, $B_t$ 表示系统对任务的内部认知, $P_t$ 表示尚待执行的计划, $V_t$ 表示已经通过检查的结果. Agent 根据可见上下文 $C_t$ 产生动作 $a_t$ , 环境执行动作并返回观测 $o_{t+1}$ , 随后系统完成状态转移:

(a_t, o_{t+1}) = \mathcal{I}(C_t, E_t), \qquad S_{t+1}=\mathcal{U}(S_t,a_t,o_{t+1}).

$\mathcal{I}$ 是决策与交互过程, $\mathcal{U}$ 是状态更新过程. 公式里最容易被忽略的是 $B_t$ 与 $E_t$ 并不相同. 文件已经写入磁盘属于环境事实; 模型声称文件已经写入只是内部认知. 只有重新读取文件或运行检查, 这项结果才有资格进入 $V_t$ . 一旦把猜测直接当成事实, 后续规划会在错误状态上继续展开, 轨迹越长, 偏差越难被发现.

1. 五种「长」分别在测什么

长输出描述一次生成的 token 数. 它主要考验长文本组织、局部一致性和解码稳定性. 一篇很长的文章可以在单次调用中完成, 生成期间没有外部状态变化, 也没有执行后的反馈. 因此长输出可能是长任务的一部分, 却不能单独证明 Long-Horizon 能力.

长上下文描述一次推理能够读取的 token 范围. 更大的窗口能容纳更多历史, 但「看得见」不等于「能够持续使用」. 旧约束可能被中间噪声淹没, 同一个事实可能出现多个互相冲突的版本, 最新状态也可能只存在于工具或文件系统中. Long-Horizon 系统还要决定哪些内容应留在工作上下文, 哪些内容应写入结构化状态, 哪些历史需要压缩, 以及压缩以后如何恢复来源.

长运行时间是墙钟时间. 网络等待、训练任务和人工审批都会拉长它. 时间跨度带来的真正困难是环境可能在等待期间变化, 凭证可能过期, 用户可能修改目标, 执行体甚至可能重启. 如果任务只是等待一个不会变化的结果, 增加墙钟时间不会自动增加推理深度. 因此评测要把等待成本和状态保持能力分开记录.

多工具调用描述交互次数及工具种类. 一百个相互独立的网页查询可以并行执行, 任一次失败都不改变其他查询的含义. 相反, 一次数据库迁移可能只有十几个动作, 但后一步严格依赖前一步产生的 schema 与数据版本. 工具数量反映工作量, 工具调用之间的依赖关系才决定错误能传播多远.

多步骤任务比单轮任务更接近研究对象, 仍然需要进一步区分. 如果所有步骤早已固定, 每步都有即时、可靠的检查, 那么系统可以把任务当成一组短问题串行执行. 当步骤需要依据新观测动态选择, 中间结果要在数十步后才被验证, 并且早期选择会改变后续可行动作时, Long-Horizon 难度才真正出现.

1.1. Horizon 应由依赖结构刻画

动作数 $T$ 是最直观的长度, 但它无法区分有效步骤与填充步骤. 更有意义的表示是把轨迹写成有向依赖图 $D=(N,L)$ . 每个节点是一个动作、观测、状态更新或验证结果; 边 $i\rightarrow j$ 表示节点 $j$ 的正确性依赖节点 $i$ . 从起点到终点的最长依赖路径

H_{\mathrm{dep}}=\max_{p\in \mathcal{P}} |p|

可以称为「依赖深度」. $\mathcal{P}$ 是依赖图中的所有有效路径. 若一个任务含有一百次互不相关的查询, 它的动作数很大, 依赖深度仍可能很小. 若十个动作首尾相接, 第十步使用第一步确定的版本与约束, 它的依赖深度就是十. 这个量依然不够完整, 因为同样深度的任务可能具有完全不同的验证距离与可恢复性, 但它至少排除了用无关步骤伪造 horizon 的做法.

第二个关键量是「延迟验证距离」. 对动作 $a_i$ , 设第一个能可靠判断它是否正确的时刻为 $v(i)$ , 则

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

如果每次改动都能立即运行精确测试, $H_{\mathrm{val}}$ 很小, 错误会尽早暴露. 如果数据清洗规则要到模型训练结束后才看出问题, 前面几十步都可能建立在错误样本上. 延迟验证迫使系统维护假设、证据和不确定性, 不能把尚未检查的结果写成已完成事实.

第三个量是错误传播范围. 设动作 $a_i$ 出错后受影响的后继节点集合为 $\operatorname{Desc}(i)$ , 可以用

R_i=|\operatorname{Desc}(i)|

描述它可能污染多少后续决策. 这个计数不表示每个后继必然失败, 但能揭示早期错误的影响面. 更精细的评测还应给不同后继赋予重要性权重, 并记录错误被发现后需要撤销多少有效工作. 长程困难来自深依赖、迟反馈和广传播的组合, 轨迹长度只是它们留下的表面现象.

2. 从最终成功率走向轨迹评测

终局成功率必须保留. 用户关心任务有没有完成, 不能因为轨迹写得漂亮就给失败任务高分. 但单个终局分数会遮住失败发生在哪里. 一个系统可能稳定推进到临门一步, 因外部服务短暂不可用而失败; 另一个系统可能早早偏离目标, 偶然生成了能通过脆弱判定器的结果. 两条轨迹得到相同分数, 所反映的能力却完全不同.

评测应同时观察四层结果. 第一层是终态, 包括任务成功率、产物正确性和全部硬约束是否满足. 第二层是进度, 记录经过验证的有效子目标完成率, 不能直接采用模型自报的「已完成」. 第三层是轨迹质量, 记录无效动作、重复动作、约束违反、事实状态与内部认知的分歧. 第四层是恢复, 记录错误首次出现的位置、发现延迟、回滚范围和恢复后能否继续推进.

横向比较还要控制任务口径. 同一系统至少要按依赖深度、状态规模、验证延迟和环境可变性分桶. 只给混合平均分, 会让大量简单短依赖样本掩盖少量真正困难的长依赖任务. 更有解释力的结果是一条性能曲线: horizon 增大时, 成功率在哪一段开始下降; 下降来自忘记约束、计划失效、工具错误, 还是验证没有及时触发.

评测器本身也是系统的一部分. 最终产物可以编译、执行或精确比对时, 应优先使用环境检查. 自然语言要求无法完全程序化时, 可以组合规则、局部人工标注与模型判定, 但必须保留判定依据. 如果只让另一个模型通读整条轨迹并给印象分, 长轨迹里的关键错误同样可能被它遗漏.

2.1. 两篇子文怎样展开

本章随后分成两篇. **1.1「严格定义」**处理状态边界、目标版本、动作依赖、环境变化和可恢复性, 给出能够在不同 Agent 系统之间复用的 Long-Horizon 任务描述. 判断重点落在系统需要跨越哪些依赖、保存哪些状态、接受多晚的反馈, 而非表面时长.

1.2「评测协议」会把定义变成实验设计: 怎样构造长度分桶, 怎样防止用无关步骤填充轨迹, 怎样记录进度与约束违反, 怎样测量恢复成本, 以及如何同时报告终态指标和过程指标. 两篇合在一起以后, 后续讨论记忆、规划、checkpoint 或训练环境时才有共同参照. 否则每篇论文都说自己支持「更长任务」, 实际测量的却可能是完全不同的能力.

本章的作用就是建立这个参照系. Long-Horizon 不由最大 token 数、运行小时数或工具次数中的任何一个数字单独定义. 它最终落在一条可验证的状态链上: 目标有没有持续生效, 事实有没有及时更新, 计划有没有随证据修订, 错误能否在污染更多后继之前被发现, 系统又能否从可信位置恢复. 后面的系统设计都要回到这条状态链接受检验.

3. 状态一致性怎样计算

真实任务中命题的重要性不同。可以为每条 $f$ 设错误成本 $w_f$ ，对安全、权限和不可逆操作使用更高权重。加权缺失率写为

M_t=\frac{\sum_{f\in F_t\setminus\widehat F_t}w_f} {\sum_{f\in F_t}w_f}.

一个系统可能记住九成普通细节，却丢掉「不允许删除生产数据」这条核心约束，未加权平均会给出过于乐观的结论。硬约束还可以直接设为门槛，任一条违反就判定该轨迹失败，不让其他软指标抵消。

版本错误与内容错误也要分开。系统记得「使用 Python 3.11」，但用户后来改成 3.12，旧命题在历史上正确、当前却已过期。评测应检查系统是否用最新生效版本，能否保留变更原因，以及旧计划是否在目标更新后被正确失效。只问「上下文里有没有出现这句话」，无法测量版本选择。

4. 一条轨迹怎样被分成进度、浪费与恢复

设任务有一组可验证子目标 $g_1,\ldots,g_m$ ，每个权重为 $u_j$ 。在时刻 $t$ ，只有已经由环境检查通过的子目标才进入进度：

P_t=\frac{\sum_j u_j\mathbf 1\{g_j\text{ 已验证}}} {\sum_j u_j}.

模型自报完成、文件已创建却未检查、测试曾经通过但后续改动已使其失效，都不应继续计入当前 $P_t$ 。这要求子目标的证据与产物版本绑定，否则进度只会单调上升，看不到回归。

浪费动作可分为三类：对最终产物没有因果贡献的无效工作，因未读取现有状态而重复完成的工作，以及因早期错误而必须撤销的工作。三者对系统设计的含义不同：第一类指向计划与搜索，第二类指向记忆和状态检索，第三类指向验证频率与恢复点。把它们只合成「工具调用多了多少」，很难知道应该修哪一层。

恢复效率不只是回滚时间。系统要先发现错误，再找到最早被污染状态，选择一个可信 checkpoint，收尾阶段重做必要分支。设这四段成本为 $c_d,c_l,c_r,c_w$ ，总恢复成本为它们之和。一个高频保存 checkpoint 的系统可能降低 $c_w$ ，却提高正常运行的存储与一致性成本。合理频率取决于错误率、恢复价值和保存成本，不存在通用的每几步一次。

4.1. 反例比平均轨迹更能检验定义

第一类反例是「很长但无依赖」。让 Agent 搜集一百个相互独立的条目，每个条目有独立验证。这个任务能测吞吐、去重和进度记录，对深依赖计划的证据很弱。若某方法只在这类任务上受益，更准确的结论是它提高了大量独立任务的管理能力。

第二类是「很短但不可逆」。只有五个动作，其中第一步一旦选错就会删除唯一数据，收尾阶段才能验收。动作数很小，对权限、预演、快照与延迟验证的要求很高。它说明 Long-Horizon 难度不一定随轨迹 token 单调增长，错误成本和可逆性是独立维度。

第三类是「环境不变，目标改变」。任务进行一半时，用户用新要求替换一条旧约束。文件和工具都没有变，原计划却已经过期。评测要看系统能否识别「替换」与「追加」，能否标记受影响的产物，以及未受影响的已验证工作能否保留。这类反例直接检验目标版本，不会被更长上下文自动解决。

第四类是「内部认知与环境事实分叉」。工具返回超时，Agent 却根据预期结果写下「部署成功」；或者文件在写入后被外部进程改动，上下文仍保留旧摘要。只检查 Agent 收尾阶段说了什么会把这类轨迹误判为成功。必须重新读取环境、验证产物并对比 $B_t$ 与 $E_t$ ，才能测到真正状态一致性。

4.2. 用生存曲线代替一个混合总分

将任务按依赖深度 $h$ 分桶，定义 $S(h)$ 为系统在深度至少为 $h$ 的任务上仍能满足全部硬约束的概率。这条曲线会显示能力在哪个 horizon 附近迅速下降，也能区分「所有难度都小幅改善」与「只把失败拐点向后推」。任务在预算耗尽时未完成属于右删失，需要与明确违反约束、不可恢复崩溃分开记录。

曲线还应分别按验证距离、状态规模与错误可逆性分层。若一个系统在即时反馈任务上随深度增长保持稳定，遇到长延迟验证却迅速失败，瓶颈更可能在假设管理和 checkpoint，而不是基本工具使用。只报所有任务的平均成功率，会把这个故障与其他失败混在一起。

比较两个 Agent 时，每个任务使用相同初始环境、目标版本、权限和成本上限，按任务配对记录成功、进度与恢复成本。这样能看到两者在同一任务上的差异，减少任务本身难度方差。多个随机种子或环境变体则用于估计 Agent 随机决策与工具不稳定性，不应把同一条轨迹中的数百个步骤当成数百个独立样本。

原始轨迹、环境快照与验证器版本一起保留，后续才能用新指标重算同一次实验。