Partager via


Explorez les schémas d’orchestration multi-agents

L’orchestration générative prend également en charge les systèmes multi-agents, où un agent appelle un autre agent. Décomposer les problèmes en plusieurs agents spécialisés peut améliorer la modularité, la scalabilité et la gérabilité.

Agents en ligne

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.

Bonnes pratiques : Gardez les agents en ligne concentrés sur une seule responsabilité et bien éprouvés.

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 appelant un agent commercial pour demander des prix. Les agents connectés permettent la modularité, la séparation des domaines 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é. Ce transfert a généralement lieu 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 » 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 du parent transmettre à l’agent connecté. Copilot Studio transmet par défaut l’historique des conversations lorsqu’un agent appelle un autre, afin que l’agent connecté sache ce qui a déjà été discuté. Mais il se peut aussi que vous deviez passer certains paramètres. 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
  • Vous prévoyez de réutiliser cette capacité dans de nombreux agents principaux différents (donc c’est comme un agent de service).

Si aucune de ces conditions ne s’applique, un simple sujet (en ligne) pourrait suffire à la place d’un agent entièrement connecté. Les agents séparés introduisent une surcharge — un temps d’exécution légèrement plus long dû au changement de contexte et à la complexité de la gestion de plusieurs bots. Alors utilisez-les judicieusement. Une approche pratique consiste à commencer avec un seul agent et à ne diviser en plusieurs agents que lorsqu’on voit clairement un besoin de modularité ou une frontière qu’un seul agent ne devrait pas franchir.