0x00 概要本系列的目的是借着对 OpenClaw-RL 源码的学习来梳理强化学习的一些相关概念和思想。所以会有一些扩展和发散OpenClaw-RL 只是一个切入点。而且因为整篇系列是一个整体所以有些概念的解读/学习会在不同的文章中出现还请大家谅解。OpenClaw-RL 是一个用于在线强化学习Online RL的框架专门针对智能体工具使用场景。它通过从环境反馈中提取过程奖励信号来训练语言模型支持三种主要模式openclaw-rl基于二元奖励的强化学习Binary RL / GRPOopenclaw-opd基于后见之明提示的在线策略蒸馏On-Policy Distillation, OPDopenclaw-combine联合方法在同一 PPO 更新中同时利用 RL reward 和 OPD teacher signal现有 AI Agent 系统存在一个核心问题被浪费的下一状态信号。每次 Agent 执行动作后收到的下一状态用户回复、工具输出、终端状态变化、GUI 界面更新等仅被用作生成下一轮对话的上下文信息被提取后随即被丢弃并未转化为实时训练模型的宝贵数据资源。而 OpenClaw-RL 的核心理念正是将每一次交互都转化为学习机会。通过统一的技术框架和巧妙的方法设计它把 OPDOn-Policy Distillation变成一种在线的 next-state 学习机制让 AI Agent 能够在持续服务用户的同时从实时交互中自动学习和改进——无需人工标注也无需停机重训。具体贡献如下首次将下一状态信号作为实时在线学习源识别并系统性地回收了评估性和指导性两类信号让 Agent 在真实交互中持续进化。首个统一的异步 Agent RL 基础设施支持个人对话、终端、GUI、SWE 和工具调用五种场景的统一训练实现了策略服务、环境托管、PRM 评判和策略训练的完全解耦确保服务零中断。Token 级方向性监督OPD不同于标量奖励将所有 Token 推向同一方向OPD 提供每个 Token 的独立监督因此响应内部不同 Token 可能被强化或抑制。过程奖励与结果奖励的有机结合借鉴 RLAnything 的洞察在长视野 Agent 任务中证明过程奖励的不可或缺性。0x01 背景知识论文链接[2603.10165] OpenClaw-RL: Train Any Agent Simply by Talking开源代码链接GitHub - Gen-Verse/OpenClaw-RL: OpenClaw-RL: Train any agent simply by talking · GitHub1.1 Agentic RL 的核心难点我们回头再看看 Agentic RL 的核心难点。LLM-RL 架构就是一个带私教的模拟考试系统——把 LM 当成一个大 policy每次行动就是生成一整个回答然后根据这次回答的评分整体推一下参数。而 Agentic RL 则是在状态→动作→环境反馈这个闭环上做 RLLLM 只是这个闭环里实现策略的一部分。对数据 Agent/工具 Agent来说真正重要的是每一步选的工具和操作是否对任务有贡献——在这个粒度上单纯对最终回答打个分再 PPO 一下是很难学到东西的。一句话总结LLM-RL 优化的是回答好不好而 Agentic RL 优化的是整个系统做事情做得好不好。难点总览Agentic RL ≠ Chat RL原因是Agent 在真实环境中行动环境是动态的、不可逆的、部分可观测的。Agentic RL 面对的核心挑战维度如下奖励信号稀疏、延迟、噪声、误导状态空间高维、连续、非结构化屏幕像素、文件系统、代码库动作空间离散但巨大自然语言 token 序列时间跨度单步 → 多步 → 长程多轮环境非静态环境随 agent 的行动改变安全性错误动作不可逆删文件、发邮件难点详解难点1奖励信号稀疏 延迟问题很多 Agent 任务只有最终结果可以评分。写代码只有代码能运行才是 1GUI 操作只有最终界面状态正确才是 1中间步骤无法评分 → 梯度无法有效传播业界解法方法代表工作思路结果验证 (RLVR)DeepSeek-R1, QwQ可验证的任务数学、代码用 ground truth 打分LLM-as-JudgeSelf-Rewarding LLM用大模型对中间步骤打分本项目的 PRM 方案Process Reward ModelLets Verify, ORM vs PRM训练专用的步骤评分模型Hindsight LabelingHER, OpenClaw OPD用未来信息倒推当前步骤的质量环境信号ALFWorld, WebArena把环境的 success/failure/error 作为自然奖励难点2长序列下的 Credit Assignment问题100 步任务第 3 步的错误导致第 97 步失败如何归因传统 RLMonte Carlo returns高方差或 GAE需要 Critic贵LLM RLGRPO 直接广播 scalar reward → credit assignment 完全忽略 → 模型不知道是哪个 token/step 导致失败业界解法方法思路Step-Wise Reward对每步动作单独打分映射到 token 跨度Advantage Decomposition把 Q(s,a) 分解为步骤级别Process Supervision每步要求模型写出中间推理单独评分LLM Critic让另一个 LLM 估计 V(s)但训练稳定性差OPD/Hindsight (本项目)用 teacher per-token log-probs 提供密集信号难点3探索效率问题LLM 的动作空间是整个 token 词表的指数序列随机探索几乎不可能找到好的轨迹。典型失败模式Agent 尝试写代码 → 99% 时间生成语法错误 → reward -1 → 永远无法采样到正确的轨迹来学习。业界解法方法思路课程学习从简单任务开始逐步增加难度树搜索 (MCTS LLM)显式探索保留有前景的状态节点拒绝采样只用成功轨迹训练passk 筛选DAgger / Imitation RL先 SFT 专家轨迹再 RL 微调OPD (本项目)教师提供 hindsight hint引导探索方向难点4环境多样性与泛化问题在一个环境VSCode中训练的 Agent 无法泛化到另一个环境Vim。业界解法方法代表工作思路大规模多样化环境WebArena, OSWorld覆盖大量不同 GUI/Web 场景环境域随机化Robotics RL随机化物理参数元学习MAML快速适应新环境世界模型Dreamer V3学习环境动力学在模拟中训练难点5安全性与不可逆操作问题Agent 训练时犯错可能删库、发邮件、支付费用。业界解法方法思路沙箱环境Docker/VM 隔离训练时用虚拟环境本项目的 terminal-rl 用沙箱人工审批环节高风险操作需要确认安全 overhead 大保守策略约束KL 散度约束限制 policy 偏离 ref model 太远模拟器优先先在模拟器中充分训练再谨慎迁移到真实环境1.2 本项目难点如果按照解决难度来排从易到难业界图景中的定位大致如下数学 RL → 代码 RL → 工具调用 RL → SWE RL → GUI RL → 真实对话 RL [✓] [✓] [✓] [◑] [◑] ↑ OpenClaw-RL (有 GT) (有 GT) (部分 GT) (弱 GT) (环境反馈) (行为信号)本项目的独特定位在于大多数工作在有 ground truth的任务上数学对错、代码跑通/不通OpenClaw-RL 面对的是真实用户对话——没有 ground truth只有行为信号用户的下一步操作。长程多轮真实对话 RL 的难度非常大OpenClaw-RL 处于难度谱的最困难端其 Hindsight OPD 方法是对无 ground truth 的真实任务的一种创新性应答。两种范式下的对比结构上的根本差异如下。单轮 RLπ : Input (s) —→ Output (a) —→ Reward (r) (一次映射) (一条回复) (一个分数)Agentic RLπ : S₀ —a₀—→ S₁ —a₁—→ S₂ —a₂—→ ... —aₙ—→ r (循环映射) (状态转移由环境决定) (episode 结束才有分)核心差异是时间维度单轮 RL 没有时间Agentic RL 的每个动作都发生在特定的时刻其结果塑造了未来的状态。OpenClaw-RL 特殊定位纯单轮 RL OpenClaw 纯 Agentic RL (InstructGPT) (多轮对话) (Web Agent) | | | 1 轮 1 样本 每轮 1 样本(中间状态) T 轮 1 样本(episode) dense reward dense but noisy sparse reward 无时间依赖 弱时间依赖 强时间依赖(状态转移)OpenClaw 通过 next_state 机制把多轮对话拆解成多个独立的单轮 RL 问题从而回避了 Agentic RL 最难的两个问题稀疏梯度和长 episode off-policy gap。但代价是失去了 episode 级别的信息——对话整体质量无法被单个 turn 的 reward 完整捕捉。1.2 胶水代码看到一个搞 RL Infra 同学的一种说法RL Infra 是胶水代码。我们以 OpenClaw-RL 为例来审视这个说法——确实大多数开源组件不需要修改因此在某种程度上RL Infra 是胶水代码。组件 来源 OpenClaw-RL 的工作 ───────────────────────────────────────────────────────────────────────── SGLang 推理服务 开源项目 (SGLang) ← 直接用不改 Megatron 训练 开源项目 (Megatron-LM) ← 直接用不改 Slime 框架 开源项目 (slime) ← 直接用不改 Qwen3 模型 HuggingFace 下载 ← 直接用 OpenClaw App 项目的 TypeScript 侧 ← 已有不改 真正新写的代码 (openclaw-rl/opd/combine) : ┌──────────────────────────────────────────────────────────┐ │ ~2660 行 Python (精确统计) │ │ 分布在 8 个 .py 文件中: │ │ │ │ openclaw-rl/openclaw_api_server.py 730 行 │ │ openclaw-rl/openclaw_rollout.py 152 行 │ │ openclaw-opd/openclaw_opd_api_server.py 1001 行 │ │ openclaw-opd/openclaw_opd_rollout.py 158 行 │ │ openclaw-opd/topk_distillation_loss.py 120 行 │ │ openclaw-combine/combine_loss.py 140 行 │ │ openclaw-combine/openclaw_combine_api_ 205 行 │ │ server.py │ │ openclaw-combine/openclaw_combine_rollout.py 155 行 │ │ │ │ ───────────────────────────────────────── │ │ 合计: 2661 行 │ └──────────────────────────────────────────────────────────┘然而胶水是有极高技术含量的。胶水要处理异步状态管理、跨组件协调协议、框架接口适配这几个非平凡问题——这就是为什么代码量虽然不大但设计密度相当高。解决的核心问题纯粹的胶水只是把 A 的输出接到 B 的输入。但 RL infra 要解决的问题更复杂。接下来我们借助OpenClaw-RL来逐项拆解 RL infra 面对的几个核心问题看看对“胶水”的高技术要求。① 异步时序问题推理发生在 turn t但 reward 来自 turn t1next_state。这意味着我们无法在 turn t 结束时立刻打分需要一个有状态的异步状态机来桥接这个时间差。具体的实现方案是双缓冲设计_pending_turn_data:dict[str, dict[int, dict]]—— 按 session → turn 维度暂存 turn 数据等待 PRM 评分完成后再提交为 training sample。_pending_records:dict[str, dict]—— 按 session 维度暂存 JSON 记录等待 next_state 到达后写入 record file 并触发 PRM 评分。工作流程是turn N 到达 → 数据存入_pending_turn_data和_pending_records→ turn N1 到达 →_flush_pending_record弹出_pending_records中的记录并触发_fire_prm_scoring→ PRM 异步完成后回调_maybe_submit_ready_samples→ 从_pending_turn_data取出数据提交 sample。这不是简单的 pipeline而是有状态的双缓冲异步状态机。OPD 服务器使用了相同的双缓冲设计。② 训练与服务的权重同步问题Megatron 更新参数后需要同步到 SGLang 推理引擎。同步期间 SGLang 不能服务请求权重不一致需要一套协调机制来避免推理出半新半旧的权重。解法是通过threading.Event实现暂停/恢复信号generate_rollout_openclaw调用resume_submission()→ 收集完 batch 后调用pause_submission()API 层在处理请求时检查submission_enabled.is_set()若为 False 则返回HTTP 503这个 503 是一个优雅的稍后再试信号用户无感知OpenClaw 客户端会自动重试③ 奖励信号的延迟问题PRM 打分是异步的——我们需要并行查询 m 次再做多数投票。这意味着训练不能立即可用数据需要任务编排。具体实现asyncio.gather并行发起 m 次 PRM 查询_query_prm_onceasyncio.create_task创建后台评分任务task.add_done_callback注册两个回调_task_done_cb错误日志和_maybe_submit_ready_samples就绪检查 → 提交这个设计意味着PRM 评分和用户请求处理是完全并行的评分延迟不会阻塞用户的下一轮对话。④ 被动 Rollout 的适配问题Slime 默认期望一个主动发 prompt的 rollout 函数即训练框架驱动数据生成但 OpenClaw 的 rollout 是等用户来驱动——数据由真实的用户对话产生而非训练脚本采样。因此需要generate_rollout_openclaw实现被动等待语义恢复 submission → 从 output_queue 中排空已收集的 sample → 暂停 submission → 返回给 trainer这个函数是 Slime 框架要求的--rollout-function-path自定义入口属于对框架接口的非标准使用需要对 Slime 的接口语义有精确理解OpenClaw-RL vs 标准 RL infraOpenClaw-RL 又与标准 RL infra 有所不同我们来对比一下标准 RL infra如 OpenRLHFprompt_batch → generate → score → train → loop数据流是单向的时序是同步的OpenClaw-RL用户行为驱动 → 异步打分 → 被动收集 → 异步训练数据流是反向的时序是异步的。这个反转需要对每个组件的接口语义有深入理解才能把被动接收对话适配进主动采样框架一个直觉上的类比如下维度标准 RL infraOpenClaw-RL类比工厂流水线——原材料prompt进来产品trained model出去每道工序按顺序推进餐厅后厨——顾客点菜用户发消息是随机的、异步的厨师推理服务响应服务员API proxy收集反馈大厨训练在后台利用空隙持续学习数据驱动方训练框架主动采样用户行为驱动时序特征同步单向异步反向胶水代码负责让这个餐厅正常运转确保厨师学到的菜谱及时更新确保反馈被正确归因到正确的菜品确保后厨繁忙时前台能优雅地暂停取菜。0x02 论文基础论文题目是OpenClaw-RL: Train Any Agent Simply by Talking论文主要贡献点分析主要创新点首次提出将所有异构的交互信号用户聊天、终端报错、GUI 界面变化统一转化为实时的在线强化学习训练源。关键技术与方法设计了 OpenClaw-RL 异步解耦架构推理、环境、裁判、训练四个循环互不阻塞提出了两种互补的信号恢复方法即二元强化学习Binary RL用于提取标量奖励以及后见之明引导的同策略蒸馏OPD / On-Policy Distillation用于提取 Token 级别的方向性监督。显著性结果与意义不仅让个人专属 Agent 能通过日常聊天不断进化还证明了这套架构能完美扩展到通用 Agent如终端、GUI、软件工程、工具调用在长逻辑链任务中取得了 SOTA 级别的提升。2.1 核心问题现有的 AI Agent 系统存在一个问题每次 Agent 执行动作后收到的下一状态信号用户回复、工具输出、终端状态变化、GUI 界面更新等仅被用作生成下一轮对话的上下文信息被提取后随即被丢弃并未转化为实时训练模型的宝贵数据资源。这种数据浪费体现在两个层面评估信号浪费下一状态信号隐含着对前一动作的评价用户重新提问表示不满测试通过表示成功错误日志表示失败这本是天然的过程奖励但现有系统要么忽略要么仅用于离线训练。指导信号浪费下一状态信号中往往包含具体的改进方向如用户说你应该先检查文件或详细的 SWE 报错信息但现有方法要么只能使用对/错这样的标量奖励要么依赖预先准备好的反馈-响应配对未能利用好实时、具体的指导性反馈。现有方法的局限性论文系统梳理了现有方法的不足传统 RL for LLM 依赖集中式批量训练需要预先收集数据集无法个性化、实时优化具体如下RLHF/DPO依赖离线偏好数据或成对比较需要人工标注无法从实时交互中学习标准强化学习使用标量奖励无法将文本指导信息转化为策略梯度蒸馏方法依赖预策划的反馈-响应配对而非实时信号并发工作虽然尝试在线利用下一状态信息但纠错提示仍是隐式的核心洞察论文的核心观察是下一状态信号是通用的策略可以同时从所有类型的信号中学习。个人对话、终端执行、GUI 交互、SWE 任务和工具调用轨迹不再是各自独立的训练问题而是可以在同一循环中用于训练同一策略的交互流。基于这一观察研究团队提出了 OpenClaw-RL——一个让 AI Agent边用边学的统一强化学习框架。接下来我们思考一个关键问题为什么过程奖励对智能体任务至关重要在长视野的智能体任务中仅有结果的奖励只在最终步骤提供梯度信号而绝大多数轮次缺乏监督。PRM 根据下一状态信号为每轮分配奖励在整个轨迹中提供密集的信用分配。近期的工作为此提供了强有力的实证证据——RLAnything 证明将逐步的 PRM 信号与结果奖励整合在 GUI 智能体、文本游戏智能体和编码任务中的表现始终优于仅使用结果的训练。OpenClaw-RL 直接建立在这一洞察之上它的 PRM 将实时的下一状态信号作为证据来评判每个轮次并在实证部分证明这种密集的信号对长视野 RL 设置是有帮助的。解法核心思想为把用户日常对话本身变成训练信号用下一状态next state作为天然的奖励来源——不需要人工标注不需要中断使用体验。2.2 如何解决OpenClaw-RL 的个性化目标通过 RL 优化策略权重在本质上是把用户偏好/对话经验写入模型权重这是一种 Memory Consolidation记忆固化——推理时无需额外系统知识被内化进参数。OpenClaw-RL 主要采用三种学习方法。这三种方法的关系如下Binary RLopenclaw-rl/基础方法PRM ±1 评分 GRPOOPDopenclaw-opd/独立实现的 Teacher 模型通过 hint judge 生成 hint teacher log-probs 蒸馏Combinedopenclaw-combine/继承自 OPDclass OpenClawCombineAPIServer(OpenClawOPDAPIServer)同时使用 RL Reward 和 OPD teacher signal需要特别指出的是Binary RL 和 OPD 是两套独立的实现并非继承关系。从代码中可以清晰看到OpenClawAPIServer是独立类OpenClawOPDAPIServer是独立类