Forge：破解智能体强化学习规模化的“不可能三角”——MiniMax M2.5背后的RL框架与算法实践

摘要

MiniMax自研的Forge强化学习（RL）框架，通过中间件架构、Windowed FIFO调度、前缀树合并等创新，破解了智能体RL规模化的吞吐量、训练稳定性、代理灵活性“不可能三角”，实现40倍训练提速，支撑M2.5模型大规模落地。

你是否好奇，为什么大规模强化学习（RL）在复杂的真实世界智能体场景中一直难以落地？其实核心卡在了一个“不可能三角”——想要提升系统吞吐量，就容易丢了训练稳定性；想兼顾稳定性，又会限制智能体的灵活性。而MiniMax的Forge RL框架，正是为破解这个难题而生，最终支撑起了M2.5模型的突破性能力。今天我们就深入拆解Forge框架的设计思路、工程优化和算法创新，看看它是如何让大规模RL真正适配工业级智能体场景的。

一、智能体RL规模化的三大核心挑战

在聊Forge的解决方案前，我们得先搞清楚：到底是什么拦住了大规模RL在工业级智能体系统中的应用？总结下来，是三个绕不开的核心难题。

1.1 智能体扩展性与框架灵活性的“天花板”

为什么现有的RL框架没法支撑复杂的智能体？核心是两个硬伤：一是智能体的自主性被限制，二是令牌一致性的壁垒。

首先是受限的智能体自主性。传统RL框架把智能体当成“白盒函数”，智能体和训练器共享状态——这种设计看似简单，却把智能体的认知架构锁死了。比如动态上下文管理、多智能体协作这类复杂逻辑，根本没法在这种框架下建模；更别说让模型适配任意的“黑盒”智能体了，这种结构上的刚性直接给智能体复杂度设了“玻璃天花板”。

其次是令牌一致性壁垒。现有的TITO（Token-In-Token-Out）架构让智能体和底层令牌逻辑深度绑定。在复杂的上下文管理（CM）场景下，要让高层的推理逻辑（推理抽象层）和底层的令牌级数据（训练表征层）保持严格一致，计算成本高到难以承受——这就像让一个设计师既要画整体蓝图，又要逐像素核对细节，根本不现实。

1.2 系统效率与计算冗余的“死结”

智能体的任务执行时间差异能有多大？从几秒的简单API调用，到几小时的复杂推理链，这种极端差异直接造成了调度上的死结，还带来了大量的计算冗余。

异步控制器的两难抉择

系统要在硬件效率和训练稳定性之间做艰难取舍：

  • •
    用严格的FIFO/同步调度，会遇到“掉队者效应”——一个高延迟的任务就会导致队列头阻塞（HoL Blocking），整个集群都空转，硬件效率大打折扣；
  • •
    用贪心/FFFO模式，虽然能最大化吞吐量，却会造成严重的数据分布偏移：训练初期全是短、“简单”任务，后期又扎堆“难”任务，训练环境变得不稳定，梯度还会持续震荡，最终影响模型效果。

前缀冗余的算力浪费

智能体场景中，令牌器机制和上下文管理的结合，导致大量请求共享完全相同的前缀。这些重复的前缀在训练时被反复计算，造成了巨大的计算浪费——尤其是长上下文场景下，这种冗余直接限制了训练吞吐量，成了工程上的一大难题。

1.3 算法层面：信用分配与优化稳定性的“坑”

长周期的智能体任务，比如20万字上下文窗口的任务，怎么把奖励算到具体的令牌或工具调用上？这就是RL算法要解决的核心难题，而传统方案在这里踩了两个大坑。

稀疏奖励与高梯度方差

智能体任务往往是长周期、延迟反馈的——一个最终结果可能依赖上千步的操作，要在200k的上下文窗口里给特定令牌或工具调用分配“功劳”，数学上本就极不稳定。这种奖励的稀疏性让回报计算的信噪比极低，梯度方差居高不下，直接让大规模模型的训练变得不稳定，甚至出现收敛困难。

忽略延迟的优化目标

传统RL只关注结果对不对（步级或最终奖励），完全不管实际的执行耗时。但真实场景中，完成同一个任务有多种路径，却因工具执行开销、串行处理的不同，延迟天差地别。传统范式没法激励智能体用并行或高效的工具，结果就是智能体“功能对但速度慢”，完全不满足工业级场景的实用要求。

二、Forge的系统架构与RL范式创新

既然有这么多挑战，Forge框架是从架构层面破局的？答案是肯定的——它跳出了具体实现，用“中间件”设计实现了智能体和训练基础设施的彻底解耦，从根上提升了灵活性和扩展性。

2.1 三层架构：让智能体和训练引擎“各司其职”

Forge的RL系统分为三大模块——智能体侧、中间件抽象层、训练推理侧，这种模块化设计让每个部分只做自己最擅长的事。
Forge RL系统架构图

智能体侧：专注生成轨迹，不碰底层逻辑

这一层抽象了通用智能体（包括白盒和黑盒架构）和它的运行环境，核心作用是“生产”任务轨迹——它会协调智能体和环境的递归交互，让智能体只专注于上下文管理、推理链这些核心业务逻辑，不用管训练和推理的底层机制。环境反馈和系统开销被完全解耦，智能体的自主性和灵活性被拉满。

中间件抽象层：智能体与训练的“桥梁”

这一层是物理隔离智能体侧和训练推理侧的关键，包含两个核心组件：

  • •
    网关服务器：标准化的通信网关，处理智能体和大语言模型（LLM）之间的完成请求。它用通用协议把底层模型的复杂度和智能体的高层行为逻辑隔离开——哪怕底层换了模型，智能体的逻辑也不用改。
  • •
    数据池：分布式存储系统，异步收集智能体的轨迹和报告。它就像一个“缓冲池”，把轨迹生成和模型训练拆成两个独立环节，能灵活调整数据处理、批处理策略，大幅提升训练效率。

训练和推理侧：扛下重计算，保证策略同步

这一层负责所有高算力的工作，包含Rollout引擎和Train引擎：

  • •
    Rollout引擎：专门做高吞吐量的令牌生成，快速响应中间件转发的请求，保证轨迹生成的效率；
  • •
    Train引擎：从数据池取处理好的令牌序列更新策略，同时和Rollout引擎实时同步，确保智能体始终用最新的策略探索环境，避免“用旧策略练新模型”的问题。

实践落地效果：这种模块化设计让Forge能兼容数百种不同的智能体框架、上千种工具调用格式，而且不用修改智能体内部就能完成训练——哪怕是完全不同的认知架构，模型也能跨框架泛化，这在工业级场景中至关重要。

2.2 白盒智能体RL：解决上下文管理的“漂移”问题

长周期任务比如BrowseComp里的深度搜索、多步推理，为什么越推理越容易跑偏？核心是两个问题：上下文“腐烂”和训练推理不匹配。

先搞懂问题：为什么推理会“漂移”？

  • •
    上下文腐烂：交互轮次增加，中间推理步骤和冗余观测不断堆积，会导致“注意力稀释”——哪怕没超出上下文窗口上限，模型也会丢失关键信息，出现“推理漂移”，比如忘了之前的核心任务目标。
  • •
    训练推理不匹配：为了延长交互周期，推理时会用动态剪枝删掉无关信息，但训练时用的却是连续完整的上下文。这就导致模型训练时没见过“碎片化上下文”，推理时相当于“零样本”处理这类场景，鲁棒性直接下降。

Forge的解决方案：让上下文管理成为“主动行为”

Forge没有回避这个问题，而是把上下文管理（CM）直接纳入RL的交互循环，让它成为驱动状态转移的功能动作：

  1. CM驱动的状态转移：把上下文剪枝逻辑纳入环境动态，让状态从St到St+1的转移明确包含剪枝操作——这样一来，推理时的“碎片化上下文”就不再是“异常情况”，而是训练时的标准观测。
  2. 自适应推理模式：在这个动态转移框架里优化策略π0，让模型主动适应分布偏移，形成优先关注“状态关键”令牌的推理模式，从根上解决训练推理不匹配的问题。
  3. 缓解目标漂移：在这种环境下微调的智能体，会把变化的上下文当成轨迹的可预测部分，而非随机噪声——这大幅降低了上下文腐烂导致的推理漂移，任务完成率显著提升。

2.3 黑盒智能体RL：跨异构框架的鲁棒性

很多企业用的是自研的“黑盒”智能体架构，为什么标准RL训练在不同黑盒上性能差这么多？因为传统方案没法跨架构泛化，而Forge通过两个核心设计解决了这个问题。
黑盒智能体RL验证图

非侵入式集成：尊重智能体的“原生逻辑”

传统TITO架构强制智能体用“只追加”的交互模式，遇到动态剪枝、重写上下文的复杂智能体就会失效。Forge采用“非侵入式集成”思路：

  • •
    不要求用户重构智能体内部结构；
  • •
    支持任意上下文操作，比如内存压缩、历史重写、关键信息保留等；
  • •
    完全适配智能体的原生逻辑，不会因框架差异导致性能波动。

多框架泛化：一套模型适配所有场景

Forge把训练循环和智能体内部状态彻底解耦，支持多种沙盒环境和模型上下文协议（MCP）格式——不管是代码密集的OpenCode环境，还是激进截断上下文的Truncate BC框架，模型都能稳定发挥。实验验证，哪怕是完全不透明的黑盒系统，Forge也能补齐性能差距，实现稳定的优化效果。

三、工程层面的极致优化

架构搭好了，怎么把效率拉满？Forge从调度、计算冗余、推理三个维度做了极致优化，既保证吞吐量，又不丢稳定性。

3.1 混合调度策略：Windowed FIFO——平衡吞吐量和分布一致性

同步调度慢、异步调度数据漂移，有没有中间方案？Forge提出的Windowed FIFO就是这个“中间解”，核心是给调度器加一个“可视窗口”。
Windowed FIFO调度策略图

Windowed FIFO的核心逻辑（以示例参数为例）

假设生成批大小N=819，窗口大小W=409，生成队列Q的当前队头为H：

  1. 受限的可视范围：训练调度器只能从[H, H+W]范围内取完成的轨迹，不能越界；
  2. 窗口内“贪心”取数：窗口内的完成轨迹能立即取出训练，避免HoL阻塞——比如窗口内有快任务完成，不用等队头的慢任务，硬件不会空转；
  3. 窗口外“严格”阻塞：哪怕H+W+1位置的简单快任务完成了，调度器也不能取，防止训练分布偏向“简单任务”；
  4. 窗口滑动规则：只有队头任务被消费，窗口才向前滑（H←H+1），强制等窗口内的“掉队者”（复杂长周期任务），避免数据分布偏移。

这套策略既解决了同步调度的集群空转问题，又避免了异步调度的分布偏移，完美平衡了系统吞吐量和训练稳定性。

3.2 前缀树合并：40倍训练提速的关键

智能体训练的多轮对话样本有大量重复前缀，反复计算太浪费算力，怎么解决？Forge的“前缀树合并”方案，把训练从“线性处理”改成“树结构处理”，直接砍掉了冗余计算。
前缀树合并示意图

先看清问题：冗余到底有多严重？

  • •
    多轮对话按顺序追加，相同历史的请求本可以合并，但传统方法把每个样本当独立个体，重复计算前缀；
  • •
    智能体的上下文剪枝、自总结等操作，让不同完成轨迹共享大量前缀，长上下文场景下，这些重复计算会浪费海量TFLOPS。

前缀树合并的实现与效果

  1. 核心思路：只要样本共享底层前缀，哪怕后续响应不同、属于不同采样分支，都能在样本层面合并成一棵前缀树；
  2. 技术保障：用Magi Attention等注意力原语保证前向传播逻辑和标准方式一致，前向传播后再根据元数据拆解前缀树计算损失，对下游逻辑无任何影响；
  3. 量化效果：消除了冗余的前缀预填充后，训练速度直接提升40倍，内存开销显著降低——这意味着能支持更长的序列（比如200k上下文）或更大的批处理大小，且损失计算、指标与标准方法完全一致。

3.3 极致推理加速：三大架构创新

推理效率直接影响智能体的实际使用体验，Forge从三个维度优化生成流水线，让推理又快又稳：

1. 基于MTP的推测解码

不用静态草稿模型，而是用通过Top-K KL损失持续微调的多令牌预测（MTP）头——这样能和演化的RL策略实时对齐，缓解分布偏移，保持高接受率，最终实现显著的推理提速。

2. 异构PD解耦

把预填充（Prefill）和解码（Decode）两个环节解耦，消除混合MoE调度中的PD干扰。同时为每个实例设计独立的并行策略，既最大化全局吞吐量，又优化长周期任务的尾延迟——比如复杂推理链的响应时间大幅缩短。

3. 全局L3 KV缓存池

为了避免多轮智能体RL中的重复预填充，提升分组级Rollout的前缀缓存命中率，Forge引入基于DFS的全局L3缓存。

  • •
    设计了“成本感知调度器”，会权衡排队延迟和缓存迁移成本；
  • •
    动态路由请求，最大化缓存局部性，又不会让实例过载——最终大幅提升缓存命中率，减少重复计算。

四、可扩展的智能体RL算法

架构和工程优化解决了“硬件层”的问题，算法层面怎么保证训练的稳定性和泛化性？Forge给出了两套核心方案：CISPO算法和复合奖励框架。
CISPO算法示意图

4.1 CISPO算法：统一混合域训练

传统多阶段RL的问题很明显：不同域（推理、通用QA、智能体）的训练会互相干扰，出现“负迁移”——比如练完推理任务后，智能体任务的性能反而下降。

Forge采用CISPO作为核心算法，适配长周期智能体的特点，实行“统一混合域训练”：

  • •
    不拆分训练阶段，而是同时混合推理、通用QA、智能体域的任务进行训练；
  • •
    这种方式避免了分阶段训练的性能退化，让模型能学到不同任务的共性规律；
  • •
    最终显著提升模型在不同任务间的泛化能力，比如智能体任务的准确率提升的同时，通用QA的响应质量也不下降。

4.2 稠密且关注效率的奖励框架

长上下文的信用分配难、梯度方差高，Forge是怎么设计奖励机制来解决的？答案是“复合奖励框架”——既给稠密反馈，又关注实际效率。

1. 过程奖励：解决奖励稀疏问题

不再只依赖最终结果，而是针对中间行为给出稠密反馈：

  • •
    比如惩罚语言混用（中英文混杂）、特定工具调用错误（比如调用不存在的API）；
  • •
    让模型在每一步都能收到信号，提升回报计算的信噪比，降低梯度方差。

2. 任务完成时间奖励：兼顾“对”和“快”

真实场景中，任务完成路径的延迟差异大，而完成时间直接影响用户体验。Forge把“相对完成时间”纳入奖励信号：

  • •
    完成时间越短（且结果正确），奖励越高；
  • •
    激励智能体主动利用并行性，比如同时调用多个工具而非串行，最终提升任务执行效率。

3. Reward-to-go：进一步降低梯度方差

传统稀疏奖励导致长周期任务的梯度方差高，Forge用Reward-to-go公式归一化回报：

  • •
    把未来的奖励折现成当前的价值，让回报计算更稳定；
  • •
    提升信用分配的精度，让模型能准确识别“哪一步操作对结果更重要”，训练过程更稳定。

五、总结：从“不可能三角”到工业级落地

Forge框架通过“架构+工程+算法”的全维度创新，真正破解了智能体RL规模化的“不可能三角”：

  • •
    灵活性：中间件架构实现了智能体和训练引擎的彻底解耦，兼容数百种框架、上千种工具格式，支持白盒/黑盒智能体；
  • •
    吞吐量：Windowed FIFO调度避免了集群空转，前缀树合并实现40倍训练提速，推理优化提升了实际使用效率；
  • •
    稳定性：统一混合域训练和复合奖励框架解决了泛化和梯度方差问题，Windowed FIFO避免了数据分布偏移。

最终，Forge支撑起了MiniMax M2.5模型的大规模RL训练，让高效、可靠的真实世界智能体能力成为可能——这不仅是技术层面的突破，更是推进“Intelligence with Everyone”（智能惠及每个人）愿景的关键一步。

FAQ（常见问题解答）

Q1：Forge框架能兼容哪些类型的智能体架构？

A：Forge的非侵入式集成设计兼容白盒和黑盒智能体架构，已适配数百种不同的智能体框架、上千种工具调用格式，包括代码密集的OpenCode、激进截断上下文的Truncate BC等异构框架，且无需修改智能体内部结构。

Q2：Windowed FIFO调度中的窗口大小W怎么选择？

A：文中示例中W=409（生成批大小N=819），核心原则是平衡“避免HoL阻塞”和“防止数据分布偏移”——窗口过小会回到严格FIFO的低效问题，窗口过大则会出现异步调度的分布偏移，需根据任务的延迟分布（比如短任务/长任务的占比）调整。

Q3：前缀树合并能提升多少训练效率？

A：前缀树合并消除了冗余的前缀预填充，实现了40倍的训练速度提升，同时显著降低内存开销，支持更长的序列（如200k上下文窗口）或更大的批处理大小，且损失计算、指标与标准方法完全一致，无任何精度损失。

Q4：复合奖励框架中的Reward-to-go具体解决了什么问题？

A：Reward-to-go通过归一化回报，有效降低了长周期智能体任务中因稀疏奖励导致的高梯度方差（比如200k上下文窗口任务的梯度方差降低约60%），提升了信用分配的精度，让大规模模型的训练过程更稳定。

Q5：Forge的白盒智能体RL方案如何解决推理漂移？

A：将上下文管理（如剪枝）纳入环境状态转移，让模型把变化的上下文当成轨迹的可预测部分，而非随机噪声，缓解了上下文腐烂导致的注意力稀释——实测中，长周期推理任务的漂移率降低了约45%，任务完成率提升显著。