Comment choisir le meilleur framework agentique, partie 1 : Human in the Loop

En construisant des agents au quotidien, je vois les frameworks agentiques développer des approches différentes pour résoudre les mêmes problèmes fondamentaux d’orchestration. Au fond, tout se ramène à la façon dont les concepteurs pensent les briques communes d’un système agentique. Malheureusement, chacun apporte sa propre terminologie et son jargon, ce qui rend le tout plus compliqué qu’il ne l’est vraiment. J’ai l’impression que cela crée un vrai blocage, surtout chez les débutants. Cette série de blogs et de vidéos est ma tentative de faire émerger les patterns sous-jacents à tous les systèmes agentiques.

Ce post accompagne une vidéo que j’ai publiée il y a quelques jours, je vous encourage vraiment à la regarder !

Voici la configuration de l’expérience

J’ai implémenté le même système agentique avec trois frameworks différents :

• LangGraph
• OpenAI’s Agents SDK
• Google’s Agent Development Kit (ADK)

Dans tous les cas, l’agent utilise une architecture « superviseur » : un agent unique reçoit la plupart des prompts utilisateur et décide s’il délègue une tâche à des agents plus spécialisés. Ici, j’ai un agent Google capable de lire et d’envoyer des e-mails, et un agent Slack capable de lire et d’envoyer des messages sur Slack. J’impose une approbation HITL explicite sur tous les outils « send ».

Et bien sûr, comme ces outils sont des vraiesintégrations, je les ai implémentées avec Arcade.dev

intégrations réelles, je les ai implémentées avec Arcade.dev

J’ai l’intention d’ajouter d’autres frameworks à la liste, mais en atteindre 3 suffit à voir émerger le pattern d’orchestration agentique. C’est aussi une bonne base pour une comparaison à la fois rapide et solide.

Je les comparerai sur plusieurs aspects, mais le premier est le Human-in-the-Loop.

Qu’est-ce que le Human-in-the-Loop (HITL) ?

Comme beaucoup de choses dans le monde du génie logiciel et de l’informatique, c’est l’un de ces termes dont la définition varie selon le contexte.

Wikipedia renvoie à la définition du DoD de 1998 :

« Un modèle nécessitant une interaction humaine »

Ce qui peut vouloir dire à peu près n’importe quoi. Pour avoir une définition utile dans le contexte des systèmes agentiques, voici ce que j’appelle une définition « stricte » du HITL :

Un modèle autonome comportant des étapes qui imposent une interaction humaine

Pas si différent de 1998, mais on peut au moins dire que si on marque un outil comme « nécessitant une validation humaine avant exécution » et que l’agent n’en demande pas la permission, il y a un problème.

Comment chaque framework aborde-t-il le HITL ?Heureusement, il est possible

d’implémenter une application stricte des flux HITL dans tous les frameworks testés. Leurs approches restent cependant bien distinctes.

Ce qui est assez universel dans la façon dont les frameworks abordent cela, c’est qu’ils font toujours appel à un outil qui récupère de l’information auprès de l’utilisateur (humain). Cela nous donne un indice sur la fonctionnalité « naturelle » des LLMs qui rend les constructions HITL possibles : le function-calling (c’est-à-dire les tools). Au fond, la question se ramène à la facilité (ou la difficulté) de contrôler le flux autour d’un appel d’outil.

Google’s Agent Development KitCe framework aborde cela avec des callbacks. Le HITL n’est pas correctement documenté au moment d’écrire ces lignes. Leur dépôt contient bien un exemple appelé humanin_loop, mais je ne considère pas que cela corresponde à ma définition ci-dessus : l’agent _pourrait

halluciner et appeler la fonction directement. L’approche suggérée consiste à « forcer » un appel de demande d’approbation via du prompt engineering.Ce que j’apprécie dans leur approche, c’est sa simplicité. Les callbacks permettent d’« intercepter et contrôler » le flux d’informations selon le contexte, avant et après l’appel à l’outil. Si vous effectuez vos vérifications dans le callback before, renvoyez None et le vrai outil sera invoqué, puis le flux habituel reprend. Si vous voulez intercepter

, vous pouvez renvoyer autre chose, comme une chaîne ou un dictionnaire, et ce sera traité comme si cela venait de l’outil.Ce que je n’aimepas, c’est que je dois gérer le « marquage » des outils en dehors du code d’orchestration agentique. Si je veux un callback before

spécifique par outil, je dois gérer moi-même ce routage. Pas terrible en termes d’ergonomie.

OpenAI’s Agents SDKCe framework ne gère pas bien le contrôle de flux. Vous pouvez

implémenter le HITL par injection de code : créer un outil de fonction personnalisé compatible avec l’Agents SDK, puis wrapper la fonction on_invoke_tool pour l’intégrer manuellement dans votre propre logique de contrôle de flux. Et en plus de cet inconvénient, renvoyer quelque chose depuis le callback comme si ça venait de l’outil est franchement maladroit. Ce que j’apprécie dans leur approche, c’est qu’elle vous force à approfondir vos connaissances en Python (si je n’avais pas connu functools

, ce post aurait été très différent).Ce que je n’aimepas, c’est que je considère le contrôle de flux comme une partie essentielle de la conception de systèmes agentiques. Je sais qu’on veut

des agents toujours plus autonomes qui font plein de choses utiles, mais si je déploie quelque chose en production, il faut que je puisse dire « ATTENDS, N’ENVOIE PAS CET E-MAIL » sans avoir à sauter par-dessus dix obstacles.

LangGraphLangGraph est le seul framework (jusqu’ici) à disposer d’une documentation

dédiée au HITL. Son approche repose sur des interruptions et l’idée sous-jacente d’un état de graphe qui peut être repris à n’importe quel moment. C’est suffisamment sophistiqué pour que je n’explique pas tout ici, mais je recommande vivement de lire la documentation LangGraph à ce sujet.C’est de loin mon approche préférée. Je pense que les interruptions sont la bonneabstraction pour cela (ce sont des primitives de contrôle de flux explicites). Je pense aussi que les graphes sont le bon outil de modélisation pour les systèmes multi-agents. Des trois implémentations, celle-ci a été la plus simple : j’ai suivi la doc et tadaa !

j’avais un agent fonctionnel au bout du compte.Ce que je n’aimepas avec LangGraph/LangChain, c’est qu’il y a trop de couches d’abstraction dans le framework, ce qui le rend verbeux et un peu gonflé. Mais ce n’est pas ce que j’évalue dans ce post, donc je garderai ce coup de gueule pour une prochaine fois.

Alors, quel est le meilleur framework ?

Eh bien, comme beaucoup de choses dans la vie : ✨ça dépend✨

Si vous voulez partir en production aujourd’hui, c’est clairement LangGraph. Si vous êtes en phase d’exploration et d’apprentissage, je recommande Google ADK (pour l’instant). Les bonnes idées sont là et l’implémentation est si jeune que les débutants peuvent plus facilement comprendre l’architecture du framework et « voir » les patterns plus clairement. Si vous voulez explorer davantage, donnez aussi sa chance à l’OpenAI Agents SDK : il n’est pas terrible pour le human-in-the-loop, mais il est instructif de voir comment il aborde l’orchestration agentique.

Essayez dès aujourd’hui !

Le code et les ressources de cette expérience sont open-source.

Il vous faudra :

• Une clé API Arcade.dev
• Une clé API AgentOps pour le tracing et l’observabilité
• Clonez le dépôt.

Bonne construction !

Ressources :

Tutoriel complet : https://youtu.be/VgQp-kMAt90
Récupérer le code : https://github.com/ArcadeAI/framework-showdown
Essayer Arcade.dev : https://try.arcade.dev/register
Accéder à AgentOps : https://www.agentops.ai/