Dressage系统如何在异步强化学习中分层控制陈旧性？Trajectory与Batch双粒度机制解析

在大型语言模型驱动的智能体（Agentic）强化学习训练中，一个长期困扰工程实践的问题是“陈旧性”（Staleness）——即用于训练的数据样本由旧版策略生成，而模型权重已在采样期间多次更新。这种时间差会导致梯度方向偏置，严重时引发训练发散。近期开源项目 Dressage（github.com/Accio-Lab/Dressage）提出了一套分层、正交的陈旧性控制系统，从轨迹级（Trajectory-level）与批次级（Batch-level）两个维度进行约束，为高吞吐异步 RL 训练提供了可落地的工程方案。

陈旧性的双重来源与核心矛盾

异步 RL 的典型架构中，Rollout（数据采集）与 Training（模型更新）并行运行：当 Trainer 完成一轮权重更新后，仍在使用旧权重采样的 Rollout 工作器会继续产出样本；待这些样本最终送入训练队列时，其生成所依据的策略版本可能已滞后数轮。例如，t1 时刻以权重 v1 启动一条长轨迹采样，t2、t3 时刻 Trainer 分别更新至 v2、v3，至 t4 轨迹完成并提交——此时样本基于 v1 生成，但当前策略已是 v3，形成显著的 staleness gap。

更关键的是，陈旧性并非单一现象，而是源于两个不同粒度的机制：

• Trajectory 级陈旧性：源于单条长轨迹在执行过程中被反复中断续写。例如，在 Partial Rollout 设计下，当策略更新发生时，系统会在 token 边界暂停旧生成、切换新权重续写。若中断过于频繁，一条轨迹的前缀（决定状态分布的关键部分）可能来自多个旧版本，即使仅对最新 token 计算 loss，上下文仍高度陈旧。

• Batch 级陈旧性：源于异步流水线中已完成轨迹在队列中等待调度的时间延迟。一批轨迹虽各自完整，但因排队时间过长，整体进入训练批次时策略已大幅演进，造成 Train-Inference Gap 扩大，梯度估计失真。

二者共同构成核心矛盾：提升吞吐需增加 Rollout 与 Training 的重叠度，但重叠越高，陈旧性越严重。Dressage 的设计目标正是在保障高吞吐前提下，对两类陈旧性分别施加可控约束。

第一层防御：Trajectory 粒度——限制单条轨迹的版本跨度

Dressage 的第一道防线作用于单条轨迹内部，核心依赖其 Proxy 层实现的透明化 Partial Rollout 机制。传统方案难以干预外部 Agent（如调用 OpenCode 等黑盒 harness 的进程），因其执行流程不可控；而 Dressage 强制所有模型调用必须经由 Proxy 中转，使 Proxy 成为唯一入口与管控点。

具体而言，当策略版本更新时，Proxy 可依据 request-id 主动中止 SGLang 在途生成，截取已产出的 partial token 序列，并挂起 Agent 的 HTTP 请求（对 Agent 透明）。随后，系统以新权重续写剩余部分。这一机制避免了整条轨迹作废或全程使用过时策略的极端选择。

在此基础上，Dressage 对单条轨迹施加版本跨度上限约束：设定参数 max_partial_rollout_preempts，限制一条轨迹在其生命周期内允许的版本切换次数。一旦超限，Proxy 将返回 502 错误，触发该轨迹所属的 Agent 组重试。该逻辑确保单条轨迹的上下文不至于过度碎片化，维持状态分布的相对一致性。

图2展示了该层控制的核心要素：底层由 Proxy 实现透明中断续写，控制逻辑聚焦于版本跨度上限，超限时通过 502 触发组级重试。

第二层防御：Batch 粒度——动态窗口过滤与回溯复查

即便单条轨迹保持“新鲜”，批量组装时仍可能因排队延迟引入陈旧性。为此，Dressage 引入第二道防线：版本窗口机制（Version Window），作用于数据进入训练批次前的筛选阶段。

其核心参数为 keep_versions，定义一个滑动窗口宽度（如保留最近 3 个版本的轨迹）。每当新策略版本发布，系统自动推进窗口边界；同时，对已缓存但尚未入 batch 的轨迹组执行回溯复查（filter_pending）：移除那些版本号落在窗口之外的组。

值得注意的是，Dressage 并未简单丢弃旧轨迹，而是采用 GRPO Group 机制——将同一批次内轨迹按版本分组，确保每组内策略版本一致，并在统计 advantage 时保持组内一致性。这避免了跨版本混训导致的 reward signal 混淆。

此外，系统还处理元数据不完整的情况：若某轨迹缺失版本信息，Dressage 默认将其归入“最旧组”，并在后续窗口推进时优先剔除，实现容错。

图3清晰呈现了该机制的数据流：主收集循环接收轨迹后，先推进窗口、再回溯复查、最后通过 keep_group() 进行最终检查，确保仅“窗口内新鲜”轨迹进入训练批次。

两层机制的协同与配套设计

Trajectory 与 Batch 两级控制并非孤立，而是通过训练侧的 Token-Level Loss Mask 形成闭环。Dressage 在计算损失时，对非最新版本生成的 token 显式 mask 掉其 loss 贡献——即仅保留每条轨迹最后一个真实由当前策略生成的 token 的梯度信号。这一设计与前两层形成互补：前者防止陈旧前缀污染状态分布，后者确保梯度更新不被历史策略干扰。

配套机制还包括：

• 版本追踪器（tracker）：实时记录各策略版本的生效时间与轨迹归属；
• Drain Queue：主收集循环定期清空积压队列，防止陈旧轨迹无限堆积；
• 组级重试语义：当轨迹因版本超限被拒绝，其所属 Agent 组整体重试，而非单条重试，保障策略一致性。

当前局限与优化方向

尽管 Dressage 提供了较完整的陈旧性治理框架，其当前实现仍存在若干局限：

未来优化方向包括：引入基于 staleness gap 的动态窗口调整算法；将重试成本纳入调度决策；扩展至 multi-agent 协同训练中的跨策略陈旧性协调。

行业意义：为 Agentic RL 工程化铺路

Dressage 的价值不仅在于技术细节，更在于它将原本模糊的“陈旧性问题”转化为可量化、可配置、可监控的工程模块。在当前 Agentic RL 快速发展的背景下，大量研究聚焦于奖励设计、工具调用与记忆机制，却较少关注底层训练稳定性。而实际部署中，训练崩溃或收敛缓慢往往源于隐性的陈旧性累积。

类似思路已在工业界初步验证：例如 DeepMind 的 AlphaDev 采用类似版本隔离策略，避免代码生成样本因策略漂移而失效；Anthropic 的 Constitutional AI 训练链路中也设置了 rollout 版本校验环节。Dressage 将此类经验系统化、模块化，为开源社区提供了一个可复用的参考架构。

随着智能体任务复杂度提升，长周期、多步骤的交互式训练将成为常态，陈旧性控制的重要性将进一步凸显。Dressage 所提出的“分粒度、正交约束”哲学，或将成为下一代 Agentic RL 基础设施的标准组件之一。