OpenClaw-RL 深度研究：和 AI 聊天就能训练它——给 OpenClaw 加上强化学习

> GitHub: Gen-Verse/OpenClaw-RL

> 论文: arxiv.org/abs/2603.10165

> 排名: HuggingFace Daily Papers #1（2026-03-10）

> 赞助: Tinker

> 研究时间: 2026-03-26

🎯 一句话版本

给 OpenClaw 加强化学习：你正常聊天，系统在后台自动收集对话轨迹、用 PRM/Judge 打分、训练模型。36 次交互就能看到明显改善。不中断使用，不需要手动标注。支持 Binary RL + On-Policy Distillation + 组合方法。还能训练 Terminal/GUI/SWE/Tool-call 通用 Agent。

🧠 为什么重要？

今天刚读完 Junyang Lin 的文章说"从训练模型到训练 Agent"，OpenClaw-RL 就是具体实现：

> 你每天和 OpenClaw 聊天 → 对话变成训练数据 → 模型在后台持续优化 → Agent 越用越懂你

这解决了 AI 个性化的终极问题——不是靠 prompt 工程，而是靠实际训练模型权重。

🔄 架构：4 组件异步循环

用户 ←→ Agent 服务（不中断）
            ↓
    Rollout 收集（对话轨迹）
            ↓
    PRM/Judge 评估（异步打分）
            ↓
    策略训练（后台更新权重）
            ↓
    更新后的模型 → 回到 Agent 服务

关键：四个组件互不阻塞。 你在聊天时，训练在跑；训练在跑时，打分在进行；全部异步。

📊 三种学习范式

Binary RL

你给 👍 或 👎 → PRM 基于"下一个状态"（用户的下一条消息/环境反馈）自动打分 → GRPO 优化

OPD（On-Policy Distillation）

你给文本反馈（"你应该先检查文件"）→ Judge 提取 hindsight hint → 用 hint 增强原始 prompt 创建"增强 teacher" → teacher 和 student 的 token-level 概率差成为训练信号

比 Binary RL 信号更丰富——不只是"好/坏"，而是"应该怎么改"。

Combined（推荐）

两者统一：scalar 监督 + token-level 方向信号。实验效果最好。

📈 效果

> 36 次问题解决交互（学生场景）就能看到明显改善。

> 24 次批改交互（教师场景）就能看到明显改善。

不是几千次、几万次——是几十次对话就能让模型变得更好。

🔧 Track 2：通用 Agent 训练

同一套异步 RL 骨架，还能训练通用 Agent：

🔌 和 OpenClaw 的集成

步骤

1. 安装扩展：rl-training-headers 到 OpenClaw

2. 启动 RL Server：

`bash

cd slime

bash ../openclaw-combine/run_qwen3_4b_openclaw_combine.sh

`

3. 配置 openclaw.json：把模型指向 RL Server（http://:30000/v1）

4. 聊天：正常用。系统自动收集→打分→训练

硬件选项

支持的基础模型

• Qwen3-4B
• Qwen3-8B

💡 与我们的关联

1. 这就是 OpenClaw 的下一步 ⭐⭐⭐⭐

之前我们讨论了各种记忆系统（Hermes/TELOS/Hindsight）——都是通过上下文让 AI 更懂你。OpenClaw-RL 走得更远：直接修改模型权重。

2. ub2 上可以跑吗？

• Qwen3-4B LoRA：可能可以在单张 RTX 4090 上跑
• Qwen3-8B LoRA：显存可能紧张
• Full fine-tuning：8× GPU，ub2 不够
• Tinker 云：零 GPU 方案，但需要网络和 API

3. 和 Junyang Lin 文章的完美呼应

今天 Junyang Lin 说：

> "从训练模型 → 训练 Agent → 训练系统"

OpenClaw-RL 就是"训练 Agent"的具体实现——在真实对话环境中，用环境反馈做 RL。

4. 和 Mario Zechner "慢下来"的张力

Mario 说 Agent 的问题是"不学习"。OpenClaw-RL 直接解决了这个问题——Agent 从每次对话中学习。但这也带来新问题：如果训练信号有噪声（你给了不恰当的 👎），模型可能往错误方向优化。

5. 隐私优势

> 整个 stack——策略模型、Judge/PRM、训练器——全在你自己的基础设施上运行。对话数据不离开你的系统。

这和我们自托管 OpenClaw 的理念一致。

📄 论文深度解读

> 论文：OpenClaw-RL: Train Any Agent Simply by Talking

> 提交：2026-03-10 | 第一作者：Ling Yang | 873KB

核心洞察：Next-State Signal 是被浪费的金矿

论文的起点非常简洁：

> 每次 Agent 做了一个动作 $a_t$ 之后，都会收到一个"下一个状态" $s_{t+1}$——用户的回复、工具的输出、终端的状态变化、GUI 的界面更新。现有系统把它当成下一轮的上下文用完就扔了。我们说它其实编码了两种信息。

两种被浪费的信号：

这是论文最有价值的抽象：所有 Agent 交互（对话/终端/GUI/SWE/工具调用）本质上都是同一个东西——动作→下一状态→包含评估+方向信息。不需要分开处理。

MDP 形式化

每个交互流被建模为 MDP $(S, A, T, r)$：

• 状态 $s_t$：到第 $t$ 轮为止的全部上下文
• 动作 $a_t$：Agent 生成的 token 序列
• 转移 $T(s_{t+1}|s_t, a_t)$：确定性的（环境给出回复）
• 奖励 $r(a_t, s_{t+1})$：从下一状态信号推断

Binary RL：详细机制

PRM Judge 构造：

PRM(a_t, s_{t+1}) → r ∈ {+1, -1, 0}

• 工具调用结果 → 通常有明确结论（成功/失败）
• 用户下一条消息 → 可能包含满意/不满信号
• 没有明确信号 → 模型根据场景估计（鼓励用户多给显式反馈）

多数投票：跑 $m$ 次独立 Judge 查询，取多数票 $r_{final} = MajorityVote(r_1, ..., r_m)$。

训练目标：标准 PPO-style clipped surrogate，但有非对称边界：

• $\varepsilon = 0.2$（下界）
• $\varepsilon_{high} = 0.28$（上界）
• $\beta_{KL} = 0.02$

关键限制：这是实时对话场景，没有 group 结构可以做 GRPO 式的标准化。所以 advantage 直接用 $A_t = r_{final}$。

OPD：论文最大的创新

为什么标量奖励不够？

> 用户说"你应该先检查文件再编辑"——这不只是说"你错了"（标量 -1），而是说了哪些 token 应该不同、怎么不同。标量奖励把这些信息全部丢掉了。

4 步流程（详细版）：

Step 1. Hindsight Hint 提取

Judge(a_t, s_{t+1}) → {score ∈ {+1, -1}, hint ∈ T*}

⚠️ 关键设计：不直接用 $s_{t+1}$ 作为 hint。原始下一状态通常有噪声（用户回复可能同时包含纠正和新问题）。Judge 把 $s_{t+1}$ 蒸馏成 1-3 句简洁的、可操作的指令。

Step 2. Hint 筛选

• 在正面投票中，选 hint > 10 字符的
• 取最长的那个（最有信息量）
• 没有有效 hint → 直接丢弃这个 sample

这是故意的——OPD 用样本质量换取信号质量。只有方向性信号清晰的 turn 才进入训练。Binary RL 负责广覆盖，OPD 负责精确制导。

Step 3. 增强 Teacher 构造

把 hint 追加到最后一条用户消息后面：

s_enhanced = s_t ⊕ "[user's hint]\n{hint}"

这等于创造了一个"如果用户提前告诉你该怎么做"的平行世界。

Step 4. Token-Level Advantage

A_t = log π_teacher(a_t | s_enhanced) - log π_θ(a_t | s_t)

• $A_t > 0$：Teacher（知道 hint）给这个 token 更高概率 → 学生应该增强它
• $A_t < 0$：Teacher 认为这个 token 不合适 → 学生应该抑制它

和其他方法的区别：

• vs RLHF：RLHF 用标量偏好信号
• vs DPO：DPO 需要配对偏好数据
• vs 标准蒸馏：需要一个独立的更强 teacher 模型
• OPD 用的是同一个模型——只是给它更多信息后，它自己就知道该怎么做了

Combined Method

A_t = w_binary × r_final + w_opd × (log π_teacher - log π_θ)

默认 $w_{binary} = w_{opd} = 1$。两者共享同一个 PPO loss，只是 advantage 计算不同。

实验结果详解

个人 Agent（模拟实验）：

关键发现：

• Binary RL 单独用效果很弱（0.25→0.23，甚至下降）
• OPD 有延迟效应（8步时只有0.25，16步时突然跳到0.72）——因为有效样本少，需要积累
• Combined 两者互补：Binary RL 提供早期覆盖，OPD 提供后期精确制导

通用 Agent：

Process Reward 对长 horizon 任务至关重要——因为 outcome-only 只在最后一步给梯度。

Session-Aware 设计

每个 API 请求被分为两类：

• Main-line turn：Agent 的主要回复 + 工具执行结果 → 可训练
• Side turn：辅助查询、记忆整理、环境转换 → 转发但不训练

这个分类让 RL 框架精确知道哪些 turn 属于哪个 session。

训练超参数

基础设施：建立在 Slime 之上

Slime 是清华 THUDM 的 RL 框架。OpenClaw-RL 在此基础上增加了：

• SGLang 做推理
• Megatron 做训练
• HTTP/API 连接环境
• Session-aware 多轮跟踪
• 非阻塞日志（JSONL，每次权重更新清空）
• 优雅权重更新（不中断推理）

论文定位：Related Work 中的位置

🛠️ 实操指南：怎么跑、花多少钱

方案一：Tinker 云（零 GPU，最简单）⭐推荐入门

Tinker 是一个训练 API 云平台，4 个函数搞定：forward_backward → optim_step → sample → save_state。

步骤：

1. 注册 Tinker：auth.thinkingmachines.ai/sign-up

2. 安装 OpenClaw 扩展：

`bash

# 复制 rl-training-headers 到 OpenClaw extensions 目录

plugins enable rl-training-headers

gateway restart

`

3. 启动训练：

`bash

cd openclaw-tinker

export TINKER_API_KEY="your-key"

python run.py --method combine \

--model-name Qwen/Qwen3-8B \

--batch-size 16 --prm-m 1 \

--w-opd 1.0 --w-rl 1.0

`

4. 配置 openclaw.json：把模型指向 http://localhost:30000/v1

5. 正常聊天。系统自动收集→打分→训练。

Tinker 价格（per M tokens）：

月费估算（每天 50 轮对话，每轮 ~2K tokens）：

方案二：本地 GPU（ub2 单卡 4090）

cd slime
bash ../openclaw-combine/run_qwen3_4b_openclaw_combine_lora.sh

• Qwen3-4B LoRA：可能 刚好够跑（24GB VRAM）
• Qwen3-8B LoRA：大概率爆显存
• 花费：仅电费，但单卡同时跑推理+训练很紧张

方案三：8× GPU 集群（Full Fine-tuning）

默认配置需要 8× GPU。适合有 GPU 集群的团队。效果最好但成本最高。

OpenClaw 扩展原理

扩展 rl-training-headers 在每个 LLM API 请求中注入两个 HTTP header：

RL Server 根据这两个 header 把对话轨迹分组、过滤 side turn、只训练 main turn。

具体例子：学生场景

训练前：模型回复数学题时用 "bold"、分步骤、过度结构化——一眼 AI。

训练后（36 次交互）：回复变得更自然、更口语化。学生正常给反馈（"太正式了"、"别用这种格式"），模型自己学会了。

Qwen3.5-27B 能跑吗？

仓库没有现成的 27B OpenClaw-RL 脚本。现有 OpenClaw 脚本只覆盖 Qwen3-4B 和 Qwen3.5-4B。

但基础设施支持：

• Slime 底层有 slime/scripts/models/qwen3.5-27B.sh 模型配置
• Tinker 云定价列了 Qwen3.5-27B：采样 $3.73/M，训练 $3.73/M

性价比建议：Tinker 上跑 27B 不如用 Qwen3-30B-A3B（MoE，只激活 3B）——价格 $0.30/$0.36/M，比 27B 便宜 10 倍，推理速度也快得多。

方案对比

> ⚠️ 训练出的小模型适合个性化（风格/偏好/格式），不适合替代大模型的推理能力。训练后的 4B 在复杂任务上仍然不如直接用 Claude Opus。

⚠️ 注意事项

1. 硬件门槛高：默认 8× GPU，即使 LoRA 也需要不少资源

2. 还在快速迭代：一个月内发了 7 个版本更新

3. 小模型限制：目前只支持 Qwen3-4B/8B，不是 Claude Opus 级别

4. 训练质量依赖反馈质量：垃圾反馈 → 垃圾模型

5. 和大模型 API 的对比：训练后的 4B 模型可能仍然不如直接用 Claude Opus

📊 评分

报告由深度研究助手自动生成 | 2026-03-26

来源: GitHub / 论文