Moonshot AI 的 Kimi 團隊與 kvcache-ai 已開源 AgentENV（AENV），這是一個設計用於大規模執行代理環境的分散式平台。AgentENV 用於 Kimi K3 的代理式強化學習（RL）訓練；Kimi K3 是 Moonshot 的 2.8 兆參數 Mixture-of-Experts 模型。該專案以 MIT 授權釋出。

為什麼環境基礎架構是代理式 RL 的瓶頸

代理式 RL 不只是從模型取樣文字。它要求模型在真實的電腦環境中採取行動。每一次 rollout 都需要一個隔離的 Linux 環境，並具備檔案系統、網路堆疊與執行中的程序。在這類訓練迴圈中，環境是資料生成路徑的一部分，因此重置速度、隔離性，以及重現或分支任務狀態的能力，都會直接影響可收集的有效 rollout 數量。

這項需求造成了棘手的基礎架構取捨。容器可以快速啟動，但它們共享主機核心，當執行模型生成的程式碼時，隔離性會被削弱。完整虛擬機則提供更強的隔離，但啟動較慢，且在閒置時仍會占用記憶體。

AgentENV 旨在處理這一缺口。它執行 Firecracker microVM，並試圖讓閒置狀態、重新啟動與分支的成本低到足以支援訓練規模的工作負載。

AgentENV 基於 Firecracker 的架構內部

每個 AgentENV 沙盒都以 Firecracker microVM 執行，擁有自己的 Linux 核心、檔案系統與網路命名空間。請求會透過 Axum HTTP API 接收，並轉發給負責管理沙盒生命週期的 orchestrator。

儲存是此設計的核心部分。根檔案系統透過 ublk 使用者空間區塊裝置提供，後端則是 overlaybd 分層映像。唯讀基礎層會在沙盒之間共享，而每個沙盒會寫入自己的上層。

在每個 guest 環境內，名為 envd 的 daemon 會在 port 49983 上管理命令執行、檔案操作與健康狀態回報。反向代理會將來自用戶端的 HTTP 與 WebSocket 流量路由到虛擬機內執行的服務。

該專案也描述了兩種提高密度的機制。主機 page cache 會在儲存資料與記憶體快照資料之間共享。Memory ballooning 會將可回收的 guest 記憶體歸還給主機，協助在環境隨時間分歧時維持超額配置。

快照、暫停、恢復與分叉

快照、暫停、恢復與分叉是 AgentENV 的核心功能。系統會以增量方式快照記憶體與檔案系統變更，而不是每次都寫入完整映像。

官方報告的效能數字顯示，以快照支援的環境可在 50 ms 內啟動或恢復，並在 100 ms 內暫停。即使在大量磁碟修改的情況下，增量快照擷取也據稱可在 100 ms 內完成。

分叉是最貼近 RL 工作負載的功能。執行中的沙盒可以在同一節點上複製成最多 16 個獨立的子沙盒。來源環境會在擷取期間短暫暫停，然後恢復。每個子沙盒都會繼承來源的檔案系統、記憶體與資源配置。

實際效果是，昂貴的設定只需執行一次。團隊可以安裝依賴項、複製儲存庫，並到達特定任務狀態，然後將該精確狀態分支成平行 rollout。這對代理任務很重要，因為重複試驗需要從同一個已準備好的狀態開始，但探索不同的行動軌跡。快照可持久化到與 S3 相容的物件儲存，或共享的分散式檔案系統。

有一個預設行為值得注意：每個沙盒都有 TTL，到期會觸發暫停而非刪除。若要刪除，必須在 create API 中傳入 autoPause: false。

按需載入與快照儲存庫

映像會透過 overlaybd 按需載入。本機磁碟作為有界快取，保留熱資料並淘汰冷資料。

這項設計支援機群層級的運作，因為節點不需要預先暖機每個映像，也不需要儲存每個快照的完整副本。可定址的映像集合因此可以超過本機磁碟容量，同時在整個叢集內維持快速啟動。

快照狀態分為三層。Builder staging workspace 會在建置期間保存 artifact。已提交的快照儲存庫作為耐久的事實來源。節點本機 runtime cache 則儲存啟動時衍生的設定。

支援兩種儲存庫後端：預設的 posix_fs，以及 oss。oss 路徑使用共享的 S3 相容用戶端，因此需要明確指定 region。

AgentENV 也包含一個基於 iroh 的選用 peer-to-peer 傳輸，可向同儕節點宣告已提交的 artifact。該功能預設停用。文件明確指出，P2P 不會改變已提交快照的模型。對於共享儲存，文件要求至少 1 Gbps，並強烈建議 10 Gbps 或更快。

E2B 相容性作為採用途徑

AgentENV 提供與 E2B 相容的 HTTP API。只要將 E2B_API_URL 指向 AgentENV 伺服器，使用者即可在不修改程式碼的情況下執行官方 E2B Python 或 TypeScript SDK。

這種相容性是一項刻意的發行選擇。已在 E2B 上執行代理的團隊，可以在不重寫代理程式碼的情況下自行託管 runtime。AgentENV 也提供原生 aenv CLI，文件建議在 AgentENV 專用工作流程中使用。

部署選項

AgentENV 需要 Linux kernel 6.8+ 與 /dev/kvm 存取權；安裝腳本另需 Ubuntu 24.04。aenv CLI 支援 x86_64 與 arm64 上的 Linux 和 macOS。伺服器本身僅支援 Linux，因為它需要 KVM。

文件描述了五種部署路徑：

• 以 systemd service 執行伺服器的安裝腳本
• 發布於 ghcr.io/kvcache-ai/aenv-server 的 Docker 映像
• 模擬多節點叢集的 Docker Compose stack
• 包含 gateway、scheduler 與 node DaemonSet 的 Kubernetes manifests
• 使用 Rust toolchain 從原始碼建置的路徑

多節點部署會新增位於 :8080 的 gateway 與位於 :9090 的 scheduler。多節點控制平面在文件中被描述為原型，這使得叢集排程的成熟度，以及共享儲存相關的營運需求，成為團隊評估較大規模部署時的關鍵細節。

AgentENV 將每個代理環境作為 Firecracker microVM 而非容器執行，提供核心層級的隔離。該專案報告稱，基於快照的啟動或恢復時間低於 50 ms，暫停時間低於 100 ms。執行中的沙盒可在同一節點上分叉成最多 16 個獨立子沙盒，而與 E2B 相容的 HTTP API 可讓既有 E2B Python 與 TypeScript SDK 程式碼無需修改即可執行。