Production Agent Scenario¶
Agentic RL 中的隐含假设¶
几乎所有 Agentic RL 框架都建立在一个隐含假设上：
训练阶段 ≠ 部署阶段
标准流程：在离线/模拟数据上训练 → 部署固定模型 → 定期重训。
这在研究场景下可行，但在生产环境中遇到根本性障碍：
| 问题 | 表现 |
|---|---|
| 分布偏移 | 训练数据是合成的；真实用户请求分布不同 → 部署后能力退化 |
| 冷启动 | 新部署的模型对特定用户的习惯、工具、工作流一无所知 → 漫长的"预热"期 |
| 长尾任务 | Benchmark 覆盖常见任务；用户的小众需求无法被离线训练覆盖 |
| 环境漂移 | 工具 API 更新、用户行为变化 → 静态模型无法自适应 |
Claw-R1 的核心场景：个人 Agent 自我进化¶
Claw-R1 的首个验证场景是 OpenClaw 个人助手：
设置：
用户在 Mac Mini 上部署 OpenClaw，连接 Slack / 微信 / 邮件。
每天通过消息与 OpenClaw 交互：日程安排、信息检索、代码辅助等。
传统方案：
OpenClaw 使用固定的 GPT-4o / Claude 3.5。
能力不会随使用而增长。
Claw-R1 方案：
1. 用户消息 → OpenClaw → Gateway（拦截 LLM 调用）
2. Gateway 记录每次交互 → DataPool（本地）
3. Reward Model 对每次交互评分
4. 远程服务器上的训练引擎持续消费 DataPool，更新模型权重
5. 更新的权重推送回 Gateway；下次调用使用改进后的模型
结果：
用户 Mac Mini 上的 OpenClaw 会随时间推移越来越了解该用户。
传统 RL 框架无法满足的三个需求¶
① 服务连续性¶
模型权重更新不能中断 Gateway 的请求处理。在 Claw-R1 中：
- Trainer 直接管理 Rollout Engine 和 Reward Model 的生命周期（
wake_up/sleep/ 权重同步） - Gateway 是纯 HTTP 代理 — 只转发请求和提交 step；不管理任何引擎生命周期
- 这保证了即使在权重更新期间，请求转发和数据收集也能持续进行
② 无预设数据¶
传统框架需要预先收集的数据集。Claw-R1 的训练数据完全来自实时用户交互：
- 用户问了什么、Agent 如何回答、调用了哪些工具 — 这些自动成为训练数据
- 零数据工程；数据随服务运行自然积累
③ 真实环境的 Reward 信号¶
传统 RLVR 的 reward 来自可验证的任务结果。生产环境的 reward 更加微妙：
- 用户继续追问 → 隐式正信号
- 用户纠正 Agent → 负反馈
- 任务完成后无后续 → Reward Model 估计中间步骤质量
Claw-R1 使用 Reward Model 将这些软信号转换为可训练的 process reward。
三种运行模式¶
| 模式 | Agent 类型 | 数据来源 | 说明 |
|---|---|---|---|
| 白盒离线 | AgentFlow (Python) | 合成数据集或预收集的 trajectory | 已完整实现；推荐用于研究 |
| 黑盒离线 | 任何 HTTP Agent | 预收集的数据集 | 已完整实现；通过 base_url 接入 |
| 黑盒在线 | 任何 HTTP Agent | 实时用户交互 | 目标生产模式；Gateway 端点已实现 |
部署 = 训练¶
Claw-R1 引入了一种新范式：
┌─────────────────────────────────────────────────────┐
│ 传统：训练 → 部署（固定） │
│ │
│ [合成数据] → [训练] → [固定模型] → 用户 │
└─────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────┐
│ Claw-R1：部署 = 训练（持续） │
│ │
│ 用户 ──► Agent ──► [实时数据] ──► 训练 ──► Agent │
│ ▲___________________________________| │
└─────────────────────────────────────────────────────┘
在这种范式下：
- 每次用户交互都是一个训练样本
- 每次模型更新都改善 Agent 的真实世界表现
- Agent 运行时间越长，对其特定用户和环境的表现越好