Function calling et outils

Le LLM ne fait rien directement — et c’est voulu

On l’a vu au chapitre 1 : le LLM ne lit pas de fichier, n’exécute pas de commande, n’écrit pas sur le disque. Il produit du texte — et ce texte peut être une demande d’appel d’outil (function call).

{ "name": "read_file", "input": { "path": "src/Order.cs" } }

Le runtime de l’agent intercepte cette demande, exécute l’action (lire le fichier), et renvoie le résultat au LLM. Le LLM voit le contenu du fichier et décide quoi faire ensuite.

Point clé : Cette séparation n’est pas une limitation technique — c’est une décision de sécurité. Le runtime peut filtrer, valider et auditer chaque action demandée par le LLM. C’est ce qui permet les systèmes de permissions (mode auto-accept, confirmation par action) et le principe du ZTE (Zero Trust Execution) : ne jamais faire confiance au LLM pour s’auto-limiter.

Comment le LLM choisit un outil

Chaque outil est décrit par un nom, une description en langage naturel, et un schéma de paramètres (JSON Schema). Ces descriptions sont injectées dans le contexte du LLM.

Le LLM choisit l’outil en lisant les descriptions. Si la description est vague ou trompeuse, le LLM peut choisir le mauvais outil ou ne pas l’utiliser du tout.

Piège : La qualité de la description d’un outil est aussi importante que la qualité de son implémentation. Un outil parfaitement codé mais mal décrit est invisible pour le LLM.

Bonnes pratiques pour les outils

Description claire

L’outil doit expliquer ce qu’il fait, quand l’utiliser, et ce qu’il renvoie. Le LLM n’a pas accès au code source de l’outil — il ne voit que la description.

Erreurs lisibles

Si l’outil échoue, le message d’erreur doit aider le LLM à corriger. Un message comme exit code 1 n’est pas actionnable. Un message comme File not found: src/Order.cs — did you mean src/Orders/Order.cs? l’est.

Un outil = une action

Un outil read_file qui lit, un outil write_file qui écrit. Pas un méga-outil file_manager qui fait tout — le LLM aura du mal à choisir le bon mode d’utilisation.

Point clé : C’est le Single Responsibility Principle appliqué aux outils. Un outil = une action claire avec un contrat explicite. Plus la description est ciblée, plus le LLM choisit juste.

Nombre d’outils et tokens

Point clé : Le nombre d’outils n’est pas une mesure de qualité. Chaque outil ajoute sa description dans le contexte du LLM — plus d’outils = plus de tokens consommés. Un agent avec 4 outils bien conçus et un bon usage de bash peut accomplir autant qu’un agent avec 15 outils dédiés. La différence est dans l’ergonomie, pas dans la capacité.