大家第一次用 AI Agent 的时候，可能很自然地丢给它一个具体的需求，等着它端到端地完成任务。这种期待很常见，毕竟 Agent 的产品形态本身就在暗示：它不只是回答问题，而是可以连续规划、调用工具、执行动作、检查结果，直到把任务做完。
比如，我们可能会直接把一个目标交给 Agent：帮我给这个项目加一个权限校验功能。
这句话看起来只是一个功能需求。但 AI Agent 真正执行时，需要先理解项目结构，找到接口入口，判断现有鉴权逻辑，设计改动方案，再修改代码、补充测试用例、更新文档，并检查是否影响现有的调用逻辑。
我们给出的是一个目标，但 Agent 面对的会是一条很长的执行链路。正因为如此，很多 AI Agent 在完成指定目标时，并不会在第一步就失败，而是在任务变长之后逐渐失控：前几步看起来正常，中间开始忘记先前的约束，后面基于错误中间结果继续推理，最后交付一个似模似样但不符合预期的结果。
本文解读的这篇论文讨论的就是这类问题背后的一个基础变量：horizon length。论文标题是 On Training Large Language Models for Long-Horizon Tasks: An Empirical Study of Horizon Length。它关注的不是"AI 是否足够聪明"，而是一个更工程化的问题：当 Agent 完成任务所需的连续步骤变长时，AI Agent 的训练和执行会出现什么变化，以及如何降低这种长链路（多步骤）带来的结果不稳定。
本论文的价值
如果单纯地把这篇论文概括为" AI Agent 执行的任务越长，它便越容易出错"，那确实没有太多信息量，这篇论文也没有什么解读的价值。毕竟，用过 AI Agent，或是稍微设计过系统的人，自然知道链路越长，越容易出问题。一个任务需要连续做 5 个步骤才能完成，和一个任务需要连续做 20 步，后者当然更容易失败。任务完成的步骤数越多，AI Agent 要做的决策次数也会变多，中间状态自然增加，出错机会也会随之增加。
这篇论文真正有价值的地方，不是重复这个常识，而是把"长任务更难"拆成了一个可以分析、比较和干预的变量：有效 horizon（有效决策跨度）。问题不再只是：这个任务长不长？而是：
- 这个任务是否被设计成了过长的连续决策链？
- 是否存在可验证的中间节点？
- 是否能把一串低层操作，封装成更高层的工具调用或子任务？
- 是否能把最终反馈拆成阶段反馈？
这几个问题，才是它对 AI Agent 使用和设计真正有启发的地方。
Horizon length 不是上下文长度
论文里的 horizon length，不是 context window（上下文长度）。
上下文长度描述的是模型一次能容纳多少信息；horizon length 描述的是 Agent 为完成目标，需要连续执行多少步动作或决策。
两者相关，但不能混为一谈。长上下文只能说明模型"看得更多"，不代表它就能稳定完成长链路任务。AI Agent 要完成长链路任务，还取决于连续决策是否可靠、错误会不会累积，以及失败后能否定位到具体是哪一步出了问题。
很多 Agent 系统的问题恰恰在这里：上下文能力提升了，但长任务执行能力未必同步提升。
长任务面临的问题
上面我们提到，AI Agent 的最终交付结果不如预期，可能是在很早期的某个环节发生了偏差。这篇论文从训练角度解释了这种现象。随着 horizon length 的增加，AI Agent 的任务并不只是"要做更多步"这么简单，更关键的是：Agent 需要在更长的链路里持续做对，而一旦失败，也很难定位到底错在哪里。论文把这两个核心困难概括为探索困难（exploration difficulties）和结果归因困难（credit assignment challenges）。论文引言也指出，随着 horizon 增加，状态—动作空间会快速膨胀，使得成功路径更难以探索；而延迟反馈也会让结果归因更困难，也就是更难判断最终成败应该归因于哪一步。
这种现象在训练曲线上也有所体现。
图注：展示了不同 goal distance 下的训练动态
数据显示，较短任务链路上，RL 训练相对稳定；当完成目标所需步骤增加后，训练开始出现明显不稳定，甚至发生训练崩塌。这里的 goal distance，可以理解为从初始状态到完成目标最少需要多少个步骤。论文把任务所需的步骤按 L1–L7 分层，数字越大，代表任务链路越长。训练集覆盖 L1–L4，更长的 L5–L7 则用来测试模型能否泛化到训练时没见过的长任务。
上表按 goal distance 对任务进行层级划分，方便把 horizon 从笼统的"任务复杂度"里拆出来，作为一个可以单独观察和比较的变量。
实践部分：减少有效 horizon
这篇论文最值得用来指引实践的建议，是它提出的应对原则：horizon reduction。也就是说，减少 Agent 为完成目标任务所必须连续做对的决策步数。horizon reduction 不是要把任务要求变低，而是改变任务的执行组织方式。
论文表明，只要能有效压缩 horizon，AI Agent 的训练稳定性和长任务表现都可能会带来明显提升。作者也在下图的总结中，把 horizon reduction 视为稳定 RL、提升长 horizon 泛化能力的关键思路。
在论文中，主要讨论了两种降低有效 horizon 的方法：
把低层操作封装成更高层的动作
有效降低 horizon 最直接的方法，就是把一串细碎、容易出错的低层操作，封装成更高层的动作。论文在实验中用的是宏动作（macro actions）。相比逐步执行原子动作（atomic actions），宏动作可以一次推进多个步骤，从而缩短有效 horizon。
图注：宏动作对长 horizon 任务训练的改善。它说明，减少有效 horizon 不只是让结果略微变好，而是会明显影响训练能否稳定进行。
上图显示，宏动作在不同设置下都会带来收益：在较短任务链路上，AI Agent 的训练会更快、最终表现会更高；在较长任务链路上，采用原子动作会发生训练崩塌，而宏动作仍能保持稳定的学习过程。
论文专门做了一个对照实验来说明：真正起作用的不是"宏动作的表达更强"，而是有效 horizon 确实变短了。
上图中，A 表示正常的宏动作设置：宏动作可以一次推进多个低层步骤，从而有效地压缩 horizon。B 使用同一个宏动作策略，但限制每轮只能执行一个原子动作，相当于人为地拉长 horizon。结果显示，B 虽然前期成功率上升更快，但后期会发生训练崩塌；A 则能保持相对稳定，并最终收敛到较高表现。这说明，真正有效减少 horizon 的关键不只是"是否使用宏动作策略"，而是任务的有效执行链路是否真的被缩短。也就是说，effective horizon 是训练稳定性的主要决定因素之一。
对应到用户侧，大概就是一个 Agent 做网页任务时只能逐步点击、输入、复制、粘贴，那么整个任务会暴露出很长的低层动作链。但如果系统能提供更高层的工具调用，例如"查询订单""导出报表""发送邮件"，Agent 就不必在几十个细碎动作中持续保持稳定。
论文在讨论部分也明确指出，Coding Agent 通过生成可执行程序、GUI Agent 通过引入更高层 API，本质上都可以理解为在做 horizon reduction。
把全局目标拆成可验证的子目标
另一条可行方案是子目标拆解，把一个长链路目标拆分成多个短链路子问题。
论文在 Sudoku 实验中引入了子目标引导策略（subgoal-guided policy），用中间子目标提供过程反馈，而不是只依赖最终结果带来的稀疏奖励（sparse reward）。
上图显示了子目标拆解对 RL 的影响，对应了"拆任务、设中间检查点"的思路：把最终目标拆成中间可验证的子目标，可以缓解长链任务里的反馈滞后问题。数据表明，相比稀疏奖励基线，这种策略学习过程更稳定，成功率也明显更高。
对于在使用 AI Agent 的我们来说，下次不要一次性说：帮我完成这个项目。要拆成：
- 先判断任务目标是否清楚；
- 再给出执行计划；
- 然后完成第一阶段并输出中间结果；
- 再根据检查结果进入下一阶段。
这不是为了增加操作成本，而是为了把原本只有"最后验收"的长反馈链，优化成多个可被验证的短反馈链。论文在讨论中也指出，子目标拆解的主要收益，在于把归因困难局部化，并把优化约束在更短的 effective horizons 上。
对 Agent 用户的四点启发
如果把这篇论文用于 AI Agent 实践，主要有四条原则：
第一，不要把复杂任务一次性丢给 Agent。 如果一个任务包含需求理解、方案规划、工具调用、执行、结果验证等多个环节，最好不要要求 Agent 一口气完成。更稳妥的做法，是先让它输出计划，再确认计划，再按阶段执行。
第二，每个阶段都应该有中间产物。 一个好的 Agent 任务不应该只有最终结果，还应该有可检查的中间结果。这样做不只是为了方便审阅，更是为了尽早发现偏差，防止 Agent 沿着错误链路继续执行。
第三，优先提供高层工具，而不是暴露大量低层动作。 如果希望 Agent 做数据分析，就尽量提供结构化读取、计算和校验工具；如果希望它做研发任务，就尽量提供测试、运行脚本、查看 diff 等能力。这样做是为了减少 Agent 必须连续控制的低层动作数量。
第四，不要把长上下文误认为长任务能力。 长上下文当然有价值，但它解决的是"信息能否放进来"，并不自动等于"长任务能否稳定完成"。长任务失败的原因，往往不只是信息缺失，也包括链路太长、反馈太晚和中间错误不可见。
局限性
这篇论文毕竟还是一篇训练研究，不是完整的 Agent 使用手册。它的主实验环境是 Sudoku、Rush Hour，以及一个更贴近真实交互的 WebShop。这样的设置有利于隔离 horizon length 的影响，但和真实业务场景之间仍然有距离。
真实环境中的 Agent 还会受到工具质量、数据质量、权限设计、任务定义、用户反馈等多种因素影响。
这篇论文提供了一个有用的分析框架：在 Agent 系统中，任务链路长度本身就是影响稳定性的关键变量。通过动作抽象、子目标拆分和中间反馈，可以减少有效 horizon，从而提高长任务执行的可靠性。
上图展示了 horizon reduction 在 WebShop、更大模型和不同优化器下的效果。说明"缩短有效 horizon"这一趋势不只出现在主实验设置里。
结语
这篇论文不是因为它发现了"长任务更难"这个常识，而是因为它把这个常识进一步拆成了一个可分析、可验证、也可设计的问题。
它提醒我们：Agent 的可靠性，不只取决于模型能力，也取决于任务被组织成什么样的执行链路。很多时候，问题不一定出在模型"不会"，而出在任务链太长、动作太低层、反馈太晚、中间状态又不可见。
所以，对 Agent 用户来说，最值得保留的启发并不是"换更强模型"，而是：
- 给 Agent 阶段，而不是一条没有检查点的长路；
- 给 Agent 高层工具，而不是一堆细碎动作；
- 给 Agent 中间反馈，而不是只在最后验收。
以上就是这篇 long-horizon 论文最实用的部分：让 Agent 更可靠，不只是提升模型，也包括缩短它必须连续做对的那条链。
