Modèles d’orchestration multi-agent et bonnes pratiques

L’orchestration générative prend également en charge les systèmes multi-agents, où un agent appelle d’autres agents. Lorsque vous divisez les problèmes en plusieurs agents spécialisés, vous rendez votre application plus modulaire, évolutive et gérable.

Agents intégrés

Les agents en ligne, également appelés agents enfants, sont de petits flux de travail réutilisables au sein d’un même agent. Ce sont souvent des sujets que l’agent principal utilise comme sous-programmes. Par exemple, l’agent principal peut appeler un sujet « Traduire un texte » comme une étape dans un plan plus large. Les agents en ligne partagent le contexte avec l’agent principal, donc le transfert de données entre eux est simple.

Bonne pratique : Gardez les agents inline concentrés sur une seule responsabilité et testez-les correctement.

Agents connectés

Les agents connectés sont des agents distincts avec leur propre orchestration, leurs outils et leurs connaissances. L’agent principal délègue une partie d’une demande à un agent pour enfants. Par exemple, un agent informatique appelle un agent commercial pour obtenir des informations sur la tarification. Les agents connectés permettent la modularité et la séparation de domaine, et peuvent contourner les limites du plan. Ils peuvent avoir des privilèges ou des connaissances différents, donc appliquez des contrôles de gouvernance et d’audit.

Cependant, l’utilisation d’agents connectés nécessite une gouvernance rigoureuse :

• Orchestration : L’orchestrateur parent doit avoir des critères clairs pour savoir quand passer à un agent connecté. L’orchestrateur se met généralement hors service lorsque l’intention de l’utilisateur correspond au domaine de l’agent connecté. Pour faciliter ce processus, décrivez clairement la fonction de l’agent connecté dans la configuration du parent concerné. Traitez l’ensemble de l’agent connecté comme un « outil » agentique avec une description, du point de vue du parent.

• Transfert de données : Vous devez gérer le transfert de données. Décidez quel contexte venant du parent transmettre à l’agent connecté. Copilot Studio passe l’historique des conversations par défaut quand un agent appelle un autre, de sorte que l’agent connecté comprend le contexte précédent de la conversation. Mais il se peut aussi que vous deviez passer des paramètres spécifiques. Par exemple, si l’agent principal connaît déjà le nom de l’utilisateur plus tôt, il peut l’envoyer à l’agent connecté pour éviter de redemander.

• Sécurité : L’agent connecté peut avoir accès à des choses que l’agent parent n’a pas. Assurez-vous qu’appeler l’agent connecté ne contourne pas involontairement les restrictions. Par exemple, si l’agent parent n’est pas autorisé à supprimer les enregistrements mais que l’agent connecté le peut, l’agent parent ne devrait pas appeler l’agent connecté dans des situations où la suppression pourrait avoir lieu sans approbation appropriée. Traitez un appel d’agent connecté comme n’importe quelle autre action puissante. S’il fait quelque chose de sensible, soumettez-le aux vérifications nécessaires ou au consentement de l’utilisateur.

• Audit et surveillance : Consignez quand un agent connecté a été invoqué et ce qu’il a fait. Comme c’est un agent distinct, vous avez des relevés de notes distincts. Il est important pour le débogage de corréler les sessions parentes et les sessions connectées. Typiquement, les identifiants de la télémétrie relient les deux.

Quand séparer les agents

Ne créez pas un agent séparé pour chaque sous-tâche. Utilisez des agents séparés si la sous-tâche :

• Est-elle suffisamment complexe pour avoir sa propre suite d’outils ou de connaissances (domaine d’expertise différent)
• Nécessite des règles de gouvernance ou des contrôles d’accès différents de ceux de l’agent principal
• Peut être réutilisé dans de nombreux différents agents principaux (il s’agit donc d’un agent de type service)

Si aucune de ces conditions ne s’applique, un agent inline simple peut gérer la tâche correctement tout en étant plus simple qu’un agent connecté complet. Les agents distincts introduisent une surcharge au système. Il existe un temps d’exécution légèrement plus long en raison du changement de contexte et de la complexité de la maintenance de plusieurs agents. Alors utilisez-les judicieusement. Pour une approche pratique, commencez par un agent. Ensuite, fractionnez uniquement en plusieurs agents lorsque vous voyez clairement un besoin de modularité ou une limite qu’un seul agent ne doit pas traverser.

Meilleures pratiques pour l’orchestration multi-agent

Les meilleures pratiques suivantes s’appliquent lors de la création d’instructions pour les parents et les sous-agents dans une configuration multi-agent.

1. Principe de réponse unique

Assurez-vous qu’un seul agent communique avec l’utilisateur par tour. Dans une configuration multi-agent, l’agent parent est le seul qui doit fournir la réponse finale. Les subagents sont des chercheurs, et non des répondants.

• À faire : Ajouter aux instructions du parent : « Vous êtes le seul agent à communiquer avec l’utilisateur. » Combinez les résultats de tous les agents enfants en une seule réponse.
• Ne le laissez pas ambigu. En l’absence d’instructions explicites, les sous-agents répondent directement à l’utilisateur, ce qui entraîne des messages en double ou incomplets.

2. Les instructions de sous-agent doivent déclarer leur rôle

Dites toujours aux sous-agents qu’ils sont des sous-agents. Les sous-agents ne savent pas intrinsèquement qu’ils font partie d’une orchestration. Sans conseils explicites, ils se comportent en tant qu’agents autonomes et envoient des messages directement à l’utilisateur.

• Faire : Ajouter aux instructions de chaque sous-agent : « Vous êtes un sous-agent. Ne répondez pas directement à l’utilisateur. Votre travail consiste à rechercher des informations et à renvoyer vos résultats à l’agent parent. L’agent parent gère toutes les communications avec l’utilisateur. »
• À ne pas faire : supposer que les sous-agents définiront eux-mêmes le schéma d’orchestration.

3. Utiliser une langue claire et directe dans les instructions

Utilisez toujours le langage de directive. Évitez les formulations douces ou polies. La plateforme injecte des instructions au niveau du système à l’aide d’un langage fort (MUST, DO NOT, NEVER). Les instructions écrites avec une langue douce (« essayez de le faire », « vous devriez », « il serait bon de ») perdre la priorité lorsqu’elles sont en conflit.

• Procédez comme suit : « JAMAIS répondre directement à l’utilisateur. Retournez uniquement vos résultats.
• Procédez comme suit : « Il doit y avoir exactement une réponse finale par question utilisateur ».
• N’oubliez pas : « Essayez d’éviter d’envoyer des messages à l’utilisateur et retournez plutôt vos résultats. »
• N’oubliez pas : « Dans l’idéal, nous voulons une réponse combinée unique ».

4. Utiliser une source de connaissances par sous-agent (sans chevauchement)

Attribuez à chaque sous-agent des sources de connaissance distinctes et non chevauchantes. Si deux sous-composants recherchent la même base de connaissances, un sous-agent trouve d’abord la réponse. Le deuxième sous-composant retourne des résultats dupliqués ou ignore entièrement sa recherche, sans ajouter de valeur.

• À faire : CA-1 effectue une recherche dans la source de connaissances A (par exemple, les politiques RH). CA-2 recherche la source de connaissances B (par exemple, la documentation informatique).
• À éviter : donner aux deux sous-agents accès aux mêmes documents, tables Dataverse ou sites SharePoint.
• Remarque : Si vous n’avez qu’une seule source de connaissances, utilisez un seul agent avec des connaissances au lieu de fractionner en deux sous-agents. Multi-agent ajoute de la valeur uniquement lorsque les sources sont réellement différentes.

5. Utiliser des descriptions précises et distinctes pour les sous-agents

Écrivez des descriptions claires et distinctes pour chaque sous-agent visible par le parent. L’agent principal utilise les descriptions des sous-agents pour déterminer le routage. Si les descriptions sont vagues, identiques ou inexactes, le parent ne peut pas prendre de bonnes décisions de routage.

• Faire : CA-1 : « Recherche des documents de stratégie RH pour les questions relatives aux employés ». CA-2 : « Recherche dans la base de connaissances informatiques des questions de support technique ».
• Ne donnez pas aux deux agents la même description lorsqu’ils servent différents domaines.
• N’utilisez pas de descriptions génériques telles que « Cet agent peut vous aider à répondre aux questions ».

6. Les instructions parentes doivent définir le modèle d’orchestration

Indiquez à l’agent parent comment orchestrer. Ne dites pas simplement « utiliser des agents enfants ». Le parent a besoin d’instructions explicites sur le modèle : appeler des agents, attendre les résultats, combiner, puis répondre.

• Faites : « Lorsque l’utilisateur pose une question : 1. Appelez les deux agents enfants pour collecter des informations. 2. Attendez que les deux agents fils transmettent leurs résultats. 3. Combinez les résultats en une seule réponse unifiée. 4. Fournissez exactement une réponse à l’utilisateur. Les agents enfants ne doivent pas répondre directement à l’utilisateur.
• À ne pas faire : « Lorsque l’utilisateur pose une question, faites appel à des agents enfants, obtenez les réponses des deux sources et fournissez une seule réponse combinée. » (Trop vague. L’instruction n’indique pas aux sous-agents de rester silencieux.)

7. Inclure la directive « aucune réponse directe » dans la délégation de tâche

Même avec des instructions sous-subordonnées claires, l’ajout d’un renforcement dans la tâche déléguée fournit un filet de sécurité.

• À faire : Ajouter aux instructions du parent : « Lorsque vous déléguez à un agent enfant, indiquez toujours dans la tâche : “Renvoyez uniquement vos conclusions.” » Ne répondez pas à l’utilisateur.
• Ne vous fiez pas uniquement aux propres instructions du sous-agent. Le contexte de la tâche fournit au sous-agent davantage de signaux qui renforcent le schéma.

8. Tester avec des requêtes d’incompatibilité de domaine

Testez toujours avec des questions qui ne correspondent pas au domaine d’un sous-agent. Ce test révèle si les sous-agents renvoient de manière appropriée « aucune information trouvée », plutôt que de renvoyer des informations potentiellement incorrectes, de se bloquer ou d’envoyer des messages confus.

• Effectuer un test avec des requêtes en dehors de tous les domaines sous-associés (par exemple, demandez la météo lorsque les agents gèrent les ressources humaines et informatiques).
• À faire : vérifiez que le parent gère correctement « les deux agents n’ont rien trouvé ».
• Ne vous limitez pas à tester uniquement les requêtes les plus simples qui correspondent exactement au domaine d’un sous-agent.

9. Préférez poser une question plutôt qu’informer lorsque vous attendez une réponse

Utilisez des interactions sous forme de questions lorsque vous attendez une réponse de l’utilisateur. Utilisez inform/send-style uniquement pour les messages unidirectionnel finaux. Si l’agent demande à l’utilisateur quelque chose à l’aide d’un message unidirectionnel (informer), la réponse de l’utilisateur revient au planificateur parent en tant que nouvelle requête. Dans ce cas, il est préférable de poursuivre la même conversation avec le sous-agent.

• Effectuez des instructions telles que : « Si vous avez besoin de clarification, demandez à l’utilisateur une question et attendez sa réponse ».
• N’écrivez pas d’instructions telles que : « Informez l’utilisateur sur les options et laissez-les choisir ». « Inform » signale un message unidirectionnel, tandis que « ask » signale un échange bidirectionnel.

Liste de contrôle de référence rapide

Informations associées

• Ajouter d’autres agents : aperçu
• Ajoutez un agent pour enfants
• Connectez-vous à un agent Copilot Studio existant
• Connectez-vous à un agent Microsoft Foundry
• Connect à un agent de données Microsoft Fabric
• Se connecter à un agent Microsoft 365 Agents SDK
• Connectez un agent disponible via le protocole Agent2Agent (A2A)