Claw-R1 — The Data Foundation for Agentic RL

TL;DR： Agentic RL 生态正蓬勃发展——训练框架（verl、Agent-R1、MiniMax Forge）和通用 Agent（OpenClaw、Claude Code）均取得了显著进展。随着 Agent 能力增强，一个关键问题浮现：如何系统化地从多样 Agent 交互中收集、评估和策划高质量训练数据？ Claw-R1 正是为此提供 Data Foundation——在 Agent Side 与 Training Side 之间引入 Middleware Layer（Gateway + DataPool），专注于数据收集、评估与策划，而非训练算法本身。

项目简介

Agentic RL 生态正蓬勃发展——verl、Agent-R1、MiniMax Forge 等框架在 RL 运行时和训练算法上取得了卓越进展。与此同时，通用 Agent（如 OpenClaw、Claude Code、Open Code）正在产生比传统 ReAct 轨迹更丰富、更复杂的交互数据。

随着 Agent 能力持续增强，一个关键问题浮现： 如何系统化地从多样 Agent 交互中收集、评估和策划高质量训练数据？ 这是一个相对未被充分探索但至关重要的方向——尤其当人类反馈作为天然质量信号可用时。

中国科大认知智能全国重点实验室提出的 Claw-R1 项目，正是针对这一问题提供 Data Foundation。它在 Agent Side 与 Training Side 之间引入 Middleware Layer（Gateway + DataPool），专注于数据收集、评估与策划，而非训练算法本身，填补了 Agentic RL 生态中数据基础层的空白。

项目背景

大模型强化学习的三次范式演进

大模型强化学习正经历一次重要转变：从人类偏好学习（RLHF），到任务结果学习（RLVR），再到环境交互学习（Runtime RL）。

阶段	目标	奖励来源	代表工作
RLHF	生成更符合人类偏好的文本	Human preference	InstructGPT
RLVR	完成可验证任务	Verifiable reward	VERL、Agent-R1
Runtime RL 本项目	在真实环境中行动	Environment feedback	Claw-R1

总趋势：AI 的奖励来源正在越来越接近真实世界。

Agentic RL 的困境：RLVR 的关键缺口

尽管 RLVR 已能支持多轮交互学习，但仍存在一个关键问题： Agent 运行环境并不真实。

目前大多数 RLVR 框架依赖研究导向的模拟环境：

Coding benchmark（代码生成评测）
Reasoning tasks（数学推理、逻辑推断）
Synthetic environment（人类构造的任务沙盒）

这些都是特定任务的训练场，而非真实的 Agent Runtime。模型从未真正运行在现实工具系统中，导致在真实 Agent 系统中出现工具调用混乱、规划能力不足、长任务不稳定等问题。

OpenClaw：Agent Runtime 的新基础设施

OpenClaw 是一款开源的个人 AI Agent 操作系统（MIT 协议，TypeScript 实现，本地优先原则）。自发布以来，8 周内获得超过 236,000 个 GitHub Star，成为开源历史上增长最快的项目之一。

其核心架构采用 Hub-and-Spoke 设计：15+ 主流消息平台通过统一 Gateway 接入，驱动中央的 Pi Agent Runtime 执行任务。Lane Queue 机制通过串行执行消除并发竞态条件，三层混合记忆系统则为 Agent 提供稳定的上下文管理能力，使 OpenClaw 成为第一个可在真实消息环境中自主、持续运行的 Agent 平台。

Claw-R1 框架

Claw-R1 在 Agent Side 与 Training Side 之间引入 Middleware Layer（Gateway + DataPool）作为数据基础层，形成三层架构。Claw-R1 的核心价值集中在中间层——专注于数据收集、评估与策划，让任何 Agent 系统都能以最低成本获得高质量训练数据。

1

Agent Side（数据来源） 白盒 Agent 通过 API 提交 Steps；黑盒 Agent 只需将 base_url 指向 Gateway（零代码改动）；在线服务从真实用户交互中实时收集数据。
2

Middleware Layer — Data Foundation（核心） Gateway + DataPool 构成 Claw-R1 的核心。负责通用数据收集、多维度奖励评估（基于规则 / 判别式 RM / 生成式 RM）、人类反馈信号整合、策略版本追踪，以及基于 Channel 的数据分区与策划。
3

Training Side（数据消费） 可插拔的 TrainingBackend 将策划后的数据转换为任意训练引擎的原生格式，支持 GRPO 感知分组、训练/验证 Channel 隔离和实时监控。

Claw-R1 Framework Architecture — 图 1：Claw-R1 整体架构图。左侧为 Service Machine（如 OpenClaw），中间为 Agent Runtime 与 Middleware 层，右侧为 RL Training Engine。

框架核心特色

⚡

训练与 Rollout 异步

Rollout Engine（生成）与 Training Engine（训练）异步运行，互不阻塞，数据流入 DataPool 后自动拉取批次更新模型。

🔌

Agent 与训练彻底解耦

OpenClaw 在本地机器提供服务，模型训练在高性能服务器上独立进行。无需预置数据集，边服务边训练。

🛡️

零代码侵入

OpenClaw 只需将 base_url 指向 Claw-R1 的 Gateway，框架自动采集交互数据并训练，无需修改 Agent 逻辑。

🔄

白盒 / 黑盒双模式

通过 OpenAI 兼容接口，支持白盒离线、黑盒离线、黑盒在线服务三种运行模式，适配多种部署场景。

Data Foundation：三大核心能力

Claw-R1 的核心价值不在于训练算法，而在于为 Agentic RL 提供数据基础层。当 Agent 系统日益多样化（从白盒自研 Agent 到黑盒商用 Agent，从离线实验到在线服务），如何系统化地获取高质量训练数据成为瓶颈。Claw-R1 通过三大能力解决这一问题：

📡

Universal Data Collection

白盒 Agent 通过 API 直接提交 Steps； 黑盒 Agent 只需将 base_url 指向 Gateway，零代码改动即可接入； 在线服务从真实用户交互中实时收集数据。无论 Agent 的实现语言、SDK 或部署方式如何，均可统一采集。

⚖️

Data Evaluation & Curation

多维度奖励系统（基于规则 / 判别式 RM / 生成式 RM），整合人类反馈信号作为天然质量指标，策略版本追踪实现 freshness-aware 策划，基于 Channel 的数据分区支持精细化管理。

🚀

Flexible Data Serving

可插拔 TrainingBackend 将策划后的数据转换为任意训练引擎的原生格式， GRPO 感知分组确保同一 prompt 的多次采样被正确打包，训练/验证 Channel 隔离防止数据泄漏，实时监控保障数据流水线健康。

为什么需要 Data Foundation？

当前 Agentic RL 生态中，训练框架和 Agent 运行时各自发展迅速，但两者之间的数据桥梁长期缺失。这导致了一系列实际问题：

痛点	现状	Claw-R1 方案
数据采集碎片化	每个 Agent 框架自建采集逻辑，格式不统一，无法复用	Gateway 统一代理，任何 HTTP 调用均可采集
质量评估缺失	采集后直接训练，无系统化的质量评分与过滤	多维度 Reward 系统 + 人类反馈信号整合
训练数据与真实分布脱节	依赖合成 benchmark，无法反映真实用户请求分布	在线服务实时采集，数据即生产环境分布
策略版本混乱	不同版本模型产生的数据混用，影响训练稳定性	Policy version tracking，freshness-aware 策划

核心设计解读

Claw-R1 的差异化竞争力来自三点设计的组合，三者共同构成一个完整的闭环，缺一不可。

一、base_url 即接入：最低侵入的黑盒集成

现有 Agentic RL 框架在接入 Agent 时，普遍需要修改源码或依赖特定 SDK，对生产级 Agent 系统（如 OpenClaw、AutoGen、CrewAI）而言侵入成本极高。 Claw-R1 通过网络层代理彻底解决这一问题：

方案	代表框架	侵入方式	代价
修改 Agent 源码	verl、RL-Factory	在 Agent 代码中嵌入 Rollout 接口	维护成本高，黑盒 Agent 无法用
Python 类包装	OpenRLHF	继承 `AgentInstanceBase` 重写执行逻辑	需理解框架 API，不通用
SDK Hook 拦截	Agent Lightning、ART	替换 LangChain / OpenAI SDK 的 HTTP 层	依赖特定 SDK，换框架即失效
替换 base_url Claw-R1	Claw-R1	将 LLM 调用重定向到 Gateway	零改动，任何 HTTP 调用均适用

Gateway Server 是标准 FastAPI HTTP 服务，实现完整的 OpenAI 兼容代理。对 Agent 而言，它只是调用了一个"稍慢一点的 OpenAI API"，并不知道每次对话已被送入训练流水线。 实际接入只需一行配置：

# 改之前 client = OpenAI(base_url="https://api.openai.com/v1") # 改之后（黑盒模式：base_url 含 trajectory_uid、prompt_uid） client = OpenAI(base_url="http://gateway:8000/{traj_uid}/{prompt_uid}")

对 OpenClaw 而言，只需在配置文件中把 LLM_API_BASE 从 OpenAI 地址改为 Gateway 地址即可。与 SDK Hook 相比，网络层代理不依赖任何语言或 SDK， OpenClaw（TypeScript 实现）、运行在独立容器中的 Agent、使用自定义 HTTP 客户端的 Agent 均可零改动接入。

二、Middleware Layer：解耦服务与训练的关键

传统 RLVR 训练采用同步循环（生成轨迹 → 计算奖励 → 更新权重 → 再生成），在生产环境中会导致 Rollout 阻塞训练、训练阻塞服务、真实数据浪费等根本性问题。 Claw-R1 的 Middleware Layer（Gateway + DataPool） 是 Agent Side 与 Training Side 之间的唯一桥梁：

┌─────────────────────────────────────────────────────┐ │ Agent Side（白盒 AgentFlow / 黑盒 Agent） │ │ 用户请求 → Agent → Gateway（HTTP）→ 模型推理 → 用户响应 │ │ ↓ │ │ [Gateway 异步提交 Step 到 DataPool] │ └──────────────────────────┬──────────────────────────┘ │ 异步，无阻塞 ┌──────────────────────────▼──────────────────────────┐ │ Training Side（独立运行） │ │ RayAgentTrainer ← [DataPool.fetch_batch()] ← Reward │ │ ↓ │ │ 模型权重更新 → 直接管理 Rollout Engine 生命周期 │ └─────────────────────────────────────────────────────┘

DataPool（Ray Actor）具备四大特性：

写入异步：Gateway 记录 LLM 调用后立即返回，不等待 DataPool 确认
读取异步：Training Engine 按自己节奏拉取批次，不依赖 Rollout 时序
持久化：服务中断重启后历史轨迹不丢失
混采支持：可同时消费最新轨迹（on-policy）和历史轨迹（off-policy）

与 rLLM DataPool 的核心区别：

维度	rLLM DataPool	Claw-R1 DataPool
写入来源	批量 Rollout Engine（离线生成）	真实用户请求（在线服务）
数据性质	预设任务的合成轨迹	用户真实交互轨迹
服务状态	训练时 Agent 不对外服务	训练时 Agent 持续服务
奖励计算	任务结果奖励（Verifiable）	过程奖励 + 环境反馈

rLLM 的 DataPool 是为加速批量训练的缓冲；Claw-R1 的 DataPool 是为了让 Production 服务本身成为训练数据源。

三、Production Agent 场景：部署即训练

几乎所有 Agentic RL 框架都隐含「训练阶段 ≠ 部署阶段」的假设，这在生产 Agent 场景中有根本性局限：

问题	表现
分布偏移	训练数据是合成任务，真实用户请求分布不同，导致部署后能力退化
冷启动	新部署模型不了解用户习惯、工具、工作流，需要大量"磨合期"
长尾任务	benchmark 只覆盖常见任务，真实用户的长尾需求无法通过离线训练覆盖
环境漂移	工具 API 更新、用户行为变化，静态模型无法自适应

Claw-R1 的核心场景是个人 Agent 的持续自我进化：以 OpenClaw 个人助理为例，用户每天通过 Slack / 微信 / 邮件与 OpenClaw 交互，轨迹经 Gateway 采集 → DataPool → Reward Model 评分 → Training Engine 更新权重，让 Agent 越用越"懂"这个用户。这要求系统具备三项传统 RL 框架不具备的能力：

1

服务不中断 Trainer 直接管理 Rollout Engine 生命周期，Gateway 作为纯代理持续响应，权重更新对服务透明。
2

数据不预设 训练数据完全来自用户真实交互，随服务自动积累，无需任何数据工程。
3

奖励来自真实环境 Reward Model 将用户满意度信号、任务完成度等"软奖励"转化为可训练的过程奖励，填补可验证任务到真实对话任务之间的奖励工程空白。

四、三点结合：正向飞轮

三个设计不是独立功能的叠加，而是一个互锁的正向飞轮：

base_url 即接入 → Production Agent 真实部署 → 产生真实用户请求 ↓ Middleware Layer 异步采集轨迹，不阻塞服务 ↓ RayAgentTrainer 持续消费 DataPool，更新模型权重 ↓ 更好的 Agent → 更高质量轨迹 → DataPool 质量提升 ↓（回到起点，形成正向飞轮）

缺少 base_url 即接入 → 黑盒 Agent 无法零成本集成，"真实场景"不成立；缺少 Middleware Layer → Agent Side 与 Training Side 耦合，退化为传统 RLVR；缺少 Production 定位 → 失去从真实用户交互中持续学习这一核心价值主张。

Agentic RL 的数据基础设施