Multi-harness RL 中文导读：模型也要适应它使用的工具

同一个模型，放进不同的 Agent 工具里，为什么会表现得像换了一个模型？这篇文章研究的，就是模型与它所在的运行框架如何共同决定任务表现。

本文是对 FineEnvs 技术文章的中文导读，采用概括与评论，不是全文翻译或转载。实验数据来自原文，未独立复现。

原文：The ultimate guide to multi-harness RL

原作者：Adithya S Kolavi、Joel Niklaus、Sergio Paniego Blanco、Leonie Monigatti、Amine Dirhoussi、Ben Burtenshaw、Lewis Tunstall、Leandro von Werra。作者来自 Hugging Face 与 Liquid AI。

原文发布及更新日期：2026 年 10 月 1 日。本文依据该版本整理。

先理解 harness

Harness 可以理解为模型外面的运行框架：它提供工具、整理上下文，并管理执行和停止流程。模型能否完成任务，因此也取决于它是否适应这套接口。

原文提出，让模型在多种真实框架中接受强化学习，减少对单一框架习惯的依赖。其工程方案用 OpenEnv 捕获模型调用，Harbor 提供任务与沙箱，TRL 负责训练，无须改写各个框架。

训练需要的不只是聊天记录

作者强调，训练应保存实际生成的 token、生成时的概率和损失掩码。框架可能改写历史；事后把文本重新分词，未必能还原模型当时的动作。

这也是文章值得工程读者关注的地方：任务能运行、能评分，并不意味着已经收集到了可靠的训练数据。

实验说明了什么

在 SmolDataEnvs 上，LFM2.5-2.6B 经四种框架联合训练，平均 pass@1 从 42.2% 提升到 54.2%。在它与基础模型都答对的测试任务上，工具调用减少约 31%。

但只在 OpenCode 训练也达到 52.3%；原文明确指出，两者总体正确率差距处于噪声范围。多框架方案更值得注意的是跨框架的收益分布，而非一个必然更高的总分。

实验只有单次种子，两组数据与计算量也不一致。它支持继续探索这个方向，尚不足以证明多框架 RL 在所有场景都更好。

我的理解：评估单位应该是模型与框架的组合

以下是基于文章的延伸思考，不是作者的实验结论。

可以把模型比作开发者，把 harness 比作工作环境。换一家公司，业务目标可能一样，但命令、流程和文档组织都变了。一个人熟悉旧环境，并不意味着到了新环境马上就能保持相同效率。

这个类比提醒我们：评测 Agent 时，仅报模型名字会漏掉重要条件。比较两个方案，至少还应该记录工具配置、上下文处理、重试方式和预算。否则，看起来是模型能力的差异，实际上可能混入了运行环境的影响。

对使用 Agent 写代码的人，最实际的启发也许不是立刻启动训练，而是先把问题归因做细：失败究竟发生在理解需求、选择工具、传递参数，还是处理工具返回结果？这些问题对应的改进位置并不相同。

还有一点值得谨慎：更少的工具调用只有在任务质量得到保证时才有价值。一个提前放弃的 Agent 同样很省调用。看效率指标时，应同时看成功率和统计口径，尤其要分清“所有任务”与“双方都完成的任务”。

如果想进一步了解代理如何记录轨迹、如何对接训练器，以及奖励设计中遇到的失败案例，建议直接阅读原文及其交互图表。这篇导读只保留了理解主线所需的几个问题。