Kimi AI and kvcache-ai Open Sources ‘AgentENV’: A Distributed System that Powers Agentic Reinforcement Learning (RL) Training for Kimi K3

Moonshot AI 的 Kimi 團隊與 kvcache-ai 近日正式開源了 AgentENV（AENV），這是一個專為大規模運行代理環境而設計的分散式平台，主要用於支援 Kimi K3 的代理強化學習（Agentic RL）訓練。Kimi K3 是 Moonshot AI 推出的 2.8 兆參數混合專家（Mixture-of-Experts）模型。AgentENV 的原始碼以 MIT 授權條款釋出，讓研究人員與開發者能夠自由使用並貢獻。代理強化學習與傳統的文本取樣訓練不同，它要求模型在真實的電腦環境中行動。

每一次的 rollout 都需要一個具備獨立檔案系統、網路堆疊與即時程序的隔離 Linux 環境。這個需求在既有技術中形成了一個難以取捨的困境：容器啟動速度快，但與主機共享核心，對於模型生成的程式碼來說隔離性不足；完整的虛擬機器雖然能提供良好的隔離，但啟動速度慢，且在閒置時仍佔用記憶體。AgentENV 正是為了解決這個缺口而設計，它採用 Firecracker 微型虛擬機器（microVM），讓閒置、重啟與分支等操作的成本降到足以支撐訓練規模。AgentENV 的核心架構建立在 Firecracker 之上。

每個沙箱都是一個 Firecracker microVM，擁有自己的 Linux 核心、檔案系統與網路命名空間。請求會先經過 Axum HTTP API，再由協調器（orchestrator）負責管理沙箱的生命週期。儲存層是這項設計的一大亮點：根檔案系統（rootfs）透過 ublk 使用者空間區塊裝置提供，並以 overlaybd 分層映像技術為基礎。唯讀的基底層（base layer）可在多個沙箱之間共享，每個沙箱則擁有自己的上層寫入層。在每個 Guest 內部，有一個名為 envd 的守護行程，負責處理指令執行、檔案操作，並在通訊埠 49983 回報健康狀態。

反向代理則負責將來自用戶端的 HTTP 與 WebSocket 流量導向 VM 內部執行的服務。此外，AgentENV 還實作了兩種密度機制。主機頁面快取（host page cache）在儲存與記憶體快照資料之間共享；而記憶體氣球（memory ballooning）則可將可回收的客端記憶體歸還給主機，當環境隨時間逐漸分化時，仍能維持超額配置（overcommit）的運作。快照、暫停、恢復與分支是 AgentENV 存在的核心原因。這項專案以增量方式擷取記憶體與檔案系統的快照，而非每次完整寫入映像檔。

根據官方公布的數據，快照備份的環境在 50 毫秒內即可啟動或恢復，暫停時間則在 100 毫秒內。即使磁碟有大量修改，增量快照擷取也能在 100 毫秒內完成。分支功能更是強化學習情境中的關鍵設計：一個正在運行的沙箱可在同一節點上克隆出最多 16 個獨立的子沙箱。來源沙箱在擷取期間會短暫暫停，之後恢復運作。每個子沙箱都會繼承來源的檔案系統、記憶體與資源配置。這項機制的實際效益在於，昂貴的環境設定只需執行一次——團隊可以安裝相依套件、複製程式碼倉庫、抵達任務狀態，然後將該狀態分支到多個並行的 rollout 中。快照可持久化至 S3 相容的物件儲存或共享的分散式檔案系統。

一個值得注意的預設行為是：每個沙箱都帶有 TTL（存活時間），到期時會觸發暫停而非刪除；若要刪除，必須在建立 API 時傳入 autoPause: false 參數。映像檔透過 overlaybd 技術按需載入。本地磁碟扮演有限容量的快取角色，保留熱資料並淘汰冷資料。這使得整個叢集層級的運作得以實現：節點不需要預先暖機所有映像檔，也無需持有每個快照的完整副本。因此，可存取的映像檔集合可以超過本地磁碟容量，同時整個叢集的啟動速度依然快速。

快照狀態分為三層：建置暫存工作區（builder staging workspace）保留建置過程中的產物；已提交快照儲存庫（committed snapshot repository）是持久的真相來源；節點本地運行時快取（node-local runtime cache）存放啟動時的衍生設定。支援兩種儲存庫後端：posix_fs（預設）與 oss。oss 路徑透過共享的 S3 相容用戶端運作，因此需要指定明確的區域。另有一個基於 iroh 的點對點傳輸機制，可向對等節點廣播已提交的成品，但預設為關閉狀態。文件明確指出，P2P 不會改變已提交快照模型。

對於共享儲存，官方建議至少要有 1 Gbps 的網路頻寬，並強烈推薦使用 10 Gbps 或更高的速度。為了降低採用門檻，AgentENX 提供了與 E2B 相容的 HTTP API。只要將 E2B_API_URL 指向自己的伺服器，官方 E2B Python 或 TypeScript SDK 就能無需修改程式碼直接使用。這是一項經過深思熟慮的散布策略：已經在 E2B 上運行代理程式的團隊，可以自行託管運行時環境，而不需要重寫代理程式邏輯。此外，AgentENV 也提供原生 aenv CLI，官方文件建議在處理 AgentENV 專屬工作流程時使用。

在部署方面，AgentENV 的前提條件是 Linux 核心 6.8 以上版本，以及 /dev/kvm 的存取權限；安裝腳本額外要求 Ubuntu 24.04。aenv CLI 支援 Linux 與 macOS 的 x86_64 與 arm64 架構，但伺服器本身僅限 Linux，因為它需要 KVM。官方文件記載了五種部署方式：使用安裝腳本將伺服器以 systemd 服務執行；從 ghcr.

io/kvcache-ai/aenv-server 取得 Docker 映像；使用 Docker Compose 模擬多節點叢集；透過 Kubernetes 部署，包含 Gateway、Scheduler 與節點 DaemonSet；以及使用 Rust 工具鏈從原始碼建置。多節點部署需要額外啟用通訊埠 8080 的 Gateway 與通訊埠 9090 的 Scheduler。總結來說，AgentENV 的部署選項涵蓋安裝腳本、Docker、Docker Compose 與 Kubernetes，其中多節點控制平面仍標示為原型階段。

每個代理環境都作為獨立的 Firecracker microVM 運行，而非容器，因此隔離層級達到核心層次。從快照啟動或恢復的時間低於 50 毫秒，暫停時間低於 100 毫秒。一個運行中的沙箱可在同一節點上分支出最多 16 個獨立子沙箱。HTTP API 與 E2B 相容，現有的 E2B Python 與 TypeScript SDK 程式碼可直接沿用。相關程式碼與完整文件已公開於 GitHub 專案頁面，這項研究的功勞歸屬於 Moonshot AI Kimi 團隊與 kvcache-ai 的研究人員。