Agente serverless

Construir un Agente no es fácil.

Hace un año, necesitábamos gestionar el contexto y la memoria nosotros mismos, pensar en RAG y bases de datos vectoriales, y ajustar muy cuidadosamente la precisión del uso de herramientas. La aparición de Claude Code / Claude Agent SDK cambió todo esto. Cada vez más equipos están comenzando a construir directamente Agentes usando Claude Agent SDK + VM. ¿Se ha vuelto el problema más simple? No.

Ejecutar Claude Code en VMs sigue siendo algo muy desafiante.

1. Cada sesión de usuario necesita una VM independiente. En algunos escenarios, la capacidad de persistencia de las VMs puede ser útil, pero también hace que las VMs sean difíciles de actualizar y orquestar. Por ejemplo, desde la perspectiva del usuario, esperan que el software instalado en la VM todavía esté disponible meses después. Pero las partes de la VM que se comunican con la capa de orquestación también necesitan poder desplegar actualizaciones.

2. Crear y orquestar VMs a gran escala. Un único clúster de k8s soporta la orquestación para unos pocos miles de pods, lo cual es suficiente para clústeres de servicios de aplicaciones. Pero no es suficiente para escenarios donde cada sesión necesita iniciar un pod de claude code.

3. Usar soluciones de k8s enfrenta la latencia de k8s, lo que dificulta lograr un rendimiento de menos de 1 segundo.

4. Usar soluciones de e2b requiere hacer la persistencia uno mismo, y cargar/descargar archivos es muy lento.

5. La solución de e2b no puede satisfacer requisitos específicos del entorno de red, y el despliegue privado es engorroso.

¿Cómo resolvemos estos problemas? Aprendamos de la historia. Cuando el calendario retrocedía a hace más de una década, en 2012, no había serverless en el mundo, ni k8s, ni docker. Los ingenieros de backend necesitaban mantener manualmente un proceso de servicio en una máquina física para ejecutar un servicio. En ese momento, ssh y ansible eran herramientas estándar para los ingenieros de servidores. Los procesos de servicio dependían fuertemente de varios entornos de herramientas en la máquina física. Lograr configuraciones de entorno de herramientas consistentes en todas las máquinas físicas era muy desafiante, y la escalada a gran escala era una empresa importante para la que los equipos necesitaban prepararse con mucha antelación. Aún recuerdo cuando un ingeniero cambió el entorno de una máquina y olvidó sincronizarlo con los entornos de otras máquinas, causando un bug fantasma muy difícil de rastrear en producción. Ese período fue una época muy dolorosa.

En 2012, apareció Docker. Docker empaquetó todos los entornos de herramientas en una única imagen, resolviendo el problema de inconsistencia del entorno. La comunidad se fue dando cuenta gradualmente de que un proceso de servicio ejecutándose en una máquina virtual en una máquina física podría gestionarse como un proceso en la máquina física. Pero la orquestación de Docker aún requería que los equipos de ingeniería construyeran un sistema de orquestación. Y una vez que el proceso de servicio dentro de Docker se acoplaba con la red y el sistema de archivos de la máquina física, la orquestación se volvía algo muy doloroso.

En 2014, los servicios sin estado comenzaron a convertirse en la tendencia dominante. Ese año vio el nacimiento de Kubernetes y AWS Lambda. Cada uno describía el futuro de los servicios sin estado desde diferentes ángulos. Los servicios sin estado significaban que la lógica de servicio evitaba acoplarse con direcciones de red y ya no dependía localmente de sistemas de archivos persistentes.

Luego llegaron los 10 años de cloud native, la ola de servicios sin estado dio lugar a un gran lote de infraestructura cloud native, como:

• Gateways de servicio Istio/Linkerd/Envoy/Traefik
• Plataformas CI/CD Argo CD / Flux
• Plataformas de observabilidad Prometheus/Grafana/ELK Stack
• Análisis de cadena de llamadas Jaeger/Zipkin/OpenTelemetry
• Almacenamiento Rook/MinIO/JuiceFS

Y ahora estamos en un nuevo comienzo. Hace diez años, una unidad de cómputo era un proceso de servicio API de java/python. A partir de este año, esta unidad de cómputo se ha convertido en un agente de codificación.

ACFS es como la era de mantener manualmente procesos de servicio en máquinas físicas. E2B es como Docker. Sin plataformas de orquestación de tareas, plataformas de observabilidad y capacidades de almacenamiento de persistencia de estado distribuido, la escalabilidad sigue siendo algo difícil para los agentes de codificación. Y la Serverless Agent Infra que espero tiene estas capacidades:

1. Capaz de persistir apropiadamente las sesiones y directorios de trabajo del agente de codificación sin perder contexto.
2. Super rápido, capaz de poner en funcionamiento un agente de codificación en 100ms.
3. Tiene Logging / Metric / Tracing para el comportamiento del Agente que es fácil de entender para los humanos, lo que hace más fácil para los humanos entender y ajustar los patrones de comportamiento del Agente.
4. Los desarrolladores ya no necesitan preocuparse por detalles como máquinas virtuales, contenedores y otros detalles de ops, haciendo que la orquestación a gran escala sea muy fácil.

Creo que toda la infraestructura que puede cumplir con estas capacidades ya está lista, por ejemplo, Firecracker ha validado el rendimiento y la estabilidad de las microVMs, y también hay muchas opciones para plataformas de observabilidad distribuida y sistemas de almacenamiento de archivos. Pero como desarrollador que ha experimentado usar e2b para encapsular Claude Code, integrar todo esto sigue siendo muy difícil. Por ejemplo, cuando Claude Code en E2B es interrumpido inesperadamente por OOM, es difícil para los ingenieros monitorear esto, y aún más difícil obtener la escena y los registros de ese momento.

Espero que los desarrolladores después de 2026 no tengan que pasar por un proceso tan doloroso, igual que la mayoría de los ingenieros en 2026 ya no necesitan usar ssh para inicializar manualmente máquinas físicas.

Este es el sueño de VM0. Espero que algún día pueda conducir un agente de codificación a través de una API ergonómica, como:

const agent = vm0.run({
	framework: 'claude-code',
	prompt: 'buy me a coffee'
})