Analyse comparative des cadres multi-agents : défis et atouts
Les systèmes multi-agents utilisent des agents spécialisés qui collaborent pour résoudre des tâches complexes. Un défi majeur se pose : les performances se dégradent-elles à mesure que l’on ajoute des agents et des outils, ou les mécanismes d’orchestration peuvent-ils gérer efficacement la complexité croissante ?
Nous avons évalué cinq frameworks d'agents sur 750 exécutions avec trois tâches. Nous avons mesuré la latence, la consommation de jetons et la surcharge d'orchestration afin d'identifier les architectures qui conservent leur efficacité à grande échelle et celles qui se dégradent.
Comparateur de cadre multi-agents
Nous avons testé l'évolution de l'utilisation des jetons et de la latence en fonction du nombre d'agents et d'outils. Pour trois tâches présentant le même problème, nous avons progressivement augmenté le nombre d'agents et d'outils disponibles. Concernant LangChain et LangGraph, nous avons utilisé des configurations à agent unique afin d'observer comment leurs architectures séquentielles gèrent la même complexité que celle rencontrée par les systèmes multi-agents.
Nous n'avons pas inclus le framework dont la précision est inférieure à 95 % (Swarm) dans le graphique. Vous pouvez consulter notre méthodologie d'évaluation comparative.
En particulier pour Swarm, nous avons observé que la précision évoluait parallèlement à cette complexité, en raison de différences architecturales plutôt que des capacités du modèle.
Dans les frameworks multi-agents, la précision peut généralement être améliorée par le choix du modèle de langage naturel (LLM) ou l'optimisation de sa configuration. Cependant, l'analyse des causes architecturales des variations de précision dans notre banc d'essai a révélé des informations précieuses. Elle nous a permis de comprendre les différences de conception fondamentales entre les frameworks.
Résultats de référence du cadre multi-agents
CrewAI impose une exécution séquentielle à tous les agents, ce qui entraîne une croissance exponentielle du nombre de jetons, chaque résultat étant intégré au contexte de l'agent suivant. Cette rigidité garantit l'exhaustivité du traitement, mais engendre une surcharge considérable.
Swarm privilégie la vitesse grâce à un routage sans état, mais sa précision chute progressivement (de 84 % à 0 %) à mesure que la complexité des tâches augmente. Sans suivi d'état global, les agents s'arrêtent prématurément, interrompant les chaînes d'exécution.
LangChain utilise un « super-agent » mono-agent doté d'un contexte unifié, évitant ainsi toute surcharge de coordination. Les performances restent optimales jusqu'à ce que la taille de la bibliothèque d'outils (100 outils) et la complexité du raisonnement augmentent significativement la latence.
LangGraph offre la même fiabilité que LangChain, mais engendre un surcoût lié au parcours du graphe. Le coût de la gestion d'état devient significatif en cas de forte complexité, malgré une précision élevée.
AutoGen génère un grand nombre de transferts grâce à la coordination par chat, mais utilise GroupChatManager pour supprimer dynamiquement les agents inutiles. Cela empêche la croissance exponentielle de CrewAI tout en maintenant une précision élevée, même si la consommation de jetons reste supérieure à celle des systèmes à agent unique en raison du retraitement de l'historique des conversations.
IA d'équipage
Le pipeline séquentiel basé sur les rôles de CrewAI exécute chaque agent assigné sans filtrer les agents superflus. Cette caractéristique architecturale a des implications majeures pour les systèmes multi-agents où chaque agent remplit une fonction critique. Elle garantit que le système ne négligera aucune étape prévue et continuera d'utiliser tous les agents au lieu de prendre des décisions de routage autonomes. Cependant, cette rigidité a un coût élevé en termes de consommation de ressources et de latence, à mesure que la complexité des tâches augmente.
Croissance exponentielle des ressources pour l'ensemble des tâches
De la tâche 1 à la tâche 3, nous avons observé une augmentation continue de la consommation de jetons et de la latence. La latence a quasiment doublé à chaque tâche supplémentaire, tandis que la consommation de jetons a crû de façon encore plus spectaculaire. Le nombre de transferts d'agents a naturellement augmenté en parallèle.
Pourquoi CrewAI consomme plus de jetons et de temps
Le pipeline séquentiel de CrewAI s'est parfaitement intégré aux deux flux de travail. Dans la tâche 1, l'analyste de données a collecté les informations avant que l'arbitre ne prenne ses décisions. Dans la tâche 2, ce schéma s'est poursuivi avec des rôles d'agent élargis. CrewAI a sélectionné correctement tous les outils et a démontré que l'exécution séquentielle élimine les problèmes de coordination, chaque agent exécutant les outils qui lui sont assignés sans ambiguïté de routage.
Cependant, cet alignement naturel s'est accompagné de frais généraux importants et croissants :
Le mécanisme de composition des états :
- Chaque agent génère un rapport détaillé une fois sa tâche terminée.
- Ce rapport est transmis à l'agent suivant dans la séquence
- Au moment où l'arbitre final reçoit le relais, il lit un document contenant l'historique et les résultats de tous les agents précédents, ainsi que ses propres instructions système et métadonnées d'outils.
- Le LLM consacre un temps considérable à la lecture et à la régénération d'objets d'état Markdown volumineux entre les tâches.
Cette gestion détaillée des états enveloppait même les plus petites données dans d'importantes métadonnées d'orchestration. CrewAI privilégie la compréhension globale du contexte à l'efficacité.
Rigidité de la tâche 2-3 :
- Le système a exécuté les 5 agents dans la séquence prédéfinie, même lorsqu'un sous-ensemble seulement était strictement nécessaire.
- Cette rigidité a fait grimper à la fois le coût des jetons et la latence, tout en maintenant une précision élevée.
- L'incapacité du framework à ignorer les agents inutiles est devenue de plus en plus évidente comme une contrainte architecturale fondamentale.
- Chaque agent supplémentaire complexifiait le contexte que les agents suivants devaient traiter.
Essaim
Le mécanisme de routage léger de Swarm a démontré une véritable délégation multi-agents avec une surcharge d'orchestration minimale. Un agent initial recueillait le contexte nécessaire, reconnaissait activement la fin de sa tâche et transférait explicitement la session à un agent de décision distinct. Cette architecture sans état privilégiait la vitesse et la simplicité, atteignant des performances comparables à celles des solutions mono-agent dans des scénarios simples. Cependant, à mesure que la complexité des tâches augmentait, cette approche légère révélait des limitations fondamentales en matière d'évolutivité : l'absence de suivi d'état global et d'orchestration centralisée entraînait une chute progressive de la précision.
Dégradation progressive de la précision au fil des tâches
De la tâche 1 à la tâche 3, nous avons observé une chute brutale de la précision malgré le maintien de vitesses d'exécution rapides. La précision est passée de 84 % pour la tâche 1 à 22 % pour la tâche 2, pour finalement atteindre 0 % pour la tâche 3. Cette dégradation progressive a révélé que l'architecture sans état de Swarm, optimisée pour la vitesse lors d'interactions brèves et intenses, est fondamentalement inadaptée aux chaînes de raisonnement à plusieurs étapes.
Pourquoi la précision diminue-t-elle à mesure que la complexité augmente ?
Le système de routage léger de Swarm a permis de maintenir un nombre extrêmement faible de jetons d'achèvement et une latence réduite pour toutes les tâches. Le framework fonctionnait comme une course de relais d'agents indépendants sans état global, chaque agent prenant des décisions de transfert autonomes sans supervision centrale. Cette approche excelle dans la minimisation de la consommation de jetons et l'exécution rapide, mais au prix d'une fiabilité et d'une précision fortement compromises lorsque les exigences de persistance opérationnelle augmentent.
L'angle mort architectural :
L'analyse a posteriori des journaux a révélé une lacune architecturale qui ne pouvait être résolue par la seule optimisation des prompts. Dans un premier temps, un oubli au niveau des prompts (instructions de transfert manquantes) a été identifié et corrigé. Cependant, même avec des commandes de transfert explicites, Swarm n'a pas réussi à finaliser la chaîne.
Comme le système est sans état et ne dispose pas d'un suivi global des intentions, le premier agent destinataire (par exemple, le service Finance) se contente d'envoyer un accusé de réception conversationnel (par exemple : « Données reçues, audit financier en cours ») et de clore la conversation. Swarm interprète toute fin de conversation comme une tâche terminée, ce qui conduit à des résultats rapides mais superficiels. Sans orchestrateur central pour maintenir l'état des tâches et garantir l'exécution de toutes les étapes, le système ne peut pas faire la distinction entre « l'agent a envoyé un accusé de réception » et « la tâche est entièrement terminée ». Cette limitation fondamentale signifie que même une véritable délégation multi-agents avec des transferts explicites ne peut garantir la réalisation des tâches lorsque la chaîne dépasse le cadre de simples interactions.
Tâche 1-2 : Problèmes de précision croissants
Dans la tâche 1, où Swarm a démontré d'excellentes performances avec des chaînes d'agents courtes, le système a néanmoins échoué dans 16 % des exécutions en raison d'une résolution de transfert incomplète. L'analyse des journaux de conversation a révélé que l'arbitre avait bien pris ses décisions, mais que le mécanisme de sortie de Swarm avait affiché le message de transfert intermédiaire de l'analyste de données. Les utilisateurs ont ainsi reçu le message « Je vais maintenant transmettre ces informations à l'arbitre » au lieu de la décision finale, ce qui indique que les systèmes de routage dynamique risquent de perdre les résultats finaux lors des transitions entre agents.
Dans la tâche 2, avec 5 options d'agents et 20 outils à prendre en compte, la précision s'est considérablement dégradée car la stratégie d'incitation légère et pauvre en contexte du cadre a commencé à flancher sous la complexité accrue :
- Le taux de choix correct de l'outil a chuté à 40 %, ce qui représente une baisse de 20 % par rapport à la tâche 1.
- Les agents appelaient parfois des outils non pertinents ou émettaient des messages de routage là où de véritables appels d'outils étaient attendus.
- Les agents tentaient parfois d'utiliser des outils provenant d'un domaine incorrect ou réessayaient des appels infructueux.
- En l'absence de contrôleur central, les agents perdaient la trace de l'état d'exécution ou passaient le relais à des rôles qui semblaient concluants mais qui n'avaient pas exécuté les appels d'outils nécessaires.
Tâche 3 : Le paradoxe du transfert
La tâche 3 a mis en évidence une limitation architecturale fondamentale de Swarm, avec une précision de 0 %, malgré une vitesse d'exécution optimale. Cet échec total a révélé ce que nous appelons le « paradoxe du transfert » : dans une chaîne de 10 agents, Swarm exige des transferts entièrement automatisés à chaque étape, mais sans orchestrateur central ni graphe d'état (comme LangGraph), la chaîne se rompt dès le premier maillon. Si Swarm excelle dans les transferts directs, il s'effondre dans les flux de travail complexes nécessitant une persistance opérationnelle sur de longues chaînes.
Épuisement de la chaîne de transmission :
Dans la tâche 1, avec un seul transfert, la chaîne était suffisamment courte pour que l'objectif reste pertinent. Cependant, lorsque la chaîne s'est étendue à neuf transferts dans la tâche 3, la probabilité cumulée de succès a chuté à zéro. Chaque spécialiste supplémentaire agissait comme un « point de fuite », où une réponse conversationnelle pouvait interrompre le processus avant que l'arbitre final ne soit atteint. Ce taux d'échec exponentiel démontre que le routage sans état, bien qu'optimisé pour la vitesse, ne peut pas s'adapter aux raisonnements complexes en plusieurs étapes.
Chaîne de Lang
LangChain exécute les tâches comme une machine à états simple : réception d'une requête, évaluation des outils, exécution, finalisation. Nous avons configuré LangChain comme un exécuteur mono-agent, sans aucun transfert de responsabilité, avec un seul agent pour toutes les tâches. Cette approche de contexte unifié maintient une seule entité logique tout au long de l'exécution, évitant ainsi les sauts de conversation et exécutant précisément ce que chaque tâche requiert, sans surcharge d'orchestration. Le modèle d'exécution linéaire du framework a démontré que les tâches ne nécessitant pas de collaboration entre agents bénéficient considérablement de l'absence des coûts de coordination inhérents aux systèmes multi-agents.
Mise à l'échelle efficace jusqu'au seuil d'entropie de l'outil
LangChain a produit des résultats corrects pour les trois tâches. Cependant, la tâche 3 a révélé la sensibilité du framework à la taille de la bibliothèque d'outils et à la complexité du raisonnement, la latence augmentant sensiblement avec l'accroissement de ces deux dimensions.
Pourquoi LangChain est resté efficace
Tâche 1-2 : Avantage de l'exécution linéaire
Dans la tâche 1, LangChain a minimisé la latence et optimisé l'utilisation des jetons grâce à une sélection précise des outils. Le framework a évité toute distraction liée aux mécanismes de coordination, ne traitant que les informations nécessaires à l'exécution de la tâche. L'architecture mono-agent a permis d'éliminer toute surcharge de communication entre agents, toute génération de rapports entre les étapes et tout élément de remplissage conversationnel.
Dans la tâche 2, nous avons implémenté LangChain à l'aide d'une architecture de « super-agent » où un seul contrôleur avait un accès direct aux 20 outils. En regroupant les rôles au sein d'une seule entité logique, le framework a permis de s'affranchir des échanges de données entre agents, de la génération de rapports et du remplissage des conversations. Ce modèle d'exécution linéaire a garanti que le LLM ne traitait que les résultats pertinents des outils, évitant ainsi la croissance exponentielle de l'historique des invites observée dans les frameworks multi-agents.
L'architecture contextuelle unifiée a permis d'éviter toute confusion lors de la sélection des outils, malgré la présence de 20 outils dans la bibliothèque. L'agent unique a traité les appels d'outils séquentiellement, sans coordination ni négociation avec d'autres agents, garantissant ainsi une sélection correcte des outils malgré l'enrichissement de la bibliothèque. L'absence de transferts a confirmé qu'aucune surcharge d'orchestration n'était engendrée par l'augmentation de la complexité.
Entropie des outils et complexité du raisonnement
La tâche 3 a introduit deux défis importants qui ont eu un impact sur les performances de LangChain :
Entropie de l'outil :
Alors que la tâche 1 proposait 5 outils et la tâche 2, 20, la tâche 3 en présentait 100. LangChain fonctionnant comme un système mono-agent, chaque message doit inclure la définition des 100 outils dans l'invite. Ceci crée deux goulots d'étranglement :
- Le LLM doit évaluer 100 options pour sélectionner l'outil approprié, ce qui augmente le temps de traitement.
- La taille importante de l'invite (contenant toutes les définitions d'outils) retarde le temps d'obtention du premier jeton par le modèle, augmentant ainsi la latence globale.
Complexité du raisonnement (10 rôles d'experts) :
Dans les tâches 1 et 2, l'agent jouait simplement le rôle d'arbitre et prenait une décision. Dans la tâche 3, il devait examiner successivement 10 points de vue d'experts.
Cette instruction a entraîné la génération par le modèle de sorties nettement plus longues, avec une augmentation substantielle du nombre de jetons d'achèvement par rapport à la tâche 2. Plus de texte généré se traduit directement par un temps d'exécution plus long, car le modèle doit produire chaque jeton séquentiellement.
Malgré ces difficultés, LangChain a toujours produit des résultats corrects et n'a jamais sélectionné d'outils inappropriés. La structure de boucle simple du framework (AgentExecutor) a traité les appels et les réponses des outils sans surcharge architecturale supplémentaire, maintenant ainsi les augmentations de latence proportionnelles à la complexité inhérente de la tâche plutôt que de les aggraver par des mécanismes d'orchestration.
L'approche architecturale de LangChain a démontré que l'exécution contextuelle unifiée peut maintenir la fiabilité malgré l'augmentation de la complexité, bien que les performances deviennent sensibles à la taille de la bibliothèque d'outils et à la profondeur du raisonnement. La capacité du framework à produire des résultats corrects pour toutes les tâches, tout en évitant la prolifération de jetons et la surcharge de coordination des systèmes multi-agents, a mis en évidence l'intérêt des modèles d'exécution linéaire pour les tâches ne nécessitant pas de collaboration entre agents.
LangGraph
Comme observé dans notre analyse comparative des frameworks multi-agents, LangGraph utilise une architecture de machine à états avec des transitions d'état explicites et un flux de contrôle basé sur un graphe. Nous avons configuré LangGraph comme un exécuteur mono-agent, sans aucun transfert de responsabilité, avec un agent unique pour toutes les tâches. Cette approche élimine toute communication inter-agents tout en fournissant une gestion structurée de l'état, permettant de suivre la progression de l'exécution via des nœuds et des arêtes définis. Le framework a démontré que le suivi formel de l'état peut coexister avec une exécution contextuelle unifiée.
Fiabilité constante malgré la surcharge liée à la gestion des graphes
LangGraph a produit des résultats corrects pour les trois tâches, sans erreur. Pour les tâches 1 et 2, les performances sont restées quasiment identiques à celles du modèle d'exécution linéaire de LangChain. Cependant, la tâche 3 a révélé des augmentations de latence plus marquées par rapport à LangChain, mettant en évidence le coût de calcul de la gestion d'état basée sur un graphe en présence d'une forte entropie des outils et d'une complexité de raisonnement élevée.
Pourquoi LangGraph a-t-il été choisi par LangChain ?
Le graphe d'états de LangGraph a permis de formaliser le flux de contrôle sans nécessiter plusieurs agents. Dans les deux tâches, le framework a maintenu l'absence de transfert de responsabilité tout en sélectionnant correctement tous les outils. Le contrôleur unique accédait directement à tous les outils nécessaires, traitant chaque étape par des transitions d'état plutôt que par des transferts d'agents.
L'implémentation du « super-agent » a permis au système de ne jamais répartir la charge cognitive entre plusieurs personnages. La sélection des outils est restée précise, même avec 20 outils disponibles dans la tâche 2, l'agent n'utilisant jamais d'outils incorrects ou non pertinents. Ce contexte unifié a évité les problèmes de sélection rencontrés dans les systèmes reposant sur la coordination entre agents.
Pourquoi la consommation de jetons a-t-elle correspondu à LangChain ?
Les deux frameworks utilisaient une configuration LLM, des définitions d'outils et des invites système identiques. Contrairement aux frameworks multi-agents (AutoGen, CrewAI) qui génèrent une surcharge de coordination via les conversations entre agents et les messages de coordination intermédiaires, ces deux frameworks mono-agent consolident toute l'expertise en un seul appel de modèle. Chaque jeton dépensé représente soit les instructions d'entrée, soit la sortie directe, sans surcharge intermédiaire du type « l'agent A a parlé à l'agent B ». De plus, les deux frameworks invoquent les mêmes outils dans le même ordre pour résoudre la tâche, recevant des données identiques du système sous-jacent, ce qui se traduit par des nombres de jetons d'achèvement très similaires. Les différences de jetons entre les frameworks étaient négligeables car le LLM effectuait le même raisonnement dans les deux cas.
Tâche 3 : Surcharge liée au parcours de graphes amplifiée
La tâche 3 a introduit les mêmes défis auxquels LangChain était confronté (100 outils et une complexité de raisonnement à 10 rôles), mais l'architecture basée sur les graphes de LangGraph a amplifié l'impact sur les performances :
Charge d'entropie de l'outil :
À l'instar de LangChain, LangGraph, de par son architecture mono-agent, doit inclure les 100 définitions d'outils dans chaque requête. Le LLM doit évaluer l'intégralité de la bibliothèque d'outils pour chaque sélection, et la taille considérable des requêtes retarde la génération de la réponse.
Complexité du raisonnement :
L'instruction de raisonner séquentiellement à travers 10 points de vue d'experts a entraîné la génération de résultats nettement plus longs par LangGraph, tout comme par LangChain. Cependant, la surcharge supplémentaire de LangGraph est devenue ici manifeste.
Surcharge liée à la gestion des graphes :
Alors que LangChain utilise une structure de boucle simple (AgentExecutor) qui appelle des outils et traite les réponses, LangGraph parcourt une structure de graphe complète à chaque étape. Pour chaque appel d'outil :
- Le cadre doit parcourir l'intégralité du graphe du début à la fin
- L'historique des messages (état) est mis à jour à chaque transition de nœud.
- Le système valide les transitions entre les nœuds et maintient la cohérence de l'état.
Dans les tâches 1 et 2, cette surcharge était négligeable. Dans la tâche 3, avec 100 outils et des exigences de raisonnement complexes, la charge liée à la gestion du graphe est devenue considérable. La latence supplémentaire par rapport à LangChain reflétait directement le coût de la maintenance et du parcours de la structure du graphe d'états dans un contexte de forte complexité.
Malgré cette surcharge, LangGraph n'a jamais fait de mauvais choix d'outils, n'invoquant systématiquement que les fonctions nécessaires à chaque étape. Le suivi formel de l'état du framework assurait un flux de contrôle structuré, au prix d'un temps de traitement accru.
L'architecture de LangGraph a démontré que la gestion explicite de l'état conserve sa fiabilité malgré l'augmentation de la complexité, bien que la surcharge liée au parcours du graphe s'accentue avec une entropie élevée des outils et une complexité de raisonnement importante. Pour les applications nécessitant une traçabilité, des capacités de restauration ou une logique de branchement complexe, ce compromis peut s'avérer judicieux. En revanche, pour une exécution séquentielle simple, la structure supplémentaire de LangGraph n'apporte qu'une valeur ajoutée limitée par rapport à des modèles linéaires plus simples comme LangChain.
Autogénérateur
AutoGen consommait nettement plus de ressources que les solutions mono-agent de base, sans toutefois atteindre les niveaux extrêmes du pipeline séquentiel de CrewAI. Le système reposait sur de multiples conversations entre un proxy utilisateur et des agents spécialisés. Chaque échange nécessitait un traitement complet par LLM, qui recalculait l'historique de la conversation.
Cependant, AutoGen a systématiquement sélectionné les outils appropriés et produit des résultats précis pour toutes les tâches, sans recourir à des outils superflus. Il a toutefois engendré une surcharge conversationnelle, le framework passant plus de temps à coordonner qu'à exécuter. Pour cette tâche simple, la coordination par chat d'AutoGen s'est avérée être une complexité inutile plutôt qu'un avantage pour la collaboration.
AutoGen a utilisé une architecture basée sur le chat où des agents spécialisés collaborent via un UserProxy qui gère la coordination des flux de travail.
Nous avons configuré AutoGen à l'aide de GroupChatManager pour les trois tâches, ce qui a permis une sélection dynamique des agents plutôt qu'une exécution séquentielle. Cette architecture a démontré qu'une orchestration intelligente peut permettre une collaboration multi-agents sans les coûts de ressources exponentiels des pipelines rigides.
Nombre élevé de transferts avec des performances compétitives
AutoGen a enregistré le plus grand nombre de transferts parmi tous les frameworks. Dès la tâche 1, ce framework a atteint un niveau de transferts que CrewAI n'a atteint que dans la tâche 3 (9 transferts). Ceci reflète la nature conversationnelle d'AutoGen : chaque interaction entre l'UserProxy et les agents spécialisés est comptabilisée comme un transfert, même lors de discussions sur l'outil à appeler.
Cependant, malgré ces nombreux transferts, la latence d'AutoGen est restée compétitive par rapport aux frameworks séquentiels dans les tâches 1 et 2. Dans la tâche 3, alors que la surcharge du framework CrewAI a atteint 1,35 million de jetons, AutoGen n'en a consommé que 56 700 (contre 13 500 pour LangChain et 13 600 pour LangGraph).
Pourquoi AutoGen a-t-il consommé plus de jetons malgré sa latence ?
AutoGen consommait nettement plus de jetons que les configurations mono-agent de référence, sans toutefois atteindre les niveaux extrêmes du pipeline séquentiel de CrewAI. Le système reposait sur de multiples conversations entre un proxy utilisateur et des agents spécialisés. Chaque échange nécessitait un traitement complet par LLM, qui recalculait l'historique de la conversation.
Cette accumulation récursive de jetons explique pourquoi la consommation de jetons d'AutoGen est restée supérieure à celle de LangChain et LangGraph, même avec une latence compétitive. L'historique de conversation s'enrichit à chaque tour de parole, augmentant la taille des invites, mais le GroupChatManager du framework empêche l'explosion exponentielle observée dans les pipelines séquentiels en éliminant les agents inutiles.
Cependant, AutoGen a systématiquement sélectionné les outils appropriés et produit des résultats précis pour toutes les tâches, sans recourir à des outils non pertinents. La charge de traitement conversationnelle impliquait que le framework consacrait plus de temps à la coordination qu'à l'exécution, mais cette coordination garantissait qu'aucun agent ne perde le fil de ses actions ni n'utilise les mauvais outils.
Gestionnaire de discussions de groupe d'AutoGen
Le point fort architectural d'AutoGen : la sélection dynamique des agents via GroupChatManager. Contrairement à l'orchestration séquentielle de la tâche 2, le mode GroupChat permet au framework d'activer uniquement les agents nécessaires parmi ceux disponibles.
Le gestionnaire a éliminé les spécialistes superflus, n'activant que 5 ou 6 agents sur les 10 disponibles. Dès que l'arbitre a trouvé des éléments suffisants pour prendre une décision, le gestionnaire a mis fin à la boucle. Cela a permis d'éviter la croissance exponentielle du nombre de jetons qui se serait produite si le contexte avait été transmis séquentiellement à chaque agent restant.
Cette sélection dynamique a permis de réduire considérablement la latence et la consommation de jetons par rapport au pipeline séquentiel rigide de CrewAI. Alors que CrewAI forçait les 10 agents à exécuter les tâches sans nécessité, GroupChat d'AutoGen sélectionnait de manière adaptative uniquement les agents nécessaires à la prise de décision.
Malgré les efforts de coordination, le nombre élevé de transferts témoigne d'une délibération approfondie, les agents comparant leurs conclusions avant de conclure. La capacité d'AutoGen à basculer entre les modes séquentiel et GroupChat offre une flexibilité que les architectures rigides n'ont pas, démontrant ainsi qu'une orchestration par chat avec une sélection intelligente des agents peut évoluer plus efficacement que les pipelines fixes pour les flux de travail complexes multi-agents.
Fonctionnement d'AutoGen GroupChatManager :
- À chaque étape, le responsable décide « quel agent doit prendre la parole ensuite ? » en fonction du contexte de la conversation.
- Le framework n'est pas tenu d'exécuter tous les agents séquentiellement.
- Si les informations suffisantes sont recueillies rapidement, le responsable peut se passer de spécialistes inutiles.
- Le gestionnaire peut mettre fin à la boucle dès que l'agent dispose de suffisamment d'informations pour prendre une décision.
Le défi « Veuillez continuer » : par défaut, AutoGen maintient les conversations actives. Pour les tests de performance, des signaux de terminaison précis sont essentiels afin d’éviter les fuites de jetons. Nous avons résolu ce problème en veillant à ce que tous les agents spécialisés incluent des signaux TERMINATE explicites une fois la tâche terminée.
Surcharge de gestion : Même avec GroupChatManager, l’état des messages internes d’AutoGen est plus volumineux que celui de LangChain en raison de l’orchestration multi-agents. Cependant, cela fournit des journaux et des historiques de délibérations nettement plus structurés que les frameworks plus simples.
Remarque concernant l'orchestration séquentielle et GroupChat : toutes les tâches ont été exécutées avec GroupChatManager. Lors des tests avec l'orchestration séquentielle, la consommation de jetons et la latence ont au moins doublé par rapport au mode GroupChat, confirmant ainsi que la sélection dynamique des agents offre des gains d'efficacité substantiels par rapport aux pipelines fixes.
Méthodologie d'évaluation comparative des cadres multi-agents
Chaque cadre a été testé pendant 50 itérations (N=50) par tâche pour chaque tâche.
Afin d'éliminer toute variabilité dans le processus de raisonnement du modèle, tous les frameworks ont utilisé une configuration LLM identique. Le modèle utilisé était openai/gpt-5.2 via l'API OpenRouter. La température a été fixée à 0,0 .
Aucune limite maximale de jetons n'a été imposée aux réponses du LLM, permettant aux frameworks d'utiliser autant de contexte que leur architecture interne l'exigeait pour résoudre la tâche.
Les indicateurs recueillis comprennent : le nombre d’appels à l’API LLM, les transferts entre agents, les agents uniques sollicités, les appels d’outils exécutés et la précision de ces appels. Tous les indicateurs ont été enregistrés à chaque itération et agrégés sur l’ensemble des 50 exécutions.
Nous avons séparé les résultats bruts du modèle LLM des surcharges supplémentaires induites par l'orchestration afin de mesurer l'efficacité de cette dernière. Les jetons de sortie du modèle LLM représentent les réponses utiles générées par le modèle, tandis que les surcharges du framework englobent les commandes système, les définitions d'outils et les historiques de conversation que le framework doit transmettre au modèle LLM en arrière-plan pour obtenir ces réponses.
Cette métrique, calculée en soustrayant les jetons de sortie du nombre total de jetons (Total – Jetons de sortie), révèle directement le « coût de gestion » que le framework masque à l'utilisateur. Grâce à cette distinction, nous pouvons identifier les frameworks performants et légers, par opposition à ceux qui chargent systématiquement des volumes importants de données dans le LLM à chaque étape d'orchestration. Notre analyse s'est basée sur les jetons de surcharge du framework comme principal indicateur d'efficacité.
Afin de garantir que les cadres soient évalués uniquement sur la base de leur logique de coordination, nous avons synchronisé toutes les autres variables. Cela a permis d'éliminer les facteurs de confusion et d'isoler les différences architecturales.
Les agents étaient définis dans un fichier central. Le wrapper de chaque framework injectait la même chaîne de caractères de description dans son paramètre natif : `system_message` pour AutoGen, `backstory` pour CrewAI, `system prompts` pour LangChain/LangGraph et `agent descriptions` pour Swarm. Aucune modification spécifique aux invites n'a été appliquée.
Chaque framework utilisait les mêmes fonctions Python sous-jacentes. Les définitions d'outils, les chaînes de documentation et les schémas de paramètres étaient standardisés. Aucun outil pré-intégré spécifique à un framework n'était utilisé. Ceci garantit la cohérence de la logique d'exécution des outils ; seuls les mécanismes d'orchestration diffèrent.
À chaque itération, l'ensemble de données « DataCo Smart Supply Chain » était fourni aux agents. Les données de référence (statut d'expédition, statut de paiement, marges bénéficiaires) restaient constantes d'un framework à l'autre.
Tout en conservant des entrées identiques, chaque framework a fonctionné selon son mode structurel natif. Nous n'avons pas contraint les frameworks à adopter des architectures artificielles. Au contraire, nous avons implémenté chaque framework conformément à son modèle de conception prévu afin de mesurer ses performances en conditions réelles.
AutoGen fonctionne comme un système de chat de groupe conversationnel. Il utilise des fonctions `initiate_chats` avec des signaux `TERMINATE` pour gérer les conditions de sortie. Les agents communiquent par échange de messages, un proxy utilisateur coordonnant le flux de travail.
CrewAI implémente un pipeline séquentiel basé sur les tâches. Il utilise Process.sequential, où les agents s'exécutent dans un ordre fixe. Chaque agent termine sa tâche et génère un rapport avant que l'agent suivant ne prenne le relais.
LangChain adopte une architecture linéaire. Il utilise un AgentExecutor standard qui encapsule la boucle d'appel des outils. L'agent exécute les outils séquentiellement au sein d'un même contexte.
LangGraph structure l'exécution sous forme de graphe d'état cyclique. Il utilise StateGraph, dont les nœuds représentent les étapes de traitement, et des arêtes de routage conditionnel pour déterminer le flux.
Swarm utilise des routines de transfert de contrôle. Il emploie des fonctions `transfer_to_agent` pour transférer dynamiquement le contrôle entre les agents en fonction des décisions prises lors de l'exécution.
Les tâches ont gagné en complexité afin de tester la résistance de différentes capacités d'orchestration et de différents modes de défaillance.
Tâche 1 (2 agents / 5 outils) : Teste la surcharge d'orchestration de base pour un flux de travail simple nécessitant la collecte d'informations sur les commandes et la prise de décision en matière de remboursement.
Tâche 2 (5 agents / 20 outils) : Teste l’intelligence de routage en présence de bruit. Seuls 2 à 3 agents et 3 à 5 outils sont nécessaires, mais 5 agents et 20 outils sont disponibles.
Tâche 3 (10 agents / 100 outils) : Teste les limites du filtrage à haute entropie et de la scalabilité. Seuls 2 à 3 agents et 3 à 5 outils sont nécessaires, mais 10 agents et 100 outils sont disponibles, dont 98 outils parasites conçus pour perturber le routage.
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.