LEGO-RL：面向 Coding Agent 的 Harness 原生强化学习框架

关联论文：2608.17393
作者：Tom
更新：2026-08-26

一句话结论

LEGO-RL 提出了在不修改 Harness 内部控制流的前提下，将原生 coding agent harness 与可扩展策略梯度优化相连接的方案，通过 in-process LLM proxying + 沙箱编排 + 可观测训练三大支柱，在 Qwen3.5-35B-A3B 上将 SWE-bench Verified 成绩从 57.2~64.0% 提升至 66.6~70.4%，同时保持 rollout-training 概率相关性高于 0.99。

解决什么真问题

RL 用于 coding agents 面临根本性环境错位：agent harness 原本为执行设计（管理工具集成、仓库上下文、执行反馈），而策略梯度优化需要稳定的训练信号和一致的 rollout 行为。具体表现为：

环境崩溃与 reward hacking 破坏训练信号：代码执行失败、测试框架异常等导致 reward 不准确
Train-Inference 偏差：Harness 侧对 LLM 输出的压缩/重序列化导致 token 级别的策略更新与实际 rollout 行为脱节
rollout 稀缺：长程 coding 任务中每个轨迹成本极高，导致 on-policy 样本不足

现有方案要么深度修改 harness 内部（破坏通用性），要么用行为克隆等样本效率低的方法。

核心方法

LEGO-RL 的核心设计是 "Harness-native"：不碰 harness 内部控制流的前提下，通过外层接口实现 RL 优化。

三大技术支柱：

Pillar 1：Faithful Optimization（忠实优化）

In-process LLM Proxying：在 harness 进程内嵌入 LLM proxy，劫持原始生成流（raw generation stream），实现： - Token 级对齐：捕获完整 token 序列用于精确的 token-level policy gradient 计算 - Trainer 侧 log-probability 重计算：即使 harness 侧做了 compaction 或 re-serialization，trainer 侧仍可基于原始流重算 log-prob，保证策略更新的数学一致性

关键机制：

Harness 进程内
    ↓ (LLM 输出原始流)
In-process Proxy
    ├──→ 传给 Trainer（log-prob 重计算）
    └──→ 传给 Harness（继续执行）

即使 harness 对输出做了截断/重格式化，proxy 侧保存原始序列，训练信号不丢失。

Pillar 2：Reliable Execution（可靠执行）

Scalable Sandbox Orchestration： - Image Caching：复用执行环境镜像，减少每次 rollouts 的环境启动开销 - Stage-wise Defenses：分阶段防御 reward hacking（如检测反复尝试同一失败路径的策略异常行为）

Pillar 3：Observable Training（可观测训练）

Automated Validation Plugin：自动验证每次更新的有效性，减少人工介入
Live UI：实时可视化 trajectory 诊断，帮助理解策略演化过程

GSPO（Gradient-Signal Policy Optimization）：使用何种策略梯度算法？原文未明确具体算法名称，但从实验上下文看使用的是 on-policy 策略梯度变体。

关键数值

伪代码核心逻辑：

For each harness:
    proxy = InProcessLLMProxy()
    sandbox = SandboxOrchestrator()

    for training_step in range(N):
        # Faithful capture
        raw_stream = proxy.capture(harness.run(task))

        # Trainer-side recomputation
        log_probs = trainer.recompute_log_probs(raw_stream)

        # Sandbox execution with defenses
        trajectory = sandbox.execute(raw_stream, defenses=stagewise_defs)
        reward = evaluator.score(trajectory)

        # Policy update
        policy.update(log_probs, reward)

        # Observable monitoring
        monitor.log(training_step, policy, reward)

关键实验与数据

训练对象：稀疏 MoE 模型 Qwen3.5-35B-A3B

评估基准：SWE-bench Verified（真实 GitHub issue 修复任务）

Harness	基线	LEGO-RL 后	提升
OpenHands SDK	64.0%	70.4%	+6.4pp
Claude Code	62.4%	68.2%	+5.8pp
OpenCode	57.2%	66.6%	+9.4pp

关键指标：rollout-training probability correlation > 0.99（说明 in-process proxying 有效解决了 train-inference 偏差）

GSPO 的核心效果：在三个 harness 上均有效，且跨 harness 迁移时性能保持，说明 LEGO-RL 不依赖特定 harness 实现。

亮点与局限

亮点： - Harness-native 思路优雅：不改 harness 内部控制流，任何符合 harness 接口标准的系统均可接入——高度通用 - Token 级忠实捕获解决了 RL for agents 领域长期存在的 train-inference 偏差问题 - Rollout-training correlation > 0.99 是极其有说服力的数字：说明训练信号与实际行为高度一致 - 跨 3 个不同 harness 均有效，证明了框架的泛化性

局限： - 沙箱安全防御（stage-wise defenses）细节未公开，具体实现机制不明 - Image caching 对多租户场景的安全边界未讨论 - GSPO 算法细节未披露（是 PPO/TRPO 变体还是自研？） - 原文未报告训练步数、GPU 小时数等工程成本 - 当前仅在 coding agents 场景验证，泛化到其他 agent 类型待研究

对工程落地的启发

Coding agent RL 优化不必改 harness：LEGO-RL 证明了外层接入的可能性，工程团队可以在不破坏现有 harness 生态的情况下引入 RL 优化。
In-process proxying 是关键：对于需要精确 token-level 训练信号的场景，proxy 的部署位置比算法本身更重要。
沙箱编排是 scaling 瓶颈：image caching + stage-wise defenses 是实现大规模 RL rollouts 的工程基础。
Rollout-training correlation 是核心监控指标：低于 0.99 即说明训练信号与实际执行存在偏差，需要排查 harness 侧重序列化问题。
多 harness 联合训练的潜力：三个 harness 各自独立训练但均受益，未来可能探索跨 harness 的联合优化。

与同方向工作的关系

与 SWE-bench 系列的关系：SWE-bench Verified 是 coding agent RL 的标准评估床，LEGO-RL 在其上验证了 RL 优化路径的可行性
与 Agent Lightning（2608.17528）：两者同年（2026年8月），但 Agent Lightning 关注 harnessed agentic RL 框架设计，LEGO-RL 聚焦 RL 训练与 harness 执行环境的对齐问题，互补而非重叠
与 STARK（2025年）：同样是 RL for agents 工作，但 STARK 聚焦于推理时 scaling，LEGO-RL 解决的是训练时的环境错位
与 OpenHands / Claude Code 的关系：这两个 harness 是本次实验的评估对象，LEGO-RL 的价值在于证明了在不修改其源代码的前提下仍可有效 RL 优化它们

适合谁读

RL 算法工程师：想将 RL 应用于 coding agents 但不想维护自定义 harness 的团队
Agent 系统工程师：关注如何在现有 harness 生态中引入 RL 而不破坏兼容性
ML Platform 工程师：需要 scalable sandbox orchestration 的工程实现参考
LLM 研究者：关注 token-level alignment 与 train-inference 一致性问题

工程落地与核查（Jay）

实际系统怎么用

LEGO-RL 的工程落地分为接入层和训练层两层：

接入层（Harness-native proxy）

现有 Agent Harness（如 OpenHands SDK / Claude Code / OpenCode）
    ↓ LLM 生成流
In-process LLM Proxy（拦截原始流）
    ├──→ Trainer（log-prob 重计算 + 策略更新）
    └──→ Harness 侧（继续正常执行）

Proxy 以 sidecar 或内嵌方式部署，不需要 fork 或修改 harness 源码。

训练层（Sandbox Orchestration + Observable Training） - Image caching：每次 rollout 使用预构建 Docker 镜像，减少环境启动延迟（适合 SWE-bench 类 GitHub 仓库任务） - Stage-wise defenses：reward 被分段验证，防止"通过反复提交同一错误代码刷 reward"的 shortcut 学习 - Automated validation plugin：每次策略更新后运行 mini test suite，快速判断更新是否有效

⚠️ GSPO 算法未披露（是 PPO/TRPO 变体还是自研未知），工程落地前需 fetch 原论文确认。

坑位清单

坑	描述	应对
坑 1：GSPO 算法黑盒	原文未披露 GSPO 是 PPO/TRPO 变体还是自研闭源算法	建议先用标准 PPO + GRPO 作为 baseline 验证框架，收到原文后替换 GSPO 模块
坑 2：沙箱防御细节缺	stage-wise defenses 只说"检测反复失败路径"未给具体实现	需要自行设计 reward hacking 检测逻辑（建议从 reward variance > 2σ 入手）
坑 3：Image caching 多租户安全	镜像复用对多租户场景可能有安全边界问题	用 rootless container + namespace 隔离；或每个租户独立镜像 tag
坑 4：训练成本未披露	原文未报告 N 步、GPU 小时数、Qwen3.5-35B-A3B 训练集群规模	建议在小规模（单卡 A100 × 1 天）做可行性验证后再 scaling
坑 5：Sandbox 编排扩展性	大规模 RL 需要同时跑多个 sandbox 并行 rollout，原文未讨论编排层	需要配合 Ray 或 Kubernetes Job + dynamic provisioning
坑 6：SWE-bench 泄露风险	如果训练集包含 SWE-bench 验证集题目，会导致评估虚高	必须做 train/eval split，训练时排除 SWE-bench Verified 中标记为 verified 的任务

核查结论

GSPO 算法：⚠️ 原文未披露具体名称，需 fetch 原论文 §Algorithm 节
沙箱防御实现：原文仅一句话描述，无公开实现
训练成本：GPU 小时数、训练步数等均未披露，无法做算力预算
GitHub 开源代码：⚠️ 需 fetch 确认是否已开源（henryqin1997/lego-rl 需验证）
Image caching 安全：多租户场景未讨论，需自行加固
rollout-training correlation > 0.99：此数字由原文自报，建议在本地环境复现验证