Google AX: Runtime déclaratif pour agents IA massifs
AX est le runtime d'orchestration d'agents open source à haut débit de Google, conçu pour exécuter des milliards de charges de travail d'agents autonomes en cluster. Il utilise des manifestes YAML déclaratifs pour définir les tâches, les espaces de travail, les passerelles et les modèles, en isolant le code des agents dans des bacs à sable avec un contrôle strict des sorties réseau et des quotas de ressources. Similaire à Kubernetes, une seule commande permet de déployer et de gérer le cycle de vie des agents, avec observation en temps réel, pause/reprise et débogage interactif. AX résout les défis fondamentaux de persistance d'état, d'isolation de sécurité et de contrôle des coûts pour les charges de travail d'agents, adapté à l'automatisation d'agents à grande échelle, reproductible et auditable comme la réparation de code, la recherche en plusieurs étapes ou les tâches CI. Son principal différenciateur est de traiter les agents comme des citoyens de première classe avec une exécution native en bac à sable et un cloisonnement réseau, plutôt que d'envelopper l'orchestration de conteneurs existante.
Contexte
L’émergence des agents autonomes pilotés par de grands modèles de langage (LLM) crée une nouvelle classe de charges de travail, fondamentalement différente des microservices sans état ou des traitements par lots. Ces agents accumulent un état au fil de raisonnements en plusieurs étapes, invoquent des API de modèles externes et des serveurs d’outils, et peuvent engendrer des coûts significatifs via des boucles décisionnelles itératives. Les plateformes d’orchestration de conteneurs existantes, comme Kubernetes, excellent dans la gestion des microservices, mais ne proposent pas de support natif pour l’isolation en bac à sable, le contrôle des sorties réseau et la persistance d’état qu’exigent les charges de travail agentiques. C’est dans ce contexte que Google a publié en open source AX, un runtime d’orchestration déclaratif conçu spécifiquement pour les agents. AX se positionne comme un « Kubernetes pour les agents », fonctionnant sur un « Agent Substrate » et visant l’exécution de milliards de tâches d’agents autonomes au sein d’un seul cluster. Hébergé sur GitHub, le projet a déjà recueilli près de 10 000 étoiles, témoignant d’un vif intérêt des développeurs pour une infrastructure agent normalisée.
AX traite les agents comme des citoyens de première classe, plutôt que de simplement envelopper l’orchestration de conteneurs existante. En fournissant un runtime dédié avec une exécution native en bac à sable et un cloisonnement réseau, il dépasse l’approche de scripts ad hoc pour évoluer vers une plateforme d’ingénierie. Sa philosophie de conception repose sur des manifestes YAML déclaratifs qui définissent chaque aspect de l’environnement d’exécution d’un agent, rendant le déploiement des agents aussi reproductible et auditable que celui des services conteneurisés.
Analyse approfondie
L’architecture d’AX s’articule autour de quatre primitives déclaratives : Task, Workspace, Gateway et Model. Une Task est la plus petite unité d’exécution, exécutant du code d’agent non fiable dans un bac à sable isolé, avec des limites strictes de CPU et de mémoire. Les Workspaces pré-montent des dépôts Git, des serveurs MCP et des packs de compétences, garantissant que chaque agent démarre dans un état « chaud » sans initialisation répétée. Les Gateways imposent des listes blanches d’hôtes explicites pour le trafic sortant, empêchant tout accès externe non autorisé et contrôlant à la fois les coûts et les risques de sécurité. La primitive Model configure le LLM utilisé par la plateforme elle-même, les informations d’identification étant injectées depuis les Secrets Kubernetes pour maintenir la séparation entre le code et les secrets. Toutes les primitives sont définies dans des manifestes YAML ax.io/v1alpha1 et déployées avec une seule commande ax apply -f.
Les commandes de gestion du cycle de vie rappellent l’expérience familière de Kubernetes : ax watch diffuse en temps réel les changements d’état des tâches, ax ssh permet aux développeurs d’entrer dans un bac à sable en cours d’exécution pour inspecter le système de fichiers ou les processus, et ax suspend/resume permettent la mise en pause basée sur des points de contrôle et la reprise transparente des agents de longue durée. Comparé à l’exécution de scripts d’agents directement dans des Pods Kubernetes, le bac à sable d’AX — fourni par l’Agent Substrate sous-jacent — offre une isolation plus stricte et des optimisations spécifiques aux agents, telles que la récupération des ressources pour les tâches suspendues et un cloisonnement réseau fin. Un exemple de flux de travail définit un workspace nommé « golang » qui clone une branche spécifique du dépôt source de Go, puis crée une tâche de test pour vérifier la chaîne d’outils et compiler à partir des sources. Un script demo.sh illustre le cycle de vie complet, de l’application à la suspension et à la reprise.
La prise en main nécessite un environnement Go, un cluster Kubernetes et l’outil de construction ko. Après avoir installé le CLI ax via go install, les développeurs déploient le plan de contrôle dans l’espace de noms ax-system à l’aide de make deploy, qui provisionne automatiquement Redis et construit les images nécessaires. Le projet en est encore à ses débuts ; la documentation officielle avertit que les concepts fondamentaux et les protocoles peuvent changer de manière significative et déconseille une utilisation en production. Malgré cela, l’accumulation rapide d’étoiles sur le dépôt reflète une communauté avide d’orchestration native pour les agents.
Impact sur l'industrie
AX normalise le déploiement et la gestion des charges de travail agentiques, réduisant considérablement la complexité opérationnelle liée à l’exécution de centaines ou de milliers d’agents en parallèle. Pour les équipes d’ingénierie d’entreprise, il pourrait devenir une pierre angulaire pour construire des pipelines d’agents fiables et auditables dans des scénarios tels que la réparation automatique de code, l’intégration continue et la recherche en plusieurs étapes. En offrant un modèle déclaratif, AX rend les tâches d’agents aussi gérables que des conteneurs, permettant aux équipes de versionner les configurations d’agents et d’appliquer des politiques de sécurité cohérentes sur des flottes d’agents.
L’interface de type Kubernetes abaisse la barrière d’adoption pour les équipes DevOps déjà familières avec kubectl. Cette familiarité, combinée au bac à sable natif et aux contrôles réseau, positionne AX comme un catalyseur potentiel pour faire passer les applications agentiques de prototypes expérimentaux à des systèmes de qualité production. Cependant, des risques importants subsistent : l’API est instable et peut subir des modifications cassantes fréquentes, et le projet dépend de l’Agent Substrate, lui-même en évolution, ce qui pourrait limiter la compatibilité de l’écosystème. De plus, l’industrie dans son ensemble n’a pas encore convergé vers des meilleures pratiques pour l’orchestration d’agents, et il n’est pas certain que le modèle déclaratif d’AX puisse s’adapter à des schémas complexes comme la collaboration multi-agents ou les flux de travail avec intervention humaine.
Perspectives
À mesure que les capacités des LLM progressent et que l’automatisation basée sur des agents se généralise, les runtimes qui prennent en charge nativement le cycle de vie complet des agents deviendront probablement des composants essentiels des écosystèmes cloud natifs. AX représente une étape précoce mais importante dans cette direction, offrant un aperçu de la manière dont l’infrastructure pourrait évoluer pour répondre aux exigences uniques des agents autonomes. Sa trajectoire dépendra d’un engagement soutenu de la communauté et de l’investissement continu de Google dans la couche Agent Substrate.
Les près de 10 000 étoiles sur GitHub indiquent un fort appétit pour un tel outil, mais la maturité de production reste un objectif lointain. À court terme, AX servira principalement de plateforme de recherche et d’expérimentation, permettant aux développeurs d’explorer l’orchestration d’agents à grande échelle pendant que les protocoles sous-jacents mûrissent. Pour les organisations qui planifient des charges de travail lourdes en agents, surveiller le développement d’AX — et potentiellement contribuer à sa base de code — sera une stratégie prudente. En fin de compte, le succès ou l’échec d’AX aidera à déterminer si les runtimes déclaratifs inspirés de Kubernetes deviennent la norme pour la prochaine génération d’infrastructure d’agents IA.