Qwen开源QwenGyre：面向超长任务智能体的弹性强化学习框架

训练能完成超长复杂任务的 AI Agent，一直是强化学习工程中最棘手的环节。Qwen 团队最新开源的 QwenGyre 试图正面解决这个问题——它把弹性调度和轨迹处理引入极端长时程（XLong）的 Agent 训练，并在一个 2.4T 参数级别的模型上验证了效果。

为什么长时程 Agent 训练这么难

传统的 Agent RL 训练大多假设任务在几百到几千个 token 内完成。一旦任务变成需要多轮工具调用、子代理协作、失败重试的真实软件工程任务，单次 rollout 轻松突破十万甚至几十万 token，整个训练循环的算力和工程复杂度都会失控。

QwenGyre 的定位正是这个场景：extreme-long-horizon（XLong）agent training。它要处理的不只是序列长，还包括执行过程中不断分叉的行为——压缩上下文、派生 sub-agent、失败重试，这些都会让训练样本数量爆炸，而其中大量内容高度重复。

什么是 RL 训练中的 rollout？

在强化学习语境下，rollout 指的是让当前策略模型在环境中实际执行任务、并采集轨迹数据的过程。对语言模型 Agent 而言，一次 rollout 就是从接收 prompt 开始，模型一步步生成 token、调用工具、观察返回结果、再继续决策，直到任务终止或达到轮数上限，整条记录成为一条轨迹样本。训练阶段则用这些固定下来的轨迹计算策略梯度、更新参数。

关键在于二者的资源特性完全不同：rollout 是自回归的、串行的、显存占用随上下文不断增长，且延迟高度不确定；training 则是批量的、并行的、算力密度稳定。在传统短任务设定下，二者可以用同一批 GPU 轮流执行而不致冲突；但当时程拉长到几十万 token、轨迹长度差异巨大时，谁先完成、谁在等待就变成尖锐的调度问题。这也正是 Elastic Scheduler 想要解耦的结构性矛盾。

两项核心设计：Elastic Scheduler 与 Trajectory Processor

Elastic Scheduler：让 GPU 在 rollout 和 training 之间弹性流动

Agent 训练的一个结构性矛盾是：rollout（模型实际执行任务）和 training（更新参数）对算力的需求随时间剧烈波动。传统做法要么把两者放在同一批 GPU 上（Colocate），要么用异步流水线解耦，前者互相抢占资源，后者引入策略滞后。

QwenGyre 的 Elastic Scheduler 会在 rollout 与训练之间动态重新分配 GPU。关键在于，这种重新分配是" live "的——正在执行中的任务不会被中断，避免了因资源切换导致的轨迹作废。官方数据显示，相比 Colocate 方案最高带来 1.85× 加速，相比 Async 方案为 1.78×。

Colocate 与 Async 两种经典调度范式

Colocate（共置）指把 rollout 和 training 放在同一组 GPU 上交替执行：一部分时间跑采样，一部分时间跑更新，资源共享池、通信开销小，但两者会互相争抢显存与算力，且必须严格串行，任一阶段拖慢整体吞吐。Async（异步）则把两者拆到不同 GPU 组上并行运行，采样和训练互不阻塞，吞吐更高，代价是"策略滞后"——训练用的数据来自稍早版本的模型，与当前策略存在分布偏移，可能损害收敛稳定性和最终效果。

QwenGyre 的 Elastic Scheduler 试图同时吃掉两者的优点：GPU 池不再固定归属，而是根据 rollout 队列与 training 队列的实时压力动态划拨，且迁移过程不打断正在执行的任务，避免了"为了重新分配资源而丢弃半条轨迹"的浪费。1.85×（对比 Colocate）与 1.78×（对比 Async）的加速，本质上来自这种"既不互相抢占、也不牺牲策略新鲜度"的折中。

Trajectory Processor：把分叉执行整理成前缀共享树

如果说调度器解决的是"算力怎么分"，Trajectory Processor 解决的是"样本怎么管"。

Agent 的一次执行天然是一棵树而不是一条线：同一个前缀可能衍生出压缩后继续、派出 sub-agent、或直接重试等多条分支。如果按叶子节点逐条存储，样本会大量冗余。QwenGyre 把这些分支整理成前缀共享的轨迹树（prefix-shared trajectory trees），从而得到有界且去重后的训练样本集合。

一个容易被忽视但很实用的设计是：即使任务在超时后才部分完成，这部分进展仍然会被打分。这意味着一棵树上"没走完的枝干"也能贡献梯度信号，而不是被直接丢弃——在长任务里，这能显著提升样本利用率。

前缀共享树为什么能省样本

假设一个 Agent 任务在某一步决定派生 sub-agent，随后又因失败回退到同一位置重试，那么这两条分支的前 N 个 token 是完全相同的。如果按叶子节点逐条存储，同一段前缀会被重复保存多次；在一个会反复压缩上下文、反复重试的长任务里，这种冗余可能达到数倍乃至数量级。

前缀共享轨迹树的做法是把公共前缀合并成一个节点，只在真正分叉处分裂枝干，整棵树共用存储与计算。这带来两个直接收益：一是训练样本集合变得"有界"，不会因子代理派生的递归嵌套而无限膨胀；二是前向计算的 KV 缓存与注意力计算可以在共享前缀上复用，显著降低长上下文下的显存与算力开销。配合"超时后的部分进展仍计入打分"这一设计，被压缩、被打断、走岔的枝干都不再是纯粹的浪费，而成为有效的梯度来源。

实测：Qwen3.8-2.4T-A95B 上的表现

QwenGyre 在一个大规模 MoE 模型 Qwen3.8-2.4T-A95B 上进行了验证，单次 rollout 约 70 万 token 量级。

在 NL2RepoBench（自然语言到代码仓库的生成任务）上，QwenGyre 仅用 48 步就把成绩从 52.5% 提升到 58.5%，端到端训练时间相比 Async 方案缩短约 44%。这个组合值得关注：既涨点，又快——通常长时程 RL 的改进会以训练时间暴涨为代价。

论文链接：arxiv.org/abs/2609.33848

MoE 与 A95B 命名的含义

Qwen3.8-2.4T-A95B 中的 2.4T 指模型总参数量约 2.4 万亿，A95B 中的 A 代表 Activated，即每次前向实际激活的参数量约为 950 亿。这种"总参数大、激活参数小"的结构就是混合专家模型（MoE）：前馈层被拆成多个专家，每个 token 经由路由机制只被分配到少数几个专家计算，因此推理成本大致与激活参数量挂钩，而非总参数量。

MoE 对长时程 Agent 训练尤其友好——它让单次 rollout 承载 70 万 token 量级的序列在算力上变得可行，同时保持了远超稠密模型的容量，用以记住复杂的工具调用模式与失败恢复策略。理解这一点，才能体会 QwenGyre 的调度与轨迹优化为何值得在如此规模的模型上验证：参数量越大、序列越长，训练框架层面的调度浪费与样本冗余被放大得越严重，优化收益也越可观。

对 Agent 训练工程的意义

QwenGyre 的价值不在某个单点算法，而在于它把长时程 Agent RL 中被默认接受的几个工程假设逐一改写：算力分配可以弹性且不中断执行、分叉轨迹可以被结构化复用、部分进展可以计入训练信号。

对正在做 Agent 后训练或 RL 基础设施的团队来说，这套设计思路比具体的加速数字更值得参考——它提示了一个方向：当任务时程变长，训练框架的重心会从"如何高效跑一步"转向"如何高效管理一棵不断分叉、不断超时、不断重复的执行树"。