Hugging Face 开源多 harness RL 工具链：LFM2.5-2.6B 跨四个 harness 从 42.2% 升到 54.2%

10 月 1 日，Hugging Face 与 Liquid AI 的研究者在 Hugging Face Space 上发布《The ultimate guide to multi-harness RL》，同一天 @adithya_s_k 在 X 上发出配套帖串。10 月 2 日，@huggingface 官方账号发帖称 @adithya_s_k 与 Hugging Face 团队发布了这份指南，并把事情压成一句话：同一个模型、同一份权重，在一个 agent harness 里得 62%，在另一个里只有 33%。帖文称整套工具链全部开放，包括 OpenEnv 里的捕获代理、TRL 里的训练器、任务、SFT 数据、训练代码，以及七个已训练模型。

公告给出的结果落在 LFM2.5-2.6B 上：跨四个编码 harness 同时训练后，它在 250 个留出任务 × 四个 harness 的 1,000 次评测里，pass@1 从 42.2% 升到 54.2%，在双方都解出的任务上工具调用少了 31.1%。做法不改 harness 的一行代码，只把 harness 指向一个捕获代理。这组数字由团队自己发布的指南、模型卡与配套仓库给出，公告本身不构成独立验证。

同一份权重，四个 harness 四个基线

指南给出训练前的基线：Mini-SWE-Agent 62.1%、Codex 40.0%、OpenCode 33.6%、Claude Code 33.2%，四个 harness 合计 42.2%。帖文只取其中一组对比：62% 对 33%。

差距来自 harness，也就是包在模型外面、跑 agent 循环的那个程序。它挑选模型能用的工具、写下模型读到的上下文、解析模型返回的内容、决定什么时候停。指南引用的一项测量里，同一个 GLM-5.2 在 SWE-bench Pro 上于一个 harness 得 23%、另一个得 52%。同一章引用的另一项 100 题实验显示，换 harness 让 GLM-5.1 移动 13 个百分点，而在同一个 harness 里换模型只移动 2.5 到 5 个百分点。

对开放权重模型，这个差距会落到具体使用上。指南提到 LFM2.5-2.6B 的发布方只列出 Hermes Agent 和 OpenClaw 两个训练 harness，而这次实验的四个 harness 都不在其中。

不动 harness，把 base URL 指向代理

harness 不认识训练器，只认识模型提供方：一个 base URL 加一个 API key。捕获代理就坐在这个位置上。key 是这一轮 rollout 专属的 capture session id，因此一个端口上的单个代理能同时服务所有并发 rollout，带未注册 key 的请求返回 401。编码 agent 各说各的 API 方言，代理从请求路径判断是哪一种，再按调用方原本的格式把回复放回去，四种格式分别是 OpenAI Chat Completions、OpenAI Responses、Anthropic Messages 和 Gemini。

每次模型调用，代理向推理引擎要三样东西：prompt 的 token ids、采样出的 token ids，以及每个采样 token 的 logprob。它从完整分布采样，不做 top_p 或 top_k 截断，因为 vLLM 的 processed logprobs 是在截断之后算出来的，会和策略对不上。指南给出的数字是：把 top_p 调到 1.0，importance ratio 从 0.985～0.993 提高到 0.9984～0.9999。vLLM 需要两个启动参数，--return-tokens-as-token-ids 和 --logprobs-mode processed_logprobs。

代理不信任引擎的自述。第一次见到某个引擎时，它发探测请求并给结果打分，还判断 logprob 是 raw 还是 processed。低于 tokens 级别的引擎照样能跑 rollout，但只能用于评测：OpenAI、Anthropic、Hugging Face Inference Providers 这类托管 API 就落在这一档，可以用它们评 harness，不能拿它们训练。

模型调用随后被连成一张图。代理把每次调用存成节点，连到 prompt 与 completion 构成其最长精确 token 前缀的那次调用，重试表现为兄弟节点；每条从根到叶的路径变成一条训练序列，上下文 token 的 loss mask 记 0，采样 token 记 1。@_lewtun（Lewis Tunstall）把这条管线概括为捕获代理加 Harbor 的任务与沙箱，再加 TRL 的异步 GRPO 训练器。

覆盖面上，指南称 Harbor 0.22.0 带 40 多个 agent harness 的适配器，OpenEnv 端到端验证了十个。公告配图列了 12 个 harness 的图标，从 termux-2、goose、opencode、claude-code，到 swe-agent、codex、trae-agent 和 kimi-cli，并标注 222 次被拦截的调用、454,530 个已捕获 token；帖串正文则写「十个 harness 未经修改地跑通」。代理本身是单进程，指南记录它在约 200 个并发会话时健康检查开始跟不上、320 个时进程崩溃，撞上模型调用预算的 rollout 也由代理截停，最后一条回复不进入训练数据。

多 harness 对 OpenCode-only：差别落在分项上

两次 LFM 运行共用同一套设置：1,000 个 SmolDataEnvs 训练任务（400 个 medium、600 个 hard，顺序固定），Async GRPO 跑 1,000 步，每组 8 条 rollout，权重最多落后 4 个优化步；每次运行两台 H100；每个 rollout 一个 E2B 沙箱，1 CPU、4 GB 内存。评测是 250 个留出任务 × 四个 harness，共 1,000 个单元格，单元格以第一次被判分的尝试为准，每 100 步评一次。harness 版本固定在 OpenCode 1.18.31、Claude Code 2.1.270、Codex 0.154.0、Mini-SWE-Agent 2.4.6。

OpenCode-only 运行整体 52.3%，多 harness 运行 54.2%，差距 1.9 个百分点，指南说这在噪声范围内。分项差别更清楚：多 harness 模型的分数是 OpenCode 49.6%、Claude Code 48.8%、Codex 53.6%、Mini-SWE-Agent 64.8%；只在 OpenCode 里训练的模型在 OpenCode 上更高（58.0%，从 34% 涨上来），但 Claude Code 只有 42.0%、Codex 43.2%。两组数字分别记在两个模型卡里。

工具调用上，多 harness 模型在 step 1,000 比 base 少 31.1%，统计口径是双方都解出的 356 个任务/harness 组合；OpenCode-only 模型在同样口径下少 11%。指南说节省最大的是 Codex，大约一半；例外是 OpenCode-only 模型在它没训过的 Claude Code 下反而更费，step 500 时生成的 token 比 base 多 62%。

奖励里加了工具效率项：correctness × (1 + 0.1 × 15 / (15 + tool_calls))，答对最多加 0.1，答错仍是 0，所以模型不能靠早停拿奖励。它的作用体现在 GRPO 的组内对比里：多 harness 运行有 155/686 组（22.6%）、OpenCode-only 运行有 97/555 组（17.5%）出现「所有可判分 rollout 都正确但调用次数不同」，此时只有效率奖励能把它们区分开。作为对照，指南说早期 Qwen 运行只用 correctness 奖励，单条 rollout 的工具调用从 13 次涨到 41 次。

模仿 Qwen3.8-27B 的成功轨迹：停在 47.5%

同一套 OpenEnv 与 Harbor 管线还能记录整条轨迹，团队用它做了一次模仿学习。教师是 Qwen3.8-27B，在每个 harness 上对同一批训练任务最多试三次，保留验证器第一次判对的那条，最终拿到 888 个任务的 3,189 条成功轨迹（377 个 medium、511 个 hard）。每条轨迹的每个助手回合是一个训练样本，上下文包含工具输出，损失只算下一个助手回复，tokenize 用 LFM 自己的 chat template 而不是教师的。

两个 SFT 模型都从同一个 LFM2.5-2.6B base 全量微调：OpenCode SFT 用 801 条 OpenCode 轨迹、4,825 个样本，整体 47.5%；多 harness SFT 用全部 3,189 条轨迹、17,929 个样本，整体 43.1%，在 Claude Code（33.2% → 42.4%）和 Codex（40.0% → 46.8%）上有提升，但 Mini-SWE-Agent 从 62.1% 掉到 45.2%，抵消了前面的增益，整体回到 base 的噪声范围内。

对照 RL：取各自测试集上最好的 checkpoint（OpenCode-only 是 step 900，多 harness 是 step 700），多 harness RL 到 54.6%，比同样训在四个 harness 上的多 harness SFT 高 11.5 个百分点。指南承认在测试集上挑 checkpoint 对 RL 略有偏向，两个 checkpoint 与各自 step 1,000 的分数相差都在 0.5 个百分点以内。

SFT 也减少了工具调用，尽管它没有效率奖励：多 harness SFT 在双方都解出的任务上少 24.2%，每个 harness 都少。训练时长上，SFT 是 1.5 小时和 6.5 小时，RL 是 32 小时和 46 小时；前者不含收集教师 rollout 的时间，那一步要拿 27B 模型跑遍四个 harness。

开源清单：模型、数据集、环境与训练脚本

指南本身就是一篇带交互图表的在线文章，标注的发布日期是 2026 年 10 月 1 日，作者八人，其中七人隶属 Hugging Face，一人（Leonie Monigatti）隶属 Liquid AI。

七个已训练模型挂在 FineEnvs 组织下。按同一批 250 个测试任务 × 四个 harness 的整体 pass@1 排，四个 LFM2.5-2.6B 版本分别是 multiharness-RL 54.2%、opencode-RL 52.3%、opencode-SFT 47.5%、multiharness-SFT 43.1%，另有三个 Qwen3.5-2B 运行，分别是 multiharness-RL、opencode-RL 和 opencode-standalone-RL。LFM 模型沿用 LiquidAI/LFM2.5-2.6B 的 LFM Open License v1.0，模型卡写明这不是 Liquid AI 的官方发布。

数据方面，训练与测试任务在 SmolDataEnvs-harbor-train 与 -test，模仿学习的 SFT 数据在 SmolDataEnvs-multiharness-sft，每个 harness 一个 config，另有合并 config 和已按 LFM2.5-2.6B、Qwen3.5-2B tokenize 好的版本，附带训练脚本；教师的原始 rollout 在 qwen38-27b-harbor-rollouts。环境是三套 Space：SETA whitebox、原生 OpenCode、Harbor 多 harness。教程代码在 GitHub 上，三个训练脚本分别对应「TRL 自己跑工具循环」「原生 OpenCode 跑循环」「Harbor 跑四个 harness」。

仓库里还有一句容易漏掉的限定：历史运行用的是 Harbor 加 E2B 沙箱，而当前教程改用 Daytona、并把原生 OpenCode 作为单独对比，因此它不是那两次 LFM 运行的精确复刻。

发布后，@maximelabonne 称「很高兴看到这种配方被开源」。@helloiamleonie 把指南回答的问题列成三条：模型的基础表现在不同 harness 上能差多少，只训一个和训多个分别会怎样，加一点奖励能把工具效率提高多少。

团队自己标注的边界

团队在指南与配套仓库里写下了限定条件。每个设置只跑了一次，两次 LFM 运行看到的数据量也不同：多 harness 运行是 626 个任务、18.7M 监督 token、451M 训练处理 token，OpenCode-only 是 555 个任务、12.5M、162M，因此两次运行之间的比较被指南称作观察性的。LFM 没有跑过不带效率奖励的对照，这一项的贡献无法与其它改动分开。相邻 checkpoint 之间 1 到 2 个百分点的差别被直接归为噪声，最终 checkpoint 也是在测试集上挑的。

配套仓库还留着更早的 pilot 记录：whitebox 那次 100 步训练在第 31 步因 HTTP 读超时中断；用 25 个任务得到的分数被标注为「pilot 观察，不是可靠的模型排名证据」；待办清单里写着确认可持续的学习信号，以及为新的运行时补一次完整的 whitebox 100 步 pilot。

帖文下面，几位读者提了具体问题：@masontgill 问有没有在一个从未参与训练的第五个 harness 上测过；@Hesamation 问是否会研究用用户日常编码会话里的真实 harness 做 RL，而不用预定义评测；@proxy_vector 问几个 harness 是否共用同一个奖励函数；@GigleAI 问增益在没训过的 harness 上是否还成立。

指南自己列出的下一步是：先 SFT 再 RL，与从 base 直接 RL 对比；在教师四个 harness 都解出的 692 个任务上比较不同的 harness 组合；按每个 harness 等量监督 token 重做 SFT。还有一个他们直接写下的未解问题：多 harness SFT 为什么反而让 Mini-SWE-Agent 掉分，「我们还没有搞清楚」。