Top 5 des frameworks d'IA agentique open source
Nous avons évalué 4 frameworks agentiques open source populaires sur 2 000 exécutions (5 tâches, 100 exécutions par framework), en mesurant la latence de bout en bout, la consommation de tokens et les différences architecturales.
Benchmark des frameworks d'IA agentique
Nous avons examiné comment les frameworks eux-mêmes influencent le comportement des agents et l'impact qui en résulte sur la latence et la consommation de tokens.
LangGraph est le framework le plus rapide avec les valeurs de latence les plus basses sur toutes les tâches, tandis que LangChain présente la latence et la consommation de tokens les plus élevées.
Sur 5 tâches et 2 000 exécutions, LangChain se révèle être le framework le plus économe en tokens, tandis qu'AutoGen domine en termes de latence ; LangGraph et LangChain suivent de près. CrewAI affiche le profil global le plus lourd.
Tâche 1 : Agrégation de base
Tout d'abord, nous avons mesuré la surcharge de chaque framework lors de l'appel d'un seul outil et du retour du résultat, sans effectuer de raisonnement complexe.
LangChain & LangGraph : Pour les tâches simples, ils fonctionnent presque aussi rapidement qu'un code non agentique, les deux terminant en moins de 5 secondes avec moins de 900 tokens de prompt. L'architecture de machine à états de LangGraph n'introduit aucune latence perceptible par rapport à LangChain à ce niveau de simplicité ; la surcharge de la gestion d'état se matérialise à mesure que la complexité des tâches augmente.
AutoGen : Se situe légèrement au-dessus de LangChain et LangGraph en termes de latence et de consommation de tokens, reflétant le coût de base de sa boucle de conversation multi-agent, deux agents échangeant des messages même pour une tâche en une seule étape.
CrewAI : Même lorsqu'on lui demande de faire un seul appel d'outil, il présente ce que l'on pourrait appeler une « surcharge managériale », consommant près de 3 fois plus de tokens que LangChain et prenant presque 3 fois plus de temps. Le processus de vérification en plusieurs étapes entre ses personas de Planificateur et d'Analyste offre une approche approfondie mais gourmande en ressources qui privilégie l'exhaustivité à la rapidité. Ce coût est structurel : il apparaît quelle que soit la complexité de la tâche.
Tâche 2 : Analyse comparative des revenus (gestion d'état)
Dans la Tâche 2, nous voulions voir la capacité des frameworks à conserver deux groupes de filtres différents en mémoire (persistance d'état) et à les combiner.
CrewAI
Lors de notre analyse des logs, nous avons constaté que CrewAI offre le plus haut niveau de transparence de l'infrastructure parmi les frameworks, mais au prix de la consommation de ressources la plus élevée.
Au lieu de renvoyer immédiatement les données récupérées, CrewAI valide à plusieurs reprises ses propres processus via un mécanisme d'auto-révision. Ce comportement exploratoire l'a amené à atteindre la limite max_iter=10 configurée, laissant certaines exécutions bloquées dans une boucle de réflexion continue sans produire de sortie JSON.
La cause profonde de ce comportement est que CrewAI injecte des instructions à plusieurs niveaux dans le prompt système, assignant à chaque agent un rôle, un objectif et un historique, tout en imposant une boucle de style ReAct (Thought → Action → Observation) à chaque étape. Même pour des tâches simples, le LLM ne peut pas ignorer ce rituel et produit consciencieusement de longs monologues internes, ce qui s'aggrave dans les scénarios multi-agents.
CrewAI a consommé près de deux fois plus de tokens que les autres frameworks et a pris plus de trois fois plus de temps que LangChain, ce qui le rend mieux adapté aux transitions d'état complexes et à la prise de décision multi-factorielle plutôt qu'aux tâches simples de récupération de données.
LangChain
Le framework le plus rapide et le plus économique. Dans nos logs, nous avons observé que LangChain termine la tâche en 5-6 étapes sans détour : Charger → Filtrer → Calculer → Filtrer → Calculer → Sortie. Sa gestion d'état étant très simple, la surcharge est quasi nulle et la latence est la plus faible parmi tous les frameworks.
AutoGen
A livré une performance très équilibrée. Dans la Tâche 2, il a égalé LangGraph presque exactement en termes d'utilisation de tokens et de latence, montrant que la surcharge de la boucle de conversation ne s'aggrave pas de manière significative lorsque la chaîne de tâches reste linéaire.
Cependant, il ajoute parfois une étape de vérification supplémentaire pour confirmer les paramètres lors du processus d'appel d'outil, ce qui le rend légèrement plus lent que LangChain. Lorsqu'il rencontre une erreur dans un appel d'outil ou que les données ne reviennent pas comme prévu, il met à jour immédiatement son raisonnement à l'étape suivante et arrive au JSON correct. Parce qu'il gère les sorties des outils comme un flux conversationnel, il est l'un des frameworks les plus résilients face aux erreurs logiques.
LangGraph
Dans cette tâche, LangGraph est le framework le plus stable grâce à son architecture basée sur les graphes. Dans ses logs, nous avons observé que l'état est transporté de manière très propre tout au long de l'exécution. Le risque de contamination des données ou d'interférence entre les segments est au niveau le plus bas dans ce framework. Sur l'ensemble des 100 exécutions, il a produit des résultats avec presque le même nombre d'étapes et dans la même plage de latence.
Tâche 3 : Analyse de seuils (discipline numérique)
Dans cette tâche, nous voulions voir avec quelle précision les frameworks traduisent les conditions numériques en langage naturel, telles que « moins d'un an d'ancienneté » et « plus de 70 $ de frais mensuels », en paramètres d'outil précis comme tenure_max=12 et charges_min=70.0.
Le LLM sait effectuer cette conversion ; ce que nous voulions vraiment tester, c'est si le framework peut protéger ces paramètres tout au long de ses propres mécanismes de re-tentative, du contexte de reformulation et des cycles de gestion d'état.
LangChain & LangGraph
Les deux frameworks ont transmis les paramètres (tenure_max=12, charges_min=70) directement à l'outil exactement comme le LLM les a produits, sans aucune modification ni boucle de reformulation. Cette efficacité se reflète dans les chiffres : les deux frameworks ont terminé la Tâche 3 en moins de 9 secondes avec moins de 1 800 tokens de prompt, les plus bas pour cette tâche.
Lorsque nous voulions mesurer si les seuils numériques sont préservés sans que le framework n'interfère, ces deux-là ont répondu à nos attentes : quel que soit le paramètre généré, c'est celui qui a été exécuté.
AutoGen
AutoGen réussit pleinement en termes de correction numérique. Dans certaines exécutions, on a observé que le framework ajoutait une étape de vérification avant de transmettre le paramètre généré par le LLM à l'outil, ce qui signifie que le framework a consacré une étape supplémentaire tout en préservant le paramètre. Avec 2 480 tokens et 8 secondes, il a égalé la latence de LangChain malgré l'étape supplémentaire, confirmant que la surcharge de vérification est réelle mais faible. Il a répondu à nos attentes en termes d'intégrité des paramètres, l'étape de confirmation introduisant un coût marginal en tokens plutôt qu'une pénalité de latence significative.
CrewAI
Le comportement le plus notable a été observé avec CrewAI, qui a terminé la Tâche 3 en 30 secondes avec 4 360 tokens, le plus élevé pour cette tâche. Deux schémas d'échec distincts sont ressortis de l'analyse des logs.
Dans certaines exécutions, une valeur qui aurait dû être 68.81 % a été renvoyée comme 0.6878 (ratio décimal). Cela indique que la sérialisation de la sortie du framework peut dépouiller la sortie du LLM de son contexte d'origine.
Les logs montrent que le LLM a initialement produit les bons paramètres, tenure_max=12 et charges_min=70. Cependant, une fois que CrewAI est entré dans une boucle « Failed to parse », le framework a poussé le LLM à reconsidérer. Dans le contexte de reformulation, le LLM a déplacé le seuil à tenure_max=14 et a complètement désactivé le filtre charges_min, produisant un taux de désabonnement de 46.84 %, qui est en fait le taux de désabonnement de tous les clients ayant une ancienneté inférieure à 14. C'était exactement le scénario que nous voulions observer : le mécanisme de nouvelle tentative du framework peut corrompre un paramètre que le LLM avait correctement déterminé.
Tâche 4 : Résilience aux erreurs et capacité de pivotement
Dans cette tâche, nous voulions voir comment chaque framework gère les scénarios perturbateurs et observer l'impact sur la latence et la consommation de tokens. L'outil lève 3 types d'erreurs successivement (Réseau, Délai d'attente, Limite de débit), mettant l'agent en difficulté. Les deux premières erreurs demandent à l'agent de réessayer, et après avoir réessayé les deux, l'erreur de Limite de débit entrante indique à l'agent d'attendre 10 secondes. Une fois que l'agent attend et réessaie, l'outil commence à fonctionner normalement.
LangGraph & Autogen
Ces deux frameworks ont trouvé des solutions alternatives de manière autonome lorsqu'ils ont été confrontés à des échecs d'outils dans cette tâche.
Lorsque l'outil a renvoyé un avertissement de limite de débit, au lieu de faire une pause et d'attendre, ces agents ont décidé d'abandonner complètement l'outil défaillant et de trouver un chemin alternatif. Leur approche était : « Puisque cet outil ne fonctionne pas, je vais filtrer chaque méthode de paiement une par une, calculer le taux de désabonnement pour chacune séparément, puis combiner les résultats moi-même. »
Méthode : Au lieu d'accomplir la tâche avec un seul appel d'outil, ils l'ont décomposée en utilisant deux outils distincts, un pour le filtrage et un pour le calcul, en traitant chaque PaymentMethod (chèque électronique, chèque postal, etc.) individuellement.
Ces agents fonctionnent avec un raisonnement axé sur les objectifs plutôt que sur la dépendance au chemin. Si le chemin le plus court n'est pas disponible, ils peuvent construire un plan d'exécution alternatif en quelques secondes.
LangGraph a atteint 15 010 tokens de prompt dans la Tâche 4, le nombre de tokens le plus élevé pour une seule tâche dans l'ensemble du benchmark, car sa machine d'état accumulait l'historique croissant de chaque appel d'outil manuel dans le contexte à chaque étape. AutoGen a suivi avec 10 750 tokens, un peu plus contenu en raison de son traitement conversationnel des résultats intermédiaires. Malgré cela, les deux ont terminé autour de 24-27 secondes, confirmant que le coût supplémentaire en tokens ne s'est pas traduit par une latence significative car le pivotement lui-même était rapide.
CrewAI
Malgré une consommation de tokens la plus élevée dans les tâches précédentes, CrewAI a affiché la plus faible utilisation de tokens) mais la latence la plus élevée dans cette tâche.
Pourquoi le nombre de tokens le plus bas ?
CrewAI n'a pas suivi une solution de contournement manuelle en 10-15 étapes comme ses concurrents. Lorsqu'il a rencontré des erreurs, au lieu de réinjecter à chaque étape tout l'historique et les données intermédiaires complexes dans le LLM, il a construit une boucle de raisonnement plus ciblée et modulaire. En évitant les verbosités inutiles, il est devenu le framework le plus économique dans cette tâche.
Pourquoi une latence élevée ?
La structure managériale de CrewAI fait une pause et réévalue le plan lorsqu'elle rencontre une erreur. Lorsqu'elle a reçu l'avertissement d'attente de 10 secondes, elle a passé plus de temps dans la phase de « planification stratégique ». De plus, plutôt que de pivoter vers un autre outil pour le filtrage, elle a persisté à attendre que l'outil principal se rétablisse ou à essayer avec l'outil stable, ce qui a prolongé la durée totale.
LangChain
LangChain a connu sa transformation la plus significative dans cette tâche, prouvant pourquoi la résilience dépend d'une configuration appropriée.
Lors de notre exécution initiale, LangChain a planté à chaque tentative avec une ConnectionError.
L'AgentExecutor par défaut de LangChain traite les exceptions Python brutes levées depuis un outil comme des erreurs fatales et met fin au processus. Contrairement à ses concurrents, il n'applique pas par défaut une philosophie « les erreurs sont des observations ». Comme l'agent ne voit jamais l'erreur, il n'a aucune chance de raisonner à son sujet.
Nous avons encapsulé l'appel d'outil dans langchain_agent.py avec un bloc try-except. Cela a converti l'erreur en un message lisible que l'agent pouvait traiter.
Comportement après correction : Après avoir appliqué la correction, nous avons observé dans les logs de LangChain qu'il a montré exactement le même raisonnement que LangGraph. Il a reçu 3 erreurs de l'outil, a immédiatement changé de stratégie et a pivoté vers l'utilisation de deux outils distincts, un pour le filtrage et un pour le calcul, a traité chaque méthode de paiement individuellement et a combiné les résultats.
LangChain est en réalité tout aussi capable et adaptable que LangGraph, mais parce que la gestion des erreurs du framework était désactivée par défaut, il n'a pas eu l'occasion de démontrer cette capacité. Une fois correctement configuré, il a atteint le résultat correct en utilisant la même approche de chemin alternatif.
Pourquoi ces différences se sont-elles produites ? (analyse de l'architecture des frameworks)
Si le comportement de l'agent dépendait uniquement du LLM (GPT-5.2), tous les frameworks auraient dû se comporter de manière similaire. Cependant, les différences nettes dans ces ratios trouvent leur origine dans les mécanismes internes de boucle des frameworks :
1. LangGraph & AutoGen (90 % Pivot) :
LangGraph fonctionne sur une architecture de machine à états, tandis qu'AutoGen fonctionne sur un modèle basé sur la conversation. Dans les deux systèmes, les erreurs sont traitées comme une boucle de rétroaction. Dans LangGraph, l'état qui reçoit l'erreur passe au nœud suivant ; dans AutoGen, l'agent Proxy transmet l'erreur à l'assistant sous forme de message de chat. Ce mécanisme de poussée constante oblige l'agent à continuer à chercher une solution. Parce que l'agent est confronté à plusieurs reprises à la question « J'ai une erreur, que dois-je faire ? », la probabilité qu'il décide de prendre un chemin manuel alternatif augmente à 90 %.
2. LangChain (65 % Pivot / 35 % Attente) :
LangChain fonctionne sur une architecture AgentExecutor séquentielle. Même avec la gestion des erreurs en place, sa boucle d'exécution a une structure plus linéaire et est principalement axée sur la production d'une réponse finale. Si l'outil lève des erreurs pendant 3 à 4 étapes, LangChain préfère parfois attendre que l'outil réussisse à la tentative suivante ou produise un résultat à partir du contexte existant, plutôt que de pivoter vers une stratégie alternative. Parce que le verrouillage d'état de LangChain est plus flexible que celui de LangGraph, son ratio attente/solution directe se situe autour de 35 %.
3. CrewAI (0 % Pivot) :
CrewAI fonctionne sur une architecture de processus managérial. Ses agents sont encapsulés dans des définitions de Rôle et de Tâche. Lorsque des erreurs se produisent, son architecture interne déclenche généralement une logique d'auto-correction ou de nouvelle tentative. Cependant, un changement de stratégie radical comme « abandonnons tout le plan et faisons un filtrage manuel en 5 étapes » entre en conflit avec la structure de plan managérial de CrewAI. Il fonctionne avec la discipline de « Je dois réparer l'outil qui m'a été donné ou utiliser l'alternative la plus proche » plutôt que d'abandonner complètement son plan. Il s'agit fondamentalement d'une approche centrée sur le plan plutôt que centrée sur l'objectif.
Tâche 5 : Orchestration de données non structurées (routage de données non structurées)
Dans la tâche 5, nous avons observé comment les frameworks se comportent lorsqu'ils rencontrent des colonnes JSON et de texte long (LongText) dans un CSV. Les agents devaient d'abord découvrir le type de données de ces colonnes, puis sélectionner les bons outils de traitement, de manière séquentielle ou parallèle.
Dans le monde réel, la gestion des données non structurées exige qu'un agent aille au-delà des données tabulaires standard et travaille avec des blobs JSON, des paragraphes de texte gratuit ou des objets imbriqués.
Pour qu'un framework gère correctement ce type de données, il doit bien faire deux choses :
1- une intelligence de découverte qui comprend quel outil convient à quel type de données
2- un mécanisme d'orchestration qui coordonne plusieurs appels d'outils indépendants.
Nous avons conçu la Tâche 5 spécifiquement pour mesurer ces deux capacités séparément.
AutoGen
AutoGen a livré une performance solide dans cette tâche, terminant avec 8 170 tokens de prompt et une latence médiane de 47 secondes, le résultat le plus rapide et le plus économe en tokens de la Tâche 5.
La boucle de conversation au cœur de son architecture, l'échange de messages entre AssistantAgent et UserProxyAgent, est généralement considérée comme une structure qui conduit à la verbosité. Cependant, dans la Tâche 5, cette structure s'est transformée en avantage.
En examinant l'historique de la conversation, le LLM a reconnu que les colonnes Metadata et SupportNotes étaient indépendantes l'une de l'autre. Il a ensuite envoyé une seule réponse TOOL CALLS listant 4 outils simultanément : inspect_column(Metadata), inspect_column(SupportNotes), parse_json_column(…) et summarize_text_column(…) se sont tous exécutés en parallèle. Cela lui a permis de terminer la tâche en 3 tours de LLM, avec le moins de tokens et le moins d'étapes.
La raison technique derrière ce comportement est claire : le moteur d'exécution d'outils d'AutoGen exécute la liste tool_calls renvoyée par le LLM de manière atomique et collecte les résultats en une seule étape de conversation. La philosophie du framework « gérer la conversation » permet naturellement d'ouvrir plusieurs canaux parallèles en même temps, et les chiffres de tokens et de latence le confirment directement.
LangGraph
LangGraph a terminé avec 9 150 tokens de prompt et une médiane de 70 secondes, proche d'AutoGen en tokens mais plus lent en temps. Son architecture de machine à états a montré à la fois sa plus grande force et sa faiblesse la plus notable simultanément dans la Tâche 5.
À chaque exécution, la boucle nœud llm → nœud tools → nœud llm accumule toutes les sorties d'outils précédentes dans l'état et les transmet au LLM. Cette structure garantit que l'agent n'oublie jamais rien, ce qui est normalement un avantage significatif.
Cependant, dans la Tâche 5, cette force s'est retournée contre lui. LangGraph trouvait les bons outils et construisait le bon segment. Mais même après la fin de l'analyse, il détectait des ambiguïtés dans l'état accumulé, interprétant des étapes terminées comme encore en attente, et déclenchait à plusieurs reprises des appels d'outils supplémentaires. Même s'il avait récupéré les données nécessaires et était sur le point de produire la bonne réponse, le signal « étape manquante » de la machine d'état s'est déclenché et l'agent est entré dans des boucles inutiles. En conséquence, le nombre d'appels d'outils par exécution variait entre 6 et 16. La puissance de l'état qui « n'oublie jamais rien » faisait parfois apparaître des étapes terminées comme incomplètes, ramenant l'agent dans des cycles redondants et augmentant la latence de 23 secondes par rapport à AutoGen malgré un nombre de tokens comparable.
CrewAI
La performance de CrewAI dans la Tâche 5 a produit la plus grande variance sur l'ensemble du benchmark. Dans certaines exécutions, il a suivi une séquence parfaite avec 5 appels d'outils, sans détour, s'exécutant comme un script. Dans ces exécutions, la structure managériale définie par les rôles et les tâches de CrewAI a fonctionné exactement comme prévu : lorsque l'agent comprenait clairement son rôle, il se comportait de manière prévisible et disciplinée.
Cependant, dans d'autres exécutions (par exemple, exécution 16 : 35 appels d'outils), le chaos complet s'est installé. La cause profonde était le monologue interne (Thought) que CrewAI génère à chaque étape. Après avoir correctement construit le segment avec le bon filtre, le monologue interne de l'agent a commencé à se demander si des filtres supplémentaires devaient également être appliqués. Après avoir vu le résultat, il a douté que le segment actuel soit valide ou que le précédent doive avoir la priorité. Ce doute l'a poussé à recharger les données depuis le début. Ensuite, il a filtré à nouveau, est entré dans une autre boucle de vérification, a douté à nouveau et a répété cette spirale 8 fois.
Dans CrewAI, chaque Thought produit une évaluation indépendante, et ces évaluations invalident parfois des étapes précédemment vérifiées. Le réflexe de « vérification continue » du processus managérial, dans certaines exécutions, a poussé l'agent à remettre en question ses propres décisions correctes.
LangChain
La structure AgentExecutor de LangChain est intrinsèquement séquentielle, et la Tâche 5 est là où cette contrainte était la plus visible. Avec 10 070 tokens de prompt et une médiane de 86 secondes, il était le framework le plus lent de cette tâche, bien qu'il n'ait pas le nombre de tokens le plus élevé.
Il effectue un seul appel d'outil à chaque étape, reçoit le résultat, puis passe à la suivante, ce qui signifie que 4 outils indépendants nécessitaient 4 tours distincts de LLM avec 4 périodes d'attente distinctes. La médiane de 47 secondes d'AutoGen contre les 86 secondes de LangChain est une mesure directe du coût de l'exécution séquentielle par rapport à l'exécution parallèle.
Dans la Tâche 5, le nombre d'outils de LangChain s'est stabilisé soit à 9, soit à 15. Ces deux groupes pointent vers deux stratégies typiques : dans certaines exécutions, il a sauté l'étape d'inspection et est passé directement à l'analyse syntaxique et au résumé (9 outils), tandis que dans d'autres, il a inspecté chaque colonne d'abord avant le traitement (15 outils). L'identité d'exécuteur linéaire de LangChain est devenue claire ici : il n'a montré ni l'efficacité parallèle d'AutoGen ni le chaos des monologues de CrewAI.
Gestion des données non structurées et architecture des frameworks
Les résultats de cette tâche révèlent que l'efficacité avec laquelle un framework peut gérer les données non structurées (JSON, LongText) est directement liée à son mécanisme de boucle interne :
Les frameworks capables d'appels d'outils parallèles (AutoGen) peuvent traiter des colonnes de données indépendantes en une seule étape. Dans les scénarios du monde réel impliquant de grands objets JSON et de nombreuses colonnes de texte, cette différence se traduit par un énorme avantage en termes de coût et de vitesse.
Les frameworks avec des boucles pilotées par l'état (LangGraph) excellent dans la cohérence des données, mais comportent le risque de réévaluer les étapes terminées accumulées dans l'historique.
Les frameworks basés sur le monologue (CrewAI) sont profondément capables de comprendre le type et la signification des données, mais cette profondeur se transforme parfois en remise en question excessive et en boucles.
Les frameworks d'exécution linéaire (LangChain) traitent séparément les différentes branches de données non structurées, produisant un résultat intermédiaire entre les deux mondes.
GitHub croissance des étoiles des frameworks agentiques
Comparer les frameworks d'IA agentique
Les frameworks d'IA agentique varient selon plusieurs dimensions clés, et il est essentiel de comprendre ces différences pour faire des comparaisons pertinentes.
Orchestration multi-agent
L'orchestration multi-agent coordonne plusieurs agents IA spécialisés pour aborder des workflows complexes qui dépassent les capacités d'un seul agent. Plutôt que de construire un agent monolithique, l'orchestration répartit le travail entre des agents ayant des rôles, des outils et une expertise distincts. Chaque framework offre des approches différentes pour la coordination des agents.
LangGraph
LangGraph est un framework relativement connu et se distingue comme une option clé pour les développeurs qui construisent des systèmes d'agents.
Coordination multi-agent explicite : Vous pouvez modéliser plusieurs agents comme des nœuds ou des groupes individuels, chacun avec sa propre logique, mémoire et rôle dans le système.
Il crée des flux de travail d'IA à travers les APIs et les outils. Ainsi, il est bien adapté pour le RAG et les pipelines personnalisés.
AutoGen
AutoGen permet à plusieurs agents de communiquer en échangeant des messages dans une boucle. Chaque agent peut répondre, réfléchir ou appeler des outils en fonction de sa logique interne.
Il dispose d'une collaboration asynchrone entre agents, ce qui le rend particulièrement utile pour les scénarios de recherche et de prototypage où le comportement de l'agent nécessite de l'expérimentation ou un affinement itératif.
CrewAI
CrewAI gère la plupart de la logique de bas niveau pour vous et fournit une orchestration multi-agent :
- S'intègre avec des outils de surveillance pour le traçage et le débogage
- Contrôle d'exécution intégré via des Flows avec logique conditionnelle, boucles et gestion d'état
- Prend en charge la coordination multi-agent hiérarchique (manager-worker) et structurée
OpenAI Swarm
Swarm est un framework multi-agent léger et expérimental pour le prototypage. Les agents travaillent séquentiellement par transferts, transférant des tâches tout en maintenant un contexte partagé. Il utilise des routines en langage naturel et des outils Python pour des flux de travail flexibles.
LangChain
LangChain est un framework pour construire des applications LLM à agent unique avec des outils RAG. Il fournit des composants modulaires incluant des chaînes, des outils, de la mémoire et de la récupération pour les flux de traitement de documents.
LangChain fonctionne principalement selon des schémas d'exécution à agent unique où un seul agent gère le flux de travail.
Définition de l'agent et des fonctions
LangGraph
LangGraph adopte une approche basée sur les graphes pour la conception d'agents, où chaque agent est représenté comme un nœud qui maintient son propre état. Ces nœuds sont connectés via un graphe orienté, permettant une logique conditionnelle, une coordination multi-équipe et un contrôle hiérarchique. Cela vous permet de construire et de visualiser des graphes multi-agents avec des nœuds superviseurs pour une orchestration évolutive.
LangGraph utilise des fonctions annotées et structurées qui attachent des outils aux agents. Vous pouvez construire des nœuds, les connecter à divers superviseurs et visualiser comment les différentes équipes interagissent. Pensez-y comme si vous donniez à chaque membre de l'équipe une description de poste détaillée. Cela facilite la construction et le test d'agents qui travaillent ensemble.
AutoGen
AutoGen définit les agents comme des unités adaptatives capables de routage flexible et de communication asynchrone. Les agents interagissent entre eux (et éventuellement avec des humains) en échangeant des messages, permettant une résolution collaborative des problèmes. Comme LangGraph, il utilise des fonctions annotées et structurées.
CrewAI
CrewAI adopte une approche de conception basée sur les rôles. Chaque agent se voit attribuer un rôle (par exemple, Chercheur, Développeur) et un ensemble de compétences, de fonctions ou d'outils auxquels il peut accéder. La définition des fonctions se fait via des annotations structurées.
OpenAI Swarm
OpenAI Swarm utilise un modèle basé sur les routines où les agents sont définis par des prompts et des docstrings de fonctions. Il n'a pas de modèles d'orchestration ou d'état formels, s'appuyant plutôt sur des flux de travail structurés manuellement. Le comportement des fonctions est inféré par le LLM via les docstrings (Swarm identifie ce que fait une fonction en lisant sa description), ce qui rend cette configuration flexible mais moins précise.
LangChain
LangChain utilise une architecture basée sur les chaînes où un seul agent orchestrateur gère les appels aux modèles de langage et à divers outils. Il définit les fonctions via des interfaces explicites comme les toolkits et les modèles de prompt.
Bien qu'essentiellement axé sur les workflows centralisés, LangChain prend en charge des extensions pour les configurations multi-agents, mais ne dispose pas de communication native d'agent à agent.
Mémoire
Capacités de mémoire :
- Avec état : Si le framework prend en charge une mémoire persistante entre les exécutions.
- Contextuel : S'il prend en charge la mémoire à court terme via l'historique des messages ou le passage de contexte.
Les fonctionnalités de mémoire sont un élément clé pour construire des systèmes agentiques capables de se souvenir du contexte et de s'adapter au fil du temps :
- Mémoire à court terme : Garde une trace des interactions récentes, permettant aux agents de gérer des conversations à plusieurs tours ou des flux de travail étape par étape.
- Mémoire à long terme : Stocke des informations persistantes entre les sessions, telles que les préférences de l'utilisateur ou l'historique des tâches.
- Mémoire d'entité : Suit et met à jour les connaissances sur des objets, des personnes ou des concepts spécifiques mentionnés lors des interactions (par exemple, se souvenir d'un nom d'entreprise ou d'un ID de projet mentionné précédemment).
LangGraph
LangGraph utilise deux types de mémoire : la mémoire intra-thread, qui stocke les informations pendant une seule tâche ou conversation, et la mémoire inter-thread, qui sauvegarde les données entre les sessions. Les développeurs peuvent utiliser MemorySaver pour sauvegarder le flux d'une tâche et le lier à un thread_id spécifique. Pour le stockage à long terme, LangGraph prend en charge des outils comme InMemoryStore ou d'autres bases de données. Cela offre un contrôle flexible sur la portée et la conservation de la mémoire entre les exécutions.
AutoGen
AutoGen utilise un modèle de mémoire contextuelle. Chaque agent maintient un contexte à court terme via un objet context_variables, qui stocke l'historique des interactions. Il ne dispose pas de mémoire persistante intégrée.
CrewAI
CrewAI fournit une mémoire en couches prête à l'emploi. Il stocke la mémoire à court terme dans un vector store ChromaDB, les résultats récents des tâches dans SQLite et la mémoire à long terme dans une table SQLite distincte (basée sur les descriptions de tâches). De plus, il prend en charge la mémoire d'entité via des embeddings vectoriels. Cette configuration de mémoire est automatiquement configurée lorsque memory=True est activé,
OpenAI Swarm
Swarm est sans état et ne gère pas la mémoire de manière native. Les développeurs peuvent transmettre manuellement la mémoire à court terme via context_variables, et éventuellement intégrer des outils externes ou des couches de mémoire tierces (par exemple, mem0) pour stocker un contexte à plus long terme.
LangChain
LangChain prend en charge à la fois la mémoire à court terme et à long terme grâce à des composants flexibles. La mémoire à court terme est généralement gérée via des tampons en mémoire qui suivent l'historique des conversations au sein d'une session. Pour la mémoire à long terme, LangChain s'intègre avec des vector stores ou des bases de données externes pour conserver les embeddings et les données de récupération.
Les développeurs peuvent personnaliser les portées et les stratégies de mémoire à l'aide de classes de mémoire intégrées, permettant une gestion efficace de la mémoire contextuelle et de la mémoire d'entité à travers les interactions.
Human-in-the-loop
LangGraph
LangGraph prend en charge les points d'arrêt personnalisés (interrupt_before) pour mettre en pause le graphe et attendre l'entrée de l'utilisateur en cours d'exécution.
AutoGen
AutoGen prend en charge nativement les agents humains via UserProxyAgent, permettant aux humains de réviser, d'approuver ou de modifier les étapes pendant la collaboration des agents.
CrewAI:
CrewAI permet d'obtenir un retour après chaque tâche en définissant human_input=True ; l'agent s'arrête pour recueillir une entrée en langage naturel de l'utilisateur.
OpenAI Swarm
OpenAI Swarm n'offre pas de HITL intégré.
LangChain
LangChain permet d'insérer des points d'arrêt personnalisés dans les chaînes ou les agents pour suspendre l'exécution et demander une intervention humaine. Cela prend en charge la révision, le retour d'information ou l'intervention manuelle à des points définis du flux de travail.
Intégration du Model Context Protocol (MCP) dans les frameworks d'IA agentique
Les agents d'IA ont besoin d'interagir avec des outils externes tels que des bases de données, des APIs, des systèmes de fichiers et des applications métier. Sans standard, chaque framework devait construire des intégrations personnalisées pour chaque outil, créant un écosystème fragmenté. MCP résout ce problème en fournissant un protocole universel qui permet à n'importe quel agent de se connecter à n'importe quel outil via une seule interface.
Comment chaque framework s'intègre à MCP
LangGraph
LangGraph se connecte aux serveurs MCP via un adaptateur qui découvre automatiquement les outils disponibles et les convertit au format compatible LangChain. Les agents peuvent ensuite utiliser ces outils de manière transparente en parallèle de leurs capacités natives.
AutoGen
AutoGen fournit une intégration MCP intégrée via son module d'extension. Les développeurs peuvent se connecter aux serveurs MCP et rendre tous leurs outils disponibles pour les agents AutoGen avec seulement quelques lignes de code.
CrewAI
Les agents CrewAI peuvent directement référencer les serveurs MCP dans leur configuration en utilisant de simples URL ou des paramètres structurés. Le framework gère automatiquement le cycle de vie de la connexion et la gestion des erreurs.
OpenAI Swarm
Swarm bénéficie du support MCP natif de OpenAI dans tout son écosystème. Comme OpenAI a intégré MCP dans ChatGPT et son SDK Agents, Swarm peut tirer parti de cette infrastructure directement.
LangChain
LangChain offre des capacités d'appel d'outils MCP où les fonctions Python agissent comme des ponts vers les serveurs MCP. Cela permet de récupérer des outils de diverses sources et de les intégrer dans des chaînes, des agents et d'autres composants LangChain sans wrappers personnalisés.
Ajouter comme source préféréeCe que font réellement les frameworks d'IA agentique ?
Les frameworks d'IA agentique assistent l'ingénierie des prompts et la gestion des flux de données vers et depuis les LLMs. À un niveau de base, ils aident à structurer les prompts pour que le LLM réponde dans un format prévisible et achemine les réponses vers le bon outil, la bonne API ou le bon document.
Si vous construisez à partir de zéro, vous définiriez manuellement le prompt, extrairiez l'outil que le LLM souhaite utiliser et déclencherez l'appel API correspondant. Les frameworks rationalisent cela en :
- Orchestration des prompts : Construction, gestion et routage de prompts complexes vers les LLMs
- Intégration d'outils : Permettre aux agents d'appeler des APIs externes, des bases de données, des fonctions de code, etc.
- Mémoire : Maintenir l'état entre les tours ou les sessions (à court et à long terme)
- Intégration RAG : Permettre la récupération de connaissances à partir de sources externes
- Coordination multi-agent : Structurer la façon dont les agents collaborent ou délèguent des tâches
Frameworks d'IA agentique : cas d'utilisation réels
LangGraph – Planificateur de voyage multi-agent
Un projet de production construit avec LangGraph démontre un assistant de voyage multi-agent avec état qui extrait des données de vols et d'hôtels (à l'aide des APIs Google Flights & Hotels) et génère des recommandations de voyage.3
CrewAI – Créateur de contenu agentique
Le dépôt d'exemples officiel de CrewAI inclut des flux tels que la planification de voyage, la stratégie marketing, l'analyse boursière et les assistants de recrutement, où des agents spécifiques à un rôle (par ex., « Chercheur », « Rédacteur ») collaborent sur des tâches.4
CrewAI transforme un brief de contenu de haut niveau en un article complet en utilisant Groq.
Fonctionnalités principales des frameworks d'IA agentique
Support des modèles :
- La plupart sont agnostiques au modèle, prenant en charge plusieurs fournisseurs de LLM (par ex., OpenAI, Anthropic, modèles open source).
- Cependant, les structures des prompts système varient selon le framework et peuvent mieux fonctionner avec certains modèles qu'avec d'autres.
- L'accès et la personnalisation des prompts système sont souvent essentiels pour obtenir des résultats optimaux.
Outillage :
- Tous les frameworks prennent en charge l'utilisation d'outils, un élément central pour permettre les actions des agents.
- Offrent des abstractions simples pour définir des outils personnalisés.
- La plupart prennent en charge le Model-Context-Protocol (MCP), de manière native ou via des extensions communautaires.
Mémoire / État :
- Utilisent le suivi d'état pour maintenir une mémoire à court terme entre les étapes ou les appels LLM.
- Certains aident les agents à conserver les interactions ou le contexte précédents au sein d'une session.
RAG (Retrieval-Augmented Generation) :
- La plupart incluent des options de configuration faciles pour le RAG, en intégrant des bases de données vectorielles ou des magasins de documents.
- Cela permet aux agents de référencer des connaissances externes pendant l'exécution.
Autres fonctionnalités communes
- Prise en charge de l'exécution asynchrone, permettant des appels d'agents ou d'outils simultanés.
- Gestion intégrée des sorties structurées (par ex., JSON).
- Prise en charge des sorties en streaming où le modèle génère des résultats de manière incrémentale.
- Fonctionnalités d'observabilité de base pour la surveillance et le débogage des exécutions d'agents.
Méthodologie du benchmark
1. Structure des tâches
Tâche 1 : Mesure si un seul appel d'outil peut être effectué avec le paramètre correct. La surcharge de l'infrastructure de base du framework est révélée le plus clairement dans ce scénario simple.
Tâche 2 : Nécessite de conserver les résultats de deux groupes de filtres distincts en mémoire et de les combiner en une seule sortie. La gestion d'état et la coordination multi-segments sont testées.
Tâche 3 : Mesure si les conditions numériques en langage naturel sont traduites en paramètres d'outil sans distorsion. Le véritable test est de savoir si les mécanismes de re-tentative et de reformulation du framework peuvent préserver ces paramètres.
Tâche 4 : Un outil lève des erreurs Réseau, Délai d'attente et Limite de débit successivement. On mesure si le framework change de stratégie face à ces erreurs.
Tâche 5 : L'agent doit d'abord découvrir les colonnes JSON et LongText, puis appeler les bons outils avec les bons paramètres de portée. On observe si le framework exécute les outils indépendants en parallèle ou séquentiellement.
À quoi ressemble réellement une tâche
Pour rendre la configuration concrète, voici la Tâche 5, la tâche la plus complexe du benchmark des frameworks d'IA agentique. Chaque framework a reçu le même prompt et le même ensemble d'outils ; seul le framework encapsulant le LLM changeait.
Prompt donné à l'agent :
Analysez les clients résiliés (Churn='Yes') qui paient plus de 100 en MonthlyCharges.
- Filtrez le jeu de données pour ne garder que Churn='Yes'.
- Inspectez les colonnes 'Metadata' et 'SupportNotes' pour découvrir leurs types de données.
- Extrayez la distribution de 'device_type' de la colonne JSON 'Metadata'.
- Comptez les mots-clés de réclamation à partir de la colonne de texte gratuit 'SupportNotes'.
Retournez le résultat sous forme de JSON uniquement.
Sortie JSON requise :
Pourquoi cette tâche discrimine les frameworks : l'agent doit planifier une chaîne de quatre appels d'outils, conserver le segment filtré dans l'état à travers chaque appel et reconnaître qu'une colonne est du texte JSON tandis que l'autre est du texte gratuit. Un framework qui exécute les colonnes indépendantes en parallèle (AutoGen) termine beaucoup plus vite qu'un framework qui les exécute séquentiellement (LangChain), et un framework qui réévalue les étapes terminées (LangGraph, CrewAI) boucle inutilement. Le schéma strict JSON nous permet de noter la correction automatiquement.
2. Configuration
Tous les frameworks ont utilisé le même modèle LLM (openai/gpt-5.2) et la même valeur de température (0.1). Pour toutes les tâches, chaque agent a reçu les mêmes outils et les mêmes prompts. Chaque framework a été configuré dans sa structure native : LangChain avec AgentExecutor, LangGraph avec StateGraph, AutoGen avec AssistantAgent + UserProxyAgent, et CrewAI avec Agent + Task + Crew.
Le jeu de données IBM Telco Customer Churn (7 032 clients) a été utilisé. L'état des outils a été réinitialisé avant chaque exécution. 100 exécutions indépendantes ont été effectuées pour chaque combinaison framework et tâche.
Les limites maximales d'itérations ont été définies en fonction de la complexité des tâches : 10 pour les Tâches 1, 2 et 3 ; 20 pour la Tâche 4 en raison de la boucle d'outil instable ; et 20 pour la Tâche 5 en raison de la chaîne de découverte en 4 étapes.
Citez ce benchmark
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{Top 5 des frameworks d'IA agentique open source}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/agentic-frameworks}},
note = {AIMultiple. Consulté le 10 Août 2026}
}Liens de référence
Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes, Washington Post, des entreprises mondiales comme Deloitte, HPE et des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne.
Tout au long de sa carrière, Cem a exercé en tant que consultant tech, acheteur tech et entrepreneur tech. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus d'une décennie. Il a également publié un rapport McKinsey sur la numérisation.
Il a dirigé la stratégie technologique et les achats d'un opérateur télécom tout en rendant compte au PDG. Il a également mené la croissance commerciale de l'entreprise deep tech Hypatos qui a atteint un chiffre d'affaires récurrent annuel à 7 chiffres et une valorisation à 9 chiffres à partir de 0 en 2 ans. Le travail de Cem chez Hypatos a été couvert par des publications technologiques de premier plan comme TechCrunch et Business Insider.
Cem intervient régulièrement lors de conférences technologiques internationales. Il est diplômé de la Bogazici University en tant qu'ingénieur informatique et détient un MBA de la Columbia Business School.
Commentaires 1
Partagez vos idées
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.
Thank you for this informative and detailed article! It helped me get a reading on these frameworks.