10 月 12 日，阿里千问发布了在线强化学习框架 QwenGyre。它瞄准的不是「怎么训一个更聪明的模型」，而是长程智能体训练里两个非常具体的工程麻烦：任务执行时间差异过大导致算力空转，以及复杂交互产生的大量冗余轨迹难以利用。
这两个问题的严重程度，得先看它描述的场景。QwenGyre 面向的是让编码智能体自主改代码、跑测试、定位报错、反复编译，直至完成一次完整的软件工程任务。这类任务单次执行常常持续数小时，包含数百轮模型与环境交互，单条 rollout 累计处理的上下文约 70 万 token，甚至接近百万。
耗时方差是这类任务的常态
传统在线强化学习系统通常按相对固定的节奏组织 rollout 与训练。但智能体完成任务的速度极不稳定：有的任务几分钟内就因明显错误失败，有的要跑几个小时才有有效结果。只要批里有长任务没结束，相关资源就可能被占着，训练侧只能等。
更麻烦的是轨迹会快速膨胀。智能体可能反复尝试、回滚、重复读文件，甚至因环境反馈不明确而陷入循环。把全部交互历史原样送进训练，反向传播的显存与算力开销会跟着涨一大截，而收益却不见得成正比。
三个机制，分别对应三个麻烦
弹性调度把 GPU 切成若干可动态调整的计算单元，按 rollout 完成情况在采样与训练之间重新分配。某批任务里一部分完成了，对应单元立刻转入训练，不等剩下的；仍在运行的智能体不会被强行终止，任务状态、执行进度与已算出的缓存会被保留并迁移。官方还用了一个比喻：传统同步方案像要求所有组员同时交付才能开会，最慢的人决定会议开始时间；弹性调度允许先完成的人先进复盘。
Token-in Token-out 轨迹记录记录的是每次生成时的真实上下文与输出 token，而不只是最终文本。长程任务里同一段历史常被后续多步共享，若逐步展开成独立样本就会反复复制相同上下文。框架按共享前缀把轨迹组织成树，训练时只展开被选中的路径，等于把一棵满是试错分支的执行树裁成几条更有价值的路径。
Partial Scoring 让超时但部分完成的任务也能贡献反馈。代码智能体里，一个最终没通过全部测试的任务，可能已经装好了依赖、定位到关键文件、修复了部分测试。如果只给整条轨迹一个成功或失败标签，这些中间进展就全被浪费了。
数字怎么读，哪些还没披露
官方给出的基准结果很清楚：NL2RepoBench 上以单次 rollout 约 70 万 token 的任务训练 48 步，通过率从 52.5% 提升到 58.5%；相同 GPU 预算下，相对 Async 实现取得 1.78 倍端到端加速，训练分数与 Async、Colocate 接近。阿里还在 Qwen3.6-122B 上做了跨任务验证，覆盖 NL2RepoBench、DeepSWE 与 TerminalBench 三类任务，报告均获得端到端提速。
这里有两处必须分清。52.5% 到 58.5% 是模型能力的变化，1.78 倍是同等预算下的训练效率，两者不能相加或互相替代。Cross-task 验证只说了提速、没给具体倍数，更适合读作「方向上跨任务成立」，而不是一份完整的横向性能排名。Partial Scoring 的详细公式、评分误差与消融结果，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
这个框架真正的行业含义
长程智能体训练的成本结构正在变。以前加 GPU 数量几乎是提高吞吐的直接方式，但在任务时长与分支数都不可控的场景里，瓶颈可能不是总算力，而是算力有没有在正确的时间被分配给正确的阶段。一部分 GPU 被慢任务长期占着，另一部分在等训练批次——继续扩容未必带来线性收益。
值得留个心眼的地方也很明确。长程在线强化学习牵涉模型服务、环境沙箱、分布式调度、缓存迁移与训练器协同，只发布框架名并不足以降低复现门槛，开发者还得看到完整代码、部署文档、硬件要求与可复现配置。Partial Scoring 的质量直接决定训练上限：阶段奖励越贴近真实目标越有用，评分函数若有漏洞，模型也可能学会钻空子而不是完成任务。至于 1.78 倍，那来自单一基准、单一 rollout 规模与特定比较基线，不能直接外推到更短、更稳定的任务。
可以确定的是，当一次执行需要处理 70 万 token、上百次交互与数小时环境反馈时，单纯堆模型参数已经不是全部答案了。