Chapitre 4 — Agents IA et appel d'outils

Quatrième billet de la tournée chapitre par chapitre de LLM Primer V : Construire des applications LLM réelles. Le chapitre qui traite un agent comme un modèle de langage bouclé sur des outils dont les schémas, les couches de mémoire et le câblage multi-agents doivent être conçus avant de confier la boucle à quoi que ce soit de réel.

Pourquoi ce chapitre existe

Un modèle sans état qui ne prend que du texte en entrée et n'émet que du texte en sortie est une calculatrice. Le travail de production demande d'en faire un acteur qui poursuit des objectifs sur plusieurs étapes — appeler cet outil, puis celui-là, puis décider lequel des résultats résumer pour l'utilisateur, et s'arrêter quand la tâche est terminée. Le geste a l'air simple dans un diagramme et ne l'est pas en réalité. Les agents s'égarent, bouclent, appellent le mauvais outil, inventent des arguments que l'outil ne peut pas accepter, oublient ce qu'ils ont déjà récupéré, et agissent hors de leur autorité. Le Chapitre 4 porte sur l'ingénierie qui garde la boucle lisible et bornée — les schémas, la discipline de mémoire et la structure multi-agents qui transforment une démo plausible en acteur de production.

4.1 Les architectures d'agent comme composition, non comme sélection

La boucle de base est ReAct : raisonner sur la situation, agir en appelant un outil, observer le résultat, et répéter jusqu'à ce que l'objectif soit atteint ou que le budget d'étapes soit épuisé. Les systèmes de production composent ensuite trois augmentations par-dessus la base, plutôt que de choisir entre elles. L'appel de fonction natif — le fournisseur contraint les arguments d'outil face à un schéma JSON au décodage — durcit le contrat d'entrée-sortie de sorte que la boucle n'ait plus à se remettre d'appels malformés. La planification explicite, en style Plan-and-Execute, place un plan en amont pour les tâches à long horizon et ne relance le planificateur que si le monde change. L'orchestration de flux de travail encode les transitions connues de la tâche comme un graphe et ne laisse au modèle que les décisions intraphase, forme sur laquelle la plupart des déploiements d'entreprise convergent parce qu'elle sépare ce qui est connaissable de ce qui exige du jugement. Les boucles de réflexion, le routage multi-modèle sur une flotte à paliers de coût et les sous-agents spécialistes prennent place à côté de ces augmentations.

4.2 Mécanique d'appel d'outils — le schéma est le contrat

Chaque outil a un schéma, et le schéma est le contrat que la boucle impose au modèle. Les descriptions au niveau des propriétés sont de la documentation pour le modèle, pas pour le lecteur humain ; les enums referment l'espace des arguments là où le domaine le permet ; les clés d'idempotence laissent la boucle réessayer un appel d'outil sans doubler son effet ; des erreurs structurées et rejouables laissent le modèle récupérer proprement plutôt que deviner. Les outils devraient être minimaux — un travail clair par outil — parce qu'un outil gras avec dix drapeaux optionnels est un outil que le modèle utilisera mal. Un outil ask_user a explicitement sa place au catalogue, pour que l'agent dispose d'une voie légitime pour remonter l'ambiguïté plutôt que d'inventer des arguments. La concurrence n'est sûre que si les outils déclarent leur indépendance ; la boucle traite les outils déclarés indépendants comme parallélisables et tout le reste comme strictement séquentiel. Tout incident réel de production tracé à « l'agent a fait la mauvaise chose » se ramène à un outil dont le schéma ne disait pas ce que ses arguments voulaient dire.

4.3 Trois couches de mémoire : court terme, long terme, sémantique

Les agents ont besoin de mémoire parce qu'une tâche tient rarement en un tour. La mémoire à court terme est une fenêtre glissante sur la conversation récente avec des messages épinglés qui survivent au glissement — le prompt système, l'objectif actuel, le plan en cours — et une synthèse périodique des tours qui sortent de la fenêtre. La mémoire à long terme est un magasin vectoriel de faits soignés écrit lors d'une confirmation, non à chaque observation, et récupéré à plusieurs points de la boucle plutôt qu'au démarrage seulement. La mémoire sémantique est un graphe de connaissances de triplets pour les requêtes qui exigent une composition structurée plutôt qu'une similarité — « qui rend compte à qui », « quels produits appartiennent à quelle catégorie », relations que le magasin vectoriel aplatirait. Les trois sont stockées différemment parce qu'elles s'utilisent différemment, et la discipline consiste à router écritures et lectures vers la bonne couche au lieu de tout écraser dans un unique index d'embedding.

Ce que prépare le Chapitre 4

Agents et RAG produisent tous deux des traces stochastiques. L'utilisateur se plaint, le journal montre cent spans à travers trois outils et huit appels de modèle, et l'équipe doit décider si la défaillance est une régression de récupération, une dérive de prompt, un problème de schéma d'outil, ou l'agent choisissant correctement face à un système aval cassé. On ne répond pas à cette question sans une discipline qui transforme les traces en signaux mesurables passer/échouer. Le Chapitre 5 est cette discipline — LLM-juge, Triangle RAG, tests de trajectoire pour agents, et la boucle continue où les traces de production alimentent le jeu d'évaluation qui verrouille la prochaine version.

Prochaine étape — Chapitre 5 : Évaluer les applications LLM. La discipline d'évaluation qui transforme les traces stochastiques en signaux passer/échouer sur lesquels une équipe peut livrer.