Flux complet d'une requête multi-agent

De la requête à la réponse

Entre le moment où vous envoyez votre requête et celui où la réponse s’affiche, il se passe beaucoup plus de choses qu’avec un appel classique à un LLM. Suivre ce trajet étape par étape vous servira le jour où il faudra interpréter une latence anormale, une réponse trop générale ou une facture de tokens surprenante.

Étape 1 : réception et analyse de la requête

Quand votre requête arrive au modèle grok-4.20-multi-agent-0309, le leader commence par l’analyser. Il détermine la nature de la tâche — recherche factuelle, analyse comparative, synthèse —, évalue le nombre de facettes à explorer, identifie les outils potentiellement nécessaires et arrête sa stratégie de délégation aux sub-agents.

Cette analyse initiale est transparente pour vous : elle fait partie du raisonnement chiffré du leader et n’apparaît nulle part dans la réponse. C’est aussi le moment où une formulation ambiguë fait le plus de dégâts, puisque toute la suite du travail découle de cette lecture initiale.

Étape 2 : lancement des sub-agents

Le leader délègue ensuite les sous-tâches. Chaque sub-agent reçoit une directive spécifique et se met au travail en parallèle des autres. Sur la requête portant sur les stratégies cloud européennes évoquée plus tôt, la répartition ressemblerait à ceci : un premier agent recherche les annonces récentes des fournisseurs, un deuxième analyse les aspects réglementaires (RGPD, AI Act), un troisième compare les grilles tarifaires et un quatrième examine la documentation technique.

Avec 16 agents, la décomposition devient plus fine et couvre davantage d’angles : chaque fournisseur peut se voir attribuer son propre chercheur, et les aspects réglementaires se scinder entre plusieurs juridictions.

Étape 3 : recherche et discussion

Les sub-agents ne travaillent pas en vase clos. Ils mobilisent les outils intégrés — web_search, x_search, code_execution et les autres —, échangent entre eux pour éviter les doublons et affiner leurs pistes, et signalent au leader les découvertes inattendues qui méritent une exploration supplémentaire. C’est cette conversation interne qui distingue le multi-agent d’un simple appel parallèle : un agent qui tombe sur une information contredisant celle d’un collègue peut faire réorienter la recherche.

C’est aussi la phase la plus longue et de loin la plus coûteuse, car chaque agent génère ses propres tokens d’entrée, de sortie et de raisonnement. Quand vous constatez qu’une requête dure une minute sans qu’aucun texte n’apparaisse, c’est ici qu’elle se trouve.

Étape 4 : synthèse par le leader

Une fois que les sub-agents ont terminé, ou que le budget de raisonnement est atteint, le leader reprend la main et déroule toujours la même séquence. Il collecte d’abord l’ensemble des résultats, puis élimine les redondances — sur la requête cloud, trois agents auront probablement remonté la même annonce de disponibilité régionale, et elle ne doit apparaître qu’une fois. Il structure ensuite l’information selon le format que vous avez demandé, cite les sources là où c’est pertinent, et produit enfin la réponse finale.

C’est là que se joue la qualité perçue du résultat : à recherche identique, vous obtiendrez un paragraphe fourre-tout ou un tableau comparatif lisible selon la précision avec laquelle vous avez décrit le livrable attendu.

Ce que vous recevez

La réponse comporte le texte rédigé par le leader — sa synthèse —, les appels d’outils effectués par l’ensemble des agents, leader compris, et, si vous avez activé use_encrypted_content=True, un bloc de contenu chiffré. Ces appels d’outils constituent votre unique fenêtre sur le travail réellement accompli en coulisses.

Le reste ne vous parvient jamais : ni le raisonnement interne des sub-agents en clair, ni les échanges qu’ils ont eus entre eux, ni le détail de la stratégie de délégation retenue par le leader. Inutile donc de bâtir un outil de supervision sur ces éléments — ils ne quittent pas le modèle.

Le streaming

En mode streaming, vous voyez la réponse du leader se construire progressivement. Le paramètre verbose_streaming va plus loin en vous transmettant aussi les appels d’outils au moment où ils se produisent, ce qui donne un aperçu direct de l’activité des agents.

L’intérêt est réel sur les requêtes longues : vous pouvez voir les recherches web se déclencher les unes après les autres pendant que les agents travaillent, et afficher à votre utilisateur autre chose qu’un indicateur de chargement immobile.

Implications sur la latence

Le multi-agent est inhéremment plus lent qu’un appel classique, et pour trois raisons cumulatives : les sub-agents travaillent certes en parallèle mais la coordination a un coût, le leader doit attendre l’ensemble des résultats avant de synthétiser, et la latence croît avec le nombre d’agents mobilisés.

Vous en tirerez une règle de conception simple. Pour un usage interactif — un chatbot, une barre de recherche —, restez à 4 agents. Réservez les 16 agents aux tâches asynchrones : un rapport généré en tâche de fond, une veille nocturne, une analyse dont l’utilisateur consultera le résultat plus tard.

Points clés à retenir

• Le flux suit 4 étapes : analyse → délégation → recherche → synthèse
• Les sub-agents travaillent en parallèle et échangent entre eux
• Vous ne recevez que la réponse du leader et les appels d’outils
• Le streaming avec verbose_streaming permet de suivre l’activité en temps réel
• La latence est plus élevée qu’un appel classique, surtout avec 16 agents