Lorsque nous avons lancé les agents cloud il y a un an, ils nous semblaient être un prolongement assez naturel des agents locaux. Depuis, les capacités des agents cloud se sont considérablement élargies.

Les agents cloud s’exécutent désormais sur leurs propres machines virtuelles dédiées, avec leurs propres environnements, dépendances et accès réseau. Ils peuvent travailler en parallèle, s’exécuter sans supervision et prendre en charge des tâches plus longues qu’un agent local exécuté sur votre ordinateur portable.

Ces capacités introduisent des défis en matière d’installation de l’environnement, de fiabilité et d’orchestration, qui sont moins marqués lorsqu’un agent s’exécute sur votre ordinateur portable.

Dans cet article, nous voulons partager les principaux enseignements que nous avons tirés du développement des agents cloud, et expliquer pourquoi ce travail ressemble de moins en moins à l’adaptation d’un agent local sur un serveur et de plus en plus à la création d’une couche d’exécution autour de lui.

#L’environnement de développement est le produit

Au cours de l’année écoulée, nous avons appris que le principal facteur de qualité des résultats d’un agent cloud est de veiller à ce qu’il dispose d’un environnement de développement complet, comme un développeur.

C’est quelque chose auquel on pense généralement moins en local, car les agents locaux héritent gratuitement de votre environnement de développement déjà opérationnel sur votre ordinateur portable. Dans le cloud, il faut tout reconstruire de zéro, et il est étonnamment difficile de savoir quand ce n’est pas parfaitement fait.

Au lieu d’un plantage ou d’un message d’erreur, le seul signe est souvent une légère dégradation de la qualité des résultats. Vous ne le remarquerez peut-être pas au début, ou, si vous le remarquez, vous l’attribuerez peut-être au modèle.

Mais, encore et encore, nous en sommes revenus au même diagnostic : l’agent cloud ne dispose pas de l’environnement dont il a besoin pour exécuter ou vérifier son travail. Il y a un an, cela avait moins d’importance, car les modèles ne savaient pas vraiment tirer parti de leur environnement. Mais à mesure qu’ils sont devenus plus intelligents, la configuration de l’environnement est devenue le facteur déterminant pour savoir s’ils peuvent exploiter tout leur potentiel.

Aujourd’hui, parvenir à un « environnement complet » exige de reconstruire une quantité surprenante d’infrastructure :

• De meilleurs outils pour permettre aux utilisateurs de créer l’environnement de l’agent
• Des méthodes pour mettre en veille prolongée et relancer efficacement les VM d’agent entre les messages
• Des pipelines pour créer rapidement et durablement des checkpoints, restaurer et cloner des images de VM
• Des intégrations étroites avec le harness et le client, afin que les agents comme les humains puissent comprendre l’environnement et interagir avec lui

Et à mesure que les agents cloud prennent en charge davantage de travail, ils ont besoin d’un accès réseau contrôlé pour créer des PR, récupérer des dépendances et effectuer des recherches. Au fil du temps, nous avons fini par créer ce qui s’apparente à une véritable informatique d’entreprise pour les agents, avec masquage des secrets, politiques réseau et gestion des identifiants.

#Les agents de longue durée ont besoin d’une exécution durable

Les agents cloud posent un défi de fiabilité d’un autre ordre que les agents locaux. Au lieu de se disputer les ressources de votre ordinateur portable, les agents cloud s’exécutent dans leurs propres VM isolées. Les développeurs peuvent ainsi plus facilement exécuter de nombreux agents en parallèle et leur déléguer des tâches de longue durée qui prennent souvent des heures plutôt que des minutes.

Mais l’exécution dans une VM les expose aussi à des perturbations comme des pannes chez le fournisseur d’inférence, le remplacement de pods ou l’indisponibilité de nœuds EC2.

Nous avons commencé à créer des agents cloud avec une architecture de work stealing, dans laquelle les nœuds workers pouvaient prendre en charge des agents et exécuter leur boucle jusqu’au bout. C’était une transposition sur serveur de ce qui fonctionne en local, mais l’ensemble restait fragile : notre première bêta des agents cloud plafonnait souvent à un seul 9 de fiabilité.

À mesure que les agents cloud ont gagné en maturité, nous nous sommes retrouvés à deux doigts de recréer une grande partie des primitives d’exécution durable que Temporal gère déjà (par ex. les mécanismes de nouvelle tentative, l’ordonnancement du travail entre machines, la résilience aux pannes de nœuds). Nous avons donc choisi d’y migrer à la place.

Notre boucle de l’agent actuelle sur Temporal peut survivre à de brèves baisses de fiabilité de l’inférence, à l’hibernation et à la reprise des pods, ainsi qu’à des exécutions qui s’étendent sur plusieurs jours, voire plusieurs semaines. À elle seule, cette migration nous a fait dépasser les deux 9 de fiabilité et, aujourd’hui, Temporal gère plus de 50 millions d’actions par jour sur plus de 7 millions de workflows uniques. En interne, plus de 40 % de nos PR proviennent des agents cloud, et ce chiffre continue d’augmenter.

Au fil du temps, nous avons appris à mieux concevoir nos workflows Temporal. Nous sommes passés de workflows d’agent « éternels » à plusieurs workflows plus courts qui se terminent après une seule tâche, ce qui facilite les mises à niveau de version. Nous avons aussi isolé les activités pour mieux prendre en compte les timeouts et les nouvelles tentatives, à mesure que les appels d’outils asynchrones, les sous-agents et les pannes du fournisseur d’inférence faisaient évoluer nos hypothèses de départ.

#Découpler les agents et les machines de l’état de la conversation

Un agent cloud n’est plus simplement une boucle unique exécutée sur une seule machine. Au lieu de cela, un agent peut s’exécuter sur une machine, lancer des sous-agents asynchrones sur plusieurs autres, ou démarrer en local puis déléguer une partie du travail au cloud. Un sous-agent peut même survivre à son parent, ou s’exécuter sur un type de pod complètement différent.

Pour rendre cela possible, nous avons constaté qu’il était utile de traiter la boucle de l’agent, l’état de la machine et l’état de la conversation comme des composants découplés. Comme la boucle de l’agent s’exécute dans Temporal plutôt que sur la VM elle-même, nous pouvons gérer le cycle de vie des pods indépendamment et exécuter des agents sur différents types de pods — avec, par exemple, des optimisations comme des VM en lecture seule ou des VM préchauffées.

Côté conversation, nous avons séparé la couche de stockage et de streaming du workflow principal de l’agent. Nous avons construit un mécanisme de stockage append-only efficace, qui diffuse en streaming les mises à jour de la conversation vers les clients web et desktop. Cette couche gère les nouvelles tentatives, de sorte que si une étape de la boucle de l’agent échoue après avoir diffusé une sortie partielle puis est relancée, le client peut le détecter, revenir en arrière dans le flux et afficher les nouvelles données au lieu des anciennes.

#Savoir s’effacer

Créer une harness d’agents cloud implique de réévaluer en permanence ce qui relève d’un comportement déterministe et ce qui est laissé à l’agent.

Au début, nous ne faisions pas beaucoup confiance à l’agent, donc la harness revérifiait son travail après chaque tâche, imposait un commit, puis faisait un push. À mesure que les modèles sont devenus plus intelligents, nous avons commencé à déplacer la logique hors de la harness, vers des outils contrôlés par l’agent. Il y a un an, les configurations multi-repo nécessitaient un comportement de harness codé en dur. Aujourd’hui, nous pouvons donner à l’agent la structure du dépôt, exposer des outils pour les branches et les PR, et le laisser décider comment faire le travail.

La même évolution s’est produite avec CI Autofix : les premières versions de notre harness d’agents cloud contenaient une logique pour récupérer les journaux d’échec des jobs et les écrire dans la VM. Désormais, nous donnons simplement à l’agent accès à GitHub CLI et écrivons automatiquement les sorties volumineuses dans des fichiers qu’il peut parcourir. Le message envoyé à l’agent est devenu bien plus simple, et nous nous attendons à ce que cette tendance se poursuive.

La harness ne disparaît pas ; c’est surtout ce qu’elle contient qui change. L’usage de l’ordinateur en est un bon exemple aujourd’hui. Notre harness d’agents cloud dispose d’un type de sous-agent dédié à l’usage de l’ordinateur, avec son propre routage de modèle, des instructions personnalisées et un enregistrement d’écran. Le VNC et Chrome appartiennent à l’environnement, qui est partagé entre l’agent parent et le sous-agent. Cela permet à l’agent parent de les utiliser directement, par exemple en exécutant un script Playwright. Nous utilisons cette structure parce que les modèles ne sont pas encore tout à fait prêts à gérer seuls l’usage de l’ordinateur, mais l’agent garde le contrôle du moment où il y fait appel.

Les agents cloud ont aussi besoin, dans la harness, de types de requêtes différents de ceux des agents locaux. Nous les encourageons à être plus autonomes, car le coût d’un blocage est bien plus élevé. En local, vous savez quand un agent s’est arrêté et attend une autorisation, mais dans le cloud, il peut rester ainsi pendant des heures avant que vous ne reveniez vérifier où il en est.

#Environnements auto-réparateurs pour les agents

Pour la suite, nous voulons dépasser l’alternative binaire entre tenir l’agent par la main et le laisser agir sans intervention. Une meilleure approche consiste à donner à l’agent des outils pour comprendre le système qui l’entoure.

Nous voulons que les agents cloud puissent signaler l’absence de secrets, le blocage de l’accès réseau, ou plus généralement les situations où leur environnement les empêche d’avancer, puis qu’ils puissent réagir de manière auto-réparatrice. Dans un récent article de blog de recherche, nous avons présenté une approche pour atteindre cet objectif, que nous appelons « autoinstall ».

Les agents cloud ont énormément progressé ces derniers mois, et nous nous attendons à ce que le rythme de cette évolution ne fasse que s’accélérer. Les agents cloud de Cursor permettent aux équipes de tirer parti de ce large champ de possibilités sans avoir à créer ni à maintenir l’infrastructure sous-jacente.