Conception d'une équipe d'agents : Comment Google Antigravity structure les sous-agents pour la génération autonome de code

Google Antigravity détaille l'architecture de son équipe d'agents
Google Antigravity a publié des détails sur la façon dont il organise une équipe d'agents autonomes pour créer des logiciels. Plutôt qu'un seul agent gérant tout, le système utilise sept types de sous-agents spécialisés, chacun avec des objectifs et des contraintes ciblés. Ce modèle est pertinent pour OpenClaw alors qu'il conçoit son propre système de sous-agents.
Points clés : Les sept rôles d'agents
Le billet de blog identifie les types d'agents suivants :
- Le Sentinel — Agit comme le « gestionnaire d'accueil ». N'écrit pas de code, n'analyse pas les journaux ni ne prend de décisions techniques. Son rôle : structurer l'intention de l'utilisateur, lancer l'Orchestrator et superviser l'achèvement global de la tâche.
- L'Orchestrator — Un gestionnaire exclusivement de répartition. N'écrit jamais de code ni n'exécute de builds. Se concentre sur la décomposition des exigences en jalons, le lancement d'autres sous-agents spécialisés et la synthèse de rapports.
- L'Explorer — Analyse les exigences et les journaux précédents pour rédiger des stratégies formelles à l'intention de l'Orchestrator. N'écrit jamais de code lui-même.
- Le Worker — Le véritable codeur qui implémente les stratégies, construit le code et exécute les tests.
- Le Reviewer — Examine indépendamment les modifications du Worker pour vérifier la correction de la conception, les cas limites et la conformité au contrat d'interface.
- Le Critic — Teste la solution sous stress, exécute des tests adverses pour trouver des lacunes dans la couverture.
- L'Auditor — Un enquêteur indépendant qui vérifie l'authenticité et la robustesse des solutions générées.
Cette conception assure une séparation des préoccupations : chaque agent a un rôle étroit, réduisant les chevauchements et permettant un travail parallèle. L'Orchestrator et l'Explorer sont de purs planificateurs ; le Worker est purement exécutif ; le Reviewer, le Critic et l'Auditor fournissent trois niveaux distincts de validation.
À qui cela s'adresse
Développeurs construisant des systèmes multi-agents pour la génération de code, en particulier les équipes travaillant sur le framework de sous-agents d'OpenClaw.
📖 Lire la source complète : r/openclaw
👀 See Also

Analyse du sentiment anti-IA et de l'effet de la vallée dérangeante
Des enquêtes récentes montrent un scepticisme croissant du public envers l'IA, avec 55 % des Américains en mars 2026 estimant que l'IA fera plus de mal que de bien dans la vie quotidienne. L'article explore comment l'IA déclenche des réactions de vallée de l'étrange à travers des attentes sociales décalées.

Waymo lance des opérations entièrement autonomes avec son conducteur de 6ᵉ génération
Le conducteur de 6e génération de Waymo commence ses opérations entièrement autonomes, avec une suite de détection multimodale et des imageurs nouvelle génération de 17 mégapixels.

Devenir ingénieur IA à plein temps : ne plus toucher au code
Max Heyer décrit un workflow où les agents écrivent tout le code, lui se contente de lire les diffs, rédiger les spécifications et faire la relecture. La compétence qui compte est le goût — évaluer le code est plus difficile que le produire.

Le Composer 2.0 de Cursor semble utiliser le modèle Kimi 2.5, selon les preuves fournies par les points de terminaison d'API.
L'analyse du réseau montre que le Composer 2.0 de Cursor envoie des requêtes à un point de terminaison contenant 'kimi-k2p5-rl-0317-s515-fast', suggérant qu'il est basé sur Kimi 2.5. La licence MIT modifiée exigerait une attribution mais peu d'autres obligations.