Un modèle seul invente une fiction crédible. Un modèle outillé va vérifier. La différence entre les deux tient dans quelques fonctions bien décrites — et quelques garde-fous pour qu'il s'en serve vraiment.
Un LLM ne ment pas : il complète. Quand tu lui demandes de résumer l'activité d'un dépôt qu'il ne peut pas lire, il produit la suite la plus plausible — une roadmap crédible, mais inventée. Le problème n'est pas le modèle, c'est qu'on lui a coupé l'accès au réel.
C'est le point de bascule que je raconte dans d'un prompt à l'agentique : donner des outils, c'est passer de « deviner » à « aller chercher ».
Un outil, c'est trois choses : un nom, une description (en langage naturel, c'est elle que le modèle lit), et un schéma d'entrée. Le modèle décide quand l'appeler à partir de la description — donc elle compte autant que le code.
On attache les outils au modèle. À chaque tour, il peut soit répondre, soit demander un appel d'outil. Le nœud exécute l'appel, réinjecte le résultat, et redonne la main au modèle — c'est la boucle agentique.
Donner des outils ne suffit pas : il faut cadrer leur usage, sinon l'agent boucle, appelle trop, ou ignore les outils et invente quand même.
Dis quand utiliser l'outil, pas seulement ce qu'il fait. « À appeler avant de résumer une roadmap » guide mieux que « lit GitLab ».
Un compteur max d'itérations évite qu'un agent tourne en rond sur des appels d'outils sans jamais conclure.
Un schéma Zod en sortie : si le modèle renvoie un champ mal typé, on le renvoie corriger au lieu de planter.
Sans traçage, un agent outillé est indéboguable. On voit quel outil a été appelé, avec quoi, et ce qu'il a renvoyé.
L'outil le plus dangereux est celui qui écrit. Les outils en lecture sont sûrs ; pour ceux qui modifient (créer, supprimer), ajoute une confirmation humaine — c'est tout l'objet de human-in-the-loop en vrai.
Le schéma d'entrée n'est pas de la paperasse : c'est le contrat qui empêche le modèle d'improviser. En mode strict, le fournisseur garantit que les arguments produits collent exactement au schéma — plus de champ inventé, plus de type approximatif. Côté Anthropic, on ajoute `strict: true` à la définition ; côté OpenAI, la même option exige `additionalProperties: false` et tous les champs en `required` (un champ optionnel se modélise en union avec `null`).
Avec Zod, tu écris le schéma une seule fois et LangChain le convertit en JSON Schema pour l'appel d'outil, puis valide et parse la réponse à la volée — pas de parsing manuel côté toi (doc structured output). Le même objet Zod sert donc à décrire l'entrée au modèle et à vérifier la sortie avant de la laisser continuer.
Un paramètre `user` invite le modèle à deviner : un id ? un nom ? un email ? Un paramètre `user_id` ne laisse pas le choix. Anthropic résume ça par le « test du stagiaire » : si un nouvel arrivant ne peut pas utiliser l'outil avec la seule description et les seuls noms de champs, le modèle ne le pourra pas non plus (writing tools for agents).
Le mode strict garantit la *forme*, pas le *sens*. Un JSON Schema ne dit pas quelles combinaisons de champs font sens ni quelles conventions ton API attend — ça reste à la description et à la validation métier de le porter.
Même bien décrit, un outil renvoie parfois une erreur, ou le modèle passe un argument que la validation métier refuse. La bonne réaction n'est pas de planter : c'est de renvoyer l'erreur *au modèle* comme un résultat d'outil, avec un message actionnable, pour qu'il corrige au tour suivant. Anthropic recommande des messages « spécifiques et actionnables » plutôt que des codes opaques (writing tools for agents).
Une boucle de correction sans plafond, c'est un agent qui peut boucler à l'infini (et brûler des tokens) sur un argument qu'il ne saura jamais produire. Garde le compteur d'itérations de la section 04 aussi sur la boucle de retry.
Plus tu donnes d'outils, plus le modèle se trompe de cible et plus le contexte se remplit. Anthropic conseille de rester sous ~20 outils actifs et de consolider : un `schedule_event` vaut mieux que `list_users` + `list_events` + `create_event`. Au-delà, on passe à la découverte d'outils à la demande plutôt que de tout charger dans le contexte.
« Ça marche sur mon exemple » ne suffit pas. On évalue l'usage des outils à trois niveaux : la réponse finale, l'étape isolée (a-t-il choisi le bon outil ?), et la *trajectoire* entière (a-t-il suivi le bon chemin d'appels ?). Le package `agentevals` fournit des évaluateurs prêts à l'emploi : match strict, non ordonné, ou sous-ensemble sur les appels d'outils attendus.
Ces évaluations tournent sur le traçage de la section 04 : sans trace de quel outil a été appelé avec quoi, on ne peut ni déboguer ni scorer. Le traçage est le socle, l'éval est ce qu'on construit dessus.
Un agent qui hallucine est presque toujours un agent privé d'accès au réel. Des outils bien décrits, une boucle qui exécute, des garde-fous pour cadrer : c'est ce qui transforme une fiction crédible en réponse ancrée sur les faits.
LangChain — Tools ↗