Cinq motifs pour orchestrer plusieurs agents

Un agent unique a un plafond : sa portée est fixée par ses instructions ou par la demande qu'il reçoit. Quand la tâche est grande ou traverse plusieurs domaines, il faut répartir le travail entre des spécialistes qui collaborent. Microsoft Agent Framework, le SDK open source de Microsoft (la boîte à outils de bibliothèques avec laquelle on programme contre un service), apporte les composants pour cela et cinq motifs d'orchestration déjà construits. Le module « Orchestrate a multi-agent solution with Microsoft Agent Framework » les parcourt tous. Je les parcours dans ce post : pourquoi le multi-agent, de quoi se composent les workflows, à quoi ressemble le flux de développement unifié et ce que fait chaque motif, avec ses exemples.

Pourquoi le multi-agent

L'orchestration multi-agent répartit compétences et perspectives entre les agents, et combine leurs sorties pour mieux décider. Elle enchaîne des étapes où chaque agent s'appuie sur le précédent, et route le contrôle selon le contexte. La liste des tâches candidates est celle d'usage : celles qui sont grandes d'emblée ou qui traversent plusieurs domaines.

Un exemple le rend concret : un système DevOps à quatre agents. Un de supervision, un de cause racine, un de déploiement automatisé et un de rapports. Quatre responsabilités séparées : surveiller, diagnostiquer, agir et documenter. Chacun fait le sien, et le résultat vaut plus que la somme des réponses séparées. Et les responsabilités ne se chevauchent pas : l'agent de supervision ne diagnostique pas et celui de rapports ne déploie pas. Le post précédent décrivait les pièces de Microsoft Agent Framework ; celui-ci traite de la façon dont elles se coordonnent. C'est la même idée de la cuisine avec des postes : un cuisinier peut tout faire, mais quatre faisant chacun le sien sortent plus vite et avec moins d'erreurs.

Les composants

Avant les motifs, les pièces. Mieux vaut les avoir à portée de main : les cinq motifs se construisent seulement avec celles-ci.

Des agents qui raisonnent avec un LLM (modèle de langage, le modèle qui converse et rédige), utilisent des outils et tiennent l'historique.
Des clients de chat qui abstraient le fournisseur (Azure OpenAI, OpenAI, Anthropic) derrière une interface commune. Vous changez de fournisseur et le reste du code tient debout.
AgentSession, qui maintient l'historique avec des rôles de message : USER, ASSISTANT, SYSTEM et TOOL. Le rôle TOOL est celui qui journalise les appels d'outils : l'agent demande, l'outil répond, et cela reste comme n'importe quel autre message de la conversation.
Des outils, personnalisés et intégrés.

Sur ces pièces se construisent les workflows : des séquences structurées d'étapes, avec trois composants à avoir clairs :

Les exécutants : les travailleurs. Ils peuvent être des agents IA ou de la logique personnalisée. Un exécutant n'est pas nécessairement un agent IA : la différence est le rôle qu'il joue dans le flux.
Les bords : définissent comment les messages circulent. Il y a directs, conditionnels, switch-case (chaque réponse choisit une branche différente), fan-out et fan-in (envoyer la même chose à plusieurs d'un coup et rassembler à nouveau leurs sorties).
Les événements : intégrés, exposent progression et erreurs pour déboguer et mesurer la performance. Les noms concrets : WorkflowStartedEvent, WorkflowOutputEvent, WorkflowErrorEvent, ExecutorInvokeEvent, ExecutorCompleteEvent et RequestInfoEvent.

Le flux de développement unifié

Les cinq motifs partagent le même workflow d'orchestration, dans cet ordre :

Définir les agents et décrire leurs fonctionnalités. C'est la première étape de la séquence.
Sélectionner et créer le motif, avec un agent gestionnaire si besoin.
Ajouter des callbacks (des points de code qui s'exécutent à des moments du flux) ou des transformations optionnelles.
Démarrer l'environnement d'exécution.
Invoquer l'orchestration avec la tâche.
Récupérer les résultats sans blocage. Récupérer sans blocage signifie que votre programme ne reste pas à attendre : l'orchestration tourne de son côté et le résultat arrive quand il arrive.

La conséquence qui compte : comme tous les motifs partagent l'API (la même porte d'entrée pour votre code), vous pouvez comparer des stratégies sans réécrire les agents. Vous changez l'orchestration, pas les spécialistes. C'est la séquence qu'un chef de projet suivrait : d'abord définir qui ils sont, ensuite choisir comment ils se coordonnent, et seulement à la fin exécuter. Et la dernière étape est asynchrone : les résultats sont récupérés sans bloquer. L'orchestration tourne pendant que votre programme continue.

Motif 1 : Concurrent

Plusieurs agents travaillent sur la même tâche en même temps, indépendamment, et leurs sorties sont recueillies séparément. Sert pour le brainstorming, le raisonnement d'ensemble et le vote. Et sa contre-indication se déduit de la même exigence : si les tâches ne sont pas indépendantes, le parallèle ne s'applique pas. En clair : c'est le tour où tous donnent leur avis à la fois et ensuite les idées se rassemblent.

L'exemple avec ConcurrentBuilder est mécanique : vous configurez un client de chat (par ex. AzureOpenAIChatClient), créez les agents avec create_agent, les passez avec participants(), construisez avec build(), exécutez avec run() et extrayez les sorties avec get_outputs(). Chaque message ajouté porte le nom de l'auteur, ainsi vous savez quel agent a répondu quoi. Si vous voulez du concret : quatre agents avisant sur la même décision et les quatre réponses enregistrées, signature comprise.

Motif 2 : Sequential

Un pipeline fixe : la sortie d'un agent est l'entrée du suivant. C'est le plus simple des cinq : une rangée d'étapes sans décisions en chemin. C'est celui que vous choisissez quand le fonctionne déjà et que vous voulez seulement qu'il s'exécute de la même façon à chaque fois ; quand chaque étape s'appuie sur la précédente, il n'y a rien à coordonner.

Motif 3 : Handoff

Dans le motif de la transmission, le contrôle se transfère dynamiquement entre agents selon le contexte. Chaque agent peut céder la conversation à celui qui a l'expertise adéquate : comme un appel transféré dans un cabinet, celui qui ne peut pas répondre le passe à qui peut. Ils travaillent un à la fois, et le routage se décide par résultats de classification.

L'exemple utilise WorkflowBuilder avec un groupe switch-case. Les réponses des agents sont modélisées avec Pydantic (la bibliothèque Python avec laquelle on valide des structures de données) pour renvoyer du JSON structuré. Ensuite on crée des exécutants d'entrée, de transformation et un contrôleur par type de classification ; le switch route selon le résultat. Il y a toujours un cas par défaut de secours, pour qu'une classification hors schéma ne laisse pas le flux sans chemin.

Motif 4 : Group Chat

Une conversation partagée administrée par un chat manager qui décide qui parle. Le gestionnaire ne résout pas : il distribue les tours. C'est la différence entre une réunion avec ordre du jour et un chat sans propriétaire. Le GroupChatManager prend quatre décisions à chaque tour : s'il demander l'entrée humaine (should_request_user_input), s'il terminer (should_terminate), comment filtrer ou résumer la conversation (filter_results) et qui parle ensuite (select_next_agent).

Étendre cette classe de base implémente le motif maker-checker : un agent créateur propose et un agent réviseur critique jusqu'à ce que le résultat soit acceptable. C'est le cycle d'un bon revue entre pairs : l'un livre, l'autre met le bémol, et cela se répète jusqu'à ce que le texte passe.

Les scénarios où il brille : brainstorming, décision par débat et consensus, contrôle qualité avec plusieurs perspectives. Ce sont les cas où un seul regard ne suffit pas et où le désaccord fait partie de la méthode. Pour un brainstorming avec collaboration entre plusieurs, le motif est le chat de groupe.

Motif 5 : Magentic

Pour les problèmes ouverts : tout ce qui n'a pas encore de recette écrite. Un orchestrateur planifie, délègue et adapte pendant qu'on travaille, avec un livre de tâches dynamique qu'il ajuste au fil de l'eau. Le livre est ce qui rend cet ajustement possible : le plan n'est pas écrit au début, et c'est l'artefact qu'il faut quand personne ne sait encore combien d'étapes il y aura. C'est la pièce que les autres motifs n'ont pas besoin d'eux ; ils savent déjà combien d'étapes il y a ; magentic, non. Pendant que les autres motifs exécutent une forme connue de travail, magentic garde le plan vivant.

Comment choisir, en un guide

La liste est courte exprès : la décision se résout en une question, pas en une matrice à deux entrées.

Le processus est fixe et chaque étape alimente la suivante → Sequential.
Les tâches sont indépendantes et vous pouvez les lancer ensemble → Concurrent.
Le spécialiste se décide à l'exécution → Handoff.
Débat, consensus ou plusieurs perspectives sont nécessaires → Group Chat.
Le problème est ouvert et le plan se construit sur la marche → Magentic.

flowchart TD
    P{À quoi ressemble le processus que vous voulez orchestrer ?}
    P -->|Fixe, étape par étape| S[Sequential : la sortie d'un entre dans le suivant]
    P -->|Indépendantes| C[Concurrent : tous à la fois, sorties séparées]
    P -->|Le spécialiste se décide à l'exécution| H[Handoff : le contrôle passe de main en main]
    P -->|Débat ou consensus| G[Group Chat : un gestionnaire distribue le tour]
    P -->|Problème ouvert| M[Magentic : le plan s'ajuste sur la marche]

La question au centre du diagramme est la seule que vous ayez à répondre ; les cinq chemins partent de là. La liste ci-dessus et le diagramme disent la même chose : choisir un motif est un diagnostic, pas une étude. Et la contre-indication est écrite : le sequential est un pipeline fixe sans discussion. Si votre tâche demande des échanges entre agents, cherchez un autre motif.

Du motif au laboratoire

Ce qui n'a pas été exécuté est l'exercice « Develop a multi-agent solution » : il exige les identifiants d'un service d'IA et l'exécution du SDK en local. Le post a couvert les composants, le flux unifié et les cinq motifs avec leurs exemples ; il en reste à en exécuter un et à comparer deux motifs sur la même tâche.

Si vous l'appliquez à votre projet, l'ordre est le chemin : agents définis, motif choisi, callbacks si besoin, environnement démarré et orchestration invoquée. Et une divergence de noms à garder sous la main en le cherchant : l'URL conserve le slug orchestrate-semantic-kernel-multi-agent-solution, alors que la page en espagnol parle de Microsoft Agent Framework. C'est le même héritage que le post précédent : Semantic Kernel dans l'URL, Agent Framework dans le contenu.

Mon avis

Ce qui rend ce design précieux va au-delà d'avoir cinq motifs construits : les cinq partagent une API. Le flux à six étapes est le même et les agents ne changent pas. Ça transforme un changement de stratégie en une décision bon marché à essayer. La question n'est plus « comment réécrire ça avec un autre motif ? » mais « lequel des cinq correspond à mon processus ? ».

---

*Source : le module « Orchestrate a multi-agent solution with Microsoft Agent Framework » de Microsoft Learn.*