--- Rollout)
law-RL 是一个用于在线强化学习(Online RL)的框架专门针对智能体工具使用场景。它通过从环境反馈中提取过程奖励信号来训练语言模型支持三种主要模式openclaw-rl基于二元奖励的强化学习(Binary RL / GRPO)openclaw-opd基于后见之明提示的在线策略蒸馏(On-Policy Distillation, OPD)openclaw-combine联合方法在同一 PPO 更新中同时利用 RL reward 和 OPD teacher signal可以把 RL 训练管道划分为如下5 个阶段(会有重叠依据不同系统而不同)本篇介绍Rollout。Stage 1 Stage 2 Stage 3 Stage 4 Stage 5 ───────── ───────── ───────── ───────── ───────── Prompt Rollout Reward Advantage Gradient Selection Generation Scoring Computation Update 问什么 怎么答 打几分 好了多少 往哪走0x01 Rollout基础Rollout 用策略在环境中执行并产生轨迹 τ (s₀, a₀, r₀, ..., sₜ, aₜ, rₜ)。1.1 概念在 RL 框架中rollout 这个词同时指代:含义 1: 过程 (动词)doing a rollout 用策略在环境中生成一条轨迹的过程含义 2: 结果 (名词)the rollout 生成出来的那条轨迹数据包含: tokens, log_probs, reward, loss_mask 等。在Slime代码中generate_rollout_openclaw()函数名用的是含义 1(执行rollout过程)返回的 RolloutFnTrainOutput(samples...)是含义2(rollout的结果数据)。1.1.1 标准 RLRollout 在环境中执行策略产生一条完整的交互轨迹(trajectory)。形式化给定策略 π 和环境 E 一次 rollout 产生一条轨迹 τ: τ (s₀, a₀, r₀, s₁, a₁, r₁, ..., sₜ, aₜ, rₜ) 其中 s₀ ~ ρ₀ (初始状态从 prompt 分布采样) aₜ ~ π(・|sₜ) (策略生成 action) sₜ₊₁ ~ P (・|sₜ,aₜ) (环境转移) rₜ R (sₜ, aₜ) (环境给出奖励)1.1.2 LLM RL在 LLM RL 中Rollout 给定一个 prompt, 模型生成一个完整 response 记录 log-probs 打分。当然也有人这么归纳一次 rollout 给定一个 prompt, 模型生成一个完整 responses₀ prompt (初始状态) a₀, a₁, ..., aₜ response 的每个 token (一系列 action) r 对整个 response 的打分 (terminal reward) 轨迹 τ (prompt, token₁, token₂, ..., tokenₜ, reward)注意: LLM 的 rollout 通常是 single-step episode (一轮就结束), 不像游戏有多步交互。1.1.3 GPRO一个 GRPO rollout batch:采样 B 个 prompt每个 prompt 生成 N 个 response总共 B × N 条轨迹每条轨迹包含:prompt (input)response tokens (actions)log π_old (a_t | s_t) (旧策略的 log-probs, 用于后续 PPO ratio 计算)reward (打分)1.1.4 OpenClaw-RLOpenClaw 的 rollout的特点不主动生成等用户对话 → 从 queue 收集凑够 rollout_batch_size 个样本 一次 rollout每条轨迹包括prompt 用户消息 (s₀)response 模型回复 (a₀...aₜ)rollout_log_probs SGLang 生成时记录的 log π_old (用于 PPO ratio)reward PRM 评分(OPD) teacher_log_probs teacher 的 log-probs主动和被动的对比如下。标准 RL Rollout: ──────────────────────────────────────────────── dataset load (math_data.jsonl) for prompt in dataset.sample (batch_size): ← 主动选题 responses model.generate (prompt, n4) ← 主动生成 N 个 for resp in responses: score reward_model (resp) submit (prompt, resp, score) OpenClaw Rollout: ──────────────────────────────────────────────── openclaw_rollout.py def generate_rollout_openclaw (...): worker.resume_submission () ← 打开阀门 while len (data) rollout_batch_size: data queue.get() ← 等等用户发消息 await asyncio.sleep(0.05) ← 继续等... worker.pause_submission () ← 关阀门 return data # 数据从哪来从 API Server 的请求处理流程来 # rollout 函数本身不生成任何数据具体可以参见下表标准OpenClaw谁控制prompt?训练系统用户谁控制N?训练系统n4~16用户永远n1数据到达时间确定的GPU生成速度不确定的等用户--disable-rollout-global-dataset不需要必须没有dataset1.2 RL2 对比我们用 RL2 这个框架来做对比看看它是怎么做rollout的。RL2 的本质架构为在同一组 GPU 上交替做推理和训练。或者说RL2 一个on-policy RL循环把LLM当policy network把推理服务器当采样器。展开核心数据流如下三个核心子系统及其职责Rollout SGLang推理 环境交互 → 产出(token序列reward)Actor/Critic FSDP分布式模型 → 计算logps/values → 反向传播Environment env_step(action)→ reward(规则/外部API/LLM judge)注意Reward 不是独立模块—它集成在 env_step 内实现方式完全灵活(规则/外部服务/LLM judge)PRM 可通过多轮环境实现—每个 step 返回中间 reward累加到轨迹中整个 Rollout 是异步的—SampleGroup 并发、env_step 可调外部网络、SGLang 请求并发所有组件共享同一组 GPU—通过 offload memory occupation 管理实现时分复用0x02 OpenClaw-RL Rollout基础在 OpenClaw-RL 中Rollout 是Policy Serving Environment 的交叉。Rollout 在环境中执行策略生成完整轨迹的过程 Policy的推理输出 × Environment的状态转移Rollout的完整循环如下Environment 提供 State(t)(用户消息) ↓ Policy Serving 执行推理 → Action(t)(模型回复) ↓ Environment 接收 Action(t) → Environment 提供 State(t1)(用户下一条消息) ↓ 重复直到 session 结束2.1 硬件架构在 OpenClaw-RL 的硬件架构中GPU 4-5 的名称是 SGLang Rollout Engine。但它实际负责的是 rollout 的 Policy Serving 侧→ 接收 HTTP 请求(用户消息)→ 运行 LLM 推理生成 token→ 返回模型回复rollout 的 Environment 侧(用户行为)在 GPU 之外→ 用户什么时候发消息 → 外部世界决定→ 用户发什么内容 → 外部世界决定→ 用户是否继续对话 → 外部世界决定┌──────────────────────────────────────────────────────────────┐ │ Rollout(概念上) │ │ │ │ ┌─────────────────┐ ┌───────────────────────┐ │ │ │ Policy Serving │ │ Environment │ │ │ │ GPU 4-5 │ │ 真实用户(外部) │ │ │ │ LLM 推理生成回复 │ │ 提供 state、接收 action │ │ │ └─────────────────┘ └───────────────────────┘ │ │ │ └──────────────────────────────────────────────────────────────┘2.2 总体模块交互架构图OpenClaw-RL 总体模块交互架构图 (Combine 方法) 如下可以从中找到Rollout相关内容。2.3 Slime 的 RolloutFunction 封装在代码层面Slime用一个函数封装了rollout的全部逻辑# openclaw-rl/openclaw_rollout.py def generate_rollout_openclaw(args, rollout_id, data_buffer, evaluationFalse): Slime 的 rollout function: 标准rollout(主动生成) rollout_engine.generate(prompts) → 直接调LLM生成轨迹 Policy Serving(GPU4-5)自己完成整个rollout Environment是静态的(题目数据集) OpenClaw的被动rollout 等待_sample_queue.get()→ 从真实用户对话中取已完成的轨迹 PolicyServing已经完成了(对话已结束) Environment已经交互过了(用户消息已收到) 这里只是“收集“已经发生的rollout while len(samples) batch_size: sample_sample_queue.get(blockTrue)#被动等待 return samples-disable-rollout-global-dataset的含义就是告诉Slime“不需要你主动用LLM生成rollout我的rollout由真实用户Policy Serving联合产生你只管拿已完成的样本“具体如下图。Slime 训练框架调用: generate_rollout_openclaw(args, rollout_id, data_buffer) | | passive rollout: | 不主动生成, 等待真实对话产生数据 ▼ --------------------------------------- | worker.resume_submission() | - 开启 submission_enabled Event | _drain_output_queue() | - 等待 rollout_batch_size16 组 --------------------------------------- | | ▼ (数据由异步 FastAPI handler 填入)2.4 被动RolloutOpenClaw-RL的rollout是被动rollout。generate_rollout_openclaw()等待真实用户发消息而非主动从prompt池中选择问题生成回答。这意味着系统对rollout allocation(选什么问题训练)几乎没有控制权由用户决定。优势训练数据 真实用户对话天然分布对齐无train-deploy distribution gap用户多样性天然提供entropy保障和batch内reward方差无需维护prompt数据集劣势无法做curriculum learning(由简到难)无法增大group size G(每turn只有一条用户消息)无法做dynamic sampling(不能要求用户“换个问题再问)Rollout allocation 几乎完全失控2.5 小结概念上Rollout PolicyServing Environment 两者的交互过程不专属任何一方架构上GPU 4-5标记为“Rollout Engine但只承担了Policy Serving(推理)侧的工作代码上generate_rollout_openclaw是被动收集器真正的rollout在FastAPI服务器处理用户请求时已经完成0x03 OpenClaw-RL Rollout 实现3.1 Rollout 完整流程关键设计要点机制实现方式next_state 滞后turn N 的 next_state turn N1 请求里 messages 的最后一条PRM 异步asyncio.create_task done_callback 触发提交at-least-onesession 全为 score0 时首个 turn 强制 loss_mask1权重同步暂停submission_enabled Event 控制同步中返回 5033.2 Session 生命周期假设我们session含有三轮。turn 1 → [buffered, waiting next_state] turn 2 → flush turn1(next_stateturn2.messages[-1]) → PRM(turn1) fire turn 3 → flush turn2(next_stateturn3.messages[-1]) → PRM(turn2) fire session_doneTrue → flush last_turn(next_stateNone) → force_no_prm3.2.1 示例下图展示了 rollout 的 3-turn 示例。3.2.2 单个 Turn 的完整处理流程3.2.3 多个 Turn 的机制关键时序next_state的延迟到达“机制Turn 1发生时用户发消息M1→SGLang生成R1→返回给用户此时R1的next_state还没有(用户还没回复)→_pending_records[session_id] {response_text: R1} 等待Turn 2Turn 2发生时(用户发M2Turn1的next_state)用户发消息M2 → _handle_request()被调用→ messages[-1]M2Turn 1的 next_state ← 此刻才可用→ _flush_pending_record(session_idM2)被调用→ _fire_prm_scoring(R1next_stateM2)被触发(异步)→ 同时SGLang生成R2→返回给用户→ _pending_records[session_id]{response_text:R2}等待 Turn 3PRM评估R1的结果异步返回→ _submit_turn_sample(turn_data_1,prm_result_1)→ output_queue.put(Sample(loss_mask..., rewardscore_1))这个设计导致每个 turn的 reward来自下一个HTTP请求到达的时刻而非当前请求结束的时刻。这是OpenClaw Rollout 中最独特的工程设计。3.3 At-Least-One GuaranteeAt-Least-One Guarantee 的作用是防止整个session贡献零梯度确保即使最平庸的session也有一个turn进入训练Reinforce-Ada强制至少一个梯度的session级版本。At-Least-One Guarantee 是最直接的零梯度修复。具体如下第一个被 PRM 评过(has_next_stateTrue)但 score0 的 turn → 强制 loss_mask[1]参与训练 → 至少每个 session 贡献一个样本。# _submit_turn_sample() 中的核心逻辑: exclude not has_next_state or score 0.0 # 正常情况score 0 → excludeTrue → loss_mask[0,0,...,0] # 但是特殊保障 if exclude and has_next_state and self._session_effective.get(session_id, 0) 0: exclude False # ← 强制参与训练 # at-least-one guarantee # openclaw_api_server.py:615-622 # 使用 _session_effective 计数器追踪每个 session 的有效样本数 # 首个 has_next_state 但 score0 的 turn → 强制 excludeFalse if exclude and has_next_state and self._session_effective.get(session_id, 0) 0: exclude False # ← 强制参与训练 # at-least-one guarantee # 之后 self._session_effective[session_id] 13.3.1 问题情景情景整个 session 的所有 turn 都 score0详述用户发了 5 条消息但每次都是中性反馈(score0) → 所有 turn loss_mask[0] → 这个 session 对训练没有任何贡献 → 分母增大但分子不变 → rollout_batch_size 难以填满 → 训练停滞3.3.2 逻辑分析问题逻辑all loss_mask[0] → 整个session 贡献零梯度At-Least-One 触发records[0][loss_mask][1]强制打开第一个turn 的门reward不变0.0此时的梯度情况loss_mask[1](门打开了)reward0.0 → advantage由GRPO的批内归一化决定→ 在训练 batch 中与来自其他 session的1/-1样本一起归一化→ 这个0.0 reward的样本advantage ≈ 0(在均值附近)→ 贡献的梯度接近但不等于零at-least-one的真正价值确保Policy不会在这类对话上“完全不见光“即使效果微弱也让这种回复参与了分布的锚定→ 防止Policy在这类对话上悄悄退化3.3.3 直观类比loss_mask考试是否交卷0这次不参加考试(完全不影响成绩)1参加考试(成绩会影响最终评价)advantage这次考试得了几分(正分/负分)正值这次考得好鼓励这种答题方式负值这次考得差惩罚这种答题方式~0这次成绩平平基本没有反馈at-least-one“就算这次内容不好也必须交卷强制loss_mask1哪怕advantage0至少这次答题留下了记录不会被系统彻底忽视3.3.4 设计要点为什么score0用loss_mask0而不是advantage0两种方式理论上都产生零梯度(在kl-coef0时)实践中loss_mask0更优效率直接跳过这些token的梯度计算(节省计算)语义清晰明确表达“这个turn没有学习价值不参与训练“与--kl-coef0.0一致如果有KL惩罚advantage0的token仍会通过KL term产生梯度loss_mask0彻底排除避免这种副作用为什么 Binary RL 需要 at-least-oneBinary RL的具体问题训练饥饿(training starvation)设想一个极端场景Session A: turn 1→ score0,turn 2→ score0,turn 3→ score0 Session B: turn 1→ score0,turn 2→ score0 - → output_queue中全是loss_mask[0]*T 的样本 - → Slime收到rollout_batch_size个样本 - → 前向传播正常但 ∂L/∂θ ≈ 0(所有token都被mask掉) - → 实际上没有任何参数更新 - → 占用了一次完整的 rolloutforward passbackward pass什么也没学at-least-one 的修复# openclaw_api_server.py if exclude and has_next_state and self._session_effective.get(session_id, 0) 0: excludeFalse #强制 loss_mask[1] # 但reward保持0.0注意被promote的样本reward仍是0.0所以advantage ≈ 0梯度实际上接近 0。它解决的不是“学到有用信号”而是确保output_queue 里每个 session 至少有一个非ABORTED 样本(Slime 的sample状态机要求)防止Slime内部因为全 mask0 的batch触发边界异常为什么 OPD/Combine 不需要根本原因两种“零贡献“的本质不同。关键区别Binary RL的零贡献样本会“占据“批次槽位但静默无效OPD/Combine则完全不产生样本。Binary RL的零贡献路径score0 → excludeTrue → loss_mask[0]*T → 样本进入output_queue但不产生梯度 ↑ 样本在批次中占位Slime看得到但无梯度流动OPD/Combine的零贡献路径hint被拒绝 eval0 → 样本根本不进入output_queue(直接丢弃) ↑ 样本对Slime来说不存在OPD 的信号结构情形是否进入队列advantagehint 接受√teacher_lp - rollout_lp ≠ 0几乎必然hint 拒绝×丢弃N/AOPD 样本要么有真实的 per-token 教师信号(即使 reward0 advantage 也非零)要么根本不进队列。没有“占位但无梯度的中间状态。Combine 的信号结构情形进队列OPD 项RL 项OPDRL√≠ 0≠ 0OPD-only√≠ 0 0RL-only√ 0数值对消≠ 0丢弃×N/AN/A进入队列的样本至少一个信号项非零(这是 dispatch 逻辑保证的)。设计选择的对称性Binary RL的“批次污染问题存在 → at-least-one作为“最低保证“OPD/Combine的等价保证dispatch逻辑本身就确保“进队列有信号“ → 问题从根源上消除无需at-least-oneBinary RL的 at-least-one是在loss_mask二元门控机制下的补丁而OPD/Combine 绕开了这个机制(始终 loss_mask[1]通过 advantage 对消来“关掉“不需要的信号)所以补丁也就不再需要。0x04 AsyncRolloutWorkerAsyncRolloutWorker 线程边界 开关 数据渡口4.1 功能AsyncRolloutWorker 是Slime(Policy Training)与 FastAPI Server(Policy Serving)之间的线程边界管理器它不做推理、不做打分但控制着Policy Serving的“营业时间控制着两侧的生命周期和数据流转并通过output_queue把FastAPI 异步世界里生产的样本安全地传递给Slime同步训练世界。具体功能如下启动和管理API服务器管理启动控制负责启动和管理 OpenClawAPIServer 实例生命周期管理控制 API服务器的运行状态和资源分配配置传递向API服务器传递必要的运行时参数样本队列管理输出队列创建创建queue.Queue()作为样本传输通道队列监控监控队列大小和样本积压情况超时检测实现30秒无进展警告机制训练批次收集/协调批次收集等待足够数量的样本后触发训练提交控制管理样本提交的暂停/恢复机制进度跟踪显示收集的样本数量和耗时统计提交控制(暂停/恢复)4.2 示例图4.3 三个核心职责4.3.1 线程隔离让FastAPI跑在独立asyncio事件循环里Slime的主循环(训练)是同步代码FastAPI需要异步事件循环AsyncRolloutWorker 把FastAPI server 启动在独立线程中两侧互不阻塞#worker_thread_func跑在独立线程 def worker_thread_func(self): asyncio.run(self.continuous_worker_loop()) # asyncio.run()创建独立事件循环 # FastAPI/httpx异步请求全在这个线程里continuous_worker_loop()本身只是一个 sleep(1.0)的keepalive 循环—真正的数据生产在 FastAPI的 requesthandler 里不是在这个loop里。4.3.2 开关控制submission_enabled事件同步def pause_submission(self): self._submission_enabled.clear()#关闸 →FastAPI 返回 503 self._server.purge_record_files() #清理临时记录 def resume_submission(self): self._submission_enabled.set() #开闸→FastAPI正常接受请求threading.Event 是跨线程安全的信号量Slime 主线程通过这个事件控制FastAPI线程的“营业状态“weight sync 期间paused503rollout 收集期间 resumed正常4.3.3 数据渡口output_queue跨线程传递样本queue.Queue是Python标准库中线程安全的FIFO是FastAPI线程和 Slime 主线程之间唯一的共享数据结构。#FastAPI 线程写入(async) await asyncio.to_thread(self.output_queue.put,(sample.group_index,[sample])) #Slime主线程读取(同步) def get_completed_groups(self)- list[tuple]: while True: completed.append(self.output_queue.get_nowait())4.4 与 OpenClawAPIServer 的协作机制AsyncRolloutWorker 是OpenClaw-RL框架中的异步轨迹收集工作者负责管理整个 rollout数据收集流程的生命4.4.1 交互架构模式 -- 生产者-消费者模式OpenClawAPIServer作为生产者生成训练样本并放入队列AsyncRolloutWorker作为消费者管理者提供队列并协调消费过程Slime训练器作为最终消费者从队列中获取样本进行训练4.4.2 层次化控制结构AsyncRolloutWorker (顶层控制) ↓ 创建并管理 OpenClawAPIServer(数据生产) ↓ 提交到 SampleQueue(数据传输) ↓ 消费于 SlimeTrainer(模型训练)4.4.3 具体交互机制队列传递机制队列创建AsyncRolloutWorker 在初始化时创建self.output_queue queue.Queue()队列共享将output_queue作为参数传递给OpenClawAPIServer样本提交OpenClawAPIServer 调用 self.output_queue.put((group_index[sample]))队列消费Slime训练器通过rollout_worker.get_output_queue()获取队列并消费状态同步机制提交开关AsyncRolloutWorker 维护_submission_enabled 状态_暂停信号训练开始前调用pause_submission()禁用提交恢复信号权重更新后调用resume_submission()启用提交API服务器响应OpenClawAPIServer在提交前检查提交状态权重更新协调记录清理AsyncRolloutWorker 调用purge_record_files()清空记录文件状态重置确保新策略开始时的数据一致性API服务器配合OpenClawAPIServer响应清理请求并重置内部状态4.4.4 两者配合的工作流程初始化阶段AsyncRolloutWorker 初始化创建输出队列self.output_queuequeue.Queue()设置提交状态self.submit_enabledTrue初始化统计变量样本计数、时间戳等OpenClawAPIServer初始化接收队列引l用从AsyncRolloutWorker获取output_queue初始化内部状态_turn_counts_pending_records 等字典启动FaStAPI服务准备接收用户请求运行阶段数据生产流程用户请求到达OpenClawAPIServer处理请求并生成样本样本构建完成调用_submit_turn_sample()创建Sample对象队列提交执行 self.output_queue.put((group_index[sample]))队列监控AsyncRolloutWorker检测队列大小变化批次收集流程队列检查AsyncRolloutWorker 定期检查output_queue.qsize()批次判断当队列大小达到值时准备训练批次提交暂停调用pause_submission()防止新样本干扰当前批次批次提取训练器从队列中提取完整批次训练阶段权重更新协调训练开始AsyncRolloutWorker暂停样本提交记录清理调用 OpenClawAPIServer 的 purge_record_files()状态重置清空所有待处理的回合记录和状态权重加载新策略模型加载到 SGLang服务恢复运行提交恢复AsyncRolloutWorker 调用resume_submission()新会话开始OpenClawAPIServer使用新策略处理后续请求数据一致性确保新旧策略数据不混合实际应用场景示例正常对话流程用户请求 → OpenClawAPIServer(生产样本) → output_queue → AsyncRolloutWorker (监控队列) → SlimeTrainer (消费训练)权重更新流程训练批次完成 → AsyncRolloutWorker.pause_submission() → purge_record_files() → 权重更新 → AsyncRolloutWorker.resume_submission() → 新策略生效异常处理流程队列积压警告 → AsyncRolloutWorker发出30秒超时警告 → 管理员介入或自动扩容 → 恢复正常处理
