AutoGen et CrewAI comparés : création d’équipes d’agents, calcul de leurs coûts.

Pendant longtemps, dans le domaine des applications basées sur les LLM, l’interaction avec une intelligence artificielle était représentée comme un cycle simple : quelqu’un tape une requête, un modèle répond, et la conversation se poursuit. Cela fonctionne bien pour répondre à des questions. Cependant, cela commence à poser des problèmes dès qu’il s’agit d’accomplir une tâche concrète, comme écrire et déboguer un programme, planifier un rapport de recherche, ou exécuter un flux de travail en plusieurs étapes impliquant plusieurs outils et sources de données.

Les systèmes multi-agents existent pour combler cette lacune. Au lieu de demander à une seule instruction monolithique de gérer tout le travail, la tâche est divisée en rôles : un ingénieur, un critique, un chercheur, un écrivain. Chaque rôle devient un agent, qui n’est rien de plus qu’un conteneur autour d’un LLM doté de sa propre personnalité, de sa propre mémoire et de ses propres responsabilités. Les agents communiquent entre eux, échangent des résultats partiels, se critiquent mutuellement et itèrent jusqu’à ce que le travail soit terminé. L’expérience ressemble moins à celle de consulter un oracle qu’à celle de gérer une petite équipe très rapide.

Deux frameworks dominent ce domaine et sont comparés ici : AutoGen, issu de Microsoft Research et disponible en open source, et CrewAI, une plateforme plus récente conçue en tenant compte des workflows d’entreprise. Un troisième outil, AgentOps, ajoute une couche d’observabilité permettant de voir ce que font les agents et quel en est le coût.

Rôles plutôt qu’une seule grande instruction

Le changement conceptuel précède toute mise en place d’outils. Dans une configuration à un seul agent, un prompt système remplit deux fonctions en même temps : définir une personnalité et anticiper ce à quoi le modèle pourrait être confronté. Les frameworks multi-agents répartissent la charge. Chaque agent reçoit une description de tâches plus précise, composée d’une personnalité, d’un objectif et, parfois, d’un contexte historique qui influence son approche.

Cela imite le fonctionnement des équipes humaines. Un ingénieur senior n’est pas en même temps le responsable des tests qualité, le chef de projet et l’auteur technique. En répartissant ces fonctions entre des agents, on obtient trois avantages pratiques :

• La spécialisation améliore la qualité. Un agent dont la seule mission est de vérifier le code en quête de problèmes de sécurité l’examinera de manière plus cohérente qu’un généraliste qui doit gérer plusieurs objectifs en même temps.
• Les boucles de feedback deviennent explicites. En dirigeant la sortie d’un agent vers un autre dont la tâche est de la critiquer, on crée un cycle d’évaluation délibéré, au lieu d’espérer que le même modèle détecte ses propres erreurs.
• Le travail en parallèle devient possible. Dans des systèmes plus complexes, les agents peuvent s’attaquer en même temps à différentes parties d’un objectif plus large, un agent de recherche et un agent d’écriture s’occupant de sous-tâches distinctes.

La partie difficile, que chaque framework résout à sa manière, est la communication. Comment les agents échangent-ils des informations ? Partagent-ils une même conversation, ou ont-ils des échanges isolés qui ne se croisent que rarement ? Les réponses diffèrent entre AutoGen et CrewAI, et cette différence influence tout le reste.

AutoGen : tout est une conversation

AutoGen de Microsoft considère chaque interaction entre agents comme une conversation. Sa décision de base est que les agents communiquent entre eux en langue naturelle, de la même manière que les gens le font dans une discussion en ligne. Cela en fait une solution intuitive : toute personne ayant vu deux collègues dans un canal Slack échanger pour affiner une idée possède déjà le modèle mental sous-jacent aux agents conversationnels d’AutoGen.

Essayer AutoGen Studio

Avant même d’écrire le moindre code Python, AutoGen Studio propose un moyen graphique d’expérimenter. Il s’installe via pip, lit une clé API à partir d’une variable d’environnement et démarre à partir d’une seule commande en ligne de commande. Une interface navigateur s’ouvre alors. Il suffit d’y saisir une tâche, et un agent proxy utilisateur travaille avec un ou plusieurs agents assistants jusqu’à ce que la tâche soit terminée.

Le schéma qui se dégage mérite d’être appris, car il réapparaît partout. Supposons que la demande soit de représenter l’popularité d’un terme de recherche au fil du temps. L’agent assistant commence alors à générer des extraits de code pour les sous-tâches. L’agent proxy de l’utilisateur exécute ces extraits dans un environnement isolé et évalue si le résultat est correct. Si le code échoue ou que la sortie est erronée, le proxy envoie des retours d’information, l’assistant procède à des modifications, et le cycle de codage, d’exécution, d’évaluation et de révision se poursuit jusqu’à ce que le proxy soit satisfait.

Cette boucle automatise la partie manuelle de l’examen du code. Lors d’une session normale, un développeur écrit du code, le lance, observe ses échecs et corrige personnellement les bugs. Ici, le proxy prend en charge l’étape de lancement et de vérification, permettant ainsi à une personne de s’éloigner pendant que les deux agents résolvent le problème. Ce système n’est pas parfait, car des bibliothèques modifiées ou des fonctionnalités obsolètes peuvent parfois poser des problèmes aux agents, mais il est remarquablement efficace pour les problèmes bien définis. La génération d’images, la visualisation de données et les applications courtes terminent souvent en quelques itérations seulement.

Une recommandation revient constamment : exécuter AutoGen et AutoGen Studio dans Docker chaque fois que le code généré pourrait interagir avec le système d’exploitation sous-jacent. Les agents étant conçus pour écrire et exécuter du code arbitraire, un conteneur protège l’hôte des effets secondaires. Ce conseil gagne en importance à mesure que les agents obtiennent plus d’autonomie.

Compétences en tant que capacités supplémentaires

Studio se démarque par quelques outils intégrés seulement, tels que la récupération de contenu web ou la génération d’images. Sa véritable force réside dans les compétences personnalisées. Une compétence correspond à une fonction Python ordinaire dotée d’un nom clair et d’une documentation bien rédigée, et le framework lit cette documentation pour déterminer quand et comment l’appeler.

Un exemple concret montre comment utiliser la compétence describe_image, qui envoie une image à un modèle doté de capacités visuelles et reçoit une description en retour. En étant intégrée à l’assistant principal, elle permet de formuler des demandes très précises : créer une couverture de livre pour un titre donné, puis utiliser la compétence image-description pour vérifier que le texte du titre est orthographié correctement. Les générateurs d’images sont connus pour leur faible capacité à produire du texte lisible, ce qui rend ce mécanisme de vérification particulièrement utile. L’assistant génère une image, la compétence visuelle vérifie l’orthographe des lettres, et si elle est incorrecte, l’assistant tente à nouveau. La création de petits outils bien documentés permet d’obtenir un fonctionnement étonnamment fiable.

Une philosophie de conception sous-tend ce système. Plutôt que de compter sur les agents pour écrire du code entièrement nouveau pour chaque besoin, il est souvent plus fiable de leur fournir une bibliothèque fixe de compétences éprouvées. Le code généré en temps réel par un LLM peut tomber en panne lorsque les bibliothèques évoluent ou que les dépendances changent, tandis qu’une compétence testée et emballée se comporte de manière prévisible. La question de savoir si les agents doivent écrire du code dynamiquement ou utiliser des outils prédéfinis sera abordée plus tard dans les discussions sur la planification et l’action, et c’est l’une des décisions les plus importantes lors de la conception d’un système d’agents.

Code brut avec pyautogen

Après Studio, l’étape suivante consiste à écrire du Python en utilisant le package pyautogen. Deux éléments clés sont importants :

• ConversableAgent est un agent polyvalent qui communique directement avec un LLM.
• UserProxyAgent représente l’utilisateur humain et peut exécuter du code dans un répertoire de travail.

Une configuration minimale relie les deux éléments et lance une conversation, par exemple en demandant une solution en une seule ligne pour le jeu FizzBuzz. Lorsqu’il est exécuté, le proxy demande des retours après que l’assistant ait proposé quelque chose. Appuyer sur Entrée sans donner de retour indique au proxy de passer directement à l’exécution du code. Si un paquet nécessaire, comme Pygame, est manquant, le proxy le installe avant d’exécuter le programme. Ce mécanisme d’auto-provisionnement est un signe, bien que mineur, de la liberté que ces systèmes peuvent avoir, avec à la fois des avantages et des inconvénients.

Des défis de programmation utiles pour évaluer un modèle incluent la vérification du fait qu’un nombre est premier, la création d’un jeu Snake et la réalisation d’une version clonée d’Asteroids avec Pygame. Ceux-ci sont autonomes, testables et suffisamment variés en difficulté pour mettre en évidence les différences entre les modèles ou les configurations.

Intégration d’un critique via des chats imbriqués

Un assistant ainsi qu’un proxy sont utiles, mais les systèmes multi-agents se distinguent grâce à des personnalités spécialisées. Un deuxième assistant peut servir de réviseur de code, avec un message système qui le pousse à être méticuleux, strict en matière de normes et axé sur les problèmes de sécurité et de qualité.

Plutôt que d’intégrer directement le critique dans la conversation principale, AutoGen propose des chats imbriqués. Le proxy de l’utilisateur enregistre un chat imbriqué qui s’active chaque fois que l’agent ingénieur génère de nouvelles sorties. Le code est automatiquement envoyé au critique, au sein d’une conversation secondaire ; le critique répond par une revue, qui est ensuite renvoyée dans le fil principal. Une étape de revue est insérée sans que le critique perturbe chaque échange, et il ne parle que lorsqu’il y a quelque chose de nouveau à examiner.

Dans une tâche comme l’écriture d’un jeu Snake avec Pygame, la différence par rapport à une simple exécution par un ingénieur accompagné d’un proxy est notable. Une fois le code exécuté, un critique fournit une liste d’améliorations suggérées, reproduisant ainsi efficacement l’examen des demandes de fusion que les équipes humaines effectuent quotidiennement.

Cachage pour contrôler les coûts

Les conversations impliquant plusieurs agents deviennent rapidement coûteuses. Chaque échange consomme des tokens, et les tâches complexes peuvent nécessiter des dizaines de tours. AutoGen intègre un système de cachage : par défaut, l’état de la conversation est enregistré sur disque dans un dossier .cache, permettant ainsi de reprendre une tâche longue ou interrompue sans devoir payer à nouveau pour les mêmes tokens.

Ce comportement peut être défini explicitement en enveloppant l’appel de chat dans un gestionnaire de contexte qui fournit un cache_seed. Il est facile de sous-estimer l’importance de ce point. Dans le développement d’agents, il est courant de vouloir rejouer ou auditer une exécution antérieure plutôt que de la régénérer, que ce soit pour déboguer ou pour montrer aux parties prenantes exactement comment l’agent est parvenu à une sortie.

Chat de groupe et le problème du téléphone

Les chats imbriqués présentent une faiblesse structurelle qui rappelle le jeu des enfants appelé « téléphone ». Les informations sont transmises d’un agent à l’autre en chaîne, et les détails se perdent, se distordent ou sont réinterprétés à chaque étape. Si le critique ne voit jamais la tâche originale dans son intégralité, seulement ce que l’ingénieur a décidé de transmettre, ses retours peuvent manquer le but.

La solution d’AutoGen est le chat de groupe. Un objet GroupChat conserve un pool partagé d’agents et de messages, comparable à un canal d’équipe, au lieu d’une série de relais point à point. Un GroupChatManager coordonne le tour de parole afin que les agents ne répondent pas tous en même temps. La propriété clé est que chaque membre peut voir l’ensemble de l’historique de la conversation, et non seulement ce qui lui a été explicitement transmis.

La reconstruction de l’exemple de l’ingénieur et du critique avec un chat de groupe permet une collaboration plus cohérente. Les retours du critique s’appuient sur le même contexte complet que celui de l’ingénieur, et celui-ci peut répondre directement aux critiques spécifiques sans avoir à rephraser. Le prix à payer, comme on s’y attend, est la longueur des messages. Les conversations en groupe consomment plus de tokens, car chaque agent écoute en fait chaque échange, ce qui est important lorsqu’on paie par token à grande échelle.

Ce que les premiers exemples nous apprennent

Prises ensemble, les sessions de studio et les expériences avec du code brut soulignent quelques principes applicables à tout projet d’agent. Une tâche doit être suffisamment petite pour que son succès puisse être vérifié, car la boucle de proxy ne fonctionne que lorsque l’on peut déterminer si le résultat est correct. L’exécution doit être isolée, car l’autonomie qui rend la boucle utile lui permet également d’installer des paquets et d’exécuter des programmes arbitraires. Les évaluations sont peu coûteuses à mettre en place une fois que les rôles existent, donc un critique vaut presque toujours la peine d’être essayé. De plus, le coût doit être pris en compte dès la conception : le cache, la répétition des actions et la estimation du nombre de tours nécessaires font partie intégrante de la construction du système, et non des considérations ultérieures.

Il existe également une leçon sur l’endroit où il convient de concentrer les efforts. Rédiger un bon message système pour le critique, ou une documentation claire pour une compétence, modifie le comportement bien plus que d’ajouter davantage d’agents. Les deux frameworks récompensent des descriptions précises et ciblées de la fonction de chaque agent.

CrewAI : structure plutôt que improvisation

Tandis qu’AutoGen privilégie les conversations ouvertes, CrewAI est plus structuré et orienté vers des objectifs précis, visant clairement les environnements professionnels et de production. Au lieu d’un dialogue fluide, il exige trois définitions explicites : les agents, avec leurs rôles, objectifs et histoires de fond ; les tâches qui leur sont assignées ; ainsi que l’équipe qui les réunit selon une stratégie de traitement définie.

De quoi est composé un agent

Un agent CrewAI est configuré à l’aide de quelques paramètres seulement :

• role : une courte étiquette décrivant la fonction de l’agent, par exemple Chercheur senior en blagues.
• goal : une affirmation en langue naturelle indiquant ce que l’agent cherche à accomplir, souvent structurée pour être réutilisée avec différentes entrées.
• backstory : un récit permettant de définir le personnage de l’agent, fournissant du contexte et une personnalité, à l’instar d’un prompt de personnage pour le système.
• memory et verbose : des indicateurs qui contrôlent si l’agent conserve le contexte au fil des interactions et s’il affiche ses raisonnements dans la console.
• allow_delegation : indique si l’agent peut confier des tâches à d’autres membres de l’équipe.

Les tâches sont définies séparément. Chacune comprend une description du travail, un champ expected_output qui décrit à quoi ressemble le succès aux yeux de l’agent et du lecteur, une référence à l’agent responsable, ainsi que des options telles que l’exécution asynchrone ou l’écriture du résultat dans un fichier.

L’objet Crew assemble finalement les agents et les tâches avec des paramètres définissant le mode de collaboration, qu’elle soit séquentielle ou hiérarchique, ainsi que des options relatives au partage de la mémoire, au cache, et à une limite de requêtes par minute afin de contrôler l’utilisation de l’API.

Un exemple amusant : l’équipe des blagues

Pour concrétiser cela, une équipe de création de blagues composée de deux agents est mise en place. Un chercheur senior en blagues analyse ce qui rend un sujet amusant et note les tendances sociales pertinentes, tandis qu’un rédacteur de blagues transforme ces recherches en véritables blagues. Le chercheur peut déléguer ses tâches, tandis que le rédacteur ne le peut pas. C’est une répartition logique, car le rédacteur doit être l’étape finale du processus et non un centre qui redistribue le travail.

Avec un sujet comme les blagues sur les ingénieurs en IA, l’équipe produit des résultats véritablement amusants grâce à un processus en deux étapes — recherche puis rédaction — plutôt qu’avec une seule instruction globale. Bien que cela paraisse absurde, cela illustre pourquoi séparer la compréhension du domaine de la création du résultat créatif peut aboutir à des outputs plus réfléchis. Le travail de base effectué par le chercheur sert de contexte de référence pour le rédacteur, comme une étape de récupération intégrée au flux de travail.

AgentOps : suivre l’utilisation des ressources

Les développeurs d’agents reviennent constamment à une préoccupation fondamentale : quel est le coût de l’exécution de cet agent, et où passe tout ce temps ? Sans surveillance, les systèmes multi-agents peuvent générer des factures surprenantes, car chaque échange entre agents, chaque délégation et chaque appel à des outils s’accumulent. AgentOps est une plateforme d’observabilité conçue spécifiquement pour le comportement des agents basés sur des LLM, contrairement aux outils traditionnels MLOps, qui n’ont pas été conçus pour des agents autonomes et conversationnels.

Intégrer cette solution dans un projet CrewAI ne demande que peu d’efforts : il suffit d’installer le paquet, d’obtenir une clé API, de la placer dans la configuration de l’environnement et d’initialiser la bibliothèque en haut du script. Chaque exécution est ensuite enregistrée dans un tableau de bord affichant :

• la durée totale de l’exécution ainsi que l’environnement dans lequel elle a eu lieu,
• le nombre de tokens d’entrée et de sortie pour chaque appel à un LLM,
• le temps écoulé pour chaque appel individuel,
• le coût en dollars estimé pour l’ensemble de l’exécution.

Le dernier point est révélateur la première fois qu’on le découvre. Une simple exécution d’une équipe de blagueurs, qui semble anodine pour un humain, coûte en réalité une somme non négligeable, même après avoir pris en compte tous les raisonnements intermédiaires, les délégations de tâches et les appels aux outils. Pour quiconque développe des systèmes d’agents à des fins commerciales, c’est un rappel utile à la réalité : orchestrer des agents est puissant, mais ce n’est pas gratuit, et l’observabilité permet de transformer un coût abstrait en un montant pouvant être budgétisé et optimisé.

Une équipe de développement de jeux

Afin de faire une comparaison directe avec les exemples de codage AutoGen, CrewAI est utilisé pour former une petite équipe de développement de jeux composée de trois agents :

1. Un ingénieur logiciel senior écrit l’implémentation en Python du jeu demandé.
2. Un ingénieur de contrôle de qualité logicielle examine le code à la recherche de défauts, allant des importations manquantes et des parenthèses déséquilibrées aux failles de sécurité et à une logique erronée.
3. Un ingénieur en chef QA peut déléguer certaines tâches mais reste en dernier ressort responsable de s’assurer que le code final répond à la demande initiale.

Les tâches suivent cette même structure : une première personne réalise l’implémentation initiale, une deuxième l’audit pour y détecter des défauts, et une troisième fusionne les deux versions pour en obtenir une version finale corrigée. Ce processus en trois étapes — rédaction, critique et finalisation — constitue une version plus élaborée du modèle d’ingénieur et de critique d’AutoGen, mis en œuvre grâce à la séparation déclarative des tâches et des agents chez CrewAI.

Lorsqu’il est exécuté de manière interactive, avec le script qui demande quel type de jeu est souhaité et comment il doit se comporter, le code tend à être nettement plus soigné que celui produit par un seul agent de codage non supervisé. Une partie de la raison en est que le contrôle exercé par l’ingénieur en qualité en chef permet de détecter des problèmes qui pourraient sinon passer inaperçus.

Traitement séquentiel versus hiérarchique

CrewAI propose deux façons d’organiser la manière dont une équipe travaille sur des tâches, et le choix correct est important.

Le traitement séquentiel est la méthode par défaut et la plus simple. Les tâches s’exécutent une après l’autre dans l’ordre défini, et chaque agent termine son travail avant de le transmettre au suivant. Il convient aux processus dont les étapes dépendent réellement les unes des autres dans un ordre fixe : recherche puis rédaction, ou mise en œuvre puis révision puis finalisation.

Traitement hiérarchique : un gestionnaire est placé au-dessus de l’équipe, généralement via sa propre connexion LLM utilisée uniquement pour la coordination ; ce gestionnaire supervise les agents et les tâches au lieu de les faire agir de manière synchronisée. Le passage en mode hiérarchique est simple : il suffit de spécifier Process.hierarchical au lieu de Process.sequential et de fournir un manager_llm, souvent une instance de ChatOpenAI avec une température égale à zéro afin de prendre des décisions de supervision plus stables.

En théorie, le mode hiérarchique devrait l’emporter, car un rôle de manager reflète le fonctionnement des grandes organisations humaines. Les expériences montrent le contraire. Selon AgentOps, la même tâche de jeu, exécutée sous la direction d’un manager hiérarchique, coûte plus du double, et le code n’est pas significativement meilleur pour cela. C’est un élément de données décevant. Ajouter de la coordination, un contrôle et plusieurs niveaux d’agents n’améliore pas automatiquement les résultats, et les systèmes multi-agents peuvent tout aussi facilement sombrer dans des boucles coûteuses et improductives lorsque personne ne surveille de près.

Arrêter les agents incontrôlables

Cette constatation renvoie à un mode de défaillance subtil : des schémas de pensée répétitifs. Un agent qui n’a pas confiance dans ses propres résultats peut tourner en rond avec différentes variantes de la même idée au lieu de se décider et d’avancer, gaspillant des tokens et de l’argent sans véritable progrès.

AgentOps dispose d’une visualisation « Repeat Thoughts » conçue précisément pour cela, qui montre avec quelle fréquence le raisonnement d’un agent revient à des contenus similaires au cours d’une exécution. Une répétition excessive est un signe qu’il faut modifier quelque aspect structurel. Peut-être que les descriptions des tâches sont trop ambiguës, peut-être qu’un trop grand nombre d’agents sont impliqués compte tenu de la complexité du problème, ou peut-être que le mode de traitement mérite d’être réexaminé. De tels outils de diagnostic permettent de distinguer l’expérimentation occasionnelle du travail rigoureux adapté à un environnement de production. Il vaut mieux détecter les problèmes tôt plutôt que d’attendre une facture anormalement élevée.

Styles de communication côte à côte

La question soulevée au début, à savoir comment les agents échangent des informations, dispose désormais de réponses concrètes. AutoGen propose deux modèles. Les chats imbriqués transmettent les informations via des conversations secondaires, ce qui maintient la structure principale ordonnée mais risque de perdre des détails à chaque étape. Les chats de groupe permettent à tous d’accéder à l’historique complet, ce qui améliore la cohérence au détriment du nombre de tokens utilisés. CrewAI évite ce choix en rendant le transfert explicite : chaque tâche indique son agent et son résultat attendu, et les paramètres du processus déterminent si les résultats sont transmis directement ou via un gestionnaire. Une approche favorise la collaboration émergente, tandis que l’autre privilégie un flux qui peut être consulté à l’avance.

Aucune de ces solutions ne supprime la nécessité de surveiller la facture. Toutes génèrent plus d’appels au modèle qu’un seul prompt, et toutes peuvent entrer en boucle. C’est pourquoi les outils d’observabilité sont tout aussi importants que le choix du framework.

Choix entre les deux

Aucun de ces frameworks n’est clairement supérieur. Chacun reflète une vision différente quant au degré de structure qu’un système multi-agents devrait posséder. AutoGen permet à la structure d’émerger directement de la conversation elle-même, tandis que CrewAI demande au concepteur de la définir à l’avance.

AutoGen convient lorsque :

• on cherche une flexibilité maximale et que les agents peuvent improviser leur approche grâce à un dialogue ouvert ;
• la tâche bénéficie d’échanges exploratoires, tels que des sessions de brainstorming ou un débogage itératif, où la séquence exacte des étapes n’est pas connue à l’avance ;
• un point d’entrée visuel accessible comme AutoGen Studio est utile pour des expérimentations non techniques avant de se lancer dans la programmation.

CrewAI convient lorsque :

• on a besoin de pipelines prévisibles et vérifiables, avec des rôles et des responsabilités clairement définis, comme dans les workflows d’entreprise où la cohérence prime sur l’improvisation ;
• La mémoire intégrée, le cache et la limitation de débit sont préférables aux versions personnalisées ;
• L’observabilité de premier ordre est essentielle, étant donné à quel point l’intégration avec AgentOps est fluide.

En pratique, de nombreux projets réels s’inspirent des deux approches : la clarté déclarative de CrewAI pour les parties bien comprises d’un pipeline, et la flexibilité conversationnelle d’AutoGen pour les parties plus complexes et exploratoires.