El equipo Kimi de Moonshot AI y kvcache-ai liberó AgentENV (AENV) como código abierto, una plataforma distribuida diseñada para ejecutar entornos de agentes a escala. AgentENV se utiliza para el entrenamiento de aprendizaje por refuerzo agéntico (RL) de Kimi K3, el modelo Mixture-of-Experts de Moonshot con 2.8 billones de parámetros. El proyecto se publica bajo una licencia MIT.

Por qué la infraestructura de entornos es un cuello de botella para el RL agéntico

El RL agéntico requiere más que muestrear texto desde un modelo. Requiere que el modelo actúe dentro de un entorno informático real. Cada rollout necesita un entorno Linux aislado con un sistema de archivos, una pila de red y procesos activos. En este tipo de ciclo de entrenamiento, el entorno forma parte de la ruta de generación de datos, por lo que la velocidad de reinicio, el aislamiento y la capacidad de reproducir o bifurcar estados de tareas afectan directamente cuántos rollouts útiles pueden recopilarse.

Ese requisito genera una difícil disyuntiva de infraestructura. Los contenedores pueden iniciarse rápidamente, pero comparten el kernel del host, lo que debilita el aislamiento cuando se ejecuta código generado por el modelo. Las máquinas virtuales completas proporcionan un aislamiento más sólido, pero arrancan más lentamente y siguen ocupando memoria mientras están inactivas.

AgentENV está diseñado para abordar esa brecha. Ejecuta microVMs Firecracker y busca que los estados inactivos, los reinicios y las bifurcaciones sean lo suficientemente económicos como para soportar cargas de trabajo a escala de entrenamiento.

Dentro de la arquitectura de AgentENV basada en Firecracker

Cada sandbox de AgentENV se ejecuta como una microVM Firecracker con su propio kernel Linux, sistema de archivos y namespace de red. Las solicitudes se reciben a través de una API HTTP de Axum, que las reenvía a un orquestador responsable de gestionar el ciclo de vida del sandbox.

El almacenamiento es una parte central del diseño. El sistema de archivos raíz se sirve mediante un dispositivo de bloque en espacio de usuario ublk respaldado por imágenes en capas de overlaybd. Las capas base de solo lectura se comparten entre sandboxes, mientras que cada sandbox escribe en su propia capa superior.

Dentro de cada entorno invitado, un daemon llamado envd gestiona la ejecución de comandos, las operaciones de archivos y los reportes de salud en el puerto 49983. Un proxy inverso enruta el tráfico HTTP y WebSocket desde los clientes hacia los servicios que se ejecutan dentro de la máquina virtual.

El proyecto también describe dos mecanismos para mejorar la densidad. La caché de páginas del host se comparte entre el almacenamiento y los datos de snapshots de memoria. El memory ballooning devuelve al host la memoria recuperable del invitado, lo que ayuda a sostener el overcommit a medida que los entornos divergen con el tiempo.

Snapshot, pausa, reanudación y bifurcación

La creación de snapshots, la pausa, la reanudación y la bifurcación son las funciones centrales detrás de AgentENV. El sistema captura snapshots de memoria y cambios del sistema de archivos de forma incremental, en lugar de escribir una imagen completa cada vez.

Las cifras de rendimiento reportadas indican que los entornos respaldados por snapshots arrancan o se reanudan en menos de 50 ms y se pausan en menos de 100 ms. Según el proyecto, la captura incremental de snapshots se completa en menos de 100 ms, incluso bajo una modificación intensa del disco.

La bifurcación es la función más específica para cargas de trabajo de RL. Un sandbox en ejecución puede clonarse en hasta 16 sandboxes secundarios independientes en el mismo nodo. El entorno de origen se pausa brevemente durante la captura y luego se reanuda. Cada hijo hereda el sistema de archivos, la memoria y la configuración de recursos del origen.

El resultado práctico es que una configuración costosa puede realizarse una sola vez. Un equipo puede instalar dependencias, clonar un repositorio y llegar a un estado de tarea determinado, para luego bifurcar ese estado exacto en rollouts paralelos. Esto es relevante para tareas de agentes en las que los ensayos repetidos deben comenzar desde el mismo estado preparado, pero explorar distintas trayectorias de acción. Los snapshots pueden persistirse en almacenamiento de objetos compatible con S3 o en un sistema de archivos distribuido compartido.

Un comportamiento predeterminado es destacable: cada sandbox tiene un TTL, y su expiración activa una pausa en lugar de una eliminación. La eliminación requiere pasar autoPause: false en la API de creación.

Carga bajo demanda y repositorio de snapshots

Las imágenes se cargan bajo demanda mediante overlaybd. El disco local actúa como una caché acotada, que conserva los datos calientes y expulsa los datos fríos.

Este diseño admite operaciones a nivel de flota porque los nodos no necesitan precalentar cada imagen ni almacenar una copia completa de cada snapshot. El conjunto de imágenes direccionables puede superar la capacidad del disco local mientras el inicio sigue siendo rápido en todo el clúster.

El estado de los snapshots se organiza en tres capas. Un espacio de trabajo de staging del builder mantiene los artefactos durante una compilación. Un repositorio de snapshots confirmados sirve como fuente de verdad duradera. Una caché de ejecución local del nodo almacena configuraciones derivadas en el momento del lanzamiento.

Se admiten dos backends de repositorio: posix_fs, que es el predeterminado, y oss. La ruta oss utiliza un cliente compartido compatible con S3, por lo que se requiere una región explícita.

AgentENV también incluye un transporte peer-to-peer opcional basado en iroh que puede anunciar artefactos confirmados a nodos pares. Está deshabilitado de forma predeterminada. La documentación indica explícitamente que P2P no cambia el modelo de snapshots confirmados. Para el almacenamiento compartido, la documentación pide al menos 1 Gbps y recomienda firmemente 10 Gbps o más.

Compatibilidad con E2B como vía de adopción

AgentENV expone una API HTTP compatible con E2B. Al apuntar E2B_API_URL a un servidor AgentENV, los usuarios pueden ejecutar el SDK oficial de E2B para Python o TypeScript sin cambios de código.

Esta compatibilidad es una decisión deliberada de distribución. Los equipos que ya ejecutan agentes en E2B pueden autoalojar el runtime sin reescribir su código de agentes. AgentENV también proporciona una CLI nativa aenv, que la documentación recomienda para flujos de trabajo específicos de AgentENV.

Opciones de despliegue

AgentENV requiere Linux kernel 6.8+ y acceso a /dev/kvm; el script de instalación requiere además Ubuntu 24.04. La CLI aenv es compatible con Linux y macOS en x86_64 y arm64. El servidor solo funciona en Linux porque requiere KVM.

La documentación describe cinco rutas de despliegue:

• Un script de instalación que ejecuta el servidor como un servicio systemd
• Una imagen Docker publicada en ghcr.io/kvcache-ai/aenv-server
• Una pila Docker Compose que simula un clúster multinodo
• Manifiestos de Kubernetes con un gateway, un scheduler y un DaemonSet de nodo
• Una ruta de compilación desde el código fuente usando la toolchain de Rust

Los despliegues multinodo agregan un gateway en :8080 y un scheduler en :9090. El plano de control multinodo se documenta como un prototipo, lo que convierte la madurez de la programación en clúster y los requisitos operativos en torno al almacenamiento compartido en detalles clave para los equipos que evalúan despliegues más grandes.

AgentENV ejecuta cada entorno de agente como una microVM Firecracker en lugar de un contenedor, proporcionando aislamiento a nivel de kernel. El proyecto reporta tiempos de arranque o reanudación basados en snapshots inferiores a 50 ms y tiempos de pausa inferiores a 100 ms. Un sandbox en ejecución puede bifurcarse en hasta 16 hijos independientes en el mismo nodo, y la API HTTP compatible con E2B permite que el código existente de los SDK de E2B para Python y TypeScript se ejecute sin cambios.