Agent serverless

Construire un Agent n'est pas chose facile.

Il y a un an, nous devions gérer nous-mêmes le contexte et la mémoire, réfléchir au RAG et aux bases de données vectorielles, et ajuster très soigneusement la précision de l'utilisation des outils. L'apparition de Claude Code / Claude Agent SDK a changé tout cela. Aujourd'hui, de plus en plus d'équipes commencent à construire directement des Agents avec Claude Agent SDK + VM. Le problème est-il donc devenu plus simple ? Non.

Exécuter Claude Code dans des VM reste une tâche très difficile.

1. Chaque session utilisateur nécessite une VM indépendante. Dans certains scénarios, la capacité de persistance des VM peut être utile, mais elle rend aussi les VM difficiles à mettre à niveau et à orchestrer. Par exemple, du point de vue de l'utilisateur, celui-ci espère que les logiciels installés sur la VM seront toujours disponibles des mois plus tard. Mais les composants de la VM qui communiquent avec la couche d'orchestration doivent eux aussi pouvoir déployer des mises à niveau.

2. Créer et orchestrer des VM à grande échelle. Un seul cluster k8s prend en charge l'orchestration d'environ quelques milliers de pods, ce qui est suffisant pour des clusters de services applicatifs. Mais ce n'est pas tout à fait suffisant pour des scénarios où chaque session doit démarrer un pod claude code.

3. L'utilisation de solutions k8s se heurte à la latence induite par k8s, ce qui rend difficile d'atteindre des performances en moins d'une seconde.

4. L'utilisation de solutions e2b oblige à gérer soi-même la persistance, et le téléversement comme le téléchargement de fichiers sont très lents.

5. La solution e2b ne peut pas répondre à des exigences spécifiques d'environnement réseau, et le déploiement privé est fastidieux.

Comment résoudre ces problèmes ? Tirons les leçons de l'histoire. Lorsque le calendrier nous ramène à plus d'une décennie en arrière, en 2012, il n'y avait pas de serverless dans le monde, pas de k8s, et pas de docker. Les ingénieurs back-end devaient maintenir manuellement un processus de service sur une machine physique pour faire tourner un service. À l'époque, ssh et ansible étaient les outils standards des ingénieurs serveur. Les processus de service dépendaient fortement des divers environnements d'outils présents sur la machine physique. Obtenir des configurations d'environnement d'outils cohérentes entre les machines physiques était très difficile, et la mise à l'échelle à grande échelle était un chantier majeur que les équipes devaient préparer longtemps à l'avance. Je me souviens encore d'un ingénieur qui avait modifié l'environnement d'une machine et oublié de le synchroniser avec l'environnement des autres machines, provoquant un bug fantôme très difficile à diagnostiquer en production. Cette période était un vieux temps très douloureux.

En 2012, docker est apparu. Docker a empaqueté tous les environnements d'outils dans une seule image, résolvant le problème d'incohérence des environnements. La communauté a peu à peu compris qu'un processus de service tournant dans une machine virtuelle sur une machine physique pouvait être géré comme un processus sur la machine physique. Mais l'orchestration de docker nécessitait toujours que les équipes d'ingénierie construisent un système d'orchestration. Et dès que le processus de service à l'intérieur de docker devenait couplé au réseau et au système de fichiers de la machine physique, l'orchestration devenait une chose très douloureuse.

En 2014, les services sans état ont commencé à devenir la tendance dominante. Cette année-là a vu naître Kubernetes et AWS Lambda. Chacun a décrit, sous un angle différent, l'avenir des services sans état. Les services sans état signifiaient que la logique de service évitait le couplage avec les adresses réseau et ne dépendait plus localement de systèmes de fichiers persistants.

Puis sont venues les 10 années du cloud native ; la vague des services sans état a donné naissance à une grande quantité d'infrastructures cloud native, telles que :

• Les passerelles de service Istio/Linkerd/Envoy/Treafik
• Les plateformes CI/CD Argo CD / Flux
• Les plateformes d'observabilité Prometheus/Grafana/ELK Stack
• L'analyse des chaînes d'appels Jaeger/Zipkin/OpenTelemetry
• Le stockage Rook/MinIO/JuiceFS

Et nous voici à un nouveau commencement. Il y a dix ans, une unité de calcul était un processus de service api java/python. À partir de cette année, cette unité de calcul est devenue un agent de codage.

ACFS ressemble à l'époque de la maintenance manuelle des processus de service sur les machines physiques. E2B ressemble à Docker. Sans plateformes d'orchestration de tâches, sans plateformes d'observabilité et sans capacités de stockage distribué de l'état persistant, la scalabilité reste difficile pour les agents de codage. Et l'Infra d'Agent Serverless que j'attends possède ces capacités :

1. Capable de persister de manière appropriée les sessions et les répertoires de travail de l'agent de codage sans perdre le contexte.
2. Ultra rapide, capable de mettre un agent de codage au travail en moins de 100 ms.
3. Dotée d'un Logging / Metric / Tracing du comportement de l'Agent facile à comprendre pour les humains, ce qui permet de mieux saisir et d'ajuster les schémas de comportement de l'Agent.
4. Les développeurs n'ont plus à se soucier de détails comme les machines virtuelles, les conteneurs et autres détails d'exploitation, ce qui rend l'orchestration à grande échelle très facile.

Je pense que toute l'infrastructure capable de répondre à ces exigences est déjà prête : par exemple, firecracker a validé les performances et la stabilité des microVM, et il existe aussi de nombreux choix de plateformes d'observabilité distribuée et de systèmes de stockage de fichiers. Mais en tant que développeur ayant fait l'expérience de l'encapsulation de claude code avec e2b, intégrer tout cela ensemble reste très difficile. Par exemple, lorsque claude code dans E2B est interrompu de manière inattendue par un OOM, il est difficile pour les ingénieurs de le surveiller, et encore plus difficile d'obtenir la scène et les logs de ce moment-là.

J'espère que les développeurs après 2026 n'auront pas à traverser un processus aussi douloureux, tout comme la plupart des ingénieurs en 2026 n'ont plus besoin d'utiliser ssh pour initialiser manuellement des machines physiques.

C'est le rêve de VM0. J'espère qu'un jour je pourrai piloter un agent de codage via une API ergonomique, comme ceci :

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