Agent LLM : comment une boucle modèle-outils a remplacé le chatbot

Trois dates définissent l'agent LLM moderne : 2022, année de la publication sur l'approche ReAct ; juin 2023, quand OpenAI a ajouté l'appel de fonctions à son API ; et novembre 2024, quand Anthropic a présenté le protocole MCP pour connecter des outils. Habr a publié un article sur le fonctionnement d'un agent construit au-dessus d'un LLM. L'auteur précise d'emblée qu'il ne discutera pas de l'architecture des transformeurs et aborde le système sous l'angle applicatif. L'annonce RSS ne donne que l'introduction : nous détaillons donc ci-dessous le schéma général sur lequel repose la plupart des agents, sans résumer le contenu de l'article lui-même.

Une boucle plutôt qu'une réponse unique

Un chat classique fonctionne simplement : l'utilisateur pose une question, le modèle répond. Un agent procède autrement. Le modèle reçoit une tâche et une liste d'outils disponibles, puis décide de la suite : répondre immédiatement ou appeler une fonction. Le résultat de l'appel revient dans le contexte, et le modèle passe à l'étape suivante. Cela dure jusqu'à ce qu'il juge la tâche accomplie ou que du code externe interrompe la boucle.

Le modèle, lui, n'exécute rien. Il produit une requête structurée, par exemple le nom d'une fonction et ses arguments en JSON. C'est un programme ordinaire, appelé orchestrateur ou runtime, qui l'exécute. C'est aussi là que résident la logique des nouvelles tentatives, les timeouts et les garde-fous.

De quoi se compose un agent

La plupart des implémentations reposent sur les mêmes briques, qu'il s'agisse de code maison ou d'un framework prêt à l'emploi :

• Modèle : reçoit le contexte et renvoie soit du texte, soit un appel d'outil.
• Outils : fonctions dotées d'une description textuelle et d'un schéma d'arguments. Recherche, SQL, shell, navigateur, API internes.
• Mémoire : historique des étapes dans la fenêtre de contexte, plus un stockage externe, par exemple une base vectorielle ou des fichiers.
• Orchestrateur : code ordinaire qui fait tourner la boucle, valide les appels et tient les logs.
• Condition d'arrêt : réponse finale du modèle, limite d'étapes ou budget de tokens.

Un mot à part sur MCP. Le protocole définit une manière unique de décrire les outils et les ressources, et un même serveur peut se brancher à différents clients. Pour le développeur, cela réduit le coût des intégrations : la description d'un outil s'écrit une seule fois.

Où les agents cassent

Les problèmes surviennent généralement non pas dans le modèle, mais autour de lui. Premier écueil classique : l'agent tourne en boucle. Il appelle le même outil avec les mêmes arguments et attend un résultat différent. Deuxième écueil : le contexte grossit à chaque étape. Les réponses des outils, en particulier les longs exports, chassent les instructions importantes, et le coût de chaque étape suivante augmente. Troisième écueil : les erreurs s'accumulent. Si la probabilité de réussir une étape est de 95%, environ 60% des exécutions passeront dix étapes consécutives sans erreur. C'est pourquoi les longues chaînes sans vérification fonctionnent nettement moins bien que les courtes.

Un autre risque concerne les droits. Un agent ayant accès au shell ou à une base de données exécute ce que le modèle a proposé, et le modèle peut être influencé par une entrée malheureuse ou par du texte issu d'une page web qui s'est glissé dans le contexte.

Comment construire le sien

Mieux vaut commencer par une boucle minimale, avec un seul modèle et deux ou trois outils. Une limite stricte d'étapes et un budget de tokens sont nécessaires dès le premier jour, tout comme un journal de chaque appel avec ses arguments et sa réponse : sans lui, le débogage tourne à la devinette. Les actions dangereuses, comme l'écriture, la suppression et les paiements, gagnent à passer par une confirmation humaine.

Il vaut mieux tronquer et résumer les résultats des outils avant qu'ils n'entrent dans le contexte. Les frameworks seront utiles plus tard, quand on saura quelles parties de la boucle il faut vraiment complexifier. L'auteur publie l'analyse complète avec des exemples sur Habr, et c'est là qu'il faut chercher les détails concrets d'implémentation.