QwenGyre瞄准超长程 Agent 训练，阿里用弹性调度解决 GPU 空转

阿里千问于 2026 年 10 月 12 日正式发布在线强化学习框架 QwenGyre，目标是解决长程智能体训练中最棘手的两个问题：任务执行时间差异过大导致 GPU 空转，以及复杂交互产生大量难以直接利用的冗余轨迹。

这不是又一个把模型、环境和训练器拼在一起的通用强化学习工具。QwenGyre 面向的是更具体、也更接近真实生产任务的一类场景：让 Coding Agent 自主修改代码、运行测试、定位报错、反复编译，再完成一次完整的软件工程任务。这样的任务通常持续数小时，包含数百轮模型与环境交互，单条 rollout 轨迹累计处理的上下文可达到约 70 万 Token，甚至接近百万 Token。

长程 Agent 正在改变强化学习的系统瓶颈

长程智能体是指需要经过大量连续决策和环境交互，才能完成最终目标的 AI 智能体。它与一次输入、一次输出的问答模型不同，任务结果往往取决于数十到数百个中间步骤是否能够持续推进。

以代码开发为例，智能体可能先读取仓库结构，再修改多个文件，执行测试，分析编译错误，回滚错误改动，重新设计实现，最后提交可运行的结果。每一步都会改变后续环境，早期决策产生的文件、日志、命令输出和失败经验，也会继续留在后续上下文中。

问题在于，传统在线强化学习系统通常按照相对固定的节奏组织 rollout 和训练。智能体完成任务的速度却并不稳定：有些任务几分钟内就因明显错误失败，有些任务需要数小时才能得到有效结果。只要有一条长任务没有结束，相关计算资源就可能被占用，而训练侧的 GPU 则只能等待。

这种现象可以理解为流水线中的“最长任务拖慢全局”。即使大部分采样任务已经结束，训练也往往要等到一个批次全部收齐后才能启动。任务越长、耗时差异越大，等待时间越明显，硬件利用率也越低。

长程任务的第二个问题是轨迹会快速膨胀。智能体在执行过程中可能尝试多个方案、回滚代码、重复读取文件，或者因为环境反馈不明确而陷入循环。若把所有交互历史完整保存并送入训练，训练数据会包含大量重复路径和低价值片段，反向传播的显存和计算成本随之上升。

QwenGyre 的核心：让 GPU 随任务进度流动

QwenGyre 的弹性调度机制会把 GPU 划分为多个可动态调整的计算单元，并根据 rollout 任务的完成情况，在采样和训练之间重新分配资源。

一批任务中，只要部分任务已经完成，对应的计算单元就可以立刻转入训练，而不必等待仍在执行的任务结束。仍在运行的智能体不会被强行终止，任务状态、执行进度以及已经计算出的缓存会被保留并迁移到新的资源安排中。

这个机制的关键价值是减少“等最慢任务”的时间。传统同步方案像是要求所有项目组成员同时交付后才能开会，最慢的人决定会议开始时间；QwenGyre 则允许先完成的人先进入复盘，剩余成员继续工作，训练资源因此能够更早开始产生有效计算。

QwenGyre 还允许新释放出的计算单元直接加入当前训练轮次。计算速度更快的任务可以贡献更多训练机会，最后再由核心计算单元汇总结果并完成参数更新。对于执行时间方差极大的 Agent 任务，这比固定切分 rollout GPU 和训练 GPU 更符合实际负载。

官方目前披露的重点是端到端加速和不中断的资源重分配，但没有公开调度粒度、缓存迁移的具体开销，以及不同 GPU 拓扑下的扩展效率。因此，QwenGyre 的工程优势已经有基准结果支持，但其在更大规模集群上的调度边界，仍需要后续开源代码和更完整实验数据验证。

Token-in Token-out：不再粗暴保存整条轨迹

Token-in Token-out 是一种记录模型每次生成时真实输入上下文和输出 Token 的轨迹记录方式。它的作用不是简单保存最终文本，而是还原每一次模型调用实际看到了什么，以及这次调用产生了什么结果。

对于长程智能体而言，同一段历史可能被多个后续步骤共享。如果把每一步都展开成独立样本，系统会反复复制相同的上下文，产生明显的存储和训练浪费。QwenGyre 会根据共享前缀组织轨迹树，让具有共同历史的路径共享前置内容。

训练阶段，框架只展开被选中的路径，将其转化为训练样本。这样做相当于把一棵包含大量尝试和分支的执行树，裁剪成若干条更有价值的训练路径。它并没有消除智能体执行中的试错，而是避免让所有试错都以同等成本进入后续训练。

轨迹树的另一个意义是保留了长程任务的结构信息。一次失败不一定意味着整条轨迹都没有价值：前几十步可能已经正确完成环境准备，真正的问题只出现在后续某个操作。若系统只能给整条任务一个成功或失败标签，就会丢失大量中间进展。

Partial Scoring 让“未完成”也能产生反馈

Partial Scoring 是对部分完成任务进行阶段性评分的机制。它允许系统根据任务已经完成的有效步骤，为尚未最终成功的 rollout 提供训练反馈。

在代码 Agent 场景中，一个最终失败的任务可能已经完成了依赖安装、定位了关键文件、修复了部分测试，或者将错误范围缩小到某个函数。如果因为最终没有通过全部测试，就把这条轨迹标记为完全无效，训练过程会浪费这些中间信息。

QwenGyre 的设计意图是把这些阶段性成果纳入轨迹处理流程，让超时任务和部分完成任务也能贡献信号。这对数小时级别的任务尤其重要，因为长任务天然更容易受到超时、环境异常和偶发错误影响。

不过，部分评分并不等于已经解决了长程任务的信用分配问题。如何设计可靠的阶段性奖励，如何避免模型通过完成容易步骤而获得虚高分数，以及部分奖励如何进入策略更新，仍然取决于具体任务环境和评分函数。当前公开资料介绍了机制方向，但没有给出 Partial Scoring 的详细公式、评分误差或消融实验结果。

基准结果：48 步训练后通过率提升 6 个百分点

QwenGyre 在 NL2RepoBench 在线强化学习实验中，以每次 rollout 约 70 万 Token 的任务开展训练。经过 48 步训练，模型通过率从 52.5% 提升至 58.5%，绝对提升 6.0 个百分点。

| 指标 | QwenGyre 实验结果 | |---|---:| | 单次 rollout 规模 | 约 70 万 Token | | 训练步数 | 48 步 | | 训练前通过率 | 52.5% | | 训练后通过率 | 58.5% | | 通过率绝对提升 | 6.0 个百分点 | | 相对 Async 实现端到端加速 | 1.78 倍 |

在相同 GPU 预算下，QwenGyre 相比 Async 实现实现 1.78 倍端到端加速，同时训练分数与 Async、Colocate 方案接近。这个结果说明，QwenGyre 的主要收益目前来自系统效率，而不是通过牺牲模型训练效果换取更高吞吐。

这里需要区分“通过率提升”和“训练加速”两个指标。52.5% 到 58.5% 反映的是模型在 NL2RepoBench 上的任务表现变化；1.78 倍反映的是相同 GPU 预算下的端到端训练效率。前者说明训练有效，后者说明系统减少了等待和无效计算，两者不能简单相加或互相替代。

阿里还在 Qwen3.6-122B 上进行了跨任务验证，覆盖 NL2RepoBench、DeepSWE 和 TerminalBench 三类任务，并报告了端到端提速。公开材料没有给出这三个基准分别对应的具体加速倍数，因此目前更适合将其理解为跨任务有效性验证，而不是完整的横向性能排名。

QwenGyre 和传统方案差在哪里

QwenGyre 的核心差异不在于重新发明一种强化学习目标函数，而在于重新组织长程 rollout 的计算和数据。

| 方案 | 资源组织方式 | 长程任务中的主要问题 | 适用特点 | |---|---|---|---| | Colocate | rollout 与训练共享或紧密绑定资源 | 任务耗时差异大时容易互相等待 | 架构直接，适合较短或负载稳定的任务 | | Async | rollout 与训练异步运行 | 资源利用率较高，但长轨迹管理和数据一致性更复杂 | 适合持续产生样本的在线训练 | | QwenGyre | 根据任务完成情况弹性重分配 GPU | 需要处理状态迁移、轨迹树和动态训练批次 | 面向数小时级、数十万 Token 以上的长程 Agent |

Async 架构的优势是采样和训练可以并行，但它并不天然解决单条任务过长、任务之间耗时差异巨大，以及轨迹分支数量快速增加的问题。QwenGyre 的重点是把在线强化学习的资源调度和轨迹整理放到同一个端到端系统中处理。

Colocate 方案则更容易理解和部署，但采样与训练之间的资源耦合更强。当一批 rollout 的完成时间差距拉大时，空闲 GPU 很难及时转移到训练任务。QwenGyre 的弹性资源机制，正是针对这一点进行优化。

这对 Agent 训练意味着什么

QwenGyre 的发布说明，长程 Agent 的竞争已经从单纯比较模型参数和基准分数，进入比较训练系统效率的阶段。

当任务从“生成一个函数”扩展到“维护一个代码仓库”，模型能力不再只由一次前向推理决定。它还取决于环境执行速度、上下文管理、失败恢复、轨迹筛选、奖励设计以及训练集群能否持续提供有效更新。

过去，增加 GPU 数量通常是提高训练吞吐的直接方式；但在长程任务中，瓶颈可能不是总算力，而是算力是否在正确时间被分配给正确阶段。如果一部分 GPU 被慢任务长期占用，另一部分 GPU 又在等待训练批次，继续扩容未必能得到线性收益。

QwenGyre 将“任务进度”作为资源调度依据，这个方向对 Coding Agent、深度研究 Agent、终端操作 Agent 和复杂工作流 Agent 都有参考价值。只要任务具备长时间运行、环境反馈密集和成功条件可验证等特征，就可能从类似的调度与轨迹处理机制中受益。

仍需关注的三个问题

第一，QwenGyre 的开源范围和易用性将决定它能否被广泛采用。长程在线强化学习涉及模型服务、环境沙箱、分布式调度、缓存迁移和训练器协同，仅发布框架名称并不足以降低复现门槛。开发者还需要看到完整代码、部署文档、硬件要求和可复现实验配置。

第二，Partial Scoring 的质量会直接影响训练上限。阶段性奖励越接近真实任务目标，越能帮助模型学习有效的中间策略；评分函数若存在漏洞，模型也可能学会钻奖励空子，而不是完成最终任务。

第三，1.78 倍加速需要结合任务规模和比较基线理解。该数字来自 NL2RepoBench、约 70 万 Token rollout 和相同 GPU 预算的实验，不能直接外推到所有模型、任务和集群。尤其是更短任务、更稳定的 rollout，可能无法充分体现弹性调度的优势。

判断：它解决的是 Agent 规模化训练的基础设施问题

QwenGyre 的价值在于，它把超长程 Agent 训练中最现实的系统问题摆到了核心位置：任务不再整齐结束，轨迹不再是简单线性文本，失败也不再意味着整条样本毫无价值。

从已披露结果看，QwenGyre 在 NL2RepoBench 上用 48 步训练将通过率从 52.5% 提升到 58.5%，并在相同 GPU 预算下相对 Async 实现实现 1.78 倍端到端加速。这个成绩足以说明，弹性资源调度和轨迹处理确实可能成为长程 Agent 训练的关键基础设施。

但它目前更像是一个面向下一阶段模型训练的系统性答案，而不是已经完成验证的通用标准。QwenGyre 是否能在更多环境、更大集群和不同模型架构上稳定复现，仍要等待代码、论文和更细的实验数据。

可以确定的是，当智能体一次执行需要处理 70 万 Token，上百次交互和数小时环境反馈时，单纯增加模型参数已经不是全部答案。如何让 GPU 不等待、让失败轨迹不浪费、让训练及时吸收刚刚完成的任务，正在成为 Agent 竞争的新分水岭。

参考来源

• IT之家：阿里千问发布 QwenGyre，面向超长程智能体任务的在线强化学习框架：提供 QwenGyre 发布信息、核心机制和 NL2RepoBench 实验数据。
• 阿里云 PAI 文档：Cosmos-RL 强化学习任务：用于了解阿里云强化学习任务的资源组织方式和相关框架背景。