OpenEnv 是一个用于创建智能体执行环境的工具，例如终端、浏览器，或任何智能体可以与之交互的东西。今天，我们很高兴地宣布，OpenEnv 正变得更加开放，以让训练智能体的未来走向开源。

从今天起，OpenEnv 将由一个委员会协调，该委员会目前包括 Meta-PyTorch、Reflection、Unsloth、Modal、Prime Intellect、Nvidia、Mercor、Fleet AI、Microsoft、Hugging Face 和 RadixArk。OpenEnv 现在位于 huggingface/OpenEnv

OpenEnv 项目得到了 AI 生态系统中一些领先组织的支持与采用，包括 PyTorch Foundation、vLLM、SkyRL（UCB）、Lightning AI、Axolotl AI、Stanford Scaling Intelligence Lab、Mithril、OpenMined、Scaler AI Labs、Scale AI、Patronus AI、Surge AI、Halluminate、Turing、Scorecard、Snorkel AI、SGLang 和 Miles。

为什么我们需要 OpenEnv 来训练开源智能体

像 Claude Code、Codex、OpenClaw 和 Hermes 这样的智能体运行框架一直在不断改进。它们得以改进的一个原因是，像 GPT-5.5 和 Opus 4.8 这样的模型被训练来使用各自对应的运行框架。

我们也希望在开源模型上获得这些收益：训练能够有效使用运行框架的本地模型，并通过为特定任务专门化模型来节省算力。

为什么我们需要（更加）开放

前沿实验室训练的模型与配套运行框架，在很大程度上如同手套与手一般严丝合缝。模型被训练去使用这套框架，并针对其特性进行优化。模型在一定程度上能够泛化到这些框架之外，但没有什么能胜过训练所带来的效率。

在开放生态中，情况并非如此。开发者会使用任意框架、任意模型、任意推理引擎，用于他们看重的任何用例。这是社区的根本所在，但同时也是一项挑战，需要基础设施和工具来应对。

这正是 OpenEnv 的用武之地。它是一个在框架、环境与训练器之间提供接口的库，可适用于任何模型。要让这一方案真正扎根，它需要由所有主要利益相关方共同拥有。

是协议层，而非奖励框架

伴随治理层面的变更，我们正在收紧 OpenEnv 的定位。

在近期的版本中，OpenEnv 已成为RL 环境的互操作性层。它的职责是标准化环境的发布、部署以及被智能体消费的方式。它不会规定奖励如何定义，也不会规定训练循环如何运作。奖励定义、评分标准以及训练器特有的逻辑，属于那些专精于此的库。OpenEnv 是它们都能接入的通用插座。

在实践中，这意味着：

一个接口，多种环境，它们都暴露熟悉的 Gymnasium 风格 API（reset()、step()、state()），运行在客户端/服务器架构之上。一个能说 OpenEnv 的训练器可以驱动任何兼容的环境，无需专门编写代码。

熟悉的协议与规范化打包。环境通过 HTTP 和 WebSocket 等标准协议提供服务，并使用 Docker 打包。MCP 是一等公民，因此 OpenEnv 环境可立即与 MCP 服务器兼容，同一环境在仿真（训练/评估）和生产模式下表现一致。

跨环境库互操作。你可以在不同的生态（verifiers、harbor 等）中定义和消费环境，并使用你选择的基础设施和 hub。OpenEnv 是它们底层的部署与接口层，而非它们的竞争者。

下一步

在接下来的几个月里，我们将聚焦于那些能让 OpenEnv 从一个快速成长的项目转变为可靠标准的事情：

1. 外部奖励：让奖励可以在你已经在使用的任何库中定义，以 OpenEnv 作为部署层（RFC 006）。
2. 通过数据集实现任务集：将环境任务与 Hugging Face 数据集连接起来，使环境和基准测试能够干净地组合（RFC 007）。
3. 持续的 Harness 集成：为智能体 harness 提供一等支持。
4. 端到端示例：TRL、Unsloth、Miles 等框架中的完整训练与评估演练。
5. 自动验证：衡量环境质量及其对模型学习的贡献。这将为社区提供一种可扩展的方式来评估他们的环境并推动质量提升（想想黑客松！）。RFC 008。

参与其中

OpenEnv 在设计上以社区为中心，而且仍处于早期阶段——预计会有粗糙之处，请帮助我们打磨完善。查看代码和 RFC：github.com/huggingface/OpenEnv

感谢所有帮助促成这一转变的人。让我们一起构建开源智能体强化学习的共同基础。