El problema fundamental que Agent Substrate y Agent Sandbox buscan resolver es la ineficiencia y la inadecuación de los sistemas de orquestación de contenedores tradicionales, como Kubernetes, para gestionar cargas de trabajo de agentes de IA. Los agentes de IA se comportan más como procesos de un sistema operativo de tiempo compartido que como servicios de larga duración y replicados. Esto implica sesiones de larga duración pero mayormente inactivas, con ráfagas de ejecución de código generado dinámicamente y no confiable, que requieren aislamiento estricto y persistencia de estado volátil.
La arquitectura de Kubernetes, con su API server centralizado y su scheduler diseñado para un número modesto de Pods de larga duración, se convierte en un cuello de botella cuando se enfrenta a millones de eventos de scheduling de grano fino generados por agentes. La necesidad de gestionar el estado de la memoria y el sistema de archivos de sesiones inactivas, y la naturaleza no confiable del código ejecutado, exigen un enfoque diferente para el aislamiento y la programación, que Kubernetes no puede proporcionar de manera eficiente sin modificaciones sustanciales o capas adicionales.
Arquitectura del Sistema
La solución propuesta se compone de dos componentes principales: Agent Sandbox y Agent Substrate. Agent Sandbox es un entorno de ejecución de código abierto, construido sobre Kubernetes, que proporciona aislamiento a nivel de kernel para código generado por modelos. Utiliza gVisor por defecto para crear un 'jail' en lugar de un contenedor tradicional, asumiendo que la carga de trabajo es hostil. También permite el uso de Kata Containers para un aislamiento de kernel completo. Para mitigar la latencia de arranque en frío, Agent Sandbox mantiene pools de réplicas pre-aprovisionadas y utiliza snapshots de Pods para hibernar sesiones inactivas, liberando recursos computacionales.
Agent Substrate es la capa de runtime que orquesta millones de agentes, en su mayoría inactivos. Funciona como un control plane ligero y enfocado que se sitúa junto a un clúster de Kubernetes, desacoplando la lógica de scheduling de agentes del control plane estándar de Kubernetes. Su principio clave es la sobreasignación de memoria virtual aplicada a la computación, similar a cómo un sistema operativo pagina memoria fría a disco. Substrate multiplexa un gran número de actores con estado en un pool mucho más pequeño de Pods de worker pre-calentados, y 'snapshottea' los agentes inactivos a almacenamiento. Esto permite una sobreasignación de 30x o más con activación en sub-segundos, ya que los Pods de worker ya están en ejecución. Utiliza dos Custom Resources: WorkerPool para definir la capacidad computacional y ActorTemplate para definir los agentes. Kubernetes se mantiene para el aprovisionamiento de máquinas y servicios de larga duración, mientras que Substrate maneja las decisiones de scheduling específicas de agentes.
Flujo de Ejecución y Hibernación de Agentes
- 1 Evento de Agente Un evento externo (ej. prompt de usuario) llega para un agente.
- 2 Agent Substrate Recibe el evento y localiza el agente objetivo.
- 3 Pool de Workers Pre-calentados Si el agente está inactivo, Substrate lo asigna a un Worker Pod disponible.
- 4 Restauración de Snapshot El estado del agente (memoria, filesystem) se restaura desde el almacenamient...
- 5 Agent Sandbox El agente ejecuta el código dentro del entorno aislado (gVisor/Kata Containers).
- 6 Ejecución de Código El agente procesa el evento y genera una respuesta.
- 7 Hibernación de Agente Tras la ejecución, si el agente queda inactivo, su estado se 'snapshottea' a ...
- 8 Liberación de Recursos El Worker Pod queda disponible para otro agente, liberando CPU/memoria.
| Capa | Tecnología | Justificación |
|---|---|---|
| orchestration | Kubernetes | Provisión de infraestructura subyacente (máquinas, Pods) y gestión de servicios de larga duración. No es el control plane primario para agentes. |
| orchestration | Agent Substrate | Control plane especializado para la orquestación de millones de agentes de IA, optimizado para sesiones bursty y con estado. Gestiona la sobreasignación y el scheduling de agentes sobre Worker Pods. vs Extender el scheduler de Kubernetes, Implementar un scheduler completamente nuevo desde cero Custom Resources: WorkerPool, ActorTemplate |
| security | Agent Sandbox | Entorno de ejecución seguro y aislado para código de agente no confiable, utilizando aislamiento a nivel de kernel. vs Contenedores Docker estándar, Máquinas virtuales completas Default: gVisor; Pluggable: Kata Containers; Default-deny network policy |
| compute | gVisor | Proporciona aislamiento de kernel ligero para Agent Sandbox, interceptando llamadas al sistema y emulando un kernel para el contenedor. vs Kata Containers, Firecracker |
| compute | Kata Containers | Opción pluggable en Agent Sandbox para aislamiento de kernel completo, utilizando máquinas virtuales ligeras. vs gVisor |
| storage | Pod Snapshots | Mecanismo para guardar y restaurar el estado volátil (RAM, filesystem) de las sesiones de agentes inactivas, permitiendo la hibernación y liberación de recursos computacionales. vs Mantener el estado en memoria en todo momento, Reconstruir el estado desde cero en cada activación |
Trade-offs
Ganancias
- ▲▲ Densidad de agentes por hardware
- ▲ Eficiencia de recursos para agentes inactivos
- ▲ Seguridad y aislamiento para código no confiable
- ▲ Latencia de activación de agentes
Costes
- △ Complejidad de la arquitectura (capa de orquestación adicional)
- △ Overhead de aislamiento (gVisor)
- △ Latencia en el 'cold-path' (restauración de snapshot)
Fundamentos Teóricos
El concepto de gestionar un gran número de procesos con estado, que pasan la mayor parte de su tiempo inactivos y se activan en ráfagas, tiene profundas raíces en los sistemas operativos de tiempo compartido. Principios como la paginación de memoria virtual, el swapping y la sobreasignación de recursos, descritos en trabajos fundamentales como los de Fernando J. Corbató y Robert M. Fano en el sistema CTSS (Compatible Time-Sharing System) de los años 60, son directamente aplicables aquí. La idea de hibernar y restaurar el estado de un proceso (o agente) es una extensión de estos mecanismos de gestión de memoria y procesos.
La necesidad de un scheduler especializado para cargas de trabajo con patrones de acceso específicos también se ha explorado en la literatura académica sobre sistemas distribuidos y bases de datos. La investigación sobre algoritmos de scheduling que optimizan la latencia de cola para solicitudes de larga duración y baja frecuencia de llegada, en contraste con los algoritmos round-robin o aleatorios que funcionan mejor para solicitudes cortas y de alta frecuencia, es un área activa de estudio que Agent Substrate aborda directamente. La gestión de estado persistente y volátil en sistemas distribuidos también se relaciona con conceptos de consistencia y tolerancia a fallos, como los explorados en el paper 'Paxos Made Simple' de Leslie Lamport (2001), aunque Agent Substrate se enfoca más en la eficiencia de recursos para el estado volátil.