Il team Kimi di Moonshot AI e kvcache-ai hanno reso open source AgentENV (AENV), una piattaforma distribuita progettata per eseguire ambienti agentici su larga scala. AgentENV viene utilizzato per l’addestramento di reinforcement learning (RL) agentico per Kimi K3, il modello Mixture-of-Experts da 2,8 trilioni di parametri di Moonshot. Il progetto è rilasciato con licenza MIT.

Perché l’infrastruttura degli ambienti è un collo di bottiglia per l’RL agentico

L’RL agentico richiede più della semplice generazione di testo da un modello. Richiede che il modello agisca all’interno di un vero ambiente informatico. Ogni rollout necessita di un ambiente Linux isolato con un filesystem, uno stack di rete e processi attivi. In questo tipo di ciclo di addestramento, l’ambiente fa parte del percorso di generazione dei dati, quindi la velocità di reset, l’isolamento e la capacità di riprodurre o diramare gli stati dei task incidono direttamente sul numero di rollout utili che possono essere raccolti.

Questo requisito crea un difficile compromesso infrastrutturale. I container possono avviarsi rapidamente, ma condividono il kernel dell’host, riducendo l’isolamento quando viene eseguito codice generato dal modello. Le macchine virtuali complete offrono un isolamento più forte, ma si avviano più lentamente e continuano a occupare memoria quando sono inattive.

AgentENV è progettato per colmare questo divario. Esegue Firecracker microVM e mira a rendere gli stati inattivi, i riavvii e le diramazioni abbastanza economici da supportare carichi di lavoro su scala di addestramento.

Dentro l’architettura di AgentENV basata su Firecracker

Ogni sandbox AgentENV viene eseguita come una Firecracker microVM con il proprio kernel Linux, filesystem e namespace di rete. Le richieste vengono ricevute tramite un’API HTTP Axum, che le inoltra a un orchestratore responsabile della gestione del ciclo di vita della sandbox.

Lo storage è una parte centrale del design. Il filesystem root viene servito tramite un dispositivo a blocchi in userspace ublk supportato da immagini a livelli overlaybd. I livelli di base in sola lettura sono condivisi tra le sandbox, mentre ogni sandbox scrive nel proprio livello superiore.

All’interno di ogni ambiente guest, un demone chiamato envd gestisce l’esecuzione dei comandi, le operazioni sui file e il reporting sullo stato di salute sulla porta 49983. Un reverse proxy instrada il traffico HTTP e WebSocket dai client ai servizi in esecuzione all’interno della macchina virtuale.

Il progetto descrive inoltre due meccanismi per migliorare la densità. La page cache dell’host è condivisa tra storage e dati degli snapshot di memoria. Il memory ballooning restituisce all’host la memoria guest recuperabile, contribuendo a sostenere l’overcommit man mano che gli ambienti divergono nel tempo.

Snapshot, pausa, ripresa e fork

Snapshot, pausa, ripresa e fork sono le funzionalità centrali alla base di AgentENV. Il sistema acquisisce snapshot incrementali delle modifiche alla memoria e al filesystem invece di scrivere ogni volta un’immagine completa.

Le prestazioni riportate indicano che gli ambienti basati su snapshot si avviano o riprendono in meno di 50 ms e vanno in pausa in meno di 100 ms. La cattura incrementale degli snapshot, secondo quanto riportato, si completa in meno di 100 ms, anche in presenza di modifiche intense al disco.

Il fork è la funzionalità più specifica per i carichi di lavoro RL. Una sandbox in esecuzione può clonarsi in un massimo di 16 sandbox figlie indipendenti sullo stesso nodo. L’ambiente sorgente si mette brevemente in pausa durante la cattura e poi riprende. Ogni figlia eredita filesystem, memoria e configurazione delle risorse della sorgente.

Il risultato pratico è che la configurazione costosa può essere eseguita una sola volta. Un team può installare dipendenze, clonare un repository e raggiungere un determinato stato del task, quindi diramare quello stato esatto in rollout paralleli. Questo è rilevante per i task agentici in cui prove ripetute devono partire dallo stesso stato preparato, ma esplorare traiettorie di azione diverse. Gli snapshot possono essere persistiti su object storage compatibile con S3 o su un filesystem distribuito condiviso.

Un comportamento predefinito è degno di nota: ogni sandbox ha un TTL e la scadenza attiva una pausa anziché l’eliminazione. L’eliminazione richiede il passaggio di autoPause: false nell’API di creazione.

Caricamento on demand e repository degli snapshot

Le immagini vengono caricate on demand tramite overlaybd. Il disco locale agisce come una cache limitata, mantenendo i dati caldi ed eliminando quelli freddi.

Questo design supporta il funzionamento a livello di flotta perché i nodi non devono pre-riscaldare ogni immagine né archiviare una copia completa di ogni snapshot. L’insieme di immagini indirizzabili può superare la capacità del disco locale, mentre l’avvio rimane rapido in tutto il cluster.

Lo stato degli snapshot è organizzato in tre livelli. Un workspace di staging del builder conserva gli artefatti durante una build. Un repository di snapshot commitati funge da fonte di verità durevole. Una cache runtime locale al nodo archivia le configurazioni derivate al momento del lancio.

Sono supportati due backend di repository: posix_fs, che è il predefinito, e oss. Il percorso oss utilizza un client condiviso compatibile con S3, quindi è richiesta una regione esplicita.

AgentENV include anche un trasporto peer-to-peer opzionale basato su iroh, che può pubblicizzare artefatti commitati ai nodi peer. È disabilitato per impostazione predefinita. La documentazione afferma esplicitamente che il P2P non modifica il modello degli snapshot commitati. Per lo storage condiviso, la documentazione richiede almeno 1 Gbps e raccomanda fortemente 10 Gbps o più.

Compatibilità E2B come percorso di adozione

AgentENV espone un’API HTTP compatibile con E2B. Puntando E2B_API_URL a un server AgentENV, gli utenti possono eseguire l’SDK ufficiale E2B per Python o TypeScript senza modifiche al codice.

Questa compatibilità è una scelta deliberata di distribuzione. I team che già eseguono agenti su E2B possono auto-ospitare il runtime senza riscrivere il codice dei loro agenti. AgentENV fornisce anche una CLI nativa aenv, che la documentazione raccomanda per i workflow specifici di AgentENV.

Opzioni di distribuzione

AgentENV richiede il kernel Linux 6.8+ e accesso a /dev/kvm; lo script di installazione richiede inoltre Ubuntu 24.04. La CLI aenv supporta Linux e macOS su x86_64 e arm64. Il server è disponibile solo per Linux perché richiede KVM.

La documentazione descrive cinque percorsi di distribuzione:

• Uno script di installazione che esegue il server come servizio systemd
• Un’immagine Docker pubblicata su ghcr.io/kvcache-ai/aenv-server
• Uno stack Docker Compose che simula un cluster multi-nodo
• Manifest Kubernetes con gateway, scheduler e DaemonSet dei nodi
• Un percorso di build da sorgente usando la toolchain Rust

Le distribuzioni multi-nodo aggiungono un gateway su :8080 e uno scheduler su :9090. Il control plane multi-nodo è documentato come prototipo, rendendo la maturità dello scheduling clusterizzato e i requisiti operativi dello storage condiviso elementi chiave per i team che valutano distribuzioni più ampie.

AgentENV esegue ogni ambiente agentico come Firecracker microVM anziché come container, fornendo isolamento a livello di kernel. Il progetto riporta tempi di avvio o ripresa basati su snapshot inferiori a 50 ms e tempi di pausa inferiori a 100 ms. Una sandbox in esecuzione può effettuare il fork in fino a 16 figlie indipendenti sullo stesso nodo, e l’API HTTP compatibile con E2B consente al codice esistente degli SDK E2B per Python e TypeScript di funzionare senza modifiche.