OpenEnv 是一個用於建立代理執行環境的工具，例如終端機、瀏覽器或任何代理可以互動的環境。今天，我們很高興地宣布 OpenEnv 將變得更加開放，以實現開源代理訓練的未來。
從今天起，OpenEnv 將由一個委員會協調，該委員會目前成員包括 Meta-PyTorch、Reflection、Unsloth、Modal、Prime Intellect、Nvidia、Mercor、Fleet AI 和 Hugging Face。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。
為什麼我們需要 OpenEnv 來訓練開源代理
代理工具框架，例如 Claude Code、Codex、OpenClaw 和 Hermes，持續不斷地改進。它們改進的一個原因是，像 GPT-5.5 和 Opus 4.8 這樣的模型經過訓練，能夠使用各自的工具框架。
我們也希望開源模型能獲得這些優勢：訓練能夠有效使用工具框架的本地模型，並透過針對特定任務優化模型來節省運算資源。
為什麼我們需要（甚至）更開放
領先實驗室訓練的模型和工具框架，在大多數情況下都是天衣無縫地協同運作。模型經過訓練以使用工具框架，並針對其特性進行優化。模型在一定程度上可以泛化到這些工具框架之外，但沒有什麼比訓練效率更重要的了。
在開源領域，情況並非如此。開發者使用任何工具框架、任何模型、任何推論引擎，來處理他們重視的任何使用案例。這是社群的基礎，但也是一個需要基礎設施和工具來解決的挑戰。
這就是 OpenEnv 的用武之地。它是一個在工具框架、環境和訓練器之間建立介面的函式庫，適用於任何模型。為了使其能夠持續發展，它需要由所有主要利害關係人共同擁有。
一個協定層，而非獎勵框架
除了治理模式的改變，我們也正在明確 OpenEnv 的定位。
在最近的版本中，OpenEnv 已成為強化學習環境的互通層。它的職責是標準化環境如何被代理發布、部署和使用。它不會規定獎勵如何定義或訓練迴圈如何運作。獎勵定義、評分標準和訓練器特定邏輯屬於專門處理這些的函式庫。OpenEnv 則是它們都可以插入的通用插座。
實際上，這意味著：
一個介面，多個環境，所有環境都透過客戶端/伺服器架構公開熟悉的 Gymnasium 風格 API (reset()、step()、state())。一個支援 OpenEnv 的訓練器可以驅動任何符合規範的環境，而無需客製化程式碼。
熟悉的協定和標準化封裝。環境透過 HTTP 和 WebSocket 等標準協定提供服務，並使用 Docker 進行封裝。MCP 是第一級公民，因此 OpenEnv 環境可以立即與 MCP 伺服器相容，並且相同的環境在模擬（訓練/評估）和生產模式下表現一致。
跨環境函式庫的互通性。您可以在不同的生態系統（驗證器、harbor 等）以及您選擇的基礎設施和中心上定義和使用環境。OpenEnv 是它們底層的部署和介面層，而不是它們的競爭對手。
下一步
在接下來的幾個月裡，我們將專注於將 OpenEnv 從一個快速成長的專案轉變為一個可靠的標準：
透過資料集定義任務集：將環境任務與 Hugging Face 資料集連接起來，以便環境和基準測試能夠清晰地組合（RFC 006）。
外部獎勵：讓獎勵可以在您已經使用的任何函式庫中定義，OpenEnv 作為部署層（RFC 007）。
持續的代理工具框架整合：對代理工具框架提供一流的支援。
端到端範例：在 TRL、Unsloth 及其他平台中提供完整的訓練和評估逐步指南。
自動驗證：衡量環境品質及其對模型學習的貢獻。這將為社群提供一種可擴展的方式來評估其環境並提高品質（想想黑客松！）。RFC 008。
參與其中
OpenEnv 在設計上以社群為中心，目前仍處於早期階段——預計會有一些不完善之處，並幫助我們改進它們。請查看程式碼和 RFC：github.com/huggingface/OpenEnv。
感謝所有幫助實現這一轉變的人。讓我們共同為開源代理式強化學習建立共同基礎。