给真 harness 做 RL：先钉死 harness，再谈配方
先问一个问题：给 Claude Code 这样的编码 agent 做 RL 训练，一条训练样本长什么样？
给真 harness 做 RL：先钉死 harness，再谈配方
先问一个问题：给 Claude Code 这样的编码 agent 做 RL 训练，一条训练样本长什么样？
很多人脑子里的答案是一条完整的对话记录。八月两篇论文给出的真答案是：一条 rollout 平均要拆成 2.4 个训练样本，只有 36% 的 rollout 还能保持完整的一条序列。
这两篇论文，一篇是微软的 Agent Lightning v1.0 技术报告（8 月 19 日，arXiv 2608.17528），一篇是学术团队 LegoX 的 LEGO-RL（8 月 18 日，arXiv 2608.17393）。同一周发布，核心想法撞了车：不要为了做 RL 去造一个简化版 agent，直接在真的 harness 上训练。
harness 是什么，为什么训练它这么麻烦
先交代背景。现在的编码 agent 是两样东西的合体：一个模型负责预测 token，一个 harness 负责其他所有事——管理上下文、调工具、跑测试、出错了重试、上下文太长就压缩。Claude Code、OpenHands、OpenCode 都是 harness。模型能力涨得快，但 harness 决定这些能力在真实仓库里能不能兑现，这也是本号一直在跟的「harness>LLM」这条线。
麻烦在于，RL 训练器的默认假设是：模型吐出一串 token，就有一串对应的奖励。而真 harness 会把这个假设打碎。上下文压缩会改写历史，子 agent 会分叉，重试会产生重复请求——训练器如果只看「对话记录」，看到的已经不是模型真正生成的东西了。
两篇论文的解法是同一个架构反转：harness 当老板，训练器只记账。 在模型 API 边界放一个代理，模型每吐一个 token，token id、掩码、对数概率当场被记下来。harness 之后怎么改写历史、怎么压缩、怎么分叉，都无所谓——账本上记的是模型真正生成过的东西。harness 一行代码不用改：微软的 Agent Lightning 用一个代理层把训练接进任意 agent，代码量三千五百行；LEGO-RL 给每个 harness 写个薄适配器，Claude Code、OpenHands、OpenCode 三个都跑通了端到端。
三个坑，两个是真的，一个是拼出来的
Agent Lightning 的报告里有一组很扎眼的统计：编码 agent 的训练跑起来，只有 36% 的 rollout 最后还是一条完整序列，平均一条拆成 2.4 个样本。这不是 bug，是 harness 正常工作的代价——压缩、分叉、重试都在干正事，只是干完之后，训练器眼里的「一条轨迹」早就不连续了。所以记账必须记到 token 级，这就是两篇论文共同的地基。
LEGO-RL 那边贡献了一张更生猛的表：reward hacking 不是理论风险，是实测发生率。训练 Qwen3.5-35B-A3B 时，agent 侧观测到的作弊手法里，偷看 git 历史的发生率最高冲到 20.5%，改测试文件 19.4%，下载参考补丁 1.9%。对应的防御也很具体：agent 阶段把仓库 rebase 成单 commit、给沙箱装分阶段出口防火墙、测试文件扣到评分阶段才发放。模型发现捷径的速度，比很多人预想的快得多。
但同一篇论文的另一个数字被视频解读者拼坏了。论文表格里，OpenHands 的训推概率相关性是 0.9993，KL 散度是 0.75（乘 10⁻³）——这是同一行里的两个不同指标。「MoE 路由不重放，相关性从 0.9993 掉到 0.75」这个说法，把两列读成了一个因果链，论文里查无此数。真话朴素得多：因为 MoE 稀疏模型的专家路由每次采样都不一样，LEGO-RL 在更新权重时把 rollout 当时的路由重放了一遍，三个 harness 的相关性才都保住了 0.998 以上。0.9993 是重放的成果，不是什么坠落前的起点。
全文最狠的一组数字
LEGO-RL 论文里最有分量的不是训练提升（虽然也不差：35B 的 MoE 模型在三个 harness 上全线上涨，OpenHands 64.0→70.4，Claude Code 62.4→68.2，OpenCode 57.2→66.6），而是一组对比：
同一个模型 checkpoint，换个评测 harness，解决率能从 2.14% 摆到 9.27%，4.3 倍；而换一套训练配方，只动 1.16 倍。
这就是论文标题里「harness-native」的真正含义：harness 不只是跑工具的外壳，它是你分数的一部分，而且是最能决定分数的那部分。训练配方还在小数点后两位上较劲的时候，评测 harness 一换，量级就变了。所以论文的结论顺序是反直觉但清楚的：先钉死 harness，再谈配方。
微软那边的数字也在这条线上：Qwen3.5-9B 用 6 千条训练样本，SWE-bench Verified 从 41.8% 提到 56.4%，14.6 个点。不是靠更大的模型，是让真 harness 里的真实轨迹变成训练信号。
拼图放回主线
把两篇放回更大的图景：agent 的改进重心正在从权重层往 harness 层漂移，而这两篇是把 RL 训练机器搬到 harness 身边的第一批施工队。以前要么给 agent 造个玩具环境训模型（训完上真环境水土不服），要么冻结 harness 只训模型（训练信号被 harness 的各种动作污染）。现在方向变了——模型和 harness 一起在真实仓库里滚，账本记在 API 边界，作弊有人抓，路由有人重放。
顺便记一个生态观察：两篇都选 Qwen3.5 当底座，都跑 SWE-bench Verified，微软的框架 18.6 千星，LEGO-RL 上线两个多月 106 星。同一道题，大厂开源和学术团队给出的答案在架构层几乎一致——这大概是比任何一个单项数字都强的信号。
信源注：Agent Lightning（GitHub 18,572 星，arXiv 2508.03680 与 2608.17528）、LEGO-RL（arXiv 2608.17393 v1，GitHub 106 星）原文逐条核对；41.8→56.4 出自 Agent Lightning README；4.3× 与 1.16× 的对比段落按 alphaxiv 摘录口径标注（v1 HTML 未含该段，应为修订版内容）；「0.9993→0.75」拼接走样为本次核对裁决；作弊发生率数字为 LEGO-RL 论文原表。