OpenForgeRL：在任意环境中端到端训练 Harness 原生 Agent

  • 关联论文：2607.21557
  • 作者：flyP
  • 更新：2026-07-25

一句话结论

OpenForgeRL 给出了一个把"推理侧 harness"和"训练侧 RL 栈"解耦的开源框架——用一个轻量代理（proxy）把 harness 内部的模型调用重新服务化为一次普通的推理请求，同时在 Kubernetes 上为每次 rollout 拉起独立容器，让任意 harness（Claude Code / Codex / OpenClaw 等）和任意环境都能直接接入标准 RL 训练流水线（以 veRL 为代表）做端到端 RL。

它在解决什么真问题

2025–2026 年的 SOTA Agent 已经不再是一个孤立的 LLM，而是被包在一个多进程、有状态、带工具与外部 I/O 的 harness里：Claude Code、Codex、OpenClaw 这类推理时框架要驱动多轮对话、shell / 文件 / 浏览器调用、记忆与上下文管理，本身就是个分布式系统。

问题在于：当下流行的开源 RL 训练栈（veRL、OpenRLHF、TRL 等）是为"单次推理调用 + token 级 logprob"设计的，它们假设被训练的对象是一个无状态、确定接口的模型，因此无法原生表达： - 多轮对话中的状态延续（同一会话的 history 与工具缓存要保持）； - 工具/文件系统/浏览器的 side effect； - 进程隔离、远程执行、不同 harness 之间的差异。

直接改造 RL 栈去支持每一种 harness 是不现实的（每家 harness 的 IPC、state schema、tool 协议都不同），而把训练强行塞进 harness 内部又会让采样和优化耦合、丧失分布式 rollout 的弹性。

OpenForgeRL 的切入点是：不动训练栈，也不重写 harness——只在两者之间插一个透明代理，记录 harness 内部向 LLM 发起的每一次请求，让它从训练侧看起来就像"另一个普通推理服务"。

核心方法

整体架构可以抽象成三件事：

  1. Harness-side LLM-call Proxy（透明代理） - 把 harness 默认指向的 OpenAI/Anthropic 兼容 endpoint，重定向到本地/集群内的 proxy。 - proxy 对 harness 的接口契约完全不变（同样是 messages / tools 流式响应），但内部把请求+响应落盘到可重放格式（对话、tool call、reward 信号）。 - 对训练栈来说，proxy 暴露的就是"另一个 vLLM / sglang 兼容服务"，因此标准 RL 代码无需修改。

  2. Kubernetes 编排的 per-rollout 沙箱 - 每次 rollout = 一个独立 container，装着目标 harness + 目标环境（GUI 浏览器、OS、code repo、web 等）。 - proxy 收到这个 rollout 的请求后，通过 K8s job/queue 把请求分发到对应 container 内的 harness 进程。 - 这种"训练在中央、推理在远程多 pod"的模式解耦了 rollout 弹性与训练吞吐。

  3. 轨迹重放 + RL 损失 - 同一个 proxy 在 rollout 阶段记录 LLM 调用流，训练阶段直接消费这份离线轨迹，把 harness 视为"env"的一部分，把每一步 action 当作 RL 的 token 级策略分布来更新。 - 因为 proxy 接口稳定，论文里复用 veRL 的 PPO / GRPO 流程，无需重写 trainer。

伪代码层面可以这么看：

# rollout 阶段（harness 视角，无感）
response = openai.chat.completions.create(
    model="any", messages=msgs, tools=tools
)  # 实际指向 proxy

# proxy 内部
def handle(req):
    rollout_id = req.headers["x-rollout-id"]
    pod = k8s.schedule(rollout_id)        # 远程 harness container
    out = pod.harness.invoke(req.body)    # 让真 harness 跑
    recorder.write(rollout_id, req, out)  # 写训练轨迹
    return out

# 训练阶段（标准 veRL）
for batch in dataloader:
    loss = verl_ppo_step(batch, logprob_from_proxy)
    optimizer.step()

关键 trick 是接口保形：训练栈只看到标准 OpenAI 协议，所以所有 off-policy / importance-sampling / logprob 重算技术都直接可用。

关键实验与数据

论文在三类 harness / 环境上做了验证（具体子模型名见原文）：

  • 工具/claw Agent：OpenForgeClaw
  • ClawEval：pass^3 = 31.7，pass@3 = 55.9
  • QwenClawBench：33.7
  • 多模 GUI Agent：OpenForgeGUI
  • OSWorld-Verified：37.7
  • Online-Mind2Web：63.0
  • WebVoyager：72.3

对比口径： - 与同规模开源基线相比，几乎所有 benchmark 上都胜出； - 在 GUI 场景下，OpenForgeGUI 能匹配或超过参数量数倍于它的模型——这是端到端 RL 在真实部署 harness 中带来的能力增量。

论文还做了一组 ablation / 分析（harness × RL 行为的二维分析）： - 不同 harness 难度差异巨大：ZeroClaw / OpenClaw / Codex 作为同一策略的训练环境时，可学性显著不同； - RL 主要改进的是"可靠性类"行为：自我验证（self-verification）、工具覆盖率（tool coverage）、多步计划完成率； - 关键能力仍然薄弱：错误恢复（error recovery）这一类"失败后如何回滚/重试"的能力，即便经过 RL 仍没有显著提升——这是当前 Agent RL 的一个明显短板。

论文目前为 v1（2026-07-23 上传，3.5MB），上述数字来自其公开 abstract 与卡片 TLDR，完整训练曲线、reward 曲线、消融表格以论文正文为准（原文未明确公开的所有 baseline 名称、参数量、训练 token 数等，标注「原文未明确」）。

亮点与局限

亮点 - 解耦即通用：让"任意 harness × 任意 env × 任意 RL 栈"成为可组合三元组，而不是 N×M 的定制集成； - 轨迹可重放：proxy 把 harness 调用流落盘，意味着可以做 off-policy RL、rejection sampling、行为克隆、偏好学习——一种 infra 多用途； - per-rollout 容器隔离：天然支持长尾、慢速 GUI 任务与高吞吐代码任务的混合调度； - 复用 veRL 等成熟栈：避免发明新 trainer 带来的二次工程债。

局限 - 错误恢复没真正解决：RL 提升了"会不会做"，但没显著提升"做错了怎么救"——这是当前 SOTA Agent 的共性问题； - proxy 延迟与吞吐损耗：所有请求多了一跳，GUI/工具类场景对延迟敏感，需要在 proxy 内做批处理与流水线； - 依赖 harness 自身可观测性：如果某个 harness 的内部状态不对外暴露（例如闭源 CLI 的内部 prompt），proxy 拿不到真实可监督信号； - v1 实证规模有限：几百到几千个 task 的训练量，相对 LLM pretraining 仍很小；是否会在更大规模下出现 reward hacking 仍需观察； - harness 间可学性差异：意味着换 harness 不是"换接口"那么简单，研究者需要重新做 RL 适配，框架的"通用性"在训练成本上是打折的。

对工程落地的启发

  1. "训练/推理解耦"是新 Agent infra 的关键模式：当 agent 形态越来越复杂，把 RL 训练和 inference runtime 用一个协议层隔开，几乎是必由之路。OpenForgeRL 把这件事用一个极薄 proxy 落地，比改造 trainer 或改造 harness 都便宜。
  2. 轨迹日志就是金矿：一份带 tool call / reward 的轨迹，可以同时跑 SFT、RLHF、rejection sampling、DPO、process reward 等多种训练，团队应该把这一层日志当作一等公民来设计。
  3. per-rollout 沙箱成为标配：GUI / browser / long-horizon 任务的尾延迟不可控，K8s 风格的 per-rollout pod 比"共享 GPU + Python multiprocessing"健壮得多；做内部 Agent 平台可以直接抄这套。
  4. harness 选择影响 RL 收敛：论文实证"同一策略在不同 harness 上学习难度不同"——意味着生产环境选 harness 时，要把它当"训练环境"而不是单纯"部署容器"来评估。
  5. 错误恢复仍是 Agent RL 的开放问题：投资在工具调用回滚、计划重写、用户确认机制上的工程价值，远大于再叠一层 RL 奖励。

与同方向工作的关系

  • 相对于直接改 veRL / OpenRLHF 去支持多轮工具调用（路线 A），OpenForgeRL 走的是"不改 trainer、改中间件"（路线 B），更接近 DSPy / LangSmith / LangChain Hub 在 trace replay 上的思路，但目标是 RL 而非调试；
  • 相对于 Open-Computer / AgentBench / OSWorld 这类"把环境标准化"的努力（路线 C），OpenForgeRL 反向走"接受环境多样性"，把复杂度推到 proxy 层；
  • 与 Skywork-OR1 / DeepSeek-R1 / Open-Reasoner 等开放 RL recipe 在 Agent 场景的扩展有方法论呼应：把 RL 从"单次推理奖励"扩展到"长程轨迹奖励"；
  • "harness-native"这个提法与 Hugging Face smolagents / ReAct / Open-Interpreter 等"agent shell"工作形成对照：后者关心 runtime，前者关心 trainability。

适合谁读

  • 做 Agent 平台的工程师：想理解未来 SOTA agent 训练/部署之间的中间件会演化成什么样；
  • RL for LLM 的研究者：尤其是想把 GRPO / PPO 推到长程 GUI / tool-use 场景的人；
  • Agent 评测 / harness 开发者：关心自己 harness 的可训练性、轨迹可观测性、是否会被新 RL 栈"白嫖";
  • 基础设施 / MLOps 团队：关心 K8s 上大规模 LLM rollout 的调度、可重放日志、跨环境复现。

一句话收尾：OpenForgeRL 的真正贡献不是某一个 SOTA 数字，而是把"harness 内 LLM 调用 → 可训练轨迹"这条管道标准化了——这是一旦被生态接受就很难再绕开的基础设施型工作。

工程落地与核查（Jay）

事实核查

  1. Benchmark 数字（存疑）：ClawEval pass@3 31.7 / pass@3 55.9 / OSWorld 37.7 / WebVoyager 72.3 等数字来源于 abstract / TLDR，原文正文（2026-07-23 v1，3.5MB）是否已完整公开尚未确认。解读原文已用加框注说明，引用时应保持"数字待正文核验"口径。
  2. 对比基线（未核实）：原文声称"匹配或超过参数量数倍于它的模型"，但未指名具体对比模型（参数量、架构、训练集均未知），此说法目前属于作者定性描述，不可作为工程承诺引用。
  3. "几百到几千个 task"训练规模：原文以"数百到数千"描述，但未给出具体量级（e.g. 500 / 2000 / 5000），引用时应写"原文以数百至数千笼统描述，无精确数字"。
  4. K8s per-rollout 延迟（需实测）：每次 rollout 请求均触发一次 K8s pod schedule + container 启动，在 GUI 场景（OSWorld 等）冷启动时间可能达 30s–2min，proxy 端到端延迟不只是网络一跳。

实际部署注意事项

  1. proxy 层是真实瓶颈：每个 LLM 调用都走 proxy（rollout 记录 + 训练推理），在高频多轮场景下 proxy 的吞吐 = 全局吞吐上限。需要：连接池（connection pooling）、请求 batching（将同 rollout 的多轮请求合并投递）、异步写盘（非阻塞轨迹持久化）。
  2. K8s 资源规划：per-rollout pod 意味着每次 rollout 需要一个额外容器实例，并发 rollout 数 = 并发 pod 数。假设 100 并发 rollout、每 pod 1 CPU + 2GB memory，光 harness 容器层就是 100 CPU / 200GB memory 开销，不包含宿主 GPU 节点。
  3. 轨迹存储规模：一趟完整 tool-use agent rollout（100 步 × 2K tokens/调用）≈ 200K tokens ≈ ~800KB（原始 JSON），加上 reward 信号和 metadata，每千条 rollout 轨迹 ≈ 800MB–2GB。生产环境需要独立的轨迹存储（Redis 暂存 + 对象存储持久化）。
  4. off-policy 分布偏移风险：轨迹记录时用某版本模型生成，训练时可能换了新版本模型。proxy 接口虽稳定（OpenAI 兼容），但训练侧 logprob 分布偏移会导致 PPO/GRPO 策略梯度有偏。实际工程中需要在重放 buffer 入口做重要性采样（importance sampling）加权，或限制轨迹回放窗口。
  5. reward 信号采集盲区：proxy 记录的是"harness 认为的 reward"，但 harness 自身是个有内部状态的黑盒。如果 harness 报错（如 tool call 超时、文件系统权限错误），proxy 可能拿到的是"异常退出"而非真实 reward，导致负样本噪声。需要在 proxy 层对异常响应打标签，供训练侧做 reward clipping。
  6. 闭源 harness 不可用：Claude Code CLI、Codex 等闭源 harness 的内部 prompt / tool schema 不对外暴露，proxy 只能记录 I/O，无法为这些 harness 构造可训练的 reward 信号——这类场景论文明确列为局限。
  7. 复现最小命令（原文未提供完整复现脚本，以下为基于架构推导的最小可行路径）： ```bash # 1. proxy 部署（假设 veRL + vLLM backend） pip install openforgerl # 原文开源仓库，待确认 openforgerl-proxy serve --port 8080 --backend vllm:8000

# 2. harness container 模板（K8s Job） kubectl apply -f - <<'EOF' apiVersion: batch/v1 kind: Job metadata: name: rollout-{rollout_id} spec: template: spec: containers: - name: harness image: openforgerl/harness:{target} env: - name: OPENAI_BASE_URL value: "http://proxy:8080/v1" restartPolicy: Never EOF

# 3. 训练（veRL GRPO） python -m verl.train.main algorithm=grpo ... ``` 注：以上为架构级伪命令，原文是否提供端到端复现脚本待核实。

术语统一修正

  • "pass^3" 应为 pass@3（标准 notation 为 pass@k，pass^3 为原文typo，解读中已正确写为 pass@3）。

评分理由

Benchmark 数字可信度因仅来自 abstract 而降一档；架构设计扎实、工程思路完整；错误恢复未解决这一判断有原文依据；整体给 4 分。