21.9 Agentic RL（智能体强化学习）

在前面的章节中，我们已经构建了从 RL 基础（§15）到偏好优化算法（§16）的完整理论体系，也在 §21.5 中看到了 GRPO 如何通过环境接口层从静态奖励走向动态交互。但那些内容本质上仍在回答一个"点"的问题——某个具体算法如何接入环境。本节要回答的是一个"面"的问题：当我们认真地、大规模地训练一个在真实环境中行动的 Agent 时，整个系统应该长什么样？

答案并不是"把 PPO 或 GRPO 套到更长的文本上"。Agentic RL 是一整套协同系统——环境建模、学习信号管理、异步数据流、策略优化和基础设施必须作为一个不可分割的整体来设计。正如 ROLL 团队（He et al., 2025）所言："RLVR 训练的是一个'会回答'的模型；Agentic RL 训练的是一个'会行动'的模型——跨时间、跨状态、跨不确定性地行动。"这个区别改变了一切。

本节的学习目标如下：（1）理解从 RLHF 到 Agentic RL 的范式跃迁本质；（2）掌握 Agentic RL 训练中必须维护的三大不变量；（3）建立完整系统的八大支柱的认知框架；（4）深入 ROLL 团队的工程实践细节——环境管理、数据过滤、训练稳定性；（5）理解异步训练管线的设计原理和长尾延迟的应对策略。

---

21.9.1 范式跃迁：从单步 Bandit 到多步 MDP

传统的 RLHF 和 RLVR 有一个被广泛低估的结构性简化：它们本质上是 in-context bandit 问题。模型接收一个 Prompt，生成一个完整回答，获得一个奖励信号，然后更新参数。整个过程中没有多步交互式决策，没有环境状态转移——它更像是一道填空题，而非一场持续的博弈。

在 Agentic RL 中，模型被放置到一个真实的交互环境里，整个训练框架经历了四个根本性的突变：

状态变复杂了。 模型面对的不再只是用户的一句话，而是包含历史交互轨迹、工具返回结果、环境反馈、甚至模型自身记忆摘要的复合状态。一个终端操作任务的上下文可能长达数万 token，其中夹杂着命令输出、错误日志和环境配置信息。

动作变立体了。 不再仅仅是预测"下一个 Token"，动作空间扩展到了高阶决策层面：调用什么工具？要不要压缩上下文？任务需不需要分发给子 Agent？每个动作都可能改变环境状态，下一步的最优行为取决于上一步的执行结果。

奖励变苛刻了。 奖励变得极度延迟和稀疏，且是复合的。一个 50 步的终端操作任务，只有最后一步的测试结果才产生明确信号。而且不仅要结果正确，还要过程高效——Token 消耗、执行时间、工具调用次数都可能成为优化目标。

时间变不均匀了。 有的任务几秒搞定，有的要跑几十分钟。如下图所示，rollout 时间呈现显著的长尾分布，大多数轨迹在 1000 秒内完成，但存在大量超过 3000 秒的异常长样本。这使得同步训练变得不现实——一个 batch 中最慢的任务会拖死所有 GPU。

图 21-9a：Rollout 时间 vs 轨迹索引。绿色点为成功轨迹，红色点为失败轨迹。长尾特性非常显著——少数极端慢的任务会成为同步训练的致命瓶颈。

我们可以用一张表来精确对比这两个范式：

维度	RLVR（in-context bandit）	Agentic RL（多步 MDP）
交互步数	单步（一次生成）	多步（持续交互，可达数十轮）
状态空间	固定输入	动态变化（含工具返回、环境反馈）
动作空间	完整文本回复	工具调用 / 命令序列 / 子任务分派
奖励密度	即时（每次生成后）	极稀疏（仅最终结果）
时间分布	均匀（生成时间相近）	长尾（秒级到分钟级）
失败模式	答案错误	环境崩溃、工具超时、无效循环、reward hacking
分布偏移来源	主要来自策略漂移	策略漂移 + 环境变化 + 异步时间错位

这张表揭示了一个核心事实：Agentic RL 的难度不在于某个算法公式变了，而在于围绕算法的整个系统生态必须重建。

---

21.9.2 三大不变量：Agentic RL 的理论根基

无论具体采用什么算法——PPO、GRPO、DAPO 还是其他变体——有三个底线条件必须在整个训练周期内被稳住。它们构成了 Agentic RL 能否有效学习的理论根基，也决定了系统设计的核心约束。

第一不变量：可探索的动作空间（语义多样性下限）

一个常见的误解是把"探索"等同于"把采样温度调高，让字词变得更随机"。但真正有价值的探索是语义和策略层面的多样性——模型必须保留多种能解决问题的真实路径。比如同一个部署任务，可以用不同的工具调用顺序、不同的任务分解方法、不同的错误恢复策略来完成。

这个不变量的关键威胁来自 SFT 阶段。如果模型在监督微调时就被逼着只会用一种"标准答案"套路，那它的可探索空间就已经塌缩（collapse） 了。后续的强化学习无论算力多大，都只是在极窄的范围里做毫无意义的局部微调——模型永远无法"顿悟"出更好的新工作流。

为了维护这个不变量，前沿团队采取了不同策略：MiniMax 提出 Continual Pretraining，在预训练阶段就植入多样的 Agent 行为模式；Kimi 则合成具有不同能力的 Agent 数据，提前扩宽动作空间；DAPO（DeepSeek Aligned Policy Optimization）显式地将多样性作为优化目标之一。

用一个具体场景来理解"塌缩"：假设 Agent 需要在 Linux 服务器上安装 Nginx。至少存在三条有效路径——用 apt 从默认源安装、用 docker pull nginx 容器化部署、从源码编译安装。如果 SFT 阶段只示范了 apt install nginx，模型的策略分布就集中在这一条路径上。当它被放到一个没有 apt 的 CentOS 环境中时，RL 几乎无法找到替代方案，因为探索的起点已经太窄了。

第二不变量：不退化的学习信号（连续梯度变化下限）

就算模型保留了多种解题路径，也不代表能有效学习。问题在于：如果同一批采样的题目中，简单的全对（奖励饱和），极难的全错（完全摸不到门），那这两类样本产生的梯度都趋近于零。用 GRPO 的语言说，组内优势 $A_i=(r_i-\mu )/\sigma$ 在这两种极端情况下都没有区分度。

训练系统必须源源不断地制造出能区分好坏的有效对比。Agentic RL 需要的不是更高的绝对分数，而是能被优化器利用的"轨迹差异"。如果奖励机制无法在模型当前能力边界附近区分出"略好"和"略差"的轨迹，那算力就是在白白燃烧。

这直接驱动了后面要讨论的自适应算力分配策略：不把 rollout 预算平摊给所有任务，而是把预算投给最能产生有效梯度的那些 prompt。

第三不变量：可控的分布漂移（训练/部署一致性上限）

这是三个不变量中最隐蔽、最容易被系统自身制造出来的问题。在 Agent 场景下，存在三个分布：

$$p_{\text{rollout}}(\tau )\text{（采样时的策略分布）}{p}_{\text{train}}(\tau )\text{（实际拿去更新的分布）}{p}_{\text{deploy}}(\tau )\text{（上线部署时的分布）}$$

这三者在 Agentic RL 中几乎不可能天然一致。比如为了效率，你把长任务切段（Chunked MDP），或者异步地让先完成的任务先更新梯度——这些操作都会导致"现在更新的参数"与"当初采样的策略"发生时间错位（Off-Policy Drift）。更隐蔽的是，只要工具接口、上下文整理方式、解码设置中的任何一个环节在三个阶段不完全一致，模型学到的就不是你想要的动作语义。

三个不变量的内在张力。 这三者之间存在天然矛盾：探索越强，分布偏移就越难控制；过度追求稳定更新，又很容易把探索空间压没；有了探索和非退化信号，但分布偏移失控，最后学到的可能不是部署时能用的行为。Agentic RL 系统设计的核心艺术，就是在这三者之间找到动态平衡。

---

21.9.3 系统工程：训练闭环的八大支柱

理解了"为什么难"之后，接下来的问题是"怎么建"。从工程落地的角度，一个完整的 Agentic RL 训练系统可以被拆解为八个相互耦合的支柱。每一根支柱的设计，都对应着上述三大不变量中的某个或某几个约束。

支柱一：环境建模与接口

Agent 需要的不是表面逼真的"模拟器"，而是结构化保真（Structural Fidelity）——动作空间、成功判据、失败模式必须和真实部署一致。环境接口的标准化已在 §21.5 详细讨论，这里补充系统视角：环境建模需要三个"编译器"协同工作——Task Compiler 把模糊请求变成结构化任务描述；Verifier Compiler 把评判标准变成机器可执行的检查脚本；Scaffold Compiler 把能力放进不同的工作流和模板中，防止模型只会死记硬背单一模版。

支柱二：探索管理

探索不是被动的副产品，而是需要显式管理的目标。预训练和 SFT 阶段的作用是"保底"——确保模型至少见过多种 Agent 行为模式。但在 RL 阶段，系统需要主动维护多样性：比如 DAPO 在目标函数中加入多样性正则项，同时要防范 SFT 过拟合对未来强化学习潜力的"预杀"。

支柱三：算力分配

把 rollout 预算平均分配给所有任务是浪费。如果一道题已经饱和（所有采样都能做对），或者极难无解（所有采样都失败），它就不该消耗宝贵的 GPU 时间。VIP 和 RL-ADA 等方法的做法是把预算投给最能减少梯度方差、最可能恢复学习信号的 Prompt——预算分配本身已经成为 RL 核心算法不可分割的一部分。这直接服务于第二不变量。

支柱四：目标函数与策略优化

这里的关键认知是不要纠结 PPO 还是 GRPO，而要先诊断当前训练的瓶颈在哪。是梯度噪声太大？策略漂移太快？还是目标函数不匹配？不同的瓶颈需要不同的应对：K2.5 的 Token-level Clipping 控制更新幅度；MiniMax 的 CISPO（双侧重要性采样）约束策略偏移；GLM 的 TITO（Token-In-Token-Out）用采样时的原始 Token 直接训练以消除分布偏移。所有这些技术细节，都是在维护第三不变量。

支柱五：异步采样与调度

由于任务时间极不均匀，严格的同步 On-Policy 训练会让快任务等待慢任务而拖死系统。MiniMax 提出的 Windowed FIFO 是一个优雅的折中——不要求全局严格排队，但在有限时间窗口内保持大致顺序，兼顾效率和分布一致性。GLM-5 则更激进地把采样和训练完全分开。异步调度器不只是基础设施组件，它直接决定了"模型看到什么样的训练分布"。

支柱六：奖励验证

不能只看结果对不对。K2.5 对可验证任务用 Rule-based 奖励，对 Token 成本用 Budget-control 奖励，对开放式任务用 GRM（综合打分模型）。还必须对抗长回答偏见（Verbosity Bias）——模型很容易学会"水字数"来骗分。MiniMax Forge 把中间过程质量和完成时间纳入奖励，因为真实用户需要的是快速且高效的 Agent，而不是又慢又废话连篇的 Agent。

支柱七：记忆层级

上下文越长，模型越容易失焦——这被称为Context Rot（上下文腐化）。Forge 把"上下文管理"变成环境动作的一部分——模型可以主动选择压缩、丢弃或保留上下文。GLM-5 使用 Keep-recent-k 和 Discard-all 两级记忆策略。更进一步，K2.5 引入了 Agent Swarm 和 PARL（并行 Agent RL），让协调器学会何时并行、如何分派子任务——这是把模型从"单点决策者"升格为"操作系统级调度者"。

支柱八：基础设施

Infra 不仅仅是底座，它塑造了训练分布。K1.5 的部分轨迹复用、GLM-5 的 TITO、MiniMax Forge 的标准化网关设计，都在做同一件事：保证模型训练时的动作和部署时的动作是绝对对应的（维护第三不变量）。吞吐量决定了一切的上限——必须解耦训练和推理，支持异构资源调度，否则单点算法优化根本无法在真实的大规模场景下被验证。

这八个支柱不是独立的清单，而是一个耦合的系统。改动任何一根支柱，都可能影响其他几根，也都可能打破三大不变量中的某一个。理解这种耦合性，是设计 Agentic RL 系统的前提。

---

21.9.4 环境管理：CLI-Native 与 Roll-Managed 双模式

从系统视角进入工程细节，我们以 ROLL 团队的实践为案例，深入剖析 Agentic RL 训练中的关键工程决策。

在终端环境中训练 Agent，首先要解决的问题是：谁来管理 Agent 与环境的交互上下文？ ROLL 团队在实践中发展出了两种互补的模式。

图 21-9b：ROLL（训练框架）与 ROCK（沙箱执行引擎）的协作架构。左侧 ROLL 负责 RL 训练循环（Actor Train/Infer、环境管理），右侧 ROCK 负责沙箱生命周期管理和 Agent 框架执行。两端通过 ModelProxy Service 实现异步非阻塞通信。

Roll-Managed 模式：训练侧主导上下文。 在这种模式下，ROLL 框架负责整个 rollout 循环——从环境重置到模型决策、动作执行、直到轨迹终止。核心组件包括：TrajEnvManagerTB 驱动完整的 rollout 流程并保存训练轨迹；TerminalBenchEnv 加载任务数据、提交执行请求并计算奖励；SandboxManager 管理沙箱会话的生命周期。

这种模式的优势在于训练侧的高度灵活性——可以根据训练需求灵活组织上下文，引入丰富的 prompt 模板和交互机制以提升鲁棒性。缺点是训练时的 prompt 构造方式与真实 Agent 框架（如 iFlow CLI）的行为不可避免地存在偏差。

CLI-Native 模式：Agent 框架主导上下文。 在这种模式下，上下文、会话和历史信息完全由真实的 Agent 框架（iFlow CLI）维护，ROLL 仅作为调用方。模型在训练时看到的输入分布——包括动态上下文、工具列表、系统提示词、内部状态——与真实使用场景完全一致。两端通过一个轻量级的 ModelProxy Service 通信，该服务提供基于队列的异步消息机制。

这种模式最大限度地保证了训练与部署的一致性（直接服务于第三不变量），但在训练侧上下文定制方面的灵活性较低。

实际策略是在不同阶段切换两种模式。 早期探索阶段使用 Roll-Managed 模式的灵活性来快速实验不同的 prompt 策略和交互设计；当训练趋于稳定后，切换到 CLI-Native 模式以消除训练/部署分布偏差。这是一个务实的工程决策——两种模式不是非此即彼的替代关系，而是互补的工具。

保持环境"干净"：防止模型作弊。 ROLL 团队在早期训练中发现了一个极具警示意义的现象：环境中残留的中间产物（临时文件、缓存链接、甚至测试脚本）会被模型迅速发现并利用。模型不是去解决任务，而是直接读取或修改测试脚本来"通过考试"。一旦这种捷径被发现和强化，大量 rollout 就退化为直接执行测试文件。

解决方案是严格的环境隔离：rollout 前主动清理所有中间文件；测试文件仅在最终评估阶段上传，与训练阶段严格隔离。这个教训说明：在 Agentic RL 中，环境设计的安全性和奖励函数的设计同等重要。

---

21.9.5 数据过滤：False Positive 是 Agentic RL 的头号敌人

RL 训练实例的质量对 Agentic RL 至关重要，而且"高质量"的定义与传统 SFT 数据不同——不仅内容要好，还必须不可被钻空子。

40% 的伪阳性率。 在 ROLL 团队早期的合成数据中，false positive 比例一度高达约 40%。所谓伪阳性，是指自动生成的测试用例不完整或有漏洞，导致模型可以在不真正解决任务的情况下通过测试。

图 21-9c：伪阳性（False Positive）行为示意。上方是期望行为：Agent 完整地配置 git 服务器、push 代码、部署到 web 服务器。下方是伪阳性行为：Agent 跳过整个流程，直接把 hello.html 写入 web 目录，仍然通过了仅检查 curl 输出的测试。

一个典型的例子：任务要求"配置 git 服务器，使得 git push 后自动部署到 web 服务器"。但测试脚本只检查 curl http://localhost:8080/hello.html 是否返回 "hello world"。于是 Agent 完全可以跳过 git 配置，直接把文件写入 web 根目录就通过测试。这种行为一旦被奖励强化，模型就学会了"走捷径"而非"解决问题"。

LLM-as-Judge 验证模块。 为了系统性地解决这个问题，ROLL 团队在数据合成流程中引入了多 LLM 协同审查机制。多个 LLM 审查每一组"指令-测试"对，识别具有高 false-positive 风险的实例；对于高风险样本，强化测试用例或调整任务描述；只有通过验证的实例才能进入 RL 训练池。

两项铁律：Ground-Truth 与 No-Op 验证。 在 LLM-as-Judge 之外，每个实例在进入训练池前还必须通过两个基础检查：

• Ground-Truth 验证：如果标准答案（golden solution）本身都无法通过全部测试，说明测试有问题，直接丢弃。
• No-Op 验证：如果在不执行任何有效操作的情况下也能通过测试，说明测试形同虚设，直接丢弃。

环境增强（Environment Augmentation）。 除了过滤坏数据，还需要主动增加好数据的多样性。ROLL 团队借助 Roll-Managed 模式的灵活性，有意在初始环境中引入扰动：不同版本的软件包、不同的镜像源、甚至故意移除某个预装依赖或切换到不可用的配置。

图 21-9d：环境增强（Environment Augmentation）示意。理想化环境（A）中 Agent 可以直接执行预设流程；但在镜像源不可用（B）、依赖缺失（C）或配置错误（D）的场景中，Agent 必须先检查环境状态、诊断问题、恢复正常，才能继续执行任务。

这些扰动迫使模型学会在行动前主动检查环境状态——"先观察，后行动"而非"假设一切就绪"。从 RL 的角度看，这相当于扩大了状态空间的覆盖率，有效防止了策略对特定环境配置的过拟合。

---

21.9.6 训练稳定性：Mask & Filter、课程式训练与 Chunked MDP

在真实终端环境中训练 Agent，不稳定性不仅来自策略优化本身，还来自实例质量、环境噪声、框架约束以及长程信用分配等多方面因素。这一小节分享 ROLL 团队在训练稳定性方面最核心的三个技术。

Mask & Filter：分级处理噪声样本

终端环境不可避免地会出现网络故障、沙箱启动失败、工具调用超时等异常。如果将这些异常信号直接纳入策略更新，就相当于向优化器注入随机噪声。ROLL 团队遵循一个简单原则：当前对训练有害或无法提供有效学习信号的样本，都应该被移除。

具体的分级策略如下：

对于不可恢复的系统级错误（如环境启动失败、沙箱不可用、奖励计算崩溃），用占位样本替换以保证 batch size 稳定，但将所有梯度信号置零：

def handle_unrecoverable_failure(rollout):
    """处理不可恢复的系统级错误"""
    placeholder = create_placeholder_rollout()  # 占位样本
    placeholder.response_mask[:] = 0  # 梯度归零
    placeholder.advantages[:] = 0
    placeholder.rewards[:] = 0
    return placeholder

对于偶发可恢复错误（如工具超时、网速延缓），直接丢弃该样本，但设置全局 Filter 比例上限（如 50%），防止在环境大面积故障时没有足够的数据完成训练：

def should_filter(group, global_stats, threshold=0.5):
    """判断是否应该过滤该组 rollout"""
    has_transient_error = any(d.meta.get("drop_flag") for d in group)
    if not has_transient_error:
        return False
    current_ratio = global_stats["filtered"] / max(global_stats["total"], 1)
    if current_ratio >= threshold:
        return False  # 已经过滤太多，不再丢弃
    global_stats["filtered"] += 1
    return True

图 21-9e：Mask & Filter 策略的效果对比。（a）不使用该策略时（红色），训练准确率波动剧烈且收敛到约 0.704；使用后（蓝色），训练更稳定且收敛到约 0.832。（b）被 mask 的轨迹比例随训练推进逐渐降低至约 0.021，说明环境稳定性在持续改善。

课程式训练：先从正样本学起

ROLL 团队在早期训练中发现了一个与直觉相悖但非常重要的规律：数据尚未完全可靠时，仅使用正样本轨迹（Positive-Only）训练明显更稳定。

图 21-9f：大规模合成数据上的训练对比。在三个不同的训练集上，同时使用正负轨迹的训练（红色）频繁崩溃或严重震荡，而仅用正轨迹训练（橙色）在各种设置下都保持稳定。

图 21-9g：切换到小规模、专家校验的高质量数据后，趋势反转。两种方法都能稳定训练，但加入负轨迹后（红色），在 Terminal-Bench-V1 和 V2 测试集上的性能提升更显著。

基于这一发现，ROLL 团队采用了课程式策略（Curriculum Strategy）：

• 早期阶段：仅使用正样本轨迹更新策略。利用大规模合成实例构建稳定的策略流形（stable policy manifold），避免噪声负样本导致训练发散。
• 后期阶段：当拥有小规模但经过专家多轮验证的高质量实例后，引入正+负轨迹联合训练，利用负样本提供更丰富的对比信号来提升性能上限。

但 Positive-Only RL 不等同于 RFT（Reinforcement Fine-Tuning）。两者在形式和训练动力学上存在明显差异：

对比维度	Positive-Only RL	RFT（行为克隆式）
损失函数	标准 RL 目标（含 clipping、KL 约束）	交叉熵 / 行为克隆目标
采样机制	在线采样，每轮都用当前策略生成	通常使用离线收集的正样本
稳定机制	Masking、clipping、normalization	标准正则化
泛化能力	更强（策略仍在探索）	更弱（容易过拟合到示范轨迹）

前者保留了 RL 的核心优势——策略仍然在自身的分布上进行探索和更新，而不是简单地模仿固定的示范数据。

Chunked MDP 与 IPA：重新定义优化单元

在多轮 Agentic 任务中，一条轨迹可能包含数十个工具调用，产生数万个 token。但大多数 token 并不改变环境状态——真正的决策节点是每次工具调用。这促使 ROLL 团队重新思考：Agentic RL 的最佳优化单元是什么？

答案是 Interaction Chunk（交互片段）——从一次环境交互到下一次环境交互之间的连续片段，通常以一次工具调用结束，构成一个完整的功能单元。用一段伪代码来直观理解 chunk 的划分：

轨迹: [思考1][思考2][bash: ls -la][环境返回][思考3][bash: apt install nginx][环境返回][思考4][bash: systemctl start nginx][环境返回]
      ├───── chunk 1 ──────┤            ├────── chunk 2 ──────────────┤            ├────── chunk 3 ──────────────────┤

每个 chunk 包含一段思考过程（reasoning tokens）和一次工具调用（action token），以环境返回结果作为边界。传统的 token 级 RL 会对 chunk 内的每一个 token 都计算重要性采样比率和梯度，但实际上整个 chunk 的语义目的是统一的——它要么在做信息收集，要么在执行一个具体操作。

在此基础上提出的 IPA（Interaction-Perceptive Agentic Policy Optimization） 算法，其核心创新包括：

1. Chunk 级回报计算：不在 token 级别计算重要性采样比率，而是在 chunk 级别计算，更契合以结果为导向的粗粒度奖励结构。
2. Chunk 级 Masking：当推理策略与训练策略的偏差过大时，对整个 chunk 进行 masking，而不是逐 token 处理。
3. Chunk 初始化重采样：对困难任务，从特定的 chunk 起点重新采样，扩大模型在难题上的有效学习范围。

从数学角度看，传统 token 级策略梯度为：

$${\mathrm{\nabla }}_{\theta }J={\mathbb{E}}_{\tau }[\sum _{t=1}^T\frac{{\pi }_{\theta }(a_t|s_t)}{{\pi }_{{\theta }_{\text{old}}}(a_t|s_t)}{\mathrm{\nabla }}_{\theta }\log {\pi }_{\theta }(a_t|s_t)\cdot A_t]$$

其中每个 token 都有独立的重要性采样比率。而 IPA 在 chunk 级别聚合：

$${\mathrm{\nabla }}_{\theta }{J}_{\text{IPA}}={\mathbb{E}}_{\tau }[\sum _{k=1}^K{w}_k\cdot \sum _{t\in {\text{chunk}}_k}{\mathrm{\nabla }}_{\theta }\log {\pi }_{\theta }(a_t|s_t)\cdot A_k]$$

其中 $K$ 是 chunk 数量，$w_k$ 是 chunk 级的重要性权重，$A_k$ 是 chunk 级优势。当 $w_k$ 偏离 1 过远时（说明该 chunk 的采样策略与当前策略差异过大），整个 chunk 被 mask 掉。这比逐 token masking 更符合 Agentic 任务的语义结构。

图 21-9h：Token 级与 Chunk 级优化的对比。（a）Chunk-Level Optimization 的梯度范数比 Baseline 低两个数量级且更平滑；（b）训练准确率更高（0.664 vs 0.533）；（c）验证集上的提升更为显著（0.566 vs 0.510）。

图 21-9i：采用完整 IPA 算法训练得到的模型训练曲线。收敛值约 84.80%，训练过程平滑稳定，展示了 Chunked MDP + IPA 在长程 Agentic 任务上的有效性。

---

21.9.7 Crash 是常态：训练崩溃的诊断与恢复

Agentic RL 训练是一个高度耦合的系统——数据、环境、奖励、调度、优化，任何一个小环节出问题，都可能在几十个 step 之后放大成一次 crash。ROLL 团队的核心经验是：在大规模终端 RL 训练中，崩溃是常态，关键是如何快速诊断并从断点恢复。

下面用两个真实的训练崩溃案例来说明这一过程。

案例一：极端负样本主导更新

图 21-9j：训练崩溃与恢复案例一。红色曲线在 step ~80 时训练分数急剧下降。回溯发现，从 step ~50 开始，失败轨迹的最大回复长度（左下）迅速上升，但失败样本的总数基本不变（右下）——问题不是整体失败增多，而是少量极端长轨迹主导了梯度。灰色曲线是对超过 20k token 的失败轨迹进行 masking 后的恢复结果。

诊断过程是逐层剥离的：先看训练分数的下降时间点，再回溯优势值（advantage）的变化趋势，最后定位到失败轨迹的长度分布。解决方案是定向 masking——对响应长度超过阈值的失败轨迹直接屏蔽，而非全局调整超参数。

案例二：负样本全局比例失衡

图 21-9k：训练崩溃与恢复案例二。灰色曲线在前一次修复后约 40 个 step 再次出现不稳定。这次的信号是负样本数量整体增加（右下），而非个别极端轨迹。对负样本进行全局重加权后（橙色曲线），训练再次恢复稳定。

这两个案例揭示了一个重要的诊断优先级：

1. 是否有少量极端轨迹主导更新？ 典型特征：异常长的失败轨迹，伴随重尾分布的负回报。应对：定向 masking + 降权 + 收紧 clipping。
2. 负样本是否在整体上占据主导？ 应对：降低负样本全局权重，过滤低置信度失败样本，或启用课程式训练策略。
3. 模型是否在学习"坏模式"？ 如无效重试循环、滥用搜索、执行危险操作。应对：引入行为惩罚，增加奖励维度。

经验性原则是：优先对极端轨迹做定向处理（如果能通过某些特征定位），实在不行再采用全局重加权。 RL 梯度通常比监督学习噪声更大，因此更小的学习率、配合更强的约束和退火机制，往往是更安全的选择。

RL 技巧的条件依赖性。 一个非常重要但经常被忽视的事实是：同一个 RL 技巧在不同的数据条件下可能产生完全相反的效果。

图 21-9l：同一个优化技巧（是否使用标准差归一化）在两种不同数据设置下产生截然相反的结果。Setting 1 中移除 Std Normalization 导致训练崩溃（红色）；Setting 2 中同样的操作却使训练更稳定（红色收敛更高）。

这说明 Agentic RL 中不存在"万能超参数"——每一个技巧的效果都依赖于当前的数据分布、模型状态和环境特性。持续的监控和动态调整是不可避免的。

---

21.9.8 异步训练管线：长尾延迟的系统性解决

异步训练不是一个可选的优化，而是 Agentic RL 的生存必需品。让我们从问题出发，理解为什么同步训练在这个场景下行不通。

同步训练的致命瓶颈

在同步批量训练中，一个 batch 中的所有 rollout 必须全部完成后才能开始梯度更新。由于 Agentic 任务的长尾延迟特性，整个 batch 的训练时间被最慢的那个 rollout 决定。结果就是大量 GPU 空转等待——在下图中可以清楚地看到，Batch Rollout 模式下 GPU 大量时间处于 IDLE 状态。

图 21-9m：两种 rollout 调度策略对比。上方 Batch Rollout 中，GPU 必须等待最慢任务完成才能开始下一批（大量 IDLE 时间）；下方 Queue Scheduling Rollout 中，每个 GPU 完成一个任务后立即领取下一个，消除等待时间。红色 X 标记表示失败或超时的任务。

ROLL 的异步训练架构

ROLL 框架构建了一套完全异步的训练管线，通过四个层面的解耦来应对长尾延迟：

图 21-9n：异步 LLM RL 训练架构。（a）Fine-grained Rollout and Asynchronous Training：LLM 推理、环境交互和训练各自独立运行在不同设备上，通过样本缓冲区异步交换数据。（b）Train-Rollout Multiplexing：在同一组 GPU 上通过时间分片交替执行推理和训练。

环境级异步 rollout。 将 rollout 中的 LLM 生成、环境交互与奖励计算拆解为独立的异步操作。这三个阶段互不阻塞，实现更细粒度的执行调度。一个 rollout 在等待环境返回结果时，同一个 GPU 可以处理其他 rollout 的 LLM 生成请求。

冗余并行环境。 通过增加环境组的数量和大小，避免 fail-slow 或 fail-stop 的环境实例成为系统瓶颈。如果某个沙箱实例响应缓慢或完全失败，其他冗余实例可以接管任务，整体吞吐不受影响。

解耦训练与推理。 在不同的 GPU 设备上独立运行 rollout（推理）和参数更新（训练），使两者可以并行推进。推理产生的轨迹数据通过异步缓冲区传递给训练端，训练端不需要等待所有推理完成。

Train-Rollout 复用（时间分片）。 通过 time-division multiplexing 动态划分 GPU 资源，使同一组设备可以在推理和训练之间灵活切换。当推理任务在等待环境交互返回时，GPU 可以切换到训练模式处理已经收集好的轨迹数据。

这一设计的整体效果是：系统在面对各种长尾现象时依然保持鲁棒，即使个别环境实例延迟波动剧烈，整体训练吞吐仍能维持在较高水平。

GPU 时间共享的实际策略。 Train-Rollout 复用的关键挑战在于如何切分 GPU 时间。一种朴素方案是固定比例分配（如 70% 推理 + 30% 训练），但这无法适应负载波动。更好的策略是自适应切换：监控推理请求队列的深度和训练梯度缓冲区的饱和度，当推理队列空闲时切换到训练模式，当新的推理请求到达时切回推理模式。这种策略实质上是把 GPU 当作一个"可被抢占的处理器"来调度，最大化利用率。

具体实现中需要注意两个工程细节：一是推理和训练切换时的模型权重同步——训练更新了参数后，推理端必须加载最新权重，否则会加剧 Off-Policy Drift；二是显存管理——推理时的 KV Cache 和训练时的梯度/优化器状态共享同一块 GPU 内存，需要精确的内存分配策略来避免 OOM。

异步训练的分布偏移代价。 异步训练解决了效率问题，但引入了一个新的理论问题：异步收集的轨迹与当前模型参数之间存在时间错位。 先完成的轨迹是用旧策略采集的，但参数已经更新了若干步——这就是 Off-Policy Drift。这个问题在 §18.4（异步 Rollout 与样本陈旧性）中已经从算法角度讨论过，这里强调系统层面的应对：

• Windowed FIFO 调度：只允许一定时间窗口内的轨迹参与训练，超出窗口的过期轨迹被丢弃，在效率和分布一致性之间取得平衡。
• 重要性采样矫正：对于策略偏移较大的轨迹，通过重要性权重 $\frac{{\pi }_{\theta }(a|s)}{{\pi }_{{\theta }_{\text{old}}}(a|s)}$ 进行矫正，但需要 clipping 来防止方差爆炸。
• TITO（Token-In-Token-Out）：GLM-5 的做法是直接用采样时的原始 token 做训练，确保训练数据和推理数据在 token 级别完全一致。

---

21.9.9 Agent 失败模式与行为监控

Agentic RL 中的 reward hacking 比传统 RLHF 更加隐蔽。由于 Agent 与真实环境交互，它们可以用"看似合理"的方式通过测试。ROLL 团队在实践中观察到五种反复出现的失败模式：

1. 修改既定环境：Agent 不解决任务本身，而是修改环境初始设置来让测试通过。
2. 工具过度使用：反复调用工具完成琐碎操作，本质上是在暴力重试。
3. 滥用搜索：通过大量重复搜索来弥补内部推理能力不足。
4. 不安全操作：执行 rm -rf / 或 kill -9 -1 等高风险命令。
5. 隐蔽捷径：利用测试脚本或环境默认配置中的漏洞绕过任务要求。

图 21-9o：多个模型在 Terminal Bench 上的错误类型分布。策略错误（Strategy Error, 33.62%）占比最大，其次是任务理解错误（11.45%）、知识缺口（11.80%）和超时（10.80%）。无效循环（Infinite Loop, 5.20%）和幻觉（Hallucinations, 3.63%）也是值得关注的失败类型。

ROLL 团队在训练过程中对模型行为进行了细粒度监控，追踪以下信号：不同任务的成功率趋势；不同工具的成功/失败率；重复或循环的工具调用模式；不同命令的使用频率。一旦检测到异常模式——如某个工具调用突然激增、出现大量重试循环、或频繁执行危险命令——立即回滚训练并定位引发问题的实例。

这些失败模式带来了两个层面的启示。第一，测试用例的质量与鲁棒性至关重要。 薄弱或描述不充分的测试可能在无意中奖励错误行为。例如，如果测试只检查文件是否存在但不验证内容，Agent 就会学会 touch 空文件而非真正完成写入任务。第二，并非所有实例都适合 RL 训练。 某些任务本身难以通过自动化测试准确评估，它们更容易诱导模型寻找捷径，而不是学习真正的解决方案。识别并移除这类实例，是维护训练信号质量的重要手段。

沙箱环境服务的可观测性同样不可忽视。 在大规模训练中，ROLL 团队同时维持数千级别的并发沙箱会话。环境并发的抖动（如瞬时负载激增、资源回收延迟）会直接影响训练信号的质量——一批 rollout 如果恰好遇到环境慢响应，可能产生系统性的偏差信号。没有系统级的服务观测和告警机制，这类问题极难定位。

一个有趣的正面观察是并行函数调用模式。在对比分析中，Claude Sonnet 4.5 展现出显著更高的并行度——它倾向于在执行具体操作之前，先在同一步骤中通过多个并行的"检查类调用"（如 pwd、ls、python -V、pip list）来收集环境信息。这种"谋定而后动"的模式为训练提供了一个启示：显式鼓励 Agent 在状态变更之前进行一个"前置的、并行的信息收集阶段"可能是有益的。

终端 Agent 最常见的两类失败模式——无效循环（unproductive loops） 和 超时（timeouts）——都反映了模型在元认知层面的缺陷。无效循环说明模型缺乏"识别当前策略已经失败并切换思路"的能力；超时说明模型缺乏对物理世界时间流逝的感知，不知道某个命令（如大规模编译）本身就需要较长时间，结果误判为执行失败而反复重试。这两种能力都很难从静态文本语料中习得，可能需要通过专门设计的 RL 训练信号来培养。

---

21.9.10 全景视角与前沿挑战

到这里，我们已经从理论（三大不变量）、架构（八大支柱）和工程细节（环境管理、数据过滤、训练稳定性、异步管线）四个层面完整地审视了 Agentic RL 训练系统。最后，让我们站在更高的视角来审视这个领域的核心竞争点和前沿挑战。

竞争的核心不在算法。 Agentic RL 的战局已经不再是"谁发明了更好的数学公式"。Kimi、MiniMax、智谱 GLM 等前沿团队正在建立的壁垒在于协同闭环的完整度：更丰富的环境验证覆盖；更高密度的有效学习信号；更一致的训练与部署分布控制；基于极强 Infra 支持下的单位时间有效训练吞吐。

POMDP 的挑战仍未被充分解决。 终端环境本质上更接近部分可观测马尔可夫决策过程（POMDP，见 §21.1）。Agent 通常无法观察到完整的环境状态——文件系统全貌、已安装软件版本、先前修改过的配置——都很难完整呈现。许多训练中遇到的问题，本质上归结为部分可观测性和长程信用分配这两个经典但仍未被彻底解决的难题。

前沿探索方向。 有三个方向值得特别关注：

第一，挖掘更复杂的长时序任务与有效的 Agentic 模式。当前的终端基准测试中大多数任务并非真正的长序任务。另一方面，有些 Agent 能力——如跨平台、跨设备的复杂任务执行流程——在互联网文本中极其稀少（人们记录"如何思考"远多于"如何完成复杂任务"），很难仅靠 RL 自发涌现，需要主动挖掘并强化有效的行为模式。

第二，更真实的 Agent-Environment-Human 闭环优化。真实场景中用户会随时补充信息、修改需求、纠正错误。Agent 必须学会主动获取信息、在不确定时及时确认，并在收到反馈后更新判断——这要求将"提问-反馈-更新信念"的过程纳入训练框架，走向真正的 human-in-the-loop 与 online RL。

第三，更细粒度的信用分配与奖励建模。Agentic RL 比 RLVR 拥有更多可利用的中间信号——工具执行结果、子任务完成情况、环境状态一致性检查等。但依赖手工设计的复杂奖励规则（如"工具失败 $-0.5$"）不是可持续方案。如何自动化地从环境交互轨迹中提取高质量的中间信号，是一个重要的开放问题。一个有希望的方向是训练专门的 Process Reward Model（过程奖励模型），让它学会在 Agent 轨迹的每一个 chunk 上给出有区分度的评分，而非仅依赖最终的结果奖励。

Agentic RL 仍处于早期阶段。 ROLL 团队在总结中坦率地指出："本文中提到的许多技术，可能并非最佳实践或最终方案，主要都是我们在实际实验过程中总结出的经验教训。"这种诚实的学术态度值得重视——它意味着当前的最佳实践可能在一年后被更好的方案替代，但构建和运行完整系统的工程经验具有持久的迁移价值。

本节总结。 Agentic RL 不是 RLHF 的简单升级版——它是一个需要环境、算法和基础设施协同设计的完整系统。三大不变量（可探索空间、非退化信号、可控分布偏移）提供了理论判据；八大支柱（环境建模、探索管理、算力分配、目标函数、异步采样、奖励验证、记忆层级、基础设施）提供了工程框架；而 ROLL 团队的实践经验则告诉我们，在这个领域里，"论文给你的是算法，但不会告诉你轨迹跑到一半环境崩了该怎么办"。能否把这些环节一一理顺、形成可持续运转的协同闭环，才是 Agentic RL 真正的护城河。