博客

1. 摘要（Abstract）

本文研究的是长程交互环境中大模型智能体的决策稳定性问题。现有 LLM-based agents 已经具备较强的上下文理解和推理能力，但在多轮交互任务中仍然容易出现目标漂移。也就是说，模型一开始能够理解任务目标，但随着交互轮次增加，计划和动作会逐渐偏离原始意图，最终导致无效动作、循环行为或任务失败。针对这一问题，论文提出了 Multi²，一个层级化多智能体决策框架，用于提升智能体在长程交互环境中的稳定性、鲁棒性和 token 使用效率。

Multi² 的核心思想是将智能体行为拆分为两个互补角色。高层智能体 System 1 负责根据任务目标和环境观察生成上下文相关的子目标，主要承担规划功能。低层智能体 System 2 负责根据当前子目标执行具体原子动作，主要承担环境交互与动作控制功能。System 1 使用监督微调训练，以保证子目标生成的稳定性和一致性；System 2 则采用 offline-to-online reinforcement learning，使执行策略先从离线数据中稳定初始化，再通过在线交互持续改进。

实验结果表明，Multi² 在 ScienceWorld、ALFWorld 和 TextCraft 等多个交互环境中整体优于 ReAct、Reflexion、ADaPT、GRPO 和 Glider 等强基线方法。相比只依赖 prompting 或普通层级规划的方法，Multi² 不仅任务完成率更高，而且在长 horizon、任务难度增加和 OOD 分布下表现更稳。论文还发布了三个层级化 benchmark datasets，用于训练和评估 LLM 智能体的层级决策能力，弥补了该方向数据资源不足的问题。

2. 研究背景与问题动机（Introduction）

构建能够在动态环境中持续交互、规划和行动的智能体，是当前 agentic AI 的重要目标。与一次性问答不同，交互环境中的智能体每执行一个动作，环境状态都会发生变化，后续决策必须基于新的观察继续进行。因此，这类任务天然具有多轮、长程和闭环反馈的特点，对智能体的目标保持能力和执行稳定性提出了更高要求。

目前很多 LLM agent 在短任务中表现不错，但在长程任务中仍然脆弱。一个典型问题是 objective drift，即智能体在多轮交互过程中逐渐偏离原始目标。论文指出，这并不只是单纯的规划失败，而是一个交互层面的累积误差问题。前面某一步的小错误可能导致状态偏移，后续模型又基于错误状态继续推理，最终使整个轨迹越走越偏。

已有方法通常从两个方向尝试解决这个问题。一类方法如 ReAct 和 Reflexion 依赖 prompt 和长历史上下文，让模型通过推理和自我反思维持目标。但这类方法 token 消耗较大，且长历史本身并不能保证动作执行正确。另一类方法采用层级规划，例如 ADaPT 和 Glider，将复杂任务拆成子目标，从而降低规划难度。不过，论文认为仅有任务分解还不够，因为执行器如果没有经过专门训练，仍然无法有效修正长程交互中的累积错误。

因此，本文真正抓住的问题是，长程交互不是只需要更好的 planning，也需要更稳的 execution。一个可靠的 LLM agent 应该同时具备三点能力。首先是明确的任务分解，用来维持全局意图。其次是能够通过环境反馈不断改善的动作执行能力。最后是较高的 token efficiency，避免每一步都依赖越来越长的上下文。Multi² 正是围绕这三个需求设计的。

3. 框架与整体设计（System Overview）

Multi² 采用层级化多智能体结构，将原本由单个 agent 完成的长期决策任务拆解为两个角色分工明确的子系统。System 1 是高层规划器，输入任务描述和当前观察，输出下一阶段需要完成的子目标。System 2 是低层执行器，输入当前观察和 System 1 生成的子目标，输出具体的环境动作。当当前子目标完成或终止后，系统会再次调用 System 1 生成新的子目标，如此循环直到任务结束。

这种设计的关键不只是把任务拆成上下两层，而是让两个层级分别对应不同的学习目标。System 1 负责语义层面的任务理解和子目标规划，因此更适合用 SFT 学习稳定、结构化的子目标生成。System 2 直接与环境交互，需要处理状态变化、动作约束和执行错误，因此更适合用强化学习提升动作层面的鲁棒性。

论文将整个流程分为三个阶段。第一是 offline training，分别训练 System 1 和 System 2。第二是 online training，让 System 2 在环境交互中继续自我改进。第三是 execution，推理时 System 1 按需生成子目标，System 2 在每个子目标下连续执行原子动作。这样的选择性调用机制也减少了不必要的长上下文推理，因此能提升 token efficiency。

相比 Glider 这类已有层级方法，Multi² 的差异在于它更强调 role specialization。Glider 虽然也有 planner 和 controller，但在在线适应时主要更新高层规划器，低层执行器相对固定，而且不同角色之间的参数隔离不够充分。Multi² 则让 System 1 和 System 2 使用独立 LoRA adapter，并针对各自角色采用不同训练方式，从而避免规划和执行职责混在一起。

4. 数据集构造与训练方法（Method）

为了支持层级化训练，论文首先构造了两个角色专用数据集。System 1 的数据集由任务描述、观察和子目标组成，主要用于训练高层规划器学会在不同环境状态下生成合理子目标。System 2 的数据集则围绕每个子目标展开，包含观察、动作、奖励和下一步观察，用于训练低层执行器在给定子目标下选择具体动作。这样的数据划分使两个系统的训练目标更加清晰，也避免了单一数据格式同时承担规划和执行两类任务。

System 1 的训练相对直接，作者使用 SFT 对高层规划器进行行为克隆，使其模仿专家轨迹中的子目标生成过程。这样做的原因是，高层规划更偏语义理解和任务分解，目标是保持计划结构稳定，而不是通过环境探索不断试错。因此，SFT 在这里更合适，也更容易保证生成子目标的一致性。

System 2 的训练更复杂。由于低层执行器直接面对动态环境，单纯模仿离线轨迹容易过拟合，也难以处理环境变化带来的状态偏移。因此，作者使用 actor critic 形式的 offline RL 初始化 System 2。critic 学习动作价值和状态价值，actor 则结合 advantage 信息更新策略，使模型不仅模仿离线数据中的动作，也倾向于选择估计回报更高的动作。论文还加入 policy anchored advantage term，用来减轻过度模仿，提高策略在离线轨迹之外的迁移能力。

在 online training 阶段，System 2 从离线训练得到的策略出发，继续与环境交互，并把新轨迹加入 replay buffer。在线更新中，作者引入 KL regularization，使新策略不会过度偏离离线策略。这样既允许 System 2 通过在线交互修正执行错误，又避免策略更新过猛导致崩溃或 mode collapse。整体来看，这套 offline-to-online RL 设计的重点不是单纯追求更强优化，而是让低层执行器在长程交互中更稳定地自我改进。

5. 实验设置（Experimental Setup）

论文在三个交互环境上评估 Multi²，分别是 ScienceWorld、ALFWorld 和 TextCraft。ScienceWorld 更强调科学任务中的长程规划和状态变化，ALFWorld 更偏家庭场景中的物体操作和稀疏奖励，TextCraft 则关注符号化 crafting 任务中的组合依赖和目标保持。这三个环境共同覆盖了不同类型的长程交互场景，因此比较适合检验智能体是否真的具备稳定的多轮决策能力。

模型方面，作者使用 Qwen 2.5 3B、Mistral 7B v0.3 和 Llama 3.1 8B 作为 backbone，并通过 LoRA 进行参数高效微调。System 1 和 System 2 共享同一个预训练 backbone，但使用不同的 LoRA adapter。在训练和推理时，只激活当前系统对应的 adapter。这个设计既节省训练成本，又能保证规划器和执行器具备一定参数隔离。

评价指标采用严格的 pass@1，即每个任务只允许一次 rollout，不进行多次重试或采样。这一点比较重要，因为它更能反映 agent 的一次性任务完成能力，而不是依靠多次尝试碰运气。论文还区分 ID 和 OOD splits，ID 任务和训练集共享任务模板或交互模式，但具体环境实例仍不同；OOD 任务则使用新的任务模板，更能考察泛化能力。

对比方法包括 prompt-based 和 fine-tuning-based 两大类。prompt-based 方法包括 ReAct、Reflexion 和 ADaPT，fine-tuning-based 方法包括 GRPO 和 Glider。这样的基线设置比较完整，既覆盖了非层级方法，也覆盖了已有层级方法，还能区分 prompt 方案和参数更新方案之间的差异。

6. 实验结果与性能分析（Experiments）

主实验结果显示，Multi² 在大多数设置下取得最佳表现。以 Qwen 2.5 3B 为例，Multi² 在 ScienceWorld ID 上达到 60.68，在 ScienceWorld OOD 上达到 29.04，在 ALFWorld ID 和 OOD 上分别达到 61.43 和 49.29，在 TextCraft 上达到 28.50。以 Mistral 7B 为例，Multi² 在 ScienceWorld ID 上达到 69.97，在 TextCraft 上达到 44.50，也明显超过多数基线。以 Llama 3.1 8B 为例，Multi² 在 ALFWorld ID 和 OOD 上分别达到 57.86 和 56.43，在 TextCraft 上达到 35.60。整体来看，Multi² 对不同模型规模和不同环境都具有较强适用性。

从方法类别看，prompt-based 方法整体表现较弱，尤其在长程任务中容易出现错误累积。ADaPT 由于引入层级 prompting，在部分任务上比 ReAct 和 Reflexion 更好，说明任务分解本身确实有价值。GRPO 作为单 agent RL 方法在一些场景中效果有限，说明简单强化学习并不能自然解决长程目标保持问题。Glider 作为层级微调基线表现明显更强，但仍然不如 Multi²，这说明层级结构之外，角色专用训练和低层执行器的在线自我改进同样重要。

论文还给出了定性错误分析。Figure 3 展示了 ScienceWorld 中 Find a plant 任务的典型失败案例。ReAct、Reflexion 和 ADaPT 等方法容易产生被环境拒绝的非法动作，或者陷入重复执行但没有进展的循环。GRPO 和 Glider 虽然经过训练，但也可能持续朝着不合理目标执行。相比之下，Multi² 能通过明确子目标约束执行方向，同时利用 RL fine tuning 提高动作有效性，因此更少出现目标漂移和无效循环。

token efficiency 方面，Figure 4 显示 Multi² 在 ScienceWorld ID split 上用更少 token 获得更高性能。其原因在于层级框架并不需要每一步都把完整历史和复杂提示塞给同一个 agent，而是按需调用 System 1 生成子目标，再由 System 2 执行具体动作。这样既减少长 prompt 依赖，也让低层动作输出更稳定。

在 objective drift robustness 分析中，Figure 5 按任务难度展示了不同方法的性能。随着任务从 easy 到 hard，prompt-based 方法退化明显，fine-tuning-based 方法虽然更强，但在 hard 任务上仍有下降。Multi² 在困难任务上优势更明显，说明它对长 horizon 和持续目标跟踪更鲁棒。这也是全文很重要的实验支撑，因为它直接回应了论文开头提出的 objective drift 问题。

消融实验进一步说明各模块都有必要。Figure 6 显示，System 1 用 SFT、System 2 用 RL 的角色匹配方式表现最好。如果交换训练方式，让 System 1 用 RL、System 2 用 SFT，效果最差，说明规划和执行不能随便套用同一种训练范式。Figure 6 还显示，层级结构优于单模型结构，role-specific adapter 优于 shared adapter。Figure 7 则说明，policy anchored offline objective 和 KL regularized online objective 都有助于提高稳定性。

最后，Figure 8 和 Figure 9 分别分析了模型规模和在线适应效果。Figure 8 显示，在 ID split 上不同 Qwen 规模差异不大，但在 OOD split 上模型越大表现越好，说明更大 backbone 对分布外泛化更有帮助。Figure 9 显示，online RL 能进一步提升执行可靠性，尤其在 OOD split 上收益更明显，说明在线交互确实能够帮助 System 2 修正离线训练中无法覆盖的执行错误。

7. 贡献与结论（Contributions and Conclusion）

本文的主要贡献可以概括为四点。

第一，提出 Multi² 层级化多智能体框架，将长程交互任务中的 planning 和 execution 分别建模为不同优化问题。System 1 负责生成上下文相关子目标，System 2 负责在动态环境中执行原子动作，从结构上缓解目标漂移。

第二，设计了 role-specialized training pipeline。System 1 使用 SFT 保持高层规划稳定，System 2 使用 offline-to-online RL 提升动作执行鲁棒性。这种训练分工与两个系统的功能定位一致，比简单用一个 agent 或一个共享 adapter 更合理。

第三，提出面向 System 2 的 offline-to-online RL 目标，在离线阶段通过 critic guided policy anchoring 减轻过度模仿，在在线阶段通过 KL regularization 避免策略更新不稳，从而实现更安全的自我改进。

第四，论文发布了面向层级智能体训练与评估的数据集，并在 ScienceWorld、ALFWorld 和 TextCraft 上验证了 Multi² 在性能、token efficiency 和长程鲁棒性上的优势。

整体来看，这篇论文真正有价值的地方在于，它没有把长程交互失败简单归因于模型能力不够，而是把问题拆成了规划漂移、执行误差累积和 token 效率低三个层面。Multi² 的设计也对应这三个层面分别处理，用 System 1 保持目标，用 System 2 稳定执行，用按需调用降低 token 消耗。它的研究问题比较清楚，实验闭环也较完整，适合作为 LLM agent 长程决策方向的一篇阅读论文。

1. 摘要（Abstract）

本文研究的是面向终端环境的智能体训练数据构建问题。随着大模型智能体逐渐进入代码开发、系统运维、自动调试等真实任务，仅依赖静态文本数据已经难以训练出可靠的执行能力。终端任务的难点在于，模型不仅要理解指令，还要能在真实环境中执行命令、观察反馈、修复错误，并最终完成可验证的系统状态变化。因此，高质量的 terminal trajectories 对训练 agentic models 非常关键。

现有数据构建方法主要存在两个瓶颈。第一是执行性问题，每个任务往往需要对应的依赖、文件系统状态和运行环境，缺少可运行环境的轨迹很难反映真实终端操作。第二是可验证性问题，不同任务的输出形式差异很大，不能简单用统一文本答案判断是否完成。现有方法要么能扩展任务多样性但缺少真实执行 grounding，要么提供可执行环境但规模有限，难以支撑大规模 agent 训练。

针对这一问题，论文提出 TerminalTraj Pipeline，用于从真实 GitHub 仓库中自动构建 Docker 化执行环境、生成与环境对齐的终端任务，并通过可执行验证代码筛选成功轨迹。该流程首先利用模型评分筛选高质量仓库，再构建 Docker images，随后根据仓库中的 Markdown、Shell、代码文件和领域上下文生成任务实例，最后让 agent 在 Docker 环境中多轮交互，并用 pytest 等实例级验证代码确认任务是否真正完成。

最终，TerminalTraj 从 899,741 个 GitHub 仓库中构建出 32,325 个 Docker images，并生成 50,733 条 verified terminal trajectories，覆盖八种编程语言和八类专门领域。基于这些轨迹微调 Qwen2.5-Coder 系列模型后，模型在 TerminalBench 上取得明显提升，其中 TerminalTraj-32B 在 TB 1.0 上达到 35.30%，在 TB 2.0 上达到 22.00%，成为 100B 参数以下表现较强的 terminal agent 模型之一。更重要的是，该数据还能改善模型的 test-time scaling，TerminalTraj-32B 在 pass@16 下达到 63.75%。

这篇论文的核心价值不只是提出一个新数据集，而是系统性回答了 terminal agent 训练中的一个基础问题，即如何大规模构建既能真实执行、又能可靠验证的长轨迹数据。它把 agent 数据构建从普通文本合成推进到执行环境驱动的数据工程，对后续代码智能体、系统智能体和自动化工作流训练都有较强参考意义。

2. 研究背景与问题动机（Introduction）

近年来，AI agents 已经在代码修复、软件工程、工具调用和多轮推理任务中展现出较强能力，但许多评测和训练场景仍然简化了真实执行约束。真实终端任务并不是单纯回答问题，而是要求模型在命令行中读取文件、安装依赖、运行程序、处理错误输出，并根据环境反馈持续调整行动。TerminalBench 正是为了评估这种真实终端能力而提出的 benchmark。

要提升 terminal agent 的能力，关键不只是设计更好的 agent scaffold，也不只是换更大的 base model，而是需要大量高质量的训练轨迹。这类轨迹必须包含完整的 long-horizon interaction，例如模型如何观察环境、选择命令、解释 stdout 和 stderr、修正失败步骤，并最终完成任务。相比普通代码补全或问答数据，terminal trajectory 更接近真实人类开发和系统操作过程，因此训练价值更高。

但这类数据很难大规模构建。首先，每个任务都需要一个能够运行的环境。代码仓库里的文件本身并不等于可执行环境，缺少依赖、配置或 Dockerfile 时，agent 的操作就无法真实落地。其次，终端任务的答案并不一定是一个固定文本，很多任务的成功表现为文件被正确修改、服务被启动、配置生效或输出结果满足条件。因此，仅靠 LLM judge 或人工规则很难稳定判断任务是否真正完成。

已有工作在这两个方面各有不足。Nex-N1 等方法可以生成较多任务和交互轨迹，但验证过程更依赖规则或 LLM judge，与真实执行环境结合不够紧密。SWE-bench 风格的数据集提供了更真实的仓库级执行环境，但环境数量和任务覆盖又比较有限。TerminalTraj 的动机正是解决这个矛盾，即在保持执行真实性和可验证性的同时，把环境和轨迹构建扩展到更大规模。

3. 系统框架与整体设计（TerminalTraj Pipeline）

TerminalTraj Pipeline 的整体流程可以分为三个部分。第一部分是数据源收集，作者从 GitHub 中收集八种主流编程语言相关的仓库，并补充文档、视频、图像、数据文件和网页服务等外部上下文。第二部分是 Docker image curation，系统通过模型评分筛选高质量仓库，并从仓库中提取或构建可运行的 Docker 环境。第三部分是 instance generation 和 trajectory verification，系统根据环境生成任务 query 和验证代码，再让 agent 在终端环境中执行任务，最后通过代码验证筛选成功轨迹。

这个 pipeline 的关键思想是把真实开源仓库转化为可交互、可验证的 agent 训练环境。传统数据合成往往从任务描述出发，让大模型凭空生成问题和答案。TerminalTraj 则反过来，从可运行仓库和 Docker 环境出发，再生成与环境强绑定的任务。这种方式可以避免任务与环境脱节，使生成的问题必须依赖具体文件、依赖关系、命令工具和运行状态来解决。

在数据源层面，作者并不只收集代码文件，而是有意识地保留与执行相关的信息，例如 Dockerfile、Shell 脚本、Markdown 文档和构建配置。对于领域任务，系统还额外引入外部上下文，例如 Hugging Face 数据、Linux 文档、图像、视频和网页链接等，使任务不局限于普通代码执行，而是覆盖数据处理、多模态、SQL、安全、QEMU、模型训练与评估、环境交互和 Web service 等不同场景。

从整体设计看，TerminalTraj 的重点不是单纯扩大轨迹数量，而是把环境、任务、执行和验证四个环节串起来。每条最终保留下来的轨迹，都必须来自一个实际 Docker 环境，并通过对应验证代码确认成功。这使得数据本身更接近真实 terminal workflow，也更适合训练模型的实际操作能力。

4. 核心方法（Docker 环境构建与任务生成）

TerminalTraj 的第一项关键技术是 model-based repository scoring。原始 GitHub 仓库质量差异很大，很多仓库缺少完整依赖、构建配置或可执行入口。如果直接尝试构建 Docker image，会浪费大量计算资源。作者因此训练了一个 ScoreModel，根据代码文件的完整性和可执行性给每个文件打分，再汇总成仓库质量分数。低于阈值的仓库会被丢弃，从而提高后续 Docker 构建成功率。

这一设计解决的是环境稀缺问题。过去一些方法依赖 stars、commits 等启发式指标筛选仓库，但这些指标不一定代表仓库适合构建可执行环境。TerminalTraj 改为直接预测仓库的执行质量，使筛选目标和最终任务构建目标更一致。实验也显示，高分仓库不仅 Docker build 成功率更高，生成出来的任务质量也更好。

第二项关键技术是 Docker-aligned instance generation。系统不是随意生成任务，而是读取同一仓库中的 Markdown、Shell 和代码文件，让大模型反向推断什么样的用户需求会需要执行这些脚本或代码片段。这样生成的 query 与仓库环境天然对齐，agent 需要真正进入 Docker 环境中执行命令，才能完成任务。

第三项关键技术是 executable validation code。与固定答案或 LLM 打分不同，TerminalTraj 为每个任务生成可执行验证逻辑，通常以 pytest suite 的形式出现。验证代码会检查最终环境状态，例如文件是否生成、配置是否正确、程序输出是否满足要求，而不是检查 agent 是否使用了某条固定命令。这种 state-based verification 更适合终端任务，因为真实任务通常允许多种解决路径，只要最终状态正确即可。

在轨迹生成阶段，作者使用 Qwen3-Coder-480B 进行 trajectory rolling。agent 通过标准终端接口观察 stdout 和 stderr，执行命令，处理错误，并多轮修正计划。每个 query 会采样多次以增加轨迹多样性。只有最终通过验证代码的轨迹才会保留，因此数据质量主要由真实执行结果把关，而不是由模型自评决定。

5. 数据集规模与质量分析（Dataset Analysis）

TerminalTraj 的数据规模比较大。作者一共爬取 899,741 个 GitHub 仓库，覆盖 Go、C++、C、HTML、Java、JavaScript、PHP 和 Python 八种编程语言。经过质量筛选后，得到 196,051 个高质量仓库，并最终构建出 32,325 个 Docker images。随后，系统生成 1,030,695 个任务实例，并通过 agent 执行和验证筛选出 50,733 条 verified trajectories。

从数据漏斗看，最终 verified trajectory rate 只有约 4.92%。这个比例看起来不高，但恰恰说明筛选标准比较严格。大量任务虽然可以生成，但 agent 未必能完成，或者最终状态不能通过验证代码。作者保留的并不是所有生成轨迹，而是真正在执行环境中完成任务的轨迹。因此，这个数据集的特点不是宽松收集，而是高精度过滤。

作者还分析了 Docker image curation 的效率。随机选择带 Dockerfile 的仓库时，Docker build 成功率约为 9%。如果选择仓库分数高于 0.5 的样本，成功率提升到 19.5%，接近翻倍。论文实际采用更宽松的 0.2 阈值以保留语言和任务多样性，但仍能达到约 17% 的构建成功率。这说明 model-based filtering 在规模化环境构建中确实能节省计算成本。

实例质量方面，作者把任务按仓库分数分层抽样，并从 Task Soundness、Evaluability、Information Sufficiency 和 Behavioral Constrainedness 四个维度进行人工和 LLM 评价。结果显示，仓库分数越高，生成实例质量也越高。这说明仓库层面的可执行性信号能够传导到任务层面，从而同时改善环境构建和任务生成质量。

6. 实验设置与模型训练（Experiment Setup）

实验部分主要评估 TerminalTraj 数据对 terminal agent 能力的提升。作者选择 Qwen2.5-Coder 系列作为 backbone，包括 7B、14B 和 32B。选择 Qwen2.5-Coder 而不是 Qwen3-Coder 的原因是，Qwen2.5-Coder 发布时间早于 TerminalBench，可以降低 benchmark 污染风险。训练方式采用多轮监督微调，并使用 Megatron-LM 框架完成训练。

评测基准是 TerminalBench 1.0 和 TerminalBench 2.0。这两个 benchmark 都用于测试智能体在真实终端环境中的任务完成能力。作者遵循 TerminalBench 的评测协议，并使用 Terminus-2 作为主要 agent scaffold。对于没有公开 TerminalBench 结果的模型，作者进行了四次独立运行，并报告平均性能和置信区间。

对比模型覆盖面比较广，包括闭源模型、超大规模开源模型、30B 左右开源模型以及已有 agentic training 方法。闭源模型包括 Gemini、Claude 和 GPT 系列。开源模型包括 DeepSeek-V3.2、GLM-4.7、Kimi-K2、Qwen3-Coder 和 Nex-N1 系列。这样的设置可以同时比较 TerminalTraj 在同等规模、小于 100B 参数范围和超大模型之间的位置。

从实验目的看，作者想证明的不只是 TerminalTraj 数据能让 Qwen2.5-Coder 变强，而是想说明执行环境驱动的数据构建比纯文本式或 judge-based 轨迹筛选更有效。因此，后续实验不仅看主结果，还看 pass@k scaling、领域消融、验证方式对比和与 Nex-N1 数据集的比较。

7. 实验结果与性能分析（Results）

主结果显示，TerminalTraj 数据带来了非常明显的提升。Qwen2.5-Coder 原始 backbone 在 TerminalBench 上表现较弱，7B 在 TB 1.0 上只有 6.25%，在 TB 2.0 上为 0.00%。经过 TerminalTraj 训练后，TerminalTraj-7B 提升到 23.01% 和 10.10%。14B 模型提升到 28.91% 和 19.10%。32B 模型提升到 35.30% 和 22.00%。这些结果说明，terminal trajectories 对模型的真实执行能力提升非常直接。

TerminalTraj-32B 的表现尤其值得注意。它不仅超过 Qwen3-32B-Nex-N1，还超过部分更大规模的 open-source agentic models。在 TB 1.0 上，TerminalTraj-32B 比 Qwen3-32B-Nex-N1 高 6.55 个点，在 TB 2.0 上高 5.3 个点。而且 TerminalTraj 使用的是 Qwen2.5-Coder-32B 作为基础模型，backbone 并不比 Nex-N1 更强，这说明数据质量本身提供了主要增益。

Test-time scaling 结果也很关键。作者使用 pass@k 评估模型在采样更多候选轨迹时的性能变化。原始 Qwen2.5-Coder 系列 pass@k 曲线较平，说明额外采样不能有效转化为成功率提升。TerminalTraj 系列则表现出更陡的 scaling 曲线，随着 k 从 1 增加到 16，pass@k 提升约 20% 到 30%。其中 TerminalTraj-32B 在 pass@16 下达到 63.75%，并在多数 k 值下超过 Qwen3-Coder-480B。这说明执行 grounded 的训练轨迹不仅提升单次准确率，也提升了模型利用推理时计算预算的能力。

领域消融实验进一步说明，多样化终端任务非常重要。作者从八个专门领域中各抽取 1,000 条轨迹，并配合 2,000 条 general-domain 轨迹形成训练集。移除任一领域都会导致性能下降，其中 Web Service 和 QEMU 的影响最大。去掉 Web Service 会让 TB 1.0 和 TB 2.0 分别下降 8.9% 和 7.4%，去掉 QEMU 则下降 9.7% 和 8.7%。这说明 terminal agent 需要大量不同工具、系统操作和环境交互数据，单一类型数据很难训练出稳健能力。

验证方式对比也支持论文的核心观点。作者比较了 LLM-verified 和 Code-verified 两种轨迹筛选方式。结果显示，在 1K、2K、4K 和 8K 不同数据规模下，使用代码验证筛选的轨迹训练效果始终优于 LLM 判断筛选。尤其在小数据规模下，code-based verification 的优势更明显。这说明真实执行验证比模型自评更可靠，也再次证明了可验证性是 terminal trajectory 数据质量的核心。

最后，作者将 TerminalTraj 与 Nex-N1 对比。尽管 TerminalTraj 的轨迹数量少于 Nex-N1，且使用的 backbone 更弱，但带来的性能增益更大。论文报告显示，TerminalTraj 在 TB 1.0 和 TB 2.0 上的提升幅度分别是 Nex-N1 的 1.7 倍和 1.3 倍。这说明对于 terminal agent 训练而言，轨迹数量不是唯一关键，环境多样性、执行真实性和验证质量同样重要。

8. 贡献与结论（Conclusion）

本文的主要贡献包括以下四点。

第一，提出 TerminalTraj Pipeline，用于大规模构建多样化、可执行、可验证的 terminal agent trajectories。

第二，引入 model-based repository scoring，将仓库筛选从启发式规则转为可学习的质量预测，提高 Docker image 构建效率，并支持持续扩展执行环境。

第三，提出 Docker-aligned instance generation 和 code-based trajectory verification，使每个任务都与具体执行环境绑定，并通过实例级验证代码判断 agent 是否真正完成任务。

第四，构建 32,325 个 Docker images 和 50,733 条 verified trajectories，并在 TerminalBench 上验证这些数据能显著提升 Qwen2.5-Coder 系列模型的终端任务能力和 test-time scaling 表现。

这篇论文真正抓住的问题是，terminal agent 的训练瓶颈不只是模型大小，而是缺少足够多的真实执行环境和可靠验证信号。很多 agent 数据看起来像多轮轨迹，但如果没有实际执行和状态验证，就很难保证模型学到的是可迁移的操作能力。TerminalTraj 的价值就在于把数据构建建立在 Docker 环境和 executable validation 之上，使训练信号更接近真实终端任务。

从研究意义看，这篇工作把 agentic data synthesis 推向了更工程化也更可信的方向。它说明未来训练可靠智能体时，仅靠文本任务、静态答案或 LLM judge 可能不够，必须让模型进入真实环境，并用程序化验证判断结果。对于代码智能体、科研自动化、系统维护和复杂 workflow agent 来说，这种执行 grounded 的数据构建思路都很有参考价值。

1. 摘要（Abstract）

本文研究的是长程交互型 LLM Agent 的训练问题，核心关注点是稀疏延迟奖励下的贡献归因。随着大语言模型从静态文本生成逐渐走向环境交互，LLM Agent 需要在网页购物、虚拟实验、家居任务等复杂环境中进行连续决策。然而，这类任务通常只有在整个 episode 结束后才给出最终奖励，中间步骤缺少明确监督，导致模型很难判断哪一步真正推动了任务成功，哪一步造成了失败。

针对这一问题，论文提出 Q-Evolve，一种面向 LLM Agent 的自进化训练框架。它的核心思想是将过程奖励自动标注和策略学习统一到同一个 in-distribution learning loop 中。具体而言，Q-Evolve 首先使用专家轨迹对模型进行行为克隆预热，然后收集模型自身与环境交互产生的轨迹，并将专家数据和自生成数据合并成 hybrid offline dataset。在此基础上，框架训练一个 in-distribution critic，通过 weighted Implicit Q-Learning 将终局奖励向前传播，得到更可靠的 step-wise process rewards。最后，模型再利用这些过程奖励，通过 behavior-proximal policy optimization 更新策略。

这篇论文的关键创新不在于简单增加一个奖励模型，而在于强调过程奖励必须在同一数据分布内被生成和使用。作者指出，传统 PRM 方法容易出现 distribution shift，即奖励模型训练时看到的数据和策略优化时产生的数据不一致，导致中间反馈失真。Q-Evolve 则通过让 policy、critic 和 dataset 在同一闭环中共同演化，减少这种分布错位，使 agent 能够稳定自我改进。

实验方面，论文在 AlfWorld、WebShop 和 ScienceWorld 三个长程交互任务上进行评估。结果显示，Q-Evolve 在总体性能、样本效率和泛化能力上均优于多种强基线方法。尤其在 AlfWorld 上，Q-Evolve 用约 13K 环境步数就超过了多个使用 320K 环境步数的 online RL 方法，体现出较强的样本效率。整体来看，该工作为 LLM Agent 的长期决策训练提供了一种较稳健的自进化路径，也进一步说明过程级监督和策略学习需要放在统一分布中共同设计。

2. 研究背景与问题动机（Introduction）

近年来，大语言模型已经不再只是文本生成器，而是逐渐成为交互式 agent 的控制器。LLM Agent 可以通过自然语言进行推理、规划和环境交互，因此被用于导航、游戏、网页操作、机器人控制等任务。与普通问答不同，交互式任务要求模型连续观察环境、选择动作、接收反馈，并在多个步骤后完成目标。这类任务更接近真实世界的智能体问题，也更能体现大模型从语言能力走向行动能力的趋势。

但长程交互任务的训练难度很高。最重要的问题是反馈稀疏且延迟。Agent 往往要执行很多步之后，才在 episode 结束时得到成功或失败的奖励。这样一来，模型只能知道最终结果，却不知道中间哪一步是关键贡献，哪一步是无效动作。对于长程任务而言，这会严重影响学习效率，因为一个失败轨迹可能包含一些合理步骤，一个成功轨迹也可能包含一些冗余动作。如果训练方法不能拆解这些中间贡献，就很难真正提升 agent 的决策质量。

现有方法大致有几类。一类是行为克隆或监督微调，主要模仿专家轨迹，优点是稳定，但缺点是无法从模型自己的错误中持续改进。另一类是 online RL，例如 PPO 或 GRPO，它们可以利用环境交互进行学习，但通常需要大量采样，而且没有专门解决稀疏奖励下的过程级归因。还有一类是 PRM 或搜索式方法，通过人工标注或在线搜索生成 step-level rewards，但这些方法往往成本高，并且容易出现奖励模型和策略分布不一致的问题。

本文的问题意识正是在这里。作者认为，长程 LLM Agent 的关键难点不是单纯缺少奖励，而是过程奖励的可靠性依赖数据分布。如果一个 PRM 只在某些轨迹上训练，却被拿去评价策略优化后产生的新状态和新动作，它给出的分数就可能不可靠。因此，Q-Evolve 试图解决一个更根本的问题，即如何在同一分布内生成过程监督，并在同一分布内完成策略改进。

3. 方法整体框架（Framework Overview）

Q-Evolve 的整体框架可以理解为一个自进化闭环。第一步是行为克隆预热。作者先使用专家数据训练一个初始 agent，使模型具备基本任务执行能力。第二步是自生成数据收集。预热后的 agent 与环境交互，产生自己的成功和失败轨迹。第三步是构建 hybrid offline dataset。该数据集同时包含专家轨迹和 agent 自己生成的轨迹，因此既有高质量成功示范，也有模型真实分布下的错误样本。第四步是在该数据集上训练 in-distribution critic，并由 critic 推导 step-wise process rewards。第五步是利用这些过程奖励更新策略。更新后的策略再去环境中生成新轨迹，进入下一轮演化。

这个框架的关键在于 hybrid data。专家数据可以提供成功任务路径，帮助 critic 获得可靠的高价值信号。自生成数据则反映当前 agent 真正会遇到的状态和动作，包括无效动作、格式错误、重复动作和局部合理但最终失败的行为。两类数据结合后，过程奖励不再只服务于专家分布，而是能覆盖模型自身的行为分布。

另一个关键点是 in-distribution。Q-Evolve 并不是先训练一个静态 PRM，再让 policy 到新分布中自由探索，而是在每一轮演化中都把 critic learning、process reward labeling 和 policy learning 约束在同一个 hybrid dataset 内。这样做可以降低分布偏移风险，使奖励标注和策略更新互相匹配。

因此，Q-Evolve 本质上不是一个单轮训练算法，而是一个 policy、critic 和 dataset 共同演化的系统。每一轮更新都比较保守，避免离开当前数据支持范围，但多轮迭代后又能逐步提升 agent 的长程任务能力。

4. 核心方法（Methodology）

Q-Evolve 的核心方法可以分成四个部分。

第一部分是行为克隆预热。作者使用专家轨迹训练初始策略，让 agent 学会基本任务格式和操作模式。对于长程交互任务，这一步很重要，因为完全随机探索很难获得成功轨迹，也很难为后续 critic learning 提供有效信号。行为克隆虽然不能解决最终的自进化问题，但可以为后续训练提供一个可用的起点。

第二部分是 hybrid data construction 和 retrospective reward labeling。作者将专家轨迹和 self-collected rollouts 合并为一个离线数据集。随后，系统根据环境返回的文本反馈，对每一步进行规则化回看标注。例如，如果动作格式错误，会给出负奖励。如果动作不被环境接受，也会给出负奖励。如果动作执行后 observation 没有变化，则说明可能是无意义重复操作，也会被惩罚。这些辅助信号不需要人工标注，也不需要环境回溯，比较适合实际交互场景。

第三部分是 in-distribution critic learning。作者采用 weighted Implicit Q-Learning 来训练 critic。普通 Bellman backup 理论上可以把终局奖励向前传播，但在稀疏奖励任务中容易被大量零奖励和失败轨迹淹没。因此，Q-Evolve 对不同样本进行加权，更重视成功轨迹和靠近终点的步骤。这样可以让 critic 更稳定地学习哪些中间行为更可能带来最终成功。

第四部分是 process reward estimation 和 policy optimization。训练好 critic 后，作者不直接使用简单的 Q minus V 作为过程奖励，而是通过 GAE 估计 step-wise advantages。这样可以获得更平滑、更可靠的过程奖励。随后，模型使用 behavior-proximal policy optimization 更新策略。与普通 advantage weighted regression 不同，BPPO 不只是提高好动作的概率，还会显式压低负优势动作的概率，因此更适合纠正长程任务中的错误行为。

整体来看，Q-Evolve 的方法设计比较克制。它没有让 policy 在未知分布中大幅跳跃，而是在已有数据支持范围内逐步改进。这种设计虽然看起来不激进，但正好符合长程交互任务中稳定性和安全性的要求。

5. 实验设置（Experimental Setup）

论文在三个长程交互环境上进行实验，分别是 AlfWorld、WebShop 和 ScienceWorld。AlfWorld 是文本化家居任务环境，agent 需要通过较长动作序列完成 household tasks，最终只得到成功或失败的二值奖励。WebShop 是网页购物任务，agent 需要根据目标需求浏览商品并选择购买，最终奖励取决于购买商品是否满足属性要求。ScienceWorld 是虚拟科学实验环境，agent 需要完成包含多个子目标的科学任务，最终根据任务完成情况获得稀疏奖励。

模型方面，作者主要使用 Llama2-7B-Chat 构建 agent，并在后续实验中进一步验证方法能迁移到 Llama-3-8B-Instruct。对于 self-collected data，作者让 agent 在每个任务上采样多条轨迹，用于构建混合离线数据集。

基线方法覆盖较全面，包括 GPT-3.5-Turbo、GPT-4、Reflexion、SFT、RFT、PPO、Best-of-N、ETO、DMPO 和 QLASS。其中 QLASS 是一个比较强的 value-based agent 方法，通过搜索树估计 Q-value 来指导推理和动作选择。因此，Q-Evolve 与 QLASS 的比较尤其关键，因为两者都关注 value signal 和过程级指导，但 Q-Evolve 更强调 in-distribution learning 和样本效率。

评价指标方面，论文报告各环境中的平均累计奖励，并在 ScienceWorld 和 AlfWorld 上区分 seen 和 unseen 任务，以检验模型是否只是记住训练任务，还是能泛化到未见场景。

6. 实验结果与性能分析（Experiments）

主结果显示，Q-Evolve 在所有任务上的平均表现最好。根据 Table 2，Q-Evolve 的平均分达到 79.4，高于 QLASS 的 74.5，也明显高于 ETO、Best-of-N、RFT 和 SFT 等方法。尤其在 AlfWorld 上，Q-Evolve 在 seen 和 unseen split 上分别达到 90.7 和 89.6，显著超过其他方法。这说明它不仅能提升已见任务表现，也能在未见任务上保持较强泛化能力。

与 QLASS 相比，Q-Evolve 的优势不只是分数更高，还体现在样本效率上。QLASS 需要大量在线搜索和 rollout 来估计 Q-values，而 Q-Evolve 主要依赖 hybrid offline dataset 和 in-distribution critic learning，在较少环境交互下就能获得更强效果。这个结果说明，对于长程 agent 训练而言，不一定要靠大量 online exploration，更关键的是如何稳定地把稀疏终局奖励转化为可靠的过程监督。

消融实验进一步说明了各个模块的重要性。Table 3 显示，去掉 retrospective relabeling、weighted IQL、GAE 或 policy improvement 都会带来性能下降。其中去掉 GAE 后下降较明显，说明高质量 advantage estimation 是过程奖励可靠性的关键。去掉 policy improvement 后性能下降更严重，说明仅有 critic 或过程奖励还不够，必须通过合适的策略优化方法把这些信号转化为 agent 行为提升。

论文还比较了不同过程奖励选择。Table 4 显示，直接使用 Q minus V 或 potential-based shaping 的效果都不如 GAE with environmental reward。作者进一步发现，将辅助奖励直接加入 GAE 反而会损害表现。这说明辅助奖励适合帮助 critic 训练和错误识别，但最终策略优化仍应与真实任务目标保持一致。

在自进化效果方面，Figure 3 展示了从 BC 到 Iter 1 再到 Iter 2 的连续提升。多个任务上，第二轮演化相较第一轮继续提高，说明 Q-Evolve 不是一次性提升，而是真正能够通过数据刷新、critic 重学和策略再优化实现稳定迭代改进。

样本效率实验也很有说服力。Table 5 显示，在 AlfWorld 上，Q-Evolve 只使用 13K 环境步数，就超过了使用 320K 环境步数的 PPO、RLOO、GRPO 及其 SFT 变体。这个结果说明，在稀疏奖励长程任务中，单纯增加 online RL 采样并不一定高效，合理的过程奖励生成和 in-distribution policy learning 可能更加关键。

最后，Table 6 使用 Llama-3-8B-Instruct 进一步验证模型泛化性。Q-Evolve 在 WebShop、ScienceWorld 和 AlfWorld 上都优于 SFT、ETO、KnowAgent、WKM 和 ETO plus MPO 等方法，说明该框架不是只对某一个 base model 有效，而是具有一定架构和规模迁移能力。

7. 贡献与结论（Conclusion）

本文的主要贡献包括以下几个方面。

第一，提出 Q-Evolve，将自动过程奖励标注和策略学习统一到一个 in-distribution self-evolving framework 中。相比传统 PRM pipeline，它更重视过程奖励和策略优化之间的数据分布一致性。

第二，设计 hybrid offline dataset，将专家示范和 agent 自生成轨迹结合起来。专家数据提供成功路径和高质量指导，自生成数据暴露模型真实错误和行为分布，两者共同提升 critic learning 的稳定性。

第三，引入 weighted IQL 和 GAE，将稀疏终局奖励转化为 step-wise process rewards。这样既避免人工逐步标注，也不需要环境回溯或大量在线搜索。

第四，采用 behavior-proximal policy optimization，在数据支持范围内进行保守策略更新。该方法不仅强化正优势动作，也压低负优势动作，有助于纠正长程决策中的错误行为。

第五，在 AlfWorld、WebShop 和 ScienceWorld 上取得稳定提升，并在样本效率和跨模型泛化方面表现突出。

从研究意义来看，这篇论文的重点不是单纯提出一个更强的 agent，而是回答了长程 LLM Agent 训练中的一个基础问题，即在只有终局奖励的情况下，如何可靠地生成过程监督，并让 agent 在不严重偏离数据分布的前提下持续自我改进。Q-Evolve 的答案是让 policy、critic 和 dataset 共同演化，同时保证每一轮更新仍然在当前数据分布内完成。

整体来看，该工作对 LLM Agent 的训练有较强参考价值。它把 self-evolving agent 从概念层面推进到了一个更具体的强化学习框架中，也说明未来 agent 训练不能只关注最终任务成功率，还需要关注过程奖励的可靠性、数据分布的一致性和策略更新的稳定性。

1. 摘要（Abstract）

本文研究的是 LLM Agents 在长程交互任务中的强化学习训练问题。现有大模型智能体在完成复杂环境任务时，通常会把完整的历史交互记录作为上下文输入，包括任务指令、过去观察、动作和中间状态等。这种做法虽然能帮助模型理解当前处境，但也带来了明显问题：随着任务步骤变长，输入上下文不断膨胀，推理成本和训练成本都会快速上升；同时，大量冗余或无关历史信息也可能干扰模型判断，影响长期决策质量。

针对这一问题，论文提出 STEP-HRL（Augmented Step-level Hierarchical Reinforcement Learning）。它的核心思想是：长程任务不一定必须依赖完整历史上下文，而可以通过“层次化任务结构 + 局部进展摘要”来构造更紧凑的 step-level transition。具体来说，STEP-HRL 将任务分为高层子任务规划和低层动作执行两个层次。高层策略负责生成子任务，低层策略负责在当前子任务下执行具体动作。同时，论文引入一个 local progress policy，用于持续总结当前子任务内部的关键进展，把局部历史压缩成简短的文本状态，从而避免低层策略反复读取完整历史。

在训练方式上，STEP-HRL 采用两阶段流程。第一阶段使用专家轨迹进行 behavior cloning，让高层策略、低层策略和局部进展策略先学会基本输出格式和任务行为；第二阶段再进行 step-level offline RL，利用 actor-critic 框架对策略进一步优化。三个策略共享同一个 LLM backbone，并通过不同 critic network 分别学习不同层次的价值信号，以兼顾参数效率和层次化决策能力。

实验在 ScienceWorld 和 ALFWorld 两个交互式决策基准上进行。结果显示，STEP-HRL 在 Mistral-7B、Gemma-7B 和 Llama-3-8B 等不同开源模型上都显著超过 ReAct、Reflexion、SwiftSage、ETO、WKM 和 GLIDER 等基线方法，并且在 unseen tasks 上也保持较好泛化能力。效率分析进一步表明，STEP-HRL 能显著降低 token usage，使每一步输入长度更加稳定。整体来看，这篇论文的重点不是简单提出一个新的 agent prompt 或任务分解方法，而是试图回答一个更基础的问题：LLM Agent 是否一定要依赖完整历史上下文，还是可以通过结构化进展表示实现更高效的 step-level learning？

2. 研究背景与问题动机（Introduction）

LLM Agents 已经在复杂交互任务中表现出较强能力，例如文本游戏、家庭任务规划、科学实验环境和工具调用任务等。相比单轮问答，这类任务更接近真实决策过程：模型需要根据环境反馈不断调整动作，并在多步交互中完成最终目标。因此，强化学习被认为是一条重要路线，因为它可以通过环境反馈优化策略，而不是只依赖固定示范数据。

但现有 LLM Agent 的一个常见设定是 history-conditioned policy，也就是每一步决策都把完整历史交互记录输入模型。这种设计很自然，因为 Transformer 可以处理序列，过去的观察和动作也确实包含状态信息。然而，论文指出，这种做法把“长程决策”错误地等同于“长上下文建模”。随着交互步数增加，attention 计算成本会持续上升，而且未经筛选的历史记录会不断积累冗余信息，使模型更难抓住当前决策真正需要的线索。

已有工作主要从两个方向缓解这个问题。一类方法尝试压缩历史，例如做 memory summary 或 context compression；另一类方法关注长期 credit assignment，希望更准确地判断哪些步骤对最终成功有贡献。但这些方法通常仍然保留了“策略依赖完整历史”的基本设定。即使是一些层次强化学习方法，也只是把任务拆成高层和低层，却仍让两个层次的策略读取累积历史，因此没有真正摆脱 long-context dependence。

STEP-HRL 的动机正是重新审视这个前提。作者认为，长程任务真正需要的不是完整历史本身，而是能够表达任务进展的结构化信息。对全局任务来说，已经完成的子任务可以代表整体进展；对当前子任务来说，只需要保留与该子任务相关的局部进展摘要。因此，论文提出用 completed subtasks 表示 global progress，用 local progress module 表示 subtask-level progress，从而让策略基于单步转移进行学习，而不是依赖不断增长的历史上下文。

这篇论文的问题意识比较清楚：它不是单纯问“如何让 LLM Agent 做得更好”，而是进一步问“LLM Agent 的状态表示是否必须是完整历史”。这个问题抓得比较基础，也更适合训练研究阅读中对核心矛盾的把握。

3. 方法整体框架（Method Overview）

STEP-HRL 的整体框架由三个策略组成：high-level policy、low-level policy 和 local progress policy。高层策略负责根据任务目标和已完成子任务生成下一个子任务；低层策略负责在当前子任务下执行具体环境动作；局部进展策略则负责在每一步更新当前子任务的 progress summary。三个策略虽然功能不同，但共享同一个 LLM 参数，只是在离线强化学习阶段配备不同的 critic network。

在传统 HRL 中，高层策略通常根据完整全局历史生成子任务，低层策略则根据子任务和局部历史生成动作。STEP-HRL 对这一点做了改造。它认为，完整全局历史可以被已经完成的子任务序列近似表示；而子任务内部的局部历史，则由 local progress policy 逐步总结。这样，低层策略每一步只需要看到当前子任务、当前观察和当前局部进展，而不需要读取从任务开始到现在的全部记录。

Local progress policy 是整个框架的关键。它在每个子任务内部持续工作：根据当前子任务、上一步动作、当前观察和上一个 progress summary，生成新的 progress summary。这个 summary 不是简单压缩全部历史，而是选择性保留与当前子任务相关的信息。比如在 ALFWorld 的家庭任务中，它可以记录已经找到的物体、已经打开的容器、物体当前位置等；在 ScienceWorld 中，它可以记录实验状态、已观察到的现象或已经完成的操作。

这种设计让 STEP-HRL 得到两类 augmented step-level transitions。低层 transition 包含当前观察、局部进展、动作、奖励和下一步局部进展；高层 transition 则包含前一子任务的最终局部进展、下一个子任务初始观察、当前子任务、子任务奖励以及后续进展。通过这种方式，模型可以在 step-level 上学习，而不是在完整 trajectory 上学习。

4. 核心方法：局部进展建模与两阶段训练（Core Method）

STEP-HRL 的第一个核心是 local progress modeling。它解决的是“当前子任务内部到底发生了什么”这一问题。传统做法会把子任务内部的完整动作和观察都放进上下文，但 STEP-HRL 只保留一个不断更新的 progress summary。这个 summary 每一步都会被改写和补充，因此既能继承过去有用信息，又不会让输入长度随时间线性增长。

第二个核心是 层次化 step-level transition。高层策略不再依赖完整历史，而是根据任务指令、已完成子任务、上一子任务的最终 progress 和下一子任务初始观察来生成新子任务。低层策略则根据当前子任务、当前 observation 和当前 local progress 来生成 primitive action。这样，长程任务被拆成多个更短、更清晰的局部决策过程，减轻了模型直接处理长历史的负担。

第三个核心是 behavior cloning 初始化。由于 ScienceWorld 和 ALFWorld 这类环境具有专门的动作空间和状态表达，直接用 RL 训练 LLM Agent 往往效率很低。因此作者先从专家轨迹中构造三类示范数据：高层子任务生成数据、低层动作执行数据和局部进展生成数据。通过行为克隆，三个策略先学会基本任务格式和合理行为，为后续 offline RL 提供稳定起点。

第四个核心是 step-level offline RL。作者在行为克隆模型基础上继续收集轨迹，并和专家数据混合形成离线数据集。随后采用类似 IQL/ILQL 的 actor-critic 方法：critic 估计每个 step-level state-action 的价值，policy 则通过 advantage-weighted regression 更倾向于学习高价值动作。与传统基于完整历史的 RL 不同，这里的状态就是前面构造出的单步状态表示，而不是整段历史。

从方法设计上看，STEP-HRL 的创新点并不是某一个模块特别复杂，而是几个模块配合得比较紧：层次化结构负责降低任务复杂度，local progress 负责压缩局部历史，behavior cloning 负责稳定初始化，offline RL 负责提升泛化和策略质量。这些部分共同服务于一个目标：让 LLM Agent 可以在不依赖完整历史的情况下完成长程决策。

5. 实验设置（Experimental Settings）

论文在两个典型交互式决策基准上评估 STEP-HRL。第一个是 ScienceWorld，这是一个文本化科学任务环境，覆盖物理、化学、生物等多个任务族，要求智能体完成多步实验、观察和推理。这个基准的难点在于任务多样性较强，而且很多任务需要根据中间观察逐步调整操作。第二个是 ALFWorld，它来自家庭场景任务，包含 pick-and-place、清洁、加热等语言条件任务，更强调长程动作规划和环境交互。

模型方面，论文主要使用三个开源 backbone：Mistral-7B、Gemma-7B 和 Llama-3-8B。同时，作者还在不同模型规模上做了分析，包括 Llama-1B、Llama-3B 和 Llama-8B，用来验证方法是否只对大模型有效。基线方法包括 prompt-based 的 ReAct、Reflexion、SwiftSage，也包括 LoRA fine-tuning 的 ETO、WKM 和 GLIDER。此外，论文还引用了 GPT-3.5-Turbo 和 GPT-4 在相关任务上的结果作为参考。

训练流程上，所有微调类方法都使用 LoRA。STEP-HRL 先进行 behavior cloning，再进行 offline RL。专家轨迹中的子任务和 local progress annotation 由 DeepSeek 生成，offline RL 数据则由行为克隆后的策略继续收集。这个设置说明 STEP-HRL 并不是完全不依赖示范数据，它仍然需要较高质量的结构化轨迹作为训练基础。

6. 实验结果与分析（Experiments）

主结果见 Table 1。整体来看，STEP-HRL 在三个 backbone 上都明显优于已有方法，而且在 seen 和 unseen tasks 上都有稳定提升。在 ScienceWorld 上，STEP-HRL 相比强基线 GLIDER 仍能继续提高，说明它不只是靠层次化任务分解本身，而是 local progress 和 step-level learning 确实带来了额外收益。在 ALFWorld 上，STEP-HRL 的成功率基本达到 96% 到 98% 左右，已经接近饱和表现，说明它在较规则的家庭任务环境中非常有效。

更值得注意的是 unseen tasks 的表现。很多 agent 方法在 seen tasks 上可以通过模仿或记忆取得不错结果，但在 unseen tasks 上容易下降。STEP-HRL 在 ScienceWorld unseen 和 ALFWorld unseen 上仍然保持较高成绩，说明它学到的不只是具体轨迹，而是更可迁移的任务进展表示和层次化决策方式。

Table 2 展示了不同模型规模下的结果。随着模型从 Llama-1B 到 Llama-8B 增大，ScienceWorld 和 ALFWorld 上的表现整体上升。不过，即使是 Llama-1B，在 ALFWorld 上也能达到接近 90% 的成功率，说明 STEP-HRL 对小模型也有帮助。这一点很重要，因为如果一种 agent 训练方法只能在大模型上工作，实际部署价值会受限；而 STEP-HRL 显示出一定的 scale robustness。

消融实验见 Figure 2。作者分别去掉 local progress、去掉 hierarchical structure、去掉 offline RL。结果显示，三种变体都会下降，其中 local progress 的作用尤其明显。没有 local progress 时，模型只能根据当前 observation 和子任务决策，很多历史状态会变得不可区分，导致 credit assignment 和动作选择都更困难；没有层次结构时，local progress 需要独自承担全局长历史压缩，压力过大；没有 offline RL 时，模型退化为 behavior cloning，泛化能力不足。这个消融结果支撑了论文的核心判断：STEP-HRL 的效果来自层次结构、局部进展建模和离线强化学习三者共同作用。

效率分析见 Figure 3 和 Table 3。在相同观察和动作序列下，普通 RL 方法的 token usage 会随着步数持续上升，因为每一步都要读完整历史；传统 HRL 虽然整体减少 token，但在生成子任务时会出现明显峰值；STEP-HRL 则基本保持稳定，每一步输入长度波动小。该实验中，总 token usage 分别为 RL 17.8k、HRL 10.8k、STEP-HRL 9.1k，说明 STEP-HRL 不仅效果更好，也更节省上下文。Table 3 则显示，STEP-HRL 在早期步骤可能略慢，因为它包含多个策略和额外 progress generation；但随着历史增长，普通 agent 的延迟逐渐上升，而 STEP-HRL 保持稳定，更适合长程任务。

最后，Figure 4 分析了 offline RL 的敏感性。结果显示，advantage temperature、expectile parameter、数据来源和数据量都会影响最终表现。混合专家数据和 BC-collected 数据通常优于只用其中一种，说明专家数据提供高质量轨迹，而模型自己收集的数据则补充了更真实的失败和偏差样本。数据量也不是越大越好，过多低质量或冗余样本反而会影响稳定训练。

7. 贡献与结论（Contributions and Conclusion）

本文的主要贡献可以概括为四点。

第一，论文提出 STEP-HRL，将 LLM Agent 的长程决策从完整历史条件建模，转向基于 progress representation 的 step-level learning。这个视角比较重要，因为它把问题从“如何塞进更长上下文”转为“如何构造更有效的状态表示”。

第二，论文设计了 local progress module，用于在每个子任务内部选择性总结交互历史。它既保留了当前子任务中有用的信息，又避免上下文无限增长，是 STEP-HRL 区别于普通 HRL 的关键。

第三，论文提出参数高效的训练框架，使高层策略、低层策略和局部进展策略共享同一个 LLM backbone，并通过不同 critic network 分别学习不同层次的价值信号。这样既降低训练和推理开销，也促进不同层次之间的知识迁移。

第四，论文在 ScienceWorld 和 ALFWorld 上进行了较全面实验，证明 STEP-HRL 在性能、泛化和 token efficiency 上都优于已有 agent 方法。尤其是在 unseen tasks 上的提升，说明这种 step-level progress representation 具有一定泛化价值。

当然，这篇论文也有局限。作者在结论后明确提到，STEP-HRL 依赖高质量专家示范，尤其需要构造子任务和 local progress，这在复杂环境中并不总是容易。另一个问题是，子任务终止由低层输出同时预测，可能出现提前终止或延迟终止，从而影响 transition 质量和高低层协同。这些局限说明 STEP-HRL 并没有彻底解决 LLM Agent 的长程决策训练问题，但它提供了一个很清晰的方向：未来的 agent 不一定要不断扩大上下文窗口，而可以通过更结构化的任务进展表示来提高效率和鲁棒性。

总体来看，这篇论文的价值在于，它抓住了 LLM Agent 中一个容易被忽略的问题：长程交互不等于长上下文输入。STEP-HRL 通过层次化结构和局部进展摘要，把复杂历史转化为可控的 step-level state，使 LLM Agent 的强化学习训练更高效、更稳定，也更容易泛化到新任务。