智能体要干的活越来越长，但训练它们的基建还停留在短任务时代。阿里千问给出的解法叫QwenGyre。
10月12日，阿里千问正式发布QwenGyre，一套面向超长程智能体任务的在线强化学习（RL）框架。要理解它的价值，得先说清楚「超长程任务」是什么，以及它为什么难训。
所谓超长程任务，指的是单次执行持续数小时、包含数百次交互、一次完整任务轨迹（rollout）接近百万词元的作业。典型的例子不是回答一个问题，而是让智能体从零搭出一个能跑通的仓库，或者连续几小时排查一处跨系统的线上故障。这类任务正快速成为智能体的主流形态——用户要的不再是「给我一段代码」，而是「把这个活干完」。
问题出在训练环节。传统的在线强化学习架构面对这类任务有两个硬伤。第一个是GPU空转：采样（让模型去跑任务）和训练（用结果更新模型）如果串行切换，任务长短不一时，先跑完的卡要等后跑完的卡，大量算力在等待中空转；而对数小时级的任务，这种等待会被放大到不可接受。第二个是轨迹冗余：超长上下文里存在大量重复的共享前缀，反复计算同一段前缀的代价随长度线性甚至超线性增长。
QwenGyre的解法分成两条。第一条是弹性调度：把GPU划分成计算单元，任务结束一批就转入训练，运行中的任务状态完整保留、不受打扰。这意味着采样与训练不再是两段割裂的时间，而是在同一批卡上按任务完成情况动态切换，空转被压缩到最小。第二条是轨迹处理：采用Token-in Token-out的方式记录上下文，保证训练时用的是真实上下文而非重建的近似版本；通过Partial Scoring对未完成的部分成果给出反馈，让「做了一半」的任务也能贡献训练信号；再对共享前缀做去重，把冗余计算的成本砍掉。
官方给出的实验数据是这样的：在Qwen3.8-2.4T上、约70万词元rollout的条件下，NL2RepoBench通过率经48步训练从52.48%提升至58.54%。NL2RepoBench是考察「从自然语言需求生成完整代码仓库」的基准，属于长程、难核验的典型任务，六个百分点的提升在这个区间并非易事。更关键的第二个数字是：在相同GPU预算下，QwenGyre相对异步（Async）实现取得了约1.78倍的端到端加速，且训练分数与Async、Colocate两种方案接近——也就是说，快了接近一倍，而没有牺牲效果。
这里需要解释一下为什么「1.78倍」比「六个百分点」更重要。强化学习训练的迭代速度决定了模型能力爬升的速度：同样的算力预算下，如果训练快一倍，就意味着在同样的时间里可以多跑接近一倍的步数，或者在同样的步数下省下近一半的卡时。对动辄上千卡、跑数周的训练任务来说，这是实打实的成本项。
把这项工作放进更大的图景里看，它指向的是智能体训练基建的一次范式调整。过去两年，行业的主流做法是把长任务切碎、或者干脆避开长任务，只在短任务上做强化学习——因为短任务好训、回报快。但智能体真正要承接的活恰恰是长的。QwenGyre的意义在于：它把「超长任务」从训练障碍变成了训练来源。
对开发者的实际影响是，如果这套方法被验证并普及，下一代编程Agent与运维Agent的训练成本会明显下探，长任务的完成率会成为可被系统性优化、而非靠运气的目标。对行业而言，竞争维度正在从「谁的模型更强」向「谁的训练基建更能吞下长任务」延伸。
需要标注的不确定性是：上述数据来自阿里千问官方公布的实验，在Qwen3.8-2.4T单一底座与NL2RepoBench单一基准上的表现，能否迁移到其它模型与其它长程任务，仍有待第三方复现。框架的开源计划与可用范围以官方后续发布为准。