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 chacune 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 de l'agent 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 faibles 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 s'impose comme le framework le plus efficace en tokens, tandis qu'AutoGen est en tête sur la latence ; LangGraph et LangChain suivent de près. CrewAI présente le profil global le plus lourd.
Tâche 1 : Agrégation de base
D'abord, nous avons mesuré la surcharge de chaque framework lors de l'appel d'un seul outil et du renvoi du résultat, sans effectuer de raisonnement complexe.
LangChain et LangGraph : Pour les tâches simples, ils sont presque aussi rapides que du code non agentique, et terminent tous deux en moins de 5 secondes avec moins de 900 tokens de prompt. L'architecture à machine d'état de LangGraph n'introduit aucune latence notable 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 de LangGraph tant en latence qu'en consommation de tokens, reflétant le coût de base de sa boucle de conversation multi-agents, où deux agents échangent des messages même pour une tâche en une seule étape.
CrewAI : Même lorsqu'on lui demande un simple 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 Planner et Analyst offre une approche approfondie mais gourmande en ressources, qui privilégie l'exhaustivité à la vitesse. 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 observer la capacité des frameworks à conserver deux groupes de filtres différents en mémoire (persistance d'état) et à les combiner.
CrewAI
Dans 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 par un mécanisme d'auto-révision. Ce comportement exploratoire l'a amené à atteindre la limite configurée max_iter=10, 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 multicouches dans le prompt système, en attribuant à chaque agent un rôle, un objectif et un historique, tout en imposant une boucle de type ReAct « Pensée → Action → Observation » à chaque étape. Même pour des tâches simples, le LLM ne peut pas sauter ce cérémonial et produit consciencieusement des monologues internes verbeux, qui se cumulent davantage dans les scénarios multi-agents.
CrewAI a consommé presque deux fois plus de tokens que les autres frameworks et a mis plus de trois fois plus de temps que LangChain, ce qui le rend plus adapté aux transitions d'état complexes et aux prises de décision multifactorielles qu'aux simples tâches de récupération de données.
LangChain
Le framework le plus rapide et le plus rentable. Dans nos logs, nous avons observé que LangChain accomplit la tâche en 5 à 6 étapes sans détour : Charger → Filtrer → Calculer → Filtrer → Calculer → Sortir. Sa gestion d'état étant très simple, la surcharge est presque nulle et la latence est la plus faible de tous les frameworks.
AutoGen
A livré une performance très équilibrée. Dans la tâche 2, il a presque exactement égalé LangGraph tant en utilisation de tokens qu'en latence, montrant que la surcharge de la boucle de conversation ne se cumule pas significativement 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 immédiatement à jour son raisonnement à l'étape suivante et aboutit au bon JSON. Comme il gère les sorties d'outils comme un flux conversationnel, c'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é très proprement 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 les 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 des conditions numériques en langage naturel, comme « 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 mécanismes de nouvelle tentative, de re-prompt et de ses cycles de gestion d'état.
LangChain et LangGraph
Les deux frameworks ont transmis les paramètres (tenure_max=12, charges_min=70) directement à l'outil exactement comme le LLM les avait produits, sans modification ni boucle de re-prompt. Cette efficacité se reflète dans les chiffres : les deux frameworks ont accompli la tâche 3 en moins de 9 secondes avec moins de 1 800 tokens de prompt, le plus bas de cette tâche.
Lorsque nous voulions mesurer si les seuils numériques sont préservés sans interférence du framework, 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 sur le plan de la justesse 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 passait 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é dans CrewAI, qui a accompli la tâche 3 en 30 secondes avec 4 360 tokens, le plus élevé de cette tâche. Deux modèles 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 sous forme de 0.6878 (ratio décimal). Cela indique que la sérialisation de sortie du framework peut dépouiller la sortie du LLM de son contexte d'origine.
Les logs montrent que le LLM a d'abord produit les paramètres corrects, tenure_max=12 et charges_min=70. Cependant, une fois que CrewAI est entré dans une boucle « Échec de l'analyse », le framework a poussé le LLM à reconsidérer. Dans le contexte de re-prompt, le LLM a déplacé le seuil vers tenure_max=14 et a complètement désactivé le filtre charges_min, produisant un taux d'attrition de 46.84 %, qui est en réalité le taux d'attrition 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 trouvé correct.
Tâche 4 : Résilience aux erreurs et capacité de pivot
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 renvoie 3 types d'erreurs différents successivement (Network, Timeout, Rate Limit), poussant l'agent dans une impasse. Les deux premières erreurs demandent à l'agent de réessayer, et après avoir réessayé les deux, l'erreur Rate Limit entrante demande à l'agent d'attendre 10 secondes. Une fois que l'agent a attendu et réessayé, l'outil se met à fonctionner normalement.
LangGraph et Autogen
Ces deux frameworks ont trouvé des solutions alternatives de manière autonome lorsqu'ils ont été confrontés à des défaillances d'outil 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 d'attrition pour chacune séparément, puis combiner les résultats moi-même. »
Méthode : Au lieu d'accomplir la tâche en 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 (Electronic check, Mailed check, etc.) individuellement.
Ces agents fonctionnent avec un raisonnement orienté vers l'objectif plutôt qu'une dépendance au chemin. Si le chemin le plus court est indisponible, 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 sur l'ensemble du benchmark, car sa machine d'état a accumulé 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 grâce à son traitement conversationnel des résultats intermédiaires. Malgré cela, les deux ont terminé en environ 24-27 secondes, confirmant que le coût supplémentaire en tokens ne s'est pas traduit par une latence significative car le pivot lui-même était rapide.
CrewAI
Malgré la consommation de tokens la plus élevée dans les tâches précédentes, CrewAI a affiché la plus faible consommation de tokens) mais les valeurs de latence les plus élevées dans cette tâche.
Pourquoi le moins de tokens ?
CrewAI n'a pas eu recours à une solution de contournement manuelle de 10-15 étapes comme ses concurrents. Lorsqu'il a rencontré des erreurs, au lieu de renvoyer en boucle tout l'historique et les données intermédiaires complexes dans le LLM à chaque étape, il a construit une boucle de raisonnement plus ciblée et modulaire. En évitant la verbosité inutile, il est devenu le framework le plus rentable 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'il a reçu l'avertissement d'attente de 10 secondes, il a passé plus de temps dans la phase de « planification stratégique ». De plus, plutôt que de pivoter vers un autre outil de filtrage, il a persisté à attendre que l'outil principal se rétablisse ou à tenter avec l'outil stable, ce qui a prolongé la durée globale.
LangChain
LangChain a connu sa transformation la plus significative dans cette tâche, prouvant pourquoi la résilience dépend d'une configuration adéquate.
Lors de notre première exécution, LangChain a planté à chaque tentative avec une ConnectionError.
Le AgentExecutor par défaut de LangChain traite les exceptions Python brutes levées à l'intérieur d'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 enveloppé 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é le correctif, nous avons observé dans les logs de LangChain qu'il a présenté 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, puis a combiné les résultats.
LangChain est en réalité tout aussi capable et adaptatif que LangGraph, mais comme 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 des agents 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 de boucle interne propres aux frameworks :
1. LangGraph et AutoGen (90 % de pivot) :
LangGraph fonctionne sur une architecture de machine à états, tandis qu'AutoGen repose 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 coup de pouce constant force l'agent à continuer de chercher une solution. Comme l'agent est confronté à plusieurs reprises à la question « J'ai une erreur, que dois-je faire ? », la probabilité qu'il décide d'emprunter un chemin manuel alternatif monte à 90 %.
2. LangChain (65 % de pivot / 35 % d'attente) :
LangChain repose sur une architecture séquentielle AgentExecutor. Même avec la gestion des erreurs en place, sa boucle d'exécution a une structure plus linéaire et se concentre principalement sur la production d'une réponse finale. Si l'outil renvoie des erreurs pendant 3 à 4 étapes, LangChain préfère parfois attendre que l'outil réussisse à la tentative suivante ou produire un résultat à partir du contexte existant, plutôt que de pivoter vers une stratégie alternative. Comme 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 % de pivot) :
CrewAI fonctionne sur une architecture de processus managérial. Ses agents sont enveloppé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. C'est fondamentalement une approche centrée sur le plan, par opposition à une approche centrée sur l'objectif.
Tâche 5 : Orchestration des données non structurées (routage des 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, séquentiellement ou en 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 efficace en tokens de la tâche 5.
La boucle de conversation au cœur de son architecture, la messagerie 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 d'accomplir la tâche en 3 tours du LLM, avec le moins de tokens et le moins d'étapes.
La raison technique de 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 « gérer la conversation » du framework 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 sur les tokens mais plus lent en temps. Son architecture de machine à états a montré simultanément sa plus grande force et sa faiblesse la plus notable dans la tâche 5.
À chaque exécution, la boucle nœud LLM → nœud d'outils → 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 a joué contre lui. LangGraph trouvait les bons outils et construisait le bon segment. Mais même après la fin de l'analyse, il a détecté des ambiguïtés dans l'état accumulé, interprétant les étapes terminées comme encore en attente, et a déclenché à 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 à états 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 capacité de l'état à « ne jamais rien oublier » faisait parfois apparaître des étapes terminées comme incomplètes, ramenant l'agent dans des cycles redondants et poussant la latence 23 secondes au-dessus d'AutoGen malgré un nombre de tokens comparable.
CrewAI
La performance de CrewAI à la tâche 5 a produit la plus forte variance de tout le benchmark. Dans certaines exécutions, il a suivi une séquence sans faille 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, l'exécution 16 : 35 appels d'outils), un chaos complet s'en est suivi. 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 prévaloir. Ce doute l'a poussé à recharger les données depuis le début. Puis 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 c'est dans la tâche 5 que cette contrainte a été la plus visible. Avec 10 070 tokens de prompt et une médiane de 86 secondes, il a été 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 suite, ce qui signifie que 4 outils indépendants ont nécessité 4 tours distincts du 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é à 9 ou 15. Ces deux groupes indiquent deux stratégies typiques : dans certaines exécutions, il a sauté l'étape d'inspection et est passé directement à l'analyse et au résumé (9 outils), tandis que dans d'autres, il a d'abord inspecté chaque colonne avant de la traiter (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 monologué 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 des 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 réels 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 des étapes terminées accumulées dans l'historique.
Les frameworks basés sur le monologue (CrewAI) sont tout à fait capables de comprendre le type et la signification des données, mais cette profondeur se transforme parfois en questionnements excessifs et en boucles.
Les frameworks à exécution linéaire (LangChain) traitent séparément les différentes branches des 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 agentiques
Les frameworks d'IA agentiques varient selon plusieurs dimensions clés, et comprendre ces différences est essentiel pour établir des comparaisons significatives.
Orchestration multi-agents
L'orchestration multi-agents 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 dotés de rôles, d'outils et d'expertises distincts. Chaque framework propose différentes approches de 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-agents explicite : Vous pouvez modéliser plusieurs agents comme des nœuds individuels ou des groupes, chacun avec sa propre logique, sa propre mémoire et son propre rôle dans le système.
Il crée des workflows d'IA à travers les APIs et les outils. Ainsi, il convient bien au RAG et aux 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 selon sa logique interne.
Il offre une collaboration d'agents asynchrone, 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 raffinement itératif.
CrewAI
CrewAI gère la plupart de la logique de bas niveau pour vous et fournit une orchestration multi-agents :
- S'intègre aux outils de surveillance pour le traçage et le débogage
- Contrôle d'exécution intégré grâce aux Flows avec logique conditionnelle, boucles et gestion d'état
- Prend en charge la coordination multi-agents hiérarchique (manager-worker) et structurée
OpenAI Swarm
Swarm est un framework multi-agents léger et expérimental pour le prototypage. Les agents travaillent séquentiellement par transferts, en transférant les tâches tout en maintenant un contexte partagé. Il utilise des routines en langage naturel et des outils Python pour des workflows flexibles.
LangChain
LangChain est un framework pour créer des applications LLM mono-agents avec des outils RAG. Il fournit des composants modulaires, notamment des chaînes, des outils, de la mémoire et de la récupération pour les workflows de traitement de documents.
LangChain fonctionne principalement selon des modèles d'exécution mono-agent où un seul agent gère le workflow.
Définition des agents 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 par un graphe orienté, permettant la logique conditionnelle, la coordination multi-équipes et le 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 à différents superviseurs et visualiser la manière dont les différentes équipes interagissent. C'est comme donner à 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, ce qui permet 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 par 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 formels d'orchestration ou d'état, s'appuyant plutôt sur des workflows structurés manuellement. Le comportement des fonctions est déduit par le LLM à travers 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 des chaînes où un seul agent orchestrateur gère les appels vers les modèles de langage et divers outils. Il définit les fonctions par des interfaces explicites comme les toolkits et les modèles de prompt.
Bien qu'il soit principalement axé sur les workflows centralisés, LangChain prend en charge des extensions pour les configurations multi-agents, mais ne dispose pas de communication native entre agents.
Mémoire
Capacités de mémoire :
- Avec état : Indique si le framework prend en charge la mémoire persistante entre les exécutions.
- Contextuel : Indique 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é de la construction de systèmes agentiques pour mémoriser le contexte et s'adapter au fil du temps :
- Mémoire à court terme : assure le suivi des interactions récentes, permettant aux agents de gérer des conversations à plusieurs tours ou des workflows étape par étape.
- Mémoire à long terme : stocke des informations persistantes entre les sessions, comme les préférences utilisateur ou l'historique des tâches.
- Mémoire d'entité : suit et met à jour les connaissances sur des objets, personnes ou concepts spécifiques mentionnés lors des interactions (par exemple, mémoriser un nom d'entreprise ou un identifiant de projet mentionné plus tôt).
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 enregistre les données entre les sessions. Les développeurs peuvent utiliser MemorySaver pour enregistrer 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 grâce à 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 une base vectorielle ChromaDB, les résultats récents des tâches dans SQLite, et la mémoire à long terme dans une table SQLite séparée (basée sur les descriptions de tâches). De plus, il prend en charge la mémoire d'entité à l'aide d'embeddings vectoriels. Cette configuration de mémoire est automatiquement activé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 de conversation au sein d'une session. Pour la mémoire à long terme, LangChain s'intègre à des bases vectorielles ou à des bases de données externes pour conserver les embeddings et les données de récupération.
Les développeurs peuvent personnaliser la portée et les stratégies de mémoire à l'aide de classes de mémoire intégrées, ce qui permet une gestion efficace de la mémoire contextuelle et de la mémoire spécifique aux entités entre les interactions.
Humain dans la boucle
LangGraph
LangGraph prend en charge des points d'arrêt personnalisés (interrupt_before) pour mettre le graphe en pause et attendre la saisie de l'utilisateur en cours d'exécution.
AutoGen
AutoGen prend en charge nativement les agents humains via UserProxyAgent, permettant aux humains d'examiner, d'approuver ou de modifier des é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 fait une pause pour recueillir une saisie en langage naturel de l'utilisateur.
OpenAI Swarm
OpenAI Swarm n'offre pas de fonction HITL intégrée.
LangChain
LangChain permet d'insérer des points d'arrêt personnalisés dans les chaînes ou les agents pour interrompre l'exécution et demander une saisie humaine. Cela prend en charge l'examen, le retour ou l'intervention manuelle à des points définis du workflow.
Intégration du Model Context Protocol (MCP) dans les frameworks d'IA agentiques
Les agents IA doivent interagir avec des outils externes comme des bases de données, des APIs, des systèmes de fichiers et des applications métier. Sans standard, chaque framework devait créer 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 dans un format compatible LangChain. Les agents peuvent ensuite utiliser ces outils de manière transparente avec 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 aux agents AutoGen en quelques lignes de code.
CrewAI
Les agents CrewAI peuvent référencer directement les serveurs MCP dans leur configuration à l'aide d'URL simples ou de paramètres structurés. Le framework gère automatiquement le cycle de vie des connexions et la gestion des erreurs.
OpenAI Swarm
Swarm bénéficie du support natif de OpenAI pour MCP dans son écosystème. Comme OpenAI a intégré MCP dans ChatGPT et son Agents SDK, Swarm peut exploiter directement cette infrastructure.
LangChain
LangChain offre des capacités d'appel d'outils MCP où les fonctions Python servent de 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éeQue font réellement les frameworks d'IA agentiques ?
Les frameworks d'IA agentiques aident à l'ingénierie des prompts et à la gestion de la manière dont les données circulent 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 à acheminer les réponses vers le bon outil, la bonne API ou le bon document.
Si vous construisiez à partir de zéro, vous définiriez manuellement le prompt, extrairiez l'outil que le LLM souhaite utiliser et déclencheriez l'appel API correspondant. Les frameworks rationalisent cela en :
- Orchestration des prompts : création, 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 de RAG : permettre la récupération de connaissances à partir de sources externes
- Coordination multi-agents : structurer la manière dont les agents collaborent ou délèguent des tâches
Frameworks d'IA agentiques : cas d'utilisation réels
LangGraph – Planificateur de voyage multi-agents
Un projet de production construit avec LangGraph démontre un assistant de voyage multi-agents avec état qui récupère des données de vols et d'hôtels (à l'aide des Google Flights & Hotels APIs) et génère des recommandations de voyage.3
CrewAI – Créateur de contenu agentique
Le dépôt d'exemples officiel de CrewAI comprend des flux comme la planification de voyages, la stratégie marketing, l'analyse boursière et les assistants de recrutement, où des agents spécifiques à un rôle (par exemple, « Researcher », « Writer ») collaborent sur des tâches.4
CrewAI transforme un brief de contenu de haut niveau en un article complet à l'aide de Groq.
Fonctionnalités de base des frameworks d'IA agentiques
Prise en charge des modèles :
- La plupart sont agnostiques au modèle, prenant en charge plusieurs fournisseurs de LLM (par exemple, OpenAI, Anthropic, modèles open source).
- Cependant, les structures de prompts système varient selon le framework et peuvent fonctionner mieux 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 de l'activation des actions des agents.
- Offrent des abstractions simples pour définir des outils personnalisés.
- La plupart prennent en charge le Model-Context-Protocol (MCP), soit nativement, soit via des extensions communautaires.
Mémoire / État :
- Utilisent un suivi d'état pour maintenir la mémoire à court terme entre les étapes ou les appels au LLM.
- Certains aident les agents à conserver les interactions ou le contexte antérieurs 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 stockages de documents.
- Cela permet aux agents de référencer des connaissances externes pendant l'exécution.
Autres fonctionnalités courantes
- Prise en charge de l'exécution asynchrone, permettant des appels simultanés d'agents ou d'outils.
- Gestion intégrée des sorties structurées (par exemple, JSON).
- Prise en charge des sorties en streaming où le modèle génère les résultats de manière incrémentale.
- Fonctionnalités d'observabilité de base pour surveiller et déboguer les 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 bon paramètre. La surcharge de l'infrastructure de base du framework est la plus clairement révélée dans ce scénario simple.
Tâche 2 : nécessite de conserver en mémoire les résultats de deux groupes de filtres distincts 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 nouvelle tentative et de re-prompt du framework peuvent préserver ces paramètres.
Tâche 4 : un outil renvoie successivement des erreurs Network, Timeout et RateLimit. 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 agentiques. Chaque framework a reçu le même prompt et le même ensemble d'outils ; seul le framework enveloppant le LLM a changé.
Prompt donné à l'agent :
Analysez les clients résiliés (Churn=’Yes’) qui paient plus de 100 en MonthlyCharges.
- Filtrez le dataset pour 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 dans la colonne de texte gratuit ‘SupportNotes’.
Renvoyez le résultat uniquement sous forme de JSON.
Sortie JSON requise :
Pourquoi cette tâche distingue-t-elle les frameworks : l'agent doit planifier une chaîne de quatre appels d'outils, conserver le segment filtré dans l'état à chaque appel et reconnaître qu'une colonne est du 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 JSON strict nous permet de noter automatiquement la justesse.
2. Configuration
Tous les frameworks ont utilisé le même modèle de 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 dataset 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é réalisées pour chaque combinaison framework et tâche.
Les limites maximales d'itération 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}
}Résultats et horodatages de 0 points de données. Téléchargez les données utilisées dans cet article sous forme de fichier ZIP contenant 0 fichiers CSV et un README.
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.
À lire ensuite
Top 5 API de scraping d'offres d'emploi API comparés
Benchmark MFT: Files.com, Diplomat, Cerberus et Serv-U testés
Meilleures API de Scraping Zillow API Comparées: Analyse de Performance
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.