HuggingFace与LiquidAI发布多框架强化学习训练指南

多 Harness 强化学习训练指南 @huggingface × @liquidai

Agent 的能力一半在模型、一半在 Harness 里，而模型只在某一个框架里训练过就会“水土不服”。HuggingFace 和 LiquidAI 团队给出的方案是：不改任何一行框架代码，在框架与模型之间放一个记录代理，让同一个模型同时在四个真实框架里做 RL，小模型 LFM2.5-2.6B 从 42% 提升到 54%，且工具调用减少 31%

https://huggingface.co/spaces/FineEnvs/multi-harness-rl

问题：Harness 是被忽视的变量 · 同一模型 GLM-5.2，在 SWE-bench Pro 上一个框架 23%、另一个 52%；Claude Opus 4.5 同权重下 Scale 榜 45.9%，Claude Code 里 55.4%。 · 一项研究中，换框架让 GLM-5.1 波动 13 分，而在固定框架里换模型只波动 2.5–5 分；框架的影响比模型排名差异还大。 · 更严重的是“框架过拟合”：OpenSWE-32B 离开原生框架后，在 SWE-bench Verified 上从正常水平暴跌 58.8 分到 3.6%，Terminal-Bench 上直接归零；模型输出的工具调用格式别的框架根本解析不了。

原因 (@KwaiAICoder 团队归纳) 是单框架 RL 会让模型学到“这个框架的接口习惯”而非任务本身，具体过拟合在三处：动作格式、上下文结构、控制流。前沿实验室已经开始有意识地做 “harness scaling”(Kimi K3、Qwen3-Coder-Next、Liquid AI 等)，但缺一个开放、通用、不需要 frontier 预算的做法。

方法：不改框架，改“听”的位置 技术难点在于：传统 Agentic RL 中训练器拥有循环 (white-box)，能看到每个 token；而在真实框架里 (black-box)，循环归框架所有，训练器只能看到一串 API 请求-响应。而策略梯度算法需要每个 token 的精确 ID 和采样时的 logprob，只有文本是不够的，因为： · 重新分词可能得到不同的 token 序列； · 框架会编辑文本(修 JSON、改空白、加角色标记)，拿编辑后的文本训练等于在学一个模型从没生成过的回复； · 异步 RL 中模型权重已更新，事后重算 logprob 无法还原采样时的概率，importance ratio 会失真。

OpenEnv 的解法是一个 capture proxy：框架把它当模型服务 (填个 base URL + API key，key 就是每次 rollout 独有的 session id)。它自动识别四种 API 方言 (OpenAI Chat Completions、OpenAI Responses、Anthropic Messages、Gemini)，统一转成 chat completions 再以原格式回复。同时它向推理引擎 (vLLM) 要求返回精确的 prompt token ids、采样 token ids 和逐 token logprob，从完整分布采样 (把 top_p 提到 1.0 后，importance ratio 从 0.985–0.993 修到 0.9984–0.9999)。

由此构建“rollout 图”：每次模型调用是一个节点，按最长 token 前缀链接；每条根到叶的路径成为一条训练序列——上下文 token loss mask 为 0，模型采样的 token 为 1。工具链的其他部分：Harbor 提供容器化任务和沙箱(40+ 框架适配器)，TRL 的 HarnessRolloutWorker(已合并进 TRL)消费这些 trace 做 async GRPO。

实验设置 · 模型：LFM2.5-2.6B(Liquid AI 的小开源模型) · 任务：SmolDataEnvs,来自真实 Kaggle notebook 的 5000 个数据分析任务；1000 个训练 / 250 个留出测试 · 两组对照：只在 OpenCode 里训 vs. 在 OpenCode、Claude Code、Codex、Mini-SWE-Agent 四个框架同时训(GRPO 每组 8 条 rollout,同一组的 rollout 用同一框架，保证 advantage 比较的是动作而非框架) · 奖励：正确性 1/0 + 一个最多 0.1 的工具效率奖励(答对且调用更少才有) · 算力：仅 2 张 H100(一张训练一张推理)，每 rollout 一个 E2B 沙箱，训练 32–46 小时

基线本身就说明了问题：同一个未训练模型，Mini-SWE-Agent 下 62%，Claude Code 下只有 33%。

实验结果 多框架 RL (核心结果)：留出集平均 42.2% → 54.2%，四个框架全部提升；已解任务的工具调用减少 31%(Codex 下省了一半调用)。效率奖励的来源很巧妙：Qwen 预实验中纯正确性奖励让工具调用从 13 次膨胀到 41 次；而 GRPO 靠组内对比学习，当 8 条 rollout 全对时，调用次数差异是唯一的奖励对比来源(多框架运行中 22.6% 的组处于这种情况)。

单框架 vs 多框架：只训 OpenCode 让 OpenCode 从 34% 冲到 58% (超过多框架模型在 OpenCode 下的 50%),但在 Claude Code 下反而用更多的调用和 token(生成 token 最多多 62%)，又一种形式的过拟合。多框架模型在所有框架下都省调用。总准确率上两者只差 1.9 分(在噪声范围内)。

SFT 对照 (最反直觉的发现)：用大模型 Qwen3.8-27B 在同四个框架跑出 3189 条成功轨迹做模仿学习，多框架 SFT 只到 43.1% (甚至低于基线附近)，OpenCode SFT 47.5%,都明显低于 RL 的 54.6%。多框架 SFT 还让 Mini-SWE-Agent 从 62% 跌到 45%。抄大模型的答案不如让小模型自己练。(注意作者自己也声明：SFT 与 RL 在 token 量、步数、目标函数上都不对等，这是观察而非严格的方法排序。)