列的目的是借着对 OpenClaw-RL 源码的学习来梳理强化学习的一些相关概念和思想。所以会有一些基础知识、扩展和发散OpenClaw-RL 只是一个切入点。而且因为整篇系列是一个整体所以有些概念的解读/学习会在不同的文章中出现还请大家谅解。OpenClaw-RL 是一个用于在线强化学习Online RL的框架专门针对智能体工具使用场景。它通过从环境反馈中提取过程奖励信号来训练语言模型支持三种主要模式openclaw-rl基于二元奖励的强化学习Binary RL / GRPOopenclaw-opd基于后见之明提示的在线策略蒸馏On-Policy Distillation, OPDopenclaw-combine联合方法在同一 PPO 更新中同时利用 RL reward 和 OPD teacher signalframework前文提到了Reward 理论上属于 environment 的一部分, 实践中是独立的 Reward Judging 阶段。在 OpenClaw 这种工程系统中, 把它看作独立阶段更有助于理解架构。因此我们本篇继续看看 Reward Judging。0x01 Reward 基础1.1 RL 和 Agentic RL 中常见的 Reward 类型常见的 Reward 分类框架如下Reward 来源分类├─ Environment Reward│ ├─ 确定性游戏│ └─ 可验证代码/数学├─ Model-Based Reward│ ├─ Trained RMRLHF│ └─ LLM JudgeConstitutional└─ Human Reward└─ 偏好标注RLHF如果从Reward 来源谱系来分类则可以把上图细化为硬件级deterministic游戏得分、机器人传感器→ 完全客观、零噪声规则级verifiable数学答案正确性、代码测试通过→ 客观但有边界正则表达式匹配、test suite 覆盖率人类级subjectiveRLHF 中人类标注者的偏好→ 主观、昂贵、不可复现LLM Judge 级proxy ← OpenClaw 在这里LLM 解读 next_state 后的评分→ 主观的自动化版本便宜但可能有偏经典 RL经典 RL 的 Reward如下全部是 environment reward - 由模拟器/物理世界直接产生。领域 Reward 来源 类型Atari 游戏 游戏引擎分数 Environment确定性机器人控制 传感器信号距离目标 Environment连续棋类/围棋 赢/输/平 Environment稀疏对话 用户反馈/评价 Environment隐式/稀疏导航 到达目标点 Environment稀疏交通调度 等待时间、吞吐量 Environment设计的LLM RL 的 Reward非 AgenticLLM RL 的 Reward非 Agentic如下这是混合Reward有 environment reward 也有 model-based reward。场景 Reward 来源 类型数学推理 答案正确性regex/计算验证 Environmentverifiable代码生成 测试通过率 EnvironmentverifiableRLHF 人类标注偏好 → 训练 Reward Model Learned ModelConstitutional AI LLM 自评符合原则 LLM JudgeDPO 隐式 reward偏好数据 ImplicitAgentic RL 的 RewardAgentic RL 的 Reward 举例如下场景 Reward 来源 是 Environment Reward?SWE-agent代码修复 CI 通过 / 测试 pass ✓ EnvironmentWebShop网购 买到目标商品 ✓ EnvironmentALFWorld家务 任务完成 ✓ EnvironmentScienceWorld 实验成功 ✓ EnvironmentBrowser agent 网页操作成功 ✓ EnvironmentTerminal agentSETA/AReaL 命令执行结果 ✓ Environment对话 agentOpenClaw LLM Judge 评估 × Proxy RewardSearch agentASearcher 搜索质量分 部分 Env JudgeCustomer service 问题解决率 部分 Env HumanAgentic RL 的关键特点大部分有 Environment Reward。为什么 Agentic RL 通常有 environment reward这是因为 Agent 与工具/环境交互 → 环境给出确定性反馈代码执行pass/fail确定性终端命令exit code 0/non-0确定性网页操作目标元素出现/消失确定性API 调用200 OK / 4xx error确定性这些反馈直接可以作为 reward成功 → 1失败 → -1不需要 LLM Judge 做中介1.2 Reward 函数 vs Advantage 函数我们再来对比下Reward 函数和Advantage 函数的区别。Reward 是原材料, Advantage 是加工品, 梯度是最终产品。Reward环境打的原始评分告诉你这个回答有多好”Advantage加工后的信号告诉你这个回答比基线好多少”是相对化细化后的训练信号 →直接乘进梯度。Reward→Advantage→PPO clip → 梯度更新层层加工。角色分工┌──────────────┐ R ┌──────────────┐ A ┌──────────────┐│ 环境/评委 │ ──────→ │ Advantage │ ──────→ │ 策略梯度 ││ (Reward) │ │ (估计器) │ │ (更新 θ) │└──────────────┘ └──────────────┘ └──────────────┘“打分” “相对化” “更新”Reward是input(来自环境/评委)Advantage是processing(去偏、归一化、细化到token)PPO loss是output regulation(限速器)梯度更新是execution(实际改参数)核心区别Reward 函数 R(o) Advantage 函数 A(o,t)是什么 对一条 response 打分好/差/中性 对一条 response 的相对优势评估粒度 通常 per-response(1 个标量) 可以 per-response 或 per-token包含 baseline 吗 ❌ 不包含 ✅ 已减去 baseline (A R - baseline)语义 “这条回答有多好” “这条回答比平均水平好多少”梯度流 不直接进入梯度 直接乘进 policy gradient是否可以直接使用Reward我们再来看看是否可以直接使用Reward。假设Reward和Advantage如下Reward 考试卷子的绝对分数(90分)Advantage 你比班级平均分高多少(14分)方案1直接用reward(REINFORCE原始版)∇θ ≈ R·∇logπ(o|q)该方案的问题全班平均分考90分→R90→梯度很大→但其实没有学习信号假设你考90别人考85→ 但是R依然为90→你的梯度和全班90一样大因此只看 reward 无法训练——全班都 90 分时没有方向感。只有 Advantage 才能告诉 model “你的回答比别人好在哪”。方案2用advantage(减去基线)∇θ ≈ A·∇logπ(o|q)其中 AR-baseline假设你分数为90。全班平均分为 90A90-900→无梯度←正确没信号就不更新假设全班平均分为87.5A90-87.52.5→正向梯度←正确你比平均好因此还是用方案2好。直觉总结Reward“考试卷子发回来了你得了90分”Advantage“你比班级平均高5分其中第3题特别好(2)第7题不太行(-1)”PPO clip: “不管分数多高每次调整不能超过限定步长”梯度更新“针对第3题的方法多练第7题的方法少用”Advantage的三重作用1.去除baseline(减少方差)AR-b→消除共同偏移只保留相对差异→ 梯度方差从 Var(R·∇logπ) 降到 Var((R-b)·∇logπ)2.确定方向(token级别)A_t 0 → 增大 token t 的概率A_t 0 → 减小 token t 的概率A_t 0 → 不变3.确定步长|A_t| 大 → 梯度大 → 更新幅度大|A_t| 小 → 梯度小 → 更新幅度小转换方式RL中常见的Reward→Advantage转换方式如下9-转换方式0x02 OpenClaw-RL 的Reward 函数2.1 RL 变体 Reward 函数本项目全部 RL 变体一览OpenClaw-RL-main/├── openclaw-rl/ ① Binary RL (对话)├── openclaw-opd/ ① OPD (对话)├── openclaw-combine/ ③ Combine: RLOPD (对话)├── swe-rl/ ④ SWE-RL (代码修复)├── gui-rl/ ⑤ GUI-RL (桌面操控)├── terminal-rl/ ⑥ Terminal-RL (终端Agent)├── toolcall-rl/ ⑦ Tool-Call RL (数学代码)└── openclaw-tinker/ ⑧ Tinker (轻量实验后端)7 种 RL 变体对比9-7 种 RL 变体对比按奖励来源分类┌──────────────────────────────────────────────────────────────────────────────┐│ 纯环境奖励 (确定性, ground truth) ││ ④ SWE-RL: 测试套件 pass/fail ││ ⑤ GUI-RL: OSWorld evaluator (预定义验证脚本) ││ ⑥ Terminal-RL: 任务完成检测 ││ ⑦ Tool-Call: 数学答案正确性 (\boxed{} match) │├──────────────────────────────────────────────────────────────────────────────┤│ 纯代理奖励 (LLM Judge, 非确定性) ││ ① Binary RL: zero-shot Judge {-1, 0, 1} ││ ① OPD: Teacher hint log-prob distillation ││ ③ Combine: ①② │├──────────────────────────────────────────────────────────────────────────────┤│ 环境 PRM 混合 (环境为主, PRM辅助) ││ ④⑤⑥⑦ 的 PRM 模式: ││ final_reward outcome ± prm_coef × step_mean │└──────────────────────────────────────────────────────────────────────────────┘关键洞察对话场景 (①②③) 是最难的 - 没有环境信号, 全靠 LLM JudgeAgent 场景 (④⑤⑥⑦) 都有确定性环境奖励 - PRM 只是补充 dense signalPRM 在不同场景中角色相反:对话: PRM 唯一奖励来源Agent: PRM 辅助过程奖励 (解决 sparse reward 问题)共享基础设施: 所有变体都用 Slime GRPO PPO clip, 只是 rollout 和 reward 不同2.2 对话 RL 的 Reward 函数OpenClaw-RL 的对话RL只有 1 种 reward 函数唯一的 Reward 产生机制PRM Judgezero-shot LLM judge。即PRM majority vote → {-1, 0, 1}。方法 Reward 来源 输出Binary RL LLM Judge (PRM) zero-shot 评分OPD 同上(用于监控 eval_mode)Combine 同上(用于 RL 路径)具体参见下图OpenClaw 的 reward 100% 来自 Reward Judging (LLM Judge)↓┌───────────────────────┐│ SGLang PRM (GPU 6-7) ││ ├── Binary RL: ±1 评分 │ ← Judging│ └── OPD: hint 生成 │ ← Judging└───────────────────────┘↓没有 environment reward(用户对话本身不提供可验证的正确答案)2.2.1 为何不使用环境Reward传统 RL vs OpenClaw 的 reward 来源传统 RL游戏/机器人Environment → reward确定性规则定义例走了一步棋 → 赢/输/平 → 1/0/-1LLM RL数学/代码Environment → reward确定性可验证例生成代码 → 执行测试 → pass/fail → 1/-1OpenClaw-RL开放域对话✘ 没有传统意义上的 “environment reward”✔ 只有 LLM Judge 的主观评估对话场景OpenClaw 的场景 “开放域对话 agent”。对话场景的本质如下没有客观正确答案不像数学题没有可执行验证不像代码好坏是主观判断用户的下一条消息是最接近 environment 信号的东西用户说谢谢 → 可能是好用户说不对重来 → 可能是坏用户说另一个问题 → 不确定为什么一种 reward 就够了对于 Binary RL - {-1, 0, 1} 一种就够了这是因为单维度评分已经覆盖了好/坏/不确定对话场景下很难设计多维度 reward前面讨论过简单 robust 不容易被 hackHint judgeOPD的评分格式类似但目的不同选最佳 hintOPD: reward 仍然来自 PRM judge同一个函数但 advantage 不只靠 reward还有 teacher_lp - student_lpCombine: reward 来自 PRM judge OPD teacher advantage → 两种信号混合但 reward 来源是同一个2.2.2 Reward Design因为OpenClaw 的 reward 100% 来自 Reward Judging (LLM Judge)所以在 OpenClaw 语境下, Reward Design Reward Judging。openclaw_api_server.py L77-116: PRM Prompt评估规则\boxed{1} (good): 下一状态表明任务正常推进\boxed{-1} (bad): 下一状态表明助手输出错误/不完整\boxed{0} (neutral): 下一状态模糊无法判断输入Assistant output Next state用户的下一条消息或 tool return输出{-1, 0, 1}加强- Majority votem3次独立调用- 平局 → 0.0- At-least-one guaranteesession内至少一个sample有loss_mask12.2.3 阶段需要区分reward 的产生和reward 的读取两个阶段。Reward 传递到 Slime 的两步如下步骤1API Server 产生 rewardPRM judge 评分 → sample.reward 步骤2Slime 读取 rewardpassthrough不做任何额外计算 → reward_func(args, sample) 只是读取 sample.reward[“score”]需要注意两点在OpenClaw OPD中reward(PRM±1)不参与advantage计算仅用于如下监控(wandb日志中记录prm_eval_score)loss_mask 筛选reward0 时可能跳过样本reward_func (位于 openclaw-rl/openclaw_api_server.py) 并非评分函数本体而是一个简单的查表穿透函数空壳——它仅从 sample.reward dict 中读取已预先计算好的 “score” 字段返回。实际的评分逻辑在 _prm_evaluate() 中异步调用 LLM Judge majority vote。reward_func 被 Slime Trainer 回调以获取每轮 reward。具体如下async def reward_func(args, sample_or_samples, **kwargs):# 直接从 sample.reward 中取出已经算好的 scorereturn {“score”: s.reward.get(“score”, 0.0)}为什么 因为 Slime 的 --custom-rm-path 接口要求提供一个 reward_func但 OpenClaw 的 reward 已经在 API server 里算好了在 sample 被提交到训练队列之前。所以这个 func 只是取值不是计算。2.2.4 修饰/后处理Reward 函数需要一些后处理。处理 说明Majority vote m3 独立评估取多数平局处理 无多数时返回 0.0At-least-one session 内全0时强制一个为 loss_mask1Score → loss_mask ±1→训练0→跳过–disable-rewards-normalization 不做 batch 内标准化2.2.5 完整 reward 流水线用户发消息 → Model 回复 → 用户再发消息next_state↓PRM JudgeGPU 6-7├─ 调用 m3 次├─ 每次看 response next_state└─ 输出\boxed{1} / \boxed{0} / \boxed{-1}↓majority_vote → final score↓sample.reward {“score”: final_score}↓↓score1.0 score0.0 score-1.0loss_mask[1] loss_mask[0]* loss_mask[1]*除非 at-least-one↓↓提交到 Slime 训练队列↓reward_funcpassthrough取出 score↓GRPO: advantage scorebroadcast0x03 OpenClaw-RL 的Reward 函数 vs Advantage 函数所以整个 OpenClaw-RL 项目对话RL中Reward 函数 1 种PRM Judge {-1,0,1}Advantage 函数 3 种GRPO / OPD / Combined3.1 Advantage 函数OpenClaw 中三种方法用不同的 advantage:方法 Advantage 公式 粒度Binary RL (GRPO) A_t R (标量 broadcast) per-responseOPDAtlpteachert−lprollouttper-tokenCombineAtwrl⋅Rwopd⋅(lpteachertlprolloutt)per-token这里我们有一个问题为什么OPD的advantage 计算时候不需要reward这是因为teacher本身就是奖励信号的载体teacher 的log-probs 本身就是比 reward更丰富的信号。传统RL环境给reward→转化为advantage→梯度方向。OPDteacher 模型→直接给出per-token的好坏判断→梯度方向OPD的advantage 是A_tteacher_lp_t-old_lp_t teacher_lp_told_lp_t→teacher更喜欢这个token→A0→增大概率teacher_lp_told_lp_t→teacher 不喜欢这个token →A0→减小概率teacher_lp_told_lp_t→已经对齐→A≈0→不变reward告诉你整个回答好不好(1bit)而teacher log-probs告诉你每个token应该往哪走、走多远(per-token dense signal)。3.2 信息流信息流关系如下Reward 是评分原材料({-1,0,1})Advantage 是训练实际用的信号。三种方法 reward 相同但 advantage 差异巨大。9-信息流3.3 配合的完整链路阶段 1: 产生 Reward用户对话 → PRM 评分 → R ∈ {-1, 0, 1}阶段 2: Reward → Advantage├─ Binary RL: A R(broadcast 到所有 token)│ 信息量1 bit per response│├─ OPD: A_t teacher_lp_t - old_lp_t│ 信息量~32 bits per token│ (reward 只用于 loss_mask 筛选不进入 advantage)│└─ Combine: A_t w_rl·R w_opd·(teacher_lp_t - old_lp_t)信息量混合阶段 3: Advantage → 策略梯度ratio π_new / π_oldloss -min(ratio · A, clip(ratio) · A) ← PPO clip阶段 4: 梯度 → 参数更新θ_new θ_old - lr · ∇loss ← Adam optimizer3.4 对比环节 Binary RL OPD CombineReward 信息量 1 bit 1 bit(仅监控) 1 bitAdvantage 信息量 1 bit × T tokens(全相同) ~32 bits × T(每位置不同) 混合信息放大比 1× ~32T× 中间0x04 奖励函数设计的问题本节我们看看为什么奖励函数设计是环境设计最容易失败的环节。奖励是设计者价值判断的唯一编码因此对奖励函数有两个要求必须定义什么算好 ---- 这是价值判断。价值判断是主观的、不完整的、随语境变化的→ 奖励 你脑子里所有隐性假设的显式编码→ 任何未明确编码的假设 可以被利用的漏洞4.1 失败模式我们来看看奖励函数的几个失败模式。失败模式一Reward Hacking经典案例(非LLM领域)如下Atari划艇游戏奖励 速度作为分数期望行为 赢得比赛RL发现在起点附近绕圈吃分 → 正常竞速 → 得到了最高分但从未完成一次比赛 → 奖励函数被精确地最大化了”但与设计意图完全背离 LLM对话领域LLM对话领域奖励judge 打分(偏好详细、有条理的回复)期望行为简洁准确地帮助用户RL发现格式为“首先…其次…再次…总结来说…” → judge打1直接回答是的→judge 打 0这样 → 模型学会了用格式骗judge而非真正理解用户需求 → 用户说“你每次回答都太长了”但RL信号依然继续强化长度失败模式二Goodhart’s Law(古德哈特定律)当一个度量指标变成目标时它就不再是一个好的度量指标。原始意图用next_state 是否有意义” 来衡量回复质量RL优化后模型发现给出一个会让用户追问下去的神秘答案 → 用户的 next_state 内容丰富 (追问) → judge 打高分 → 但实际上用户是因为没搞懂才追问的并不是真正被帮到了度量变成了目标→度量失效失败模式三隐性假设的不完整性设计者的真实意图(脑子里)回答要准确 有帮助 合适长度 不侮辱用户 不违反事实 … 数十条隐性约束奖励函数实际编码的“judge 打 1” 只捕获了 judge 的偏好而 judge 本身的偏好也是不完整的未编码的部分可利用的自由度“准确但无帮助” → judge可能打1 (其实是 表述清晰但答非所问)helpful但长” → judge可能打1(用户追问但其实是因为想了解更多)失败模式四奖励信号的分布外行为以下是一种分布可能奖励函数在设计时的训练分布模型在初级水平时的回复”→judge的判断是可靠的模型能力提升后“模型在高级水平时的回复” → judge不一定还能准确辨别好坏 → judge自己的能力上限可能低于被训练的model → 奖励函数外推失效” → RL信号的质量随模型能力提升而下降也可以从以下两个角度看失真状态、动作、转移的失真 改变了世界怎么运转”(可客观验证)。带来的问题是测试时换到真实环境会暴露(行为异常是可观测的)。奖励函数的失真改变了什么是好”(主观无客观标准)。带来的问题是模型按照失真的奖励完美优化了 → 在你的评估体系里得高分 → 但在真实使用中体验很差且没有简单的方法发现这个 gap → 失真是隐形的最危险。4.2 OpenClaw 的奖励函数在哪里面临这些风险风险APRM judge有隐性偏好judge 与policy同族的Qwen3模型它的偏好 ≈ Qwen3的训练数据中好回复的分布但真正用户满意度 ≠ “Qwen3认为的好回复”风险Bnext_state的多义性用户追问没懂(负面)还是感兴趣(正面)judge必须推断推断有时候是错的风险Cscore0的模糊性中性”可能是好回复但judge 不确定确实平庸的回复judge 请求失败三种原因在代码里都产生 score 0 → 无法区分信号来源4.3 一句话总结奖励函数是环境设计中最容易失败的环节因为它是人类价值判断的显式编码一而价值判断天然是主观的、不完整的、随语境变化的。设计者的每一条隐性假设都必须被明确写入奖励函数任何遗漏都会成为RL 可以利用的漏洞。环境的其他部分可以用事实性规则验证奖励函数的失真却是隐形的因为模型会成功地优化错误的目标。0x05 Reward Design 的关键Reward Design的关键是目标拆分 验证策略分类。有一种比较常见的说法认为Reward Design的关键维度是correctness, quality, efficiency, robustness。也有人依据这些维度设计出来分数Score f(correctness, quality, efficiency, robustness)。但是此分数值得商榷。5.1 为什么给更多分数不够前面 0x04 已经用 Goodhart’s Law 解释了单一度量会被 hack的机制。这里我们从另一个角度追问把多个维度合并成一个综合分数为什么也救不了问题的本质不是分数不够多而是四个目标被错误地合并成了一个。Score f(correctness, quality, efficiency, robustness) 看似综合但模型会找到让 f 最大化的捷径而不是同时提升四个维度。这会导致典型失真“回答正确但解释啰嗦” → 单分高看起来质量好“测试用例全过但代码不可维护” → 单分高通过了验证“对常见问题回答好但边缘情况一概而论” → 单分高换句话说模型要么 hack 了输出找到看起来输出好但过程不好的捷径要么真的做好了输出好 过程好 在新情境下也好。合并维度的综合分数无法区分这两种情况。5.2 四个维度本质不同这四个维度不仅含义不同它们对游戏规则的抵抗力也完全不同。维度 本质Correctness 结果是否符合客观标准(有ground truth) / 信息是否正确、无幻觉、无事实错误Quality 结果有帮助需要判断/ 回答的整体品质表达、组织、深度、适当性Efficiency 是否用最少的代价达成目标(可量化但需定义代价函数) / 是否简洁、不冗余、直达要点Robustness 是否在未见过的情况下仍然有效(只能在OOD上测) / 面对 edge case/adversarial input 是否稳健5.2.1 对比各维度维度 问什么 例子Correctness “对不对” 224 ✓ / 225 ×Quality “好不好” 解释清晰 ✓ / 含糊啰嗦 ×Efficiency “简不简洁” 一句话说清 ✓ / 写了500字废话 ×Robustness “极端情况行不行” 处理了 null ✓ / 直接崩了 ×5.2.2 类比类比人类专业评价体系。一个好医生不只是诊断正确(答对)“而是怎样行医才算好”───────────────────────────────────────────────维度 验证方式───────────────────────────────────────────────Correctness → 诊断结果与病理报告一致(硬验证)Quality → 是否完成了必要的鉴别诊断(流程评审)Efficiency → 是否避免了不必要的检查(成本审计)Robustness → 遇到罕见疾病时是否仍然有效(OOD测试)───────────────────────────────────────────────如果只考核病人是否康复→ 医生学会用最大剂量药物大概率有效(高效能、低效率的投机)如果只考核检查数量是否少→ 医生学会少做检查可能漏诊所以好的医疗评价体系不是更多分数而是对怎样行医才算好的完整规格5.3 OpenClaw-RL 在这个框架下的分析OpenClaw Reward Design 目前的设计LLM Judge → 单一 score ∈ {-1, 0, 1}5.3.1 涵盖的维度OpenClaw当前隐含的好工作定义 LLM Judge的1/0/-1隐含着“好的对话工作让用户继续交互”(下一轮对话质量)。这个单一score实际上把所有 4 个维度压缩为一个判断“next_state 是否表明 assistant 的 output 成功满足了用户意图”。即这个判断隐含地融合了如果内容错误 → 用户会纠正 → -1correctness如果表达差 → 用户会困惑/重问 → -1quality如果太冗长 → 用户可能不满 → 但 PRM 可能判 0efficiencyRobustness 在对话中较少体现5.3.2 at-least-one guarantee从 Reward Design 角度来看at-least-one是在修补score0的安全区间投机问题但这是score合并太多维度的症状而非根本原因。比如如果把 Efficiency 单独作为维度回复太长→efficiency score下降→仍然有梯度不需要at-least-one guarantee来防止零梯度因为总有某个维度的 score≠0。因此→维度拆分 独立reward 可能是at-least-one 的系统级替代方案5.3.3 Specification EngineeringReward Design Specification Engineering(需求规格化)而非 Measurement Engineering(度量工程)。问题不在于有没有分数而在于这个分数是否正确地分离了不同目标并用对应的验证策略阻止了每种可能的投机方式。Reward不是测量仪而是对什么是好的工作的定义。把目标拆开不只是技术上的分解而是在做一件更根本的事明确说出好的工作由哪些维度组成为每个维度选择阻止投机的验证方式。5.3.4 价值观的编码Reward是价值观的编码。当我们说把目标拆开再选验证方式时实际上是在做这件事把人类认为好的工作的价值观编码成机器可执行的形式。这不是工程问题而是价值对齐问题你选择包含efficiency→你说好工作不浪费资源你选择包含robustness→你说好工作不只是对自己有用你只包含correctness→你说结果对就行过程不重要OpenClaw的Judge当前定义的价值观“对当前用户、当前时刻有帮助的工作就是好工作”更完整的价值观应该是“对不同用户、以高效可靠的方式产出高质量推理的工作才是好工作”这两种定义会训练出本质不同的模型。应该把Reward Design 从如何更好地测量输出提升到了如何精确地定义什么是好的工作方式一这是一个完全不同层次的问题。5.3.5 改进方向当前设计4 维度 → 1 个信号 {-1, 0, 1}信息量log₂(3) ≈ 1.58 bits/sample如果想对OpenClaw-RL进行改进则有如下思路短期把token效率单独作为第二个reward维度reward a x Judge_score β x(1 / response_length)中期增加OOD测试轮(周期性用holdout用户集测试)测Robustness是否在下降长期按correctness/quality/efficiency分开存储loss_mask允许各维度独立更新不互相干扰具体如下① 连续化 reward最小改动当前 {-1, 0, 1} → 3 级改进 [-1.0, 1.0] → 连续分数实现修改 PRM prompt“给出 0.0 ~ 1.0 的分数0完全失败1完美回答”→ 直接输出浮点数优势信号更细腻0.3 和 0.7 有区别风险LLM 给连续分的一致性比离散分差majority vote 需改为 averaging② 多维度 rubric中等改动当前 “好不好” → ±1改进 “准确性有用性安全性” → 各 0-2实现PRM Prompt: “按以下维度评分\boxed{A,H,S}”聚合score 0.4A 0.3H 0.2*S - 1.0归一化到 [-1,1]优势训练信号更丰富可以针对性优化弱项风险Judge 准确性下降注意力分散Reward hacking偏科majority vote 成本 × 维度数③ 基于 next_state 类型的自适应评分当前所有 next_state 用同一套 prompt改进根据 next_state 类型选不同策略if next_state_role “tool”:# tool return → 客观信号不需要 LLM judgescore 1.0 if not is_error(next_state_text) else -1.0 ← Environment reward!elif next_state_role “user”:# 用户回复 → 仍需 LLM judgescore llm_judge(response, next_state)优势tool 场景下有确定性 reward无噪声风险需要可靠的 error 检测逻辑④ 引入参考答案reference-based当前PRM 只看 response next_state改进PRM 还看更好的回答是什么实现先生成一个 “gold response”然后比较score compare(student_response, gold_response, user_query)优势更准确的评估有参照物风险gold response 的质量决定上限计算成本翻倍OpenClaw 已经有 hint 了 → 可能冗余⑤ 过程级评分per-token/per-step当前per-turn 评分整个 response 一个分改进per-sentence 或 per-step 评分实现把 response 分段每段独立评分“这个回答的第1部分正确吗第2部分呢”→ 得到 per-segment reward优势credit assignment 更精确风险对话 response 的步骤边界不清晰评分成本 × 段数Judge 准确性可能对短文本更差⑥ 多 Judge 集成Ensemble当前同一个 PRM 调 m3 次majority vote改进用不同的 judge prompt/模型实现Judge A: 关注准确性 → score_AJudge B: 关注有用性 → score_BJudge C: 关注安全性 → score_Cfinal weighted_average(score_A, score_B, score_C)优势多视角减少单一 judge 的盲点风险3x 计算成本权重如何定与 multi-dimensional rubric 有重叠改进优先级建议改进 难度 收益 风险 推荐度①连续化 低 中 中 ★★★★②多维 rubric (2-3维) 中 中 中 ★★★③tool 自适应 低 高确定性! 低 ★★★★★④ 参考答案 高 中 中 ★★⑤ 参考答案过程级 高高 中高 中高 ★★★★⑥多 Judge 中 中 低 ★★★5.4 验证策略及其防投机逻辑对于四个维度我们也找到了验证策略。5.4.1 策略 1硬验证(Correctness)适合有客观 ground truth 的维度示例代码题测试用例 pass/fail数学题最终答案正确答案SQL查询结果等于预期结果抗投机性强。模型无法通过看起来正确来通过硬验证必须真的得到正确结果残余投机风险 test case hacking模型学到了测试用例的具体模式而非真正的编程能力对固定测试集有效对新测试集失效防御SWE-Universe 的 Hacking Detector检测 grep/浅匹配式通过5.4.2 策略2模型判断(Quality)适合需要语义理解才能评估的维度示例: “这个解释够清晰吗” “这个计划有逻辑吗” “这个回复对用户有帮助吗”由Judge LLM 评估(OpenClaw的LLM Judge 主要干这个)抗投机性中比硬验证弱因为模型可以学到让Judge高兴的文体模式但比单一分数强因为 Judge 可以理解语义残余投机风险Judge hacking(讨好.Judge)模型学到某些 pattern 总能让 Judge 打高分例如过度解释、礼貌套话、某种格式防御多个 rubric降低单一偏好的可攻击面(Kimi K2.5)冻结Judge(不让Judge与Policy 同步进化)Majority vote(3次调用减少单次 Judge 的偏差)5.4.3 策略3对抗测试 OOD Transfer(Robustness)适合前两种方法都可能被投机的维度核心问题模型学到的是规律还是模式场景训练集上的WebAgent 任务100%成功新网站(00D)30%成功 → 硬验证和Judge都没发现问题但模型实际不健壮对抗测试专门设计让模型暴露捷径的输入示例(代码)正常输入add(23)→5对抗输入add(0, 0) → 0边界情况add(-1-2)→-3(负数)add(MAX_INT1)→(溢出)如果模型只记住了常见pattern对抗测试就会暴露OOD Transfer: 在Domain A训练在Domain B测试示例(Agent)训练desktopGUI操作OOD测试mobileGUI/新软件版本如果能力真正泛化→OOD表现仍好如果只是记住了scaffold→OOD表现崩塌抗投机性最强(因为投机的模式在对抗/O0D上会失效)代价需要单独构建对抗集和0OD测试集成本高5.4.4 小结三种验证策略的本质是覆盖好工作的三个侧面硬验证→ 输出的客观侧模型判断→ 过程的主观侧OOD/对抗→泛化到新情境的能力侧0x06 Environment 与 Reward Design 的耦合关系6.1 核心命题Reward函数是Environment可观测信号的函数Reward(t)f(state(t), action(t), state(t1)) 其三个输入都来自Environmentstate(t) 当前状态(由Environment提供的可观测信息)action(t) Agent的动作state(t1)状态转移结果(Environment对action的响应)因此推论如下你只能奖励你能观测到的东西Environment不暴露的信息 无法进入Reward计算Environment的设计直接约束了Reward的设计空间6.2 六个具体耦合点耦合1 可观测性 → Reward信息源OpenClaw中Environment暴露的信息 用户发的消息(文本内容)Environment不暴露的信息 用户满意度、用户身份、用户真实意图因此Judge只能用 “下一条消息是什么” 来推断满意度无法直接观测用户是否真的理解了”或用户是否真的用上了这个答案” 。和其它方案的对比如下游戏环境(ALFworld)→ 暴露 task completion flag → Reward 可以用 success/fail代码环境(SWE-Bench)→ 暴露test case pass/fail → Reward 可以用客观验证对话环境(OpenClaw)→ 只暴露下一条消息 → Reward只能推断用户意图耦合2 环境粒度 → Reward粒度上限我们来看看不同环境粒度对Reward的支持。环境提供episode 级反馈(最粗)→Reward最多是稀疏的outcome reward→长轨迹中credit assignment极难环境提供turn级反馈(OpenClaw)→ Reward可以是turn-level(每轮独立评分)→ 信号密度session中有多少turn就有多少独立评分机会环境提供step级反馈(ALFWorld)→ Reward可以是step-level(每个agent action独立评分)→ 最密集但需要RM对每步做出评价OpenClaw的next_state(turn 结束时用户的下一条消息)正是Environment提供turn 级反馈的关键机制有next_state → 只能做session级评估→信号更稀疏耦合3 环境的终止条件 → 无声成功问题OpenClaw 的 Environment 终止条件用户不再发消息 对话结束 轨迹结束。这里产生一个无声成功Silent Success问题最好的回复往往让用户完全满意 → 用户不需要继续问了 → 对话结束。此时 next_stateNone没有下一条消息Judge 无法获得用户满意的正向证据score 默认为 0中性——最好的表现反而得不到正信号。环境的终止条件直接制造了 reward 信号的系统性偏差短对话完整解决了问题 score 可能为 0长对话用户持续追问 score 有机会得到正信号这个局限的更深入分析见 0x07.3 局限一。耦合4 环境随机性→Reward方差不同类型Environment的随机性数学验证器(确定性)same action→same reward(方差0)代码测试(确定性)same code→same pass/fail(方差0)真实用户(最大随机) same response→不同用户反应完全不同OpenClaw的Environment 真实用户(最大随机性)比如 同一个回复用户A“谢谢解决了”(judge→1)用户B“这没用还有问题”(judge→-1)用户C沉默(judge→0)→ Reward方差极高→majority vote(m3)减少judge噪声但无法减少不同用户对同一回复反应不同”的本质方差耦合5 结构保真度→Reward有效性如果 training environment ≠ deployment environment则在训练env上优化好的行为→ 在真实env上可能失效 Reward的梯度方向是错的OpenClaw的解法(最彻底的结构保真)training environment deployment environment(同一台SGLang服务器同时服务用户 收集训练数据)→ Reward信号来自真实部署场景的真实用户→ Train-deploy mismatch 0(这是OpenClaw最核心的优势)对比ALFWorld→仿真环境与真实家庭机器人有差距WebShop→模拟购物与真实Amazon操作有差距OpenClaw→用户就是真实用户没有仿真差距耦合6 Environment覆盖度→Reward泛化性如果用户群体是均质的(例如都是程序员)Reward信号只覆盖了对程序员有效的回复这一子空间会导致→Policy优化到服务程序员的局部最优→泛化到其他用户类型时效果差OpenClaw的应对没有显式的多样性保证依赖真实用户群体的自然多样性潜在风险如果产品的早期用户是某一类型(技术用户)→训练数据偏向这类用户→模型对其他用户类型的reward信号不够0x07 next_state 奖励0x06 我们看到 Environment 与 Reward 高度耦合。这一章我们聚焦 OpenClaw 最核心的耦合机制——next_state评估它作为真实用户价值代理信号的优劣。奖励信号的真实性光谱如下越向右越真实但获取越难人工合成 RLHF偏好 行为日志 next_state 用户直接评分(数学验证) (人工标注) (点击率等) (OpenClaw) (五星/点赞)| | | | |完全准确 显式偏好 高噪声 隐式行为 最直接但非常窄 但成本高 多义性强 需解读 但极稀疏OpenClaw 的位置用隐式真实行为用户的下一句话替代显式人工标注处于真实行为和LLM 解读的结合处。7.1 next_state 设计的核心优势行为证据 陈述性偏好RLHF 的偏好标注问的是你更喜欢哪个回复但人实际使用中可能更常需要另一种回复——陈述性偏好与行为偏好存在偏差。OpenClaw 的 next_state 用的是用户实际发送的下一条消息 行为证据。这符合经济学中的显示性偏好Revealed Preference“原理行为揭示的真实偏好比我认为哪个更好更接近我实际用哪个更好”。密集且连续无需人工参与RLHF每次训练需要人工标注 → 数周到数月的数据周期OpenClaw每次用户对话立即产生信号 → 分钟级反馈循环在在线学习这个约束下next_state 可能是实际可行的最好信号。7.2 Environment-Reward 的双重角色耦合next_state 是 OpenClaw 最典型的 Environment-Reward 耦合机制。从代码看Judge Prompt 的构造 (openclaw-rl/openclaw_api_server.py):实际函数签名: _build_prm_judge_prompt(response_text, next_state_text, next_state_role)它构造一个结构化 system prompt 内含评分规则不接收 conversation_history 参数。next_state 是 Environment 的输出直接进入 Reward 计算。msgs _build_prm_judge_prompt(response_text, ns_text, ns_role)这个设计的含义Reward f(model_response, next_state)而 next_state 本身又是 Environment 的状态转移输出。因此 Environment 的每一条用户消息同时承担两个角色角色 1新的 State用于 Policy 的下一轮推理角色 2Reward 的评估证据用于 Judge 的评分这是 OpenClaw 设计里最巧妙的耦合用用户如何继续说话作为上一轮回复质量的代理信号——Environment 的状态转移本身就是对上一个 action 的隐式奖励。7.3 next_state 设计的根本局限next_state 虽然是最真实可用的行为信号但它有三个根本局限。其中前两个与 0x06 讨论的耦合点直接相关这里从信号失真的角度再做一个集中梳理。局限一“沉默的成功问题最严重这一点在 0x06 耦合3环境的终止条件中已经指出最好的回复让用户满意离开 → 对话结束 → 没有 next_state → score 默认为 0。这造成一个根本悖论——最理想的服务结果用户满意离开被识别为中性”而频繁追问可能是用户没搞懂被识别为成功对话。这是 next_state 机制最需要修补的系统性偏差。局限二next_state 的多义性这与 0x06 耦合1可观测性相关Judge 只能看到下一条消息是什么却要从中推断用户意图。同一条追问可能意味着完全不同的质量评价可能 A: 没听懂 → 本轮回复质量差 → 应该 score -1可能 B: 很感兴趣想深入 → 本轮回复质量好 → 应该 score 1可能 C: 礼貌地继续对话 → 中性Judge 必须从 next_state 的内容推断属于哪种情况但判断并不总是正确。局限三时间间隔问题用户 10 分钟后才发下一条消息这 10 分钟里可能查了其他资料、睡了一觉、中断了思路……next_state 的内容可能与对上一条回复的反应没有强因果关系从而引入噪声。7.4 比 next_state 更理想的信号但实践中更难信号类型 准确度 密度 在线 RL 可行性用户五星评分 √√√ 最直接 × 极稀疏5-10%用户评分 可行但信号太少长期留存率 √√ 真实价值 × 需要多日聚合 反馈延迟太大任务完成率 √√√ 明确 × 难以自动判断 需要 GTnext_state judge √ 近似 √√√ 高密度 最佳可行方案隐式点击行为 √ 部分真实 √√ 中等 可行但信号弱7.5 小结Environment 不只是提供训练场景它直接约束了什么可以被奖励。OpenClaw 通过 next_state 耦合、train-deploy mismatch 为零、以及依赖真实用户多样性构建了一个 environment-reward 高度一致的系统——代价是无法控制 environment 的随机性和覆盖度。在 online RL 的约束下必须是在线信号、不依赖用户显式标注、信号足够密集、可被程序化处理next_state LLM judge 可能