Long-Horizon Agents · 长任务智能体

2025 年 2 月 24 日, Anthropic 发布 Claude 3.7 Sonnet, 同时把 Claude Code 作为研究预览推出; 2025 年 7 月, Moonshot AI 发布以 agentic intelligence 为重点的 Kimi K2. 从那段时间开始, 我第一次明显觉得模型进入了「聪明, 基本可用」的阶段.

当时常见 benchmark 仍然倾向把能力压缩成一道题和一次回答: 数学题是否做对, 代码补丁是否通过测试, 一次工具调用是否成功. 这些数字继续上涨当然重要, 但也让我产生了另一个疑问: 单轮回答已经足够好以后, 模型下一阶段的能力还能从哪里提升?

Agent 给出了一部分答案. 模型开始读仓库, 调工具, 修改文件, 运行测试, 观察结果, 再决定下一步. 唐杰在谈下一阶段 AGI 能力时把「长程任务」列为关键方向, 用跨越数周、数月乃至更久的规划与执行描述它的远期尺度; 论文则需要更窄、更可测的定义. LongHorizon-Harness把问题落在持续推理、工具使用、修订与相互依赖步骤中的任务状态上, Towards Long-Horizon Agents进一步把长程能力视为模型和外部 Harness 共同形成的系统性质. Long-Horizon 研究的对象是一条持续演化、具有跨步依赖的任务状态, 不是单纯让模型输出更多 token.

这座知识库就从这个疑问开始. 现有论文分别研究任务状态管理, 上下文压缩, 用户意图变化, 外部记忆, 训练环境和 Agent harness. 它们使用的术语不同, 但都在处理同一组变量: 目标, 环境状态, 已完成动作, 验证结果和剩余计划怎样随时间更新. 把这些变量写清后, 才能比较一个系统是真的能完成长任务, 还是只在很长的轨迹里偶尔得到正确终点.

1. Long-Horizon 到底指什么

Long-Horizon 描述任务状态沿多次行动持续演化时，系统保持目标、事实与约束一致的能力。单次输出长度与时间、token、工具调用数都只能描述轨迹规模，不能单独刻画依赖深度。

一项任务是否真正具有长程难度，要看早期决策会影响多少后续动作、错误多久以后才能被发现，以及系统能否从可信状态恢复。这三个量共同决定轨迹变长后风险怎样累积。

1.1. 一条任务状态怎样持续变化

设任务在第 $t$ 步的可恢复状态为

$G_t$ 是当前目标和约束, $E_t$ 是外部环境的可观察状态, $A_{1:t}$ 是已经执行的动作, $V_t$ 是经过验证的事实与结果, $P_t$ 是剩余计划. Agent 根据当前上下文选择动作 $a_{t+1}$, 环境执行后返回观测 $o_{t+1}$, 系统再把状态更新为 $S_{t+1}$. 一项任务的 horizon 不只由动作数量决定, 还取决于早期决策会影响多远之后的状态, 以及出错后要追溯多少历史才能修复.

真正困难的地方在状态更新. 计划可能因为新证据改变, 用户可能在中途修改约束, 工具可能返回部分成功, 外部文件也可能被其他进程更新. 如果系统只保留一段自然语言摘要, 摘要遗漏的约束会永久消失; 如果保存全部轨迹, 上下文成本会持续增长, 早期噪声又会干扰后面的判断. Long-Horizon 系统必须决定哪些信息成为事实状态, 哪些只保留为审计记录, 哪些可以压缩或丢弃.

1.2. 五个容易混在一起的「长」

长输出只表示一次生成的 token 多. 模型可以连续写一万字, 却没有与环境交互, 也没有更新任务状态. 长上下文表示模型一次能够读取更多 token, 它扩大可见范围, 但不能保证模型会正确找到旧约束或识别状态冲突. 长时间运行是墙钟时间长, 一个等待下载两小时的脚本并不比五分钟内执行一百次有依赖操作的任务更难.

多工具调用说明轨迹中动作较多, 仍不能单独定义 Long-Horizon. 五十次互不相关的搜索可以并行完成, 每一步的错误不会影响下一步; 十步数据库迁移却可能具有严格依赖, 第一步选错 schema 会让后面全部无效. 多步骤任务只有在步骤之间共享状态, 早期结果会改变后续选择, 并且最终成功依赖中间约束持续成立时, 才出现本库关心的长程难度.

因此本库用五项性质识别 Long-Horizon 任务: 跨步依赖, 状态变化, 延迟验证, 错误传播和故障恢复. 任务至少应包含其中多项, 并在评测中真正测到它们. 只报告平均 token 数或工具调用数, 不能说明系统具备长程能力.

可以把这条判断压缩成一个状态式:

$G_t$ 是目标版本, $C_t$ 是持续约束, $E_t$ 是外部环境事实, $B_t$ 是系统当前相信的内容, $P_t$ 是剩余计划, $V_t$ 是经过验证的结果, $K_t$ 是可恢复点. 这里最重要的区分是 $B_t\ne E_t$: 模型说「已经改好」只是内部判断, 文件、测试与服务状态才是环境事实. 只有证据把两者对齐后, 结果才能进入 $V_t$.

2. 能力由哪些部分组成

长程执行依赖计划、状态、记忆、验证和恢复共同工作。模型负责提出动作，Harness 负责保存权威状态、约束副作用并把环境反馈提交为可验证事实。

这些组件需要按职责分开评测。更大的上下文可能改善信息可见性，却不能替代状态版本、外部存储和 checkpoint；更多 Agent 也不能自动解决冲突与证据合并。

2.1. 计划, 执行与验证

长任务需要计划, 但一次生成的完整计划很快会过期. 更可靠的做法是保留稳定目标, 只细化当前可以执行的一小段, 每次获得新证据后重算剩余计划. LongHorizon-Harness把管理者, 执行者和审计者分开: 执行者产生原始轨迹, 审计者把可验证结果写入任务状态, 管理者根据审计后的状态规划下一轮. 角色数量并不关键, 关键约束是只有经过外部验证的结果才能进入下一轮事实状态.

代码作为 Agent Harness讨论另一种组织方式: 用代码, 文件和运行时对象承载状态, 让控制流和中间结果不必全部塞进对话. 它适合结构明确, 可以程序化检查的任务, 代价是模型生成的控制逻辑本身也会出错, 权限和副作用必须由外层系统约束.

2.2. 记忆与上下文压缩

上下文压缩论文和 LiveMem处理上下文有限时怎样保留历史. 压缩不是单纯缩短文本. 一个摘要需要保存仍然有效的目标, 已验证事实, 未解决冲突和可恢复位置; 原始日志则用于追责和重建. 如果把结论与猜测混在同一段摘要里, 后续模型很难重新判断可信度.

记忆还涉及写入策略. 每一步都写会积累大量重复状态, 只在任务结束写又无法支持中途恢复. 系统需要定义写入触发条件, 版本和失效规则. 外部环境已经变化时, 旧记忆即使当时正确也可能不再适用; 因此读记忆时要同时检查时间, 来源和对应的环境版本.

2.3. 意图变化与环境生成

用户意图演化关注目标本身发生变化. 新要求可能补充原目标, 也可能替换它; 系统若只把新消息追加到上下文, 很容易同时执行互相冲突的两版约束. 目标状态需要显式版本化, 让每个计划和产物都能追溯到它依据的目标版本.

OpenForge RL和 Orchard进入训练侧. 长任务数据不能只靠固定问答对提供, 需要可执行环境, 中间反馈和能够判断进展的验证器. 环境生成扩大任务规模, 同时带来答案泄漏, 不可复现和判定器错误. 训练系统必须记录环境版本, 初始状态, 动作和验证结果, 否则一条成功轨迹无法成为可靠训练样本.

3. 怎样评测长程能力

终点成功率仍是主指标，但它无法定位失败发生在哪一段。轨迹评测还要记录有效进度、约束违反、错误检测延迟、回滚范围、恢复成本和外部副作用。

公平比较需要固定任务版本、初始环境、权限和预算，并保留逐任务结果。按依赖深度与验证距离分层后，才能区分系统是在全部难度上改善，还是仅延后了崩溃位置。

3.1. 最终成功率之外的轨迹指标

终局成功率会把两种轨迹记成同一个结果: 一条稳定推进后在收尾阶段失败, 另一条长期偏离目标却偶然得到正确答案. 长任务评测还应记录有效进度, 约束违反, 无效动作, 回滚次数, 错误首次出现的位置和恢复成本. 这些量由环境状态或可执行检查计算;模型阅读轨迹后的主观评分只能作为补充信号.

任务长度也要按有效依赖计算. 人为插入无关步骤可以增加轨迹长度, 却没有增加状态管理难度. 更有价值的分桶方式是依赖深度, 状态规模, 延迟验证距离和可逆性. METR 的 time horizon用专业人员完成任务所需时间标定任务尺度, 这是直观且有价值的能力曲线; METR 同时明确提醒, 它不是 Agent 实际自主运行时间. 本库把人类时长视为一种任务难度代理量, 再与依赖和恢复指标并列使用.

3.2. 四章怎样接起来

第 1 章先把 Long-Horizon 写成可测量的任务结构，再建立最终结果、有效进度、约束、恢复和成本口径。第 2 章处理目标版本、工作记忆、长期存储、上下文压缩和 checkpoint。第 3 章进入任务分解、滚动计划、工具交互、验证闭环与 Harness。第 4 章讨论如何构造可执行环境、生成轨迹、设计验证器并把这些材料用于训练和 benchmark。

读完整库后, 面对一个新的 Agent 系统, 应能具体检查: 目标保存在哪里, 环境状态从哪里读取, 已完成动作怎样验证, 上下文被压缩后什么信息永久丢失, 故障后从哪个 checkpoint 恢复, 评测是否真的覆盖跨步依赖. 这些问题比「能连续运行多久」更接近 Long-Horizon 能力本身.

4. 资料与结论的适用边界

定义、状态、执行和训练形成连续依赖. 第 1 章给出的有效动作、依赖深度、验证距离与恢复代价, 是后面判断记忆或计划机制是否改善 Long-Horizon 能力的共同量尺. 第 2 章确定哪些状态能够跨步保存, 第 3 章把这些状态接入计划、工具调用和验证, 第 4 章再把可执行环境中的轨迹变成训练与评测材料. 缺少前一层约束时, 「支持更长任务」往往只表示上下文更长或运行时间更久, 无法说明跨步依赖是否真的得到处理.

论文与项目仓库中的实验数字对应具体模型、Harness、任务集和预算. 脱离这些条件, 一个总分无法说明系统能否持续推进任务. 更有用的描述会指出状态发生了什么变化、证据保存在哪里、依赖怎样传播, 以及失败恢复需要多少时间和计算资源. 这些问题共同构成长任务系统的检查框架.

4.1. 把「长」写成可测量的结构

一条任务可以表示为带有先后约束的动作图 $\mathcal G=(\mathcal A,\mathcal E)$。节点是必须完成或验证的动作，边 $a_i\rightarrow a_j$ 表示 $a_j$ 依赖 $a_i$ 的产物或决策。最长路径给出依赖深度，图宽度描述可并行的工作，一个早期节点能到达的后续节点数则近似它的错误传播面。动作数相同的两个任务，若一个可以并行、另一个形成严格长链，它们的 Long-Horizon 难度显然不同。

状态规模是另一条轴。设第 $t$ 步仍然有效的独立约束数为 $m_t$，每条约束有来源、版本、适用对象和验证状态。单纯把它们压缩成一段话，无法知道哪条被遗漏或相互冲突。可以把约束保真率定义为当前状态中可正确恢复的有效约束比例，再按错误成本加权。一条「不可删数据」的安全约束，不应与一条可重新生成的格式偏好等权。

验证距离描述一个错误要经过多少个后续动作才会被发现。每步都有类型检查或测试的任务，错误可以早停；只在收尾阶段一次交付验收的任务，早期错误可能带着大量后续无效工作。若错误首次出现于 $i$，到 $j$ 才检出，$j-i$ 是一个最简单的延迟验证量；其间消耗的 token、工具时间和外部副作用给出更真实的代价。

4.2. 恢复能力比「一次不犯错」更容易验收

长链上每步都有失败概率。即使简化为每步独立、成功率都为 $p$，$H$ 步全部一次通过的概率也是 $p^H$。$p=0.98$ 在单步看起来很高，$H=100$ 时全链成功概率只约为 $0.133$。真实步骤并不独立，已污染的状态还会让后续失败更相关。所以长任务系统必须允许检测、定位、回滚和重试，靠单步正确率堆出绝对不犯错不现实。

一次恢复可以拆成四个时间：错误发生到被监测发现，发现到定位首个错误状态，定位到选定恢复点，以及恢复后重做有效工作。一个 checkpoint 若只保存对话文本，却没有文件、数据库、服务与工具版本，它只能恢复模型叙事，不能恢复真实任务。反过来，只保存环境快照而不保留目标版本与已验证理由，系统会在回滚后重复旧决策。

恢复测试应主动注入故障。在任务不同深度随机中断，删除一个中间产物，让工具返回部分成功，或在用户更改约束后恢复旧 checkpoint。验收不只看收尾阶段能否完成，还要看系统是否识别快照过期、阻止不可逆动作重放，并将已验证的无关分支保留下来。一遇错就从头重来可能成功，恢复成本会随 horizon 线性甚至更快增长。

4.3. 模型能力与 Harness 能力怎样分开

一个 Harness 可以通过更好的搜索、状态库、测试、重试和权限提高任务成功率。这不是对模型能力的造假，因为 Long-Horizon Agent 本来就是系统；但比较模型时必须固定 Harness，比较 Harness 时则要固定模型与预算。同时更换两者，成品对比只能说明整体系统谁更强。

更严格的实验可以使用二乘二交叉：基线模型与新模型，分别搭配基线 Harness 与新 Harness。模型主效应表示在共同系统支持下的平均差异，Harness 主效应表示对两个模型的平均改善，交互项则表示新 Harness 是否只与某个模型配合。若状态压缩只对强模型有效，原因可能是弱模型无法从高密度摘要恢复约束；一个平均总分看不到这种交互。

预算也要同时固定。新 Harness 可能调用更多模型轮次、更大搜索结果或更昂贵的验证器。报告任务成功率时，还应给出模型 token、工具调用、外部计算、墙钟时间与人工介入。然后才能比较等成本下的成功率，或等成功率下的成本。「能够完成」与「能在可接受成本内稳定完成」是长任务评测中的两层结论。