Diseñando Entornos de Desarrollo Aislados para Agentes de Codificación

Soy un gran fan de las demos, así que comencemos con una demo. Aquí está un ganso animado en píxeles muy tonto. Y quiero que este ganso siga mi cursor. Así que pidamos a un agente que haga eso. Lo que está sucediendo detrás de escena aquí es que se ha iniciado un entorno. El servidor de desarrollo ha comenzado. Tenemos una URL de vista previa. El agente está revisando la base de código que tenía. Está pensando en cómo implementar este cambio. Y una vez que razona con ese cambio, idealmente debería estar haciendo ese cambio, y deberíamos poder verlo. Ahí vamos. Esta charla trata sobre todas las diferentes cosas que han sucedido para hacer que esta demo funcione. Lo más importante a identificar aquí es que no hay localhost aquí, ¿verdad? Así que todo esto, es una demo real. Está ejecutándose en algún lugar, y el agente y esta URL de vista previa que usamos para ver este trabajo tuvo que encontrar su camino desde internet, desde mi navegador, a un puerto muy específico en un entorno específico. Y si cierro esta pestaña y vuelvo mañana, idealmente el agente debería poder retomar donde lo dejó. Eso es lo que intentaremos entender cómo funciona. Así que esta URL de vista previa es una computadora. Por supuesto, es un servidor, pero computadora es una forma más agradable de decirlo, y me gusta eso. Y cada agente necesita una computadora. Creo que hemos llegado a un punto donde los modelos se han vuelto lo suficientemente buenos como para que los agentes de larga duración sean ahora reales. Son capaces de hacer muchas cosas muy poderosas, y la computadora que le damos también necesita ser diseñada de una manera muy específica para que sea útil para el agente.

Soy Naresh. En mi vida pasada, trabajé en la codificación de agentes que dos veces dejaron caer FreeBench, y ahora construyo los entornos sandbox en los que se ejecutan. Hablemos de todas las cosas que acaban de suceder en esa demo que acabamos de ver y tratemos de desglosarlo en diferentes capas. Lo primero es la propia frontera de aislamiento. Hay una micro VM, su propio kernel, su propia pila de red, no hay superficie de ataque de kernel compartido con nada más que se ejecute en la misma máquina. Y luego hay un contenedor que se ejecuta dentro de él. Entonces, ya sabes, está ejecutando Ubuntu, un sistema operativo con el que estamos muy familiarizados. Instalado, o más bien, hay un montón de herramientas de desarrollo que usamos comúnmente, preinstaladas.

Luego hay sesiones por lotes y un sistema de archivos. Aquí es donde el agente ejecuta comandos. Lee y escribe archivos, instala paquetes, todas las cosas que tú y yo haríamos cada vez que tuviéramos que trabajar en una base de código como esta. Y luego está la parte de redes. El agente probablemente ejecutó NPM start dentro del contenedor. Está ejecutándose en un puerto efímero, pero llevar el tráfico del agente y nuestro navegador a ese puerto en particular es un poco no obvio. Y finalmente, está la persistencia. Así que, todos los archivos que se instalan, todos los cambios realizados por el agente, necesitan sobrevivir a todas estas sesiones.

En realidad, repasaremos algunas de las decisiones de diseño que se toman para hacer dos cosas. Una, construir un entorno sandbox como este. Y dos, cómo usar un entorno sandbox como este para construir cualquier plataforma o producto que estés interesado en construir. Comencemos con el tiempo de ejecución. ¿Con qué realmente trabaja el agente? Los agentes idealmente necesitan las mismas herramientas que los desarrolladores necesitan. Podrías técnicamente simplemente darle un repel muy pequeño y decir, está bien, ejecuta el código que necesitas, pero está súper restringido. Idealmente, queremos darle una instancia completa de Linux, una computadora real, para que pueda realizar operaciones complejas no triviales.

Pero el desafío es, ¿cuánto del trabajo pesado para hacer mucha de esta orquestación puede hacer el propio sandbox? Porque cuanto menos hace el sandbox, más tiene que hacer tu agente. Las apuestas básicas son muy simples, ¿verdad? Esta es la línea base. Ejecutar algunos comandos, leer y escribir archivos, clonar repositorios, instalar paquetes, cada sandbox, bueno, cada contenedor tiene esto, y es necesario. Pero lo que realmente separa a CodeRunner de un entorno en tiempo real es la siguiente capa. El agente necesita poder iniciar procesos en segundo plano. En esta demo, el servidor de desarrollo fue un ejemplo de un proceso en segundo plano. Necesita seguir funcionando en segundo plano, transmitiendo para que el agente pueda reaccionar al output a medida que ocurre, no después de que el comando termine.

Continuidad, cuando trabajamos en un terminal, una sesión de bash, básicamente asegura que todos los comandos que ejecutamos ocurren secuencialmente, dependiendo de cómo uses bash, realmente. Pero el agente debería tener el mismo tipo de capacidad. Y no es solo una única sesión. Idealmente, debería poder gestionar múltiples sesiones dentro del mismo sandbox. Cuando quieres construir experiencias interactivas, cuando quieres dar a tus usuarios acceso al entorno sandbox para que también puedan tal vez ver lo que el agente ha estado haciendo, o incluso ejecutar directamente sus propios comandos. Idealmente, querrías tal vez conectar una instancia XGEM.

Y el intérprete de código del que hablamos al principio, donde el agente probablemente también podría simplemente generar código en bruto y ejecutar ese código en un REPL y obtener el output, pero también con respuestas enriquecidas para que el agente no tenga que pasar por el proceso de analizar el output. Así que este es solo un pequeño subconjunto de todas las cosas que los sandboxes deberían estar haciendo. El siguiente punto es el aislamiento. ¿Cómo contenemos el entorno sandbox?

Y la paradoja es que idealmente queremos que el agente pueda hacer mucho y alcanzar muchas superficies. Pero aún necesita tener algunas barandillas a su alrededor. Así que los problemas comunes básicamente que estás considerando son, bueno, ¿qué paquetes instaló entonces el agente? ¿Se le solicitó que lo instalara? ¿Existen posibilidades de inyección de comandos que podrían impactar lo que el agente realmente hace dentro de este entorno? No sabes qué le pidió realmente el usuario a tu agente que construyera, y cada mensaje realmente da forma a las decisiones que tu agente está tomando. No lo revisas, por lo que no lo controlas. Y finalmente, tampoco tienes control total sobre lo que el agente lee antes de escribir el código. Entonces, sabes, está leyendo archivos en un repositorio, páginas web, un turno anterior en la conversación, todo esto da forma a su salida. Y todo esto realmente aumenta los vectores de ataque. Y esta es la razón por la que el aislamiento no es opcional. Y la forma en que lo hacemos importa. Así que en este punto, creo que todos estamos familiarizados con la idea de, bueno, en realidad, simplemente ejecutémoslo en un contenedor Docker. Claro. Pero ¿qué está envolviendo ese contenedor en sí? ¿Cuál es el límite? La forma más simple es simplemente espacios de nombres, núcleo compartido con el host. Es rápido, ligero, pero cada syscall de cada contenedor golpea el mismo núcleo, lo cual está bien para tu propio código, pero no para el código generado por agentes arbitrarios. Y el otro extremo del espectro son las VMs completas, donde obtienes un aislamiento genuino. Pero viene con 100 MB de sobrecarga, tiempos de arranque en frío de cinco a 30 segundos, todo lo cual es realmente poco práctico a escala. Las Micro VMs son en realidad el punto medio, y en realidad no me gusta llamarlo un punto medio porque son realmente mejores que ambas direcciones diferentes. Vienen con una sobrecarga muy, muy ligera. Son extremadamente rápidas para comenzar. Tienen su propio núcleo por sandbox. Creo que la implementación más común es Firecracker, que fue construido por AWS para Lambda. Y está específicamente diseñado para este aislamiento a nivel de hardware sin la sobrecarga completa de una VM. Esta columna resaltada es idealmente lo que deseas usar para tus sandboxes. La tercera parte es la red. ¿Cómo encuentra el agente y el navegador el sandbox correcto? Veamos esta URL. El subdominio en esta URL en realidad contiene un par de cosas. Contiene un puerto. Contiene un token de sesión único. Pero aquí hay algo que en realidad apunta a una máquina específica, ¿verdad? Y eso es intencional porque no puedes preaprovisionar DNS por sandbox. No puedes simplemente asignar una IP estable. Así que cada vez que llega la solicitud, la máquina necesita ser resuelta por la plataforma.

Así que cada vez que llega la solicitud, la máquina necesita ser resuelta por la plataforma. Extrae la información relevante ya sea directamente desde aquí o a través de un mapa interno. Haz una búsqueda rápida y abre una conexión TCP a ella. Todo esto necesita suceder detrás de escena.

Y la segunda parte es que incluso después de que la solicitud llega a la máquina correcta, también quieres asegurarte de que se está conectando al puerto correcto. Y también está establecido de tal manera que, por ejemplo, nuevamente, los servidores de desarrollo, en realidad hacen recarga en caliente, lo que significa que hay una conexión WebSocket persistente y los cambios en realidad van y vienen todo el tiempo. Esto necesita funcionar consistentemente sin ninguna configuración adicional, ¿verdad?

Así que desde el punto de vista del desarrollador, solo queremos asegurarnos de que diga, está bien, expone el puerto 5173, y obtienes una URL de vuelta con todo configurado para ti. Y la última parte es la persistencia. Y creo que esto es en realidad lo más importante porque la persistencia no se trata solo de lo que necesitas almacenar y restaurar, sino también la forma en que piensas sobre la persistencia impacta los inicios en frío, ¿verdad? La razón es, o más bien, comencemos pensando en, bueno, ¿cuáles son las dos cosas que dominan los inicios en frío, verdad? Una parte de ello es la infraestructura en sí que necesita activarse.

¿Cuánto tiempo tarda en existir la VM? ¿Cuánto tiempo antes de que realmente puedas conectarte a ella? Esa es una parte de ello. Y la segunda es realmente la preparación de la aplicación, ¿verdad? Así que cuando un usuario entra, y están comenzando una sesión nueva o están continuando desde una sesión anterior, quieres que tu aplicación alcance el estado en el que tu agente pueda realmente inmediatamente continuar trabajando. Este es realmente el vacío que el desarrollador va a sentir porque aquí es donde las cosas pueden volverse realmente lentas. Y esta es la parte donde necesitas pensar, bien, ¿cómo optimizo esto? Hay algunas maneras. La más simple, fácil de ganar son las imágenes preconstruidas, ¿verdad? Así que puedes realmente construir una imagen, asegurarte de que tiene todas las bases de código, dependencias, todo lo que necesitas. También puedes tal vez seguir reconstruyéndola en segundo plano si las cosas siguen cambiando. Y esta es la imagen que realmente se coloca dentro de la VM. Así que eso es una cosa. La segunda es si realmente tienes necesidades un poco más dinámicas, tal vez no puedas siempre integrar todo en una imagen, entonces usas volúmenes persistentes. Así que puedes realmente montar estos volúmenes en estos diferentes contenedores efímeros. Y de esa manera, sabes, todos los datos sobreviven, reinicios también. Y podrías realmente tomar estos volúmenes y adjuntarlos a múltiples sandboxes también.

La tercera, que es realmente cuando las cosas comienzan a volverse muy poderosas, son los snapshots. Podrías potencialmente tomar o más bien, sabes, si la plataforma lo soporta, deberías realmente poder tomar todo el disco o incluso una parte de ese disco y hacer un snapshot. E incluso, sabes, hacer un snapshot del estado de la memoria en sí. Y lo que esto te permite hacer es que podrías realmente pausar una VM y simplemente reanudarla en el mismo punto exacto, y el agente puede realmente simplemente continuar trabajando en ella. O también podrías, sabes, hacer un snapshot de una instancia y comenzar múltiples sandboxes. Esto podría habilitar cosas como bifurcar el estado del agente y hacer que los agentes realmente, sabes, persigan diferentes opciones. Y finalmente, también podrías tener warm pools. De esta manera, sabes, incluso antes de que estés, si puedes predecir cuál es el estado de tu sandbox antes de que el agente necesite comenzar a trabajar en ella, puedes realmente simplemente mantener un pool y ponerlo en marcha. Y todos ellos tienen, sabes, un impacto bastante significativo en la cantidad de tiempo que toma antes de que el agente pueda realmente comenzar a trabajar. Estos números son solo ilustrativos, pero puedes imaginar por qué en cada paso realmente reduces drásticamente la cantidad de tiempo que toma para que tu aplicación esté lista. Y estas son cosas en las que pensar. Y, por supuesto, la forma en que optimizas también difiere, depende del tipo de caso de uso que estás cubriendo, ¿verdad? Así que, por ejemplo, los intérpretes de código están simplemente incrustados en interfaces de usuario de chat, y, sabes, el modelo está generando algún código. Inmediatamente quieres una respuesta. Tal vez quieras un warm pool. Agentes de codificación, sabes, tus usuarios esperan que estos agentes funcionen por un tiempo más largo. Así que, comienzas a pensar en ello de manera diferente. Entornos de entrenamiento de RL, estás pensando principalmente en rendimiento agregado y así sucesivamente. Así que, diferentes tipos de optimizaciones dependiendo del tipo de caso de uso que necesitas.

Y estos son todos los primitivos que las plataformas necesitan construir para que puedas aprovecharlo como realmente quieras. Entonces, cuando todo esto se hace correctamente, sabes, idealmente deberías poder simplemente decir, está bien, quiero simplemente reanudar una instancia anterior de algo en lo que estaba trabajando, y aquí vamos. El mismo estado en el que estábamos, podemos volver a él. Así que, veamos bajo el capó e intentemos entender, bueno, ¿cómo se ve esto desde tu punto de vista al usar algún sandbox? Así que, en realidad, todo este demo que acabamos de ver. En su forma más simple, es realmente solo, ya sabes, ocho líneas de código. Vamos a desglosarlo un poco.

El primero es el aislamiento. Así que, cada sesión obtiene su propia VM. Puedes pensar en, ya sabes, sandboxes separados por usuario, por organización. Hay todo tipo de cosas que podrías hacer. Y luego están todos los diferentes métodos que realmente te permiten iniciar procesos, esperar a que un proceso particular esté listo, leer y escribir archivos, ya sabes, cuando realmente quieras. Luego, la parte de networking de la que hablamos, todas las cosas que abordamos anteriormente en la sección de networking pueden ser realmente solo una línea. Obtienes una URL, y eso es todo lo que necesitas considerar. Y finalmente, quieres hacer algo de persistencia. En este demo, francamente, todo lo que estoy haciendo es solo almacenar mi código en un bucket, pero, ya sabes, también podrías optar por algunas de las estrategias más avanzadas dependiendo de los casos de uso como discutimos.

Así que, esto es lo que, al menos desde un contexto de Cloudflare donde trabajo, la forma en que se ve toda esta arquitectura puede pensarse como, ya sabes, solicitudes del agente y el navegador alcanzando el edge, el worker. Y desde allí, hay un objeto durable, que básicamente, lo más importante que ofrece en este contexto es que es globalmente direccionable de manera única, que es algo que queríamos. Queremos alcanzar un sandbox muy específico, ¿verdad? Así que, el objeto durable asegura que puedas hacer el enrutamiento, y luego puedes alcanzar el sandbox particular, y dentro del sandbox, haces todas las cosas que quieres hacer.