Comment construire un workflow multi-agent avec GPT-6 Astra

Les systèmes multi-agents sont utiles lorsqu'une tâche complexe contient des flux de travail indépendants pouvant s'exécuter en parallèle. Ils sont inefficaces lorsque chaque étape dépend de la précédente. La fonctionnalité multi-agent de l'API Responses de GPT-6 Astra permet à un agent racine de générer, de communiquer avec des sous-agents et d'attendre leurs résultats, puis de synthétiser leurs conclusions.

À la date de vérification, OpenAI documente Responses multi-agent comme une fonctionnalité bêta. Les guides de démarrage rapide JavaScript et Python utilisent le SDK Responses bêta ; les intégrations HTTP brutes et WebSocket envoient l'en-tête OpenAI-Beta: responses_multi_agent=v1. Les schémas d'éléments peuvent changer, donc isolez la gestion bêta derrière un adaptateur.

Choisissez un travail qui se décompose réellement

Les candidats solides incluent l'exploration de zones de codebase distinctes, la comparaison de documents, la recherche d'hypothèses indépendantes ou la mise en œuvre de suites de tests isolées. Les candidats faibles incluent un seul calcul ordonné, une petite tâche, un fichier partagé que chaque travailleur doit modifier, ou un appel externe lent qui domine le temps d'exécution.

Les sous-agents peuvent réduire le temps réel et les interférences de contexte, mais ils augmentent l'utilisation de tokens. Optimisez la latence et la qualité des tâches réussies, pas le nombre d'agents.

Responsabilités du root et du sous-agent

Définissez multi_agent.enabled pour que la racine devienne éligible à générer une arborescence de sous-agents. Les sous-agents partagent le modèle de la requête et les outils disponibles. La racine doit :

• définir les critères de résultat et de décomposition ;
• attribuer des tâches limitées et non chevauchantes ;
• passer le contexte minimum suffisant ;
• résoudre les conflits et les lacunes ;
• synthétiser une seule réponse finale responsable.

Un brief de sous-agent doit préciser le périmètre, le résultat attendu, les exigences en matière de preuves, les contraintes et la condition de complétion. « Rechercher les concurrents » est vague. « Comparer les prix publics et les fonctionnalités d’exportation de ces quatre produits nommés, citer les pages principales et signaler les inconnues » est testable.

Contrôle de l'état mutable partagé

Les agents parallèles ne doivent pas modifier le même enregistrement ou fichier sans coordination. Privilégiez une exploration en lecture seule suivie d'un commit unique appartenant à la racine. Pour le code, divisez par module et effectuez une passe d'intégration. Pour les systèmes métier, laissez les sous-agents proposer des actions tandis que la racine ou une transaction applicative effectue l'écriture.

Dans un pipeline créatif, des agents distincts peuvent examiner la continuité du script, la cohérence des personnages et les exigences audio, la racine produisant un seul brief de production pour Elser AI. Ils ne devraient pas réécrire indépendamment le même storyboard.

Budgétiser l'arbre

Définissez les limites de l'application pour la profondeur, les agents simultanés, le nombre total de jetons, les appels d'outils, le temps écoulé et les tentatives. Les directives officielles notent que les sous-agents peuvent augmenter l'utilisation des jetons. Un arbre borné empêche également que la délégation récursive ne devienne un déni de service accidentel.

Donnez à la racine une instruction explicite sur le moment où la délégation est autorisée. Si le workflow nécessite une orchestration prévisible, implémentez le graphe dans votre application plutôt que de demander au modèle de l'inventer.

La synthèse est une tâche distincte

Ne concaténez pas les sorties des sous-agents. Demandez à la racine de comparer les affirmations, vérifier les citations, identifier les désaccords et indiquer quelles preuves l'emportent. Préservez la provenance via des identifiants de source ou des champs de résultat structurés.

Un contrat de synthèse peut exiger :

• constats partagés par tous les groupes de travail ;
• les désaccords et leurs causes ;
• preuve manquante ;
• action recommandée et niveau de confiance ;
• quel sous-agent/source soutient chaque affirmation conséquente.

Si deux agents dépendent de la même source erronée, un consensus apparent n'est pas une confirmation indépendante.

Sécurité et approbations

Les sous-agents héritent des outils disponibles, donc gardez le catalogue restreint. L'autorisation côté serveur s'applique à chaque appel, quel que soit l'agent qui l'a demandé. Exigez une approbation pour les actions conséquentes et identifiez l'action réelle, et non simplement le nom du sous-agent.

Traitez les messages entre agents comme un contenu de modèle non fiable. Validez les résultats structurés et évitez de transmettre des secrets, sauf si la tâche l'exige. Un agent racine ne peut pas « superviser » en toute sécurité des autorisations que l'application ne parvient pas à appliquer.

Évaluer le workflow

Comparez un système multi-agent par rapport à une référence mono-agent sur le même ensemble de test. Mesurez la qualité des réponses, la couverture, la latence, les jetons, les appels d'outils, le travail en double, le taux de conflit et les échecs d'intégration. Injectez des défaillances : un sous-agent lent, un résultat erroné, une panne d'outil et un agent qui ne revient jamais.

N'adoptez le multi-agent que lorsque le gain justifie la complexité d'orchestration. Un arbre d'agents plus petit avec des briefs plus clairs surpasse souvent un grand comité.

Modèle de référence : recherche parallèle, décision en série

Considère une évaluation de migration. La racine crée trois flux de travail délimités : un agent inventorie l'utilisation des API, un autre examine les implications de sécurité, et un troisième estime le coût opérationnel. Tous les trois sont en lecture seule et renvoient un schéma commun : constats, preuves, incertitude et actions recommandées. La racine attend, identifie les conflits et rédige un plan. Ce n'est qu'après l'approbation humaine que le code applicatif crée des tickets.

Ce modèle fonctionne car l'exploration est indépendante tandis que la décision et la mutation restent séquentielles. Il donne également à la racine une chance de remarquer des preuves dupliquées. Si chaque agent cite la même page obsolète, la synthèse doit signaler la dépendance partagée au lieu de compter trois votes.

Définissez une politique de délai d'attente avant l'exécution. Le root doit pouvoir terminer avec deux des trois rapports tout en nommant explicitement le flux de travail manquant, ou annuler l'exécution lorsque ce flux est obligatoire. Évitez les cycles d'attente interminables. Stockez les identifiants des sous-agents et les états terminaux afin qu'un opérateur puisse diagnostiquer la branche lente sans lire l'intégralité du transcript.

Pour les décisions réglementées, exiger que le root cite des identifiants de preuves structurés plutôt qu’un simple souvenir libre. L’action finale doit être traçable jusqu’à la source, au résultat de l’agent, à la synthèse du root et à l’approbation humaine.

FAQ

Est-ce que GPT-6 Astra multi-agent est généralement disponible ?

Le guide officiel qualifie la fonctionnalité multi-agents de Responses de version bêta à compter du 7 septembre 2026. Consultez la page du modèle et le guide avant le déploiement.

Les sous-agents utilisent-ils des modèles différents ?

La fonctionnalité documentée indique que les sous-agents partagent le modèle de la requête et les outils disponibles.

Est-ce que le multi-agent est toujours plus rapide ?

Non. La coordination et la synthèse ajoutent des frais généraux, et une dépendance lente peut dominer l'exécution.

Quand l'orchestration doit-elle rester dans le code de l'application ?

Lorsque le graphe doit être déterministe, les étapes sont ordonnées, les écritures partagent un état mutable, ou la conformité exige des transitions explicites.

Conclusion

Un bon workflow multi-agent GPT-6 Astra est un système de décomposition contrôlé : briefs indépendants, contextes délimités, outils minimaux, pas d'écritures partagées non contrôlées, et une synthèse rigoureuse. Commencez par une base d'agent unique, n'ajoutez du parallélisme que là où le travail se sépare réellement, et traitez les schémas bêta ainsi qu'une consommation de jetons plus élevée comme des contraintes opérationnelles.