Das Kimi-Team von Moonshot AI und kvcache-ai haben AgentENV (AENV) als Open Source veröffentlicht, eine verteilte Plattform, die für den Betrieb von Agentenumgebungen in großem Maßstab entwickelt wurde. AgentENV wird für agentisches Reinforcement-Learning-(RL-)Training von Kimi K3 eingesetzt, Moonshots Mixture-of-Experts-Modell mit 2,8 Billionen Parametern. Das Projekt wird unter einer MIT-Lizenz veröffentlicht.

Warum Umgebungsinfrastruktur ein Engpass für agentisches RL ist

Agentisches RL erfordert mehr, als Text aus einem Modell zu sampeln. Es verlangt, dass das Modell in einer echten Computerumgebung handelt. Jeder Rollout benötigt eine isolierte Linux-Umgebung mit Dateisystem, Netzwerk-Stack und laufenden Prozessen. In einer solchen Trainingsschleife ist die Umgebung Teil des Pfads zur Datengenerierung; daher beeinflussen Reset-Geschwindigkeit, Isolation und die Fähigkeit, Aufgabenstände zu reproduzieren oder zu verzweigen, direkt, wie viele nützliche Rollouts gesammelt werden können.

Diese Anforderung führt zu einem schwierigen Infrastruktur-Kompromiss. Container können schnell starten, teilen sich jedoch den Host-Kernel, was die Isolation schwächt, wenn modellgenerierter Code ausgeführt wird. Vollständige virtuelle Maschinen bieten stärkere Isolation, starten aber langsamer und belegen auch im Leerlauf weiterhin Speicher.

AgentENV soll diese Lücke schließen. Es betreibt Firecracker microVMs und zielt darauf ab, Leerlaufzustände, Neustarts und Verzweigungen kostengünstig genug zu machen, um Workloads im Trainingsmaßstab zu unterstützen.

Ein Blick in die Firecracker-basierte Architektur von AgentENV

Jede AgentENV-Sandbox läuft als Firecracker microVM mit eigenem Linux-Kernel, Dateisystem und Netzwerk-Namespace. Anfragen werden über eine Axum HTTP API entgegengenommen, die sie an einen Orchestrator weiterleitet, der für die Verwaltung des Sandbox-Lebenszyklus verantwortlich ist.

Storage ist ein zentraler Bestandteil des Designs. Das Root-Dateisystem wird über ein ublk-Userspace-Blockgerät bereitgestellt, das von overlaybd-Layered-Images gestützt wird. Schreibgeschützte Basisschichten werden sandboxübergreifend geteilt, während jede Sandbox in ihre eigene obere Schicht schreibt.

In jeder Gastumgebung verwaltet ein Daemon namens envd die Befehlsausführung, Dateioperationen und Health-Reports auf Port 49983. Ein Reverse Proxy leitet HTTP- und WebSocket-Traffic von Clients an Dienste weiter, die innerhalb der virtuellen Maschine laufen.

Das Projekt beschreibt außerdem zwei Mechanismen zur Verbesserung der Dichte. Der Page Cache des Hosts wird über Storage- und Memory-Snapshot-Daten hinweg geteilt. Memory Ballooning gibt rückgewinnbaren Gastspeicher an den Host zurück und hilft so, Overcommit aufrechtzuerhalten, während Umgebungen im Zeitverlauf auseinanderlaufen.

Snapshot, Pause, Resume und Fork

Snapshotting, Pausieren, Fortsetzen und Forking sind die Kernfunktionen von AgentENV. Das System erstellt Snapshots von Speicher- und Dateisystemänderungen inkrementell, statt jedes Mal ein vollständiges Image zu schreiben.

Die gemeldeten Leistungswerte besagen, dass Snapshot-gestützte Umgebungen in unter 50 ms starten oder fortgesetzt werden und in unter 100 ms pausieren. Die inkrementelle Snapshot-Erfassung soll selbst bei umfangreichen Festplattenänderungen in unter 100 ms abgeschlossen sein.

Forking ist die Funktion, die am stärksten auf RL-Workloads zugeschnitten ist. Eine laufende Sandbox kann sich auf demselben Node in bis zu 16 unabhängige Child-Sandboxes klonen. Die Quellumgebung pausiert während der Erfassung kurz und wird anschließend fortgesetzt. Jedes Child erbt Dateisystem, Speicher und Ressourcenkonfiguration der Quelle.

Der praktische Effekt ist, dass aufwendige Einrichtung einmal durchgeführt werden kann. Ein Team kann Abhängigkeiten installieren, ein Repository klonen und einen bestimmten Aufgabenstand erreichen, um genau diesen Zustand anschließend in parallele Rollouts zu verzweigen. Das ist relevant für Agentenaufgaben, bei denen wiederholte Versuche aus demselben vorbereiteten Zustand starten, aber unterschiedliche Aktionsverläufe erkunden sollen. Snapshots können in S3-kompatiblem Object Storage oder in einem gemeinsam genutzten verteilten Dateisystem persistiert werden.

Ein Standardverhalten ist bemerkenswert: Jede Sandbox hat eine TTL, und deren Ablauf löst eine Pause statt einer Löschung aus. Für eine Löschung muss autoPause: false an die Create API übergeben werden.

On-Demand-Loading und das Snapshot-Repository

Images werden bei Bedarf über overlaybd geladen. Die lokale Festplatte dient als begrenzter Cache, der häufig genutzte Daten vorhält und selten genutzte Daten verdrängt.

Dieses Design unterstützt den Betrieb auf Flottenebene, weil Nodes nicht jedes Image vorwärmen oder eine vollständige Kopie jedes Snapshots speichern müssen. Die adressierbare Image-Menge kann die lokale Festplattenkapazität überschreiten, während der Start im gesamten Cluster schnell bleibt.

Der Snapshot-Zustand ist in drei Schichten organisiert. Ein Builder-Staging-Workspace hält Artefakte während eines Builds. Ein committed Snapshot-Repository dient als dauerhafte Source of Truth. Ein node-lokaler Runtime-Cache speichert abgeleitete Konfigurationen für den Startzeitpunkt.

Zwei Repository-Backends werden unterstützt: posix_fs, das Standard-Backend, und oss. Der oss-Pfad nutzt einen gemeinsam verwendeten S3-kompatiblen Client, daher ist eine explizite Region erforderlich.

AgentENV enthält außerdem einen optionalen Peer-to-Peer-Transport auf Basis von iroh, der committed Artefakte gegenüber Peer-Nodes ankündigen kann. Er ist standardmäßig deaktiviert. Die Dokumentation stellt ausdrücklich fest, dass P2P das committed Snapshot-Modell nicht verändert. Für Shared Storage fordert die Dokumentation mindestens 1 Gbps und empfiehlt ausdrücklich 10 Gbps oder schneller.

E2B-Kompatibilität als Weg zur Einführung

AgentENV stellt eine E2B-kompatible HTTP API bereit. Wenn E2B_API_URL auf einen AgentENV-Server zeigt, können Nutzer das offizielle E2B Python oder TypeScript SDK ohne Codeänderungen verwenden.

Diese Kompatibilität ist eine bewusste Distributionsentscheidung. Teams, die bereits Agenten auf E2B betreiben, können die Runtime selbst hosten, ohne ihren Agentencode neu schreiben zu müssen. AgentENV stellt außerdem eine native aenv CLI bereit, die in der Dokumentation für AgentENV-spezifische Workflows empfohlen wird.

Bereitstellungsoptionen

AgentENV erfordert Linux-Kernel 6.8+ und Zugriff auf /dev/kvm; das Installationsskript erfordert zusätzlich Ubuntu 24.04. Die aenv CLI unterstützt Linux und macOS auf x86_64 und arm64. Der Server selbst ist ausschließlich für Linux verfügbar, da er KVM benötigt.

Die Dokumentation beschreibt fünf Bereitstellungspfade:

• Ein Installationsskript, das den Server als systemd-Dienst ausführt
• Ein Docker-Image, das unter ghcr.io/kvcache-ai/aenv-server veröffentlicht ist
• Ein Docker-Compose-Stack, der einen Multi-Node-Cluster simuliert
• Kubernetes-Manifeste mit Gateway, Scheduler und Node DaemonSet
• Ein Build-from-Source-Pfad mit der Rust-Toolchain

Multi-Node-Bereitstellungen fügen ein Gateway auf :8080 und einen Scheduler auf :9090 hinzu. Die Multi-Node-Control-Plane ist als Prototyp dokumentiert, wodurch der Reifegrad des Cluster-Schedulings und die betrieblichen Anforderungen rund um Shared Storage wichtige Details für Teams sind, die größere Deployments evaluieren.

AgentENV führt jede Agentenumgebung als Firecracker microVM statt als Container aus und bietet damit Isolation auf Kernel-Ebene. Das Projekt meldet Snapshot-basierte Start- oder Resume-Zeiten von unter 50 ms sowie Pause-Zeiten unter 100 ms. Eine laufende Sandbox kann in bis zu 16 unabhängige Children auf demselben Node forken, und die E2B-kompatible HTTP API ermöglicht es bestehendem E2B Python und TypeScript SDK-Code, unverändert zu laufen.