Forge: 大规模原生 Agent RL 系统

Forge: 大规模原生 Agent RL 系统

1. 问题建模

1.1 Agent可扩展性与框架灵活性

• Agent 自由度受限 ：将 Agent 视为白盒就要求在 Agent 和 RL Framework 之间共享和传递状态。这种设计难以对复杂的 Agent 架构（如动态上下文管理、Multi-Agent RL等）进行建模，导致模型能力无法在复杂的黑盒Agent上有效泛化。

• Token 一致性问题 ：现有的 TITO（Token-In-Token-Out）模式迫使 Agent 与底层的 Tokenizer 逻辑深度耦合。在复杂的上下文管理机制下，要想维持 Agent 和 RL 之间的严格一致性，其工程成本是非常大的。

1.2 系统效率与计算冗余

• 训推异步调度逻辑 ：跑过异步 RL 的同学都知道，在 MFU 和 RL 算法稳定性之间权衡是非常复杂的。严格的 FIFO(First In First Out)/同步调度会被于长尾样本 block；而 Greedy/FFFO(First Finish First Out) 虽然最大化了吞吐量，却带来了不可控的 distribution shift，极易导致 RL 中途崩掉。

• 前缀冗余 ：在多轮 Agent 请求和 group-level 的 Rollout 中，Tokenizer 的 encode-decode 不一致性和上下文管理机制，会导致请求间共享了大量的前缀，这种冗余在训练期间造成了巨大的计算浪费。

1.3 Credit Assignment与优化稳定性

• 稀疏奖励问题 ：复杂的 Agent 任务的 trajectory 通常包括长达数千步，使得基于稀疏奖励的 credit assignment 在数学上非常不稳定。这种稀疏性导致回报计算中的信噪比极低，引起高梯度方差，破坏了大规模模型训练的稳定性。

• Long CoT 的负面影响 ：在 R1 出来之后大家的 RL 都很关注 response length 的增长。但在真实的 Agent 场景中，用户其实对执行时间非常关注，如果不加以限制可能会导致训出来的模型虽然刷榜很强，但用户体验很差。

2. 系统架构与 Agent RL范式

2.1 RL系统设计

• 1. Agent ：该层抽象了通用 Agent（涵盖白盒和黑盒架构）及其运行环境。它负责协调环境交互，使Agent成为一个纯粹的 Trajectory Producer 。通过将环境交互与 LLM generation 解耦，Agent可以专注于核心业务逻辑（如 context management 和复杂的环境交互等），而无需关心底层的训练和推理细节。

• 2. 中间件抽象层 ：作为桥梁，该层在物理上将Agent 侧与训练/推理引擎隔离。

• Gateway Server ：充当标准化通信网关，处理Agent与LLM之间的交互请求。通过通用标准协议，它有效地将底层模型的复杂性与Agent的高层行为逻辑隔离开来。

• Data Pool ：作为分布式数据存储，异步收集trajectory和process signal。它充当生成和训练解耦的缓冲区，允许灵活的数据处理和批处理策略。

• 3. 训练与推理引擎 ：

• Rollout Engine ：专用于高吞吐量 Token 生成，响应 Agent 的生成请求。

• Train Engine ：通过Scheduler从 Data Pool 中 fetch 数据，更新 Agent model，并与采样引擎保持同步，确保Agent使用最新的策略分布进行探索。

2.2 白盒 Agent RL：以上下文管理为例

• 上下文场景性能退化 ：随着交互轮次增加，中间推理和冗余观察的积累会产生“注意力稀释”。这种噪声会导致模型在绝对上下文窗口内对关键信息失去焦点。

• 训推不一致 ：虽然上下文管理可以延长交互周期，提升 Agent 在长上下文场景的表现，但仅在推理时使用会由于偏离RL训练的数据分布，迫使模型在推理时被迫接受上下文变迁，处理不常见的长下文，从而影响模型表现。

• CM 驱动的状态转换 ：我们将CM建模为agent action，而上下文变迁则蕴含在环境的 dynamics 中。状态从 S t 到 S t+1 的转换隐式包含了上下文切换的逻辑，将上下文适应包含在了模型的训练目标中。

• 自适应推理模式 ：通过在此框架内优化策略 π ，模型学会了内化分布偏移，涌现出优先关注 State-critical Token 的鲁棒推理模式。

• 感知上下文管理策略 ：在该策略下，模型在RL生成过程中就需要学会预见可能的上下文管理和改变，模型通过主动保留与目标任务相关的信息和减少无关上下文信息，大幅提升了在 Context-Management Agent 下的性能。

2.3 黑盒 Agent RL：跨框架的鲁棒性

• 非侵入式集成 ：Forge 不感知 Agent 内部的实现细节，内部只需要将请求打到 RL 服务的GateWay，框架内部即可进行数据收集和训练，因此在实际 RL 训练时可以兼容任意上下文操作（如记忆压缩、历史重写），任意内部的Agent Loop（例如 Deep Think、Multi-Agent 等等）。

• 多框架泛化 ：通过将训练循环与Agent内部状态解耦，Minimax-M2.5广泛适配大量黑盒Agent——无论是以沙盒+MCP环境为主的代码Agent（例如我们将 Opencode Agent 直接视为一个黑盒Agent来训练），还是使用激进上下文缩减策略的Agent（如 Truncate BC）。实验表明，该方法在完全不透明的黑盒系统上依然能带来稳定的提升。

3. 工程优化

3.1 混合调度策略：Windowed FIFO

• 受限可见性 ：调度器只能从 [H, H+W] 范围内获取已完成的轨迹。

• 局部贪婪（窗口内） ：在活动窗口内，调度器可立即提取任何已完成轨迹，避免了队头阻塞（HoL），快速任务无需等待头部任务完成。

• 全局严格阻塞（窗口外） ：即使索引为 H+W+k 的任务已完成，调度器也 禁止 获取它。

• 约束推进 ：只有当头部的任务被消费时，窗口才向前滑动（ H ← H + 1）。这迫使调度器必须等待当前窗口内的“长周期落后任务”，防止训练分布向“快而简单”的样本严重偏移。

3.2 Prefix Tree Merging

• 只要共享基础前缀，Completions 就能在样本级别合并到一棵前缀树中（即使后续响应或采样分支不同）。

• 通过利用 Attention Mask 原语（如 Magi Attention）表示不同 branch 之间的依赖关系，可以保证前向计算在数学上与 naive 方案完全一致，在计算 loss 时，我们会把前缀树 unmerge 为序列的格式，不影响后续的 loss 计算和指标统计。

• 该方案消除了冗余的前缀，相比于 naive 方案实现了约 40倍的训练加速 ，且显著降低了显存开销。

3.3 推理加速

• Dynamic MTP ：首先我们引入 MTP 进行推理加速，同时为了保证训练过程中维持 draft model 的高接受率，我们通过 Top-K KL Loss在RL过程中持续训练 detached MTP Head，与 RL policy保 持对齐。

• Rollout 侧的 PD 分离 ：PD分离可以消除 MoE 调度中的 PD 干扰，为每个实例提供独立的并行和生成策略，在最大化吞吐量的同时优化长尾样本的延迟，防止极端样本阻塞 FIFO scheduler，并带来较高的 offpolicy。

• 全局 L3 KV Cache Pool ：在多轮和超长上下文的 Agent 场景下，请求间拥有极高的共享前缀比例，但是局部的 kv cache 受容量限制，无法达到满意的 prefix cache 命中率，甚至在 RL batch size 极大的情况下，会发生大量由于驱逐导致的重计算，因此需要支持全局的 L3 KV cache。同时，Forge 还通过 scheduler cost-aware 的调度机制，权衡排队延迟和缓存传输时间来动态路由请求，在不使实例超载的前提下最大化缓存局部性。

4. Scalable Agent RL 算法

4.1 Dence & Process Reward

• 过程奖励（Process Reward） ：监督 Agent 的中间行为（如惩罚语言混合或特定工具调用错误），提供密集反馈，而不只依赖最终结果。

• 任务完成时间奖励 ：将相对完成时间作为奖励信号。因为真实延迟不仅取决于 Token 生成，还受工具执行和子 Agent 调用影响，这能激励 Agent 主动利用并行策略、选择最短的执行路径来加速任务。

• 用于降低方差的后续奖励（Reward-to-go） ：长周期任务的稀疏奖励容易引发高梯度方差。我们使用 Reward-to-go 来标准化回报，大幅提高了信用分配的精度，稳定了优化过程。