Wu Wei

Comment fonctionne la boucle d'un agent

· #agents

Explainer

Sujet
La boucle d'un agent (agent loop)
Niveau
Intermédiaire
Couvre
tool-calling · contexte · arrêt · risques

« Agent » est le mot le plus usé de l'année. Mais sous le bruit se cache une mécanique concrète et assez simple, et la comprendre fait la différence entre utiliser un agent avec discernement et prier pour que ça marche. La définition qui a le mieux tenu est celle d'Anthropic, que Simon Willison résume en une phrase : un agent est un modèle qui utilise des outils dans une boucle (simonwillison.net). Pas de boucle, pas d'agent — juste un appel isolé à un modèle.

Un agent n'est pas un workflow

Avant la boucle, une distinction qui évite bien des ennuis. Anthropic sépare deux choses que le jargon confond : un workflow est un système où le modèle et les outils sont orchestrés par des chemins de code que tu écris à l'avance ; un agent est un système où le modèle lui-même décide de sa trajectoire et de l'outil à utiliser, à partir du feedback de l'environnement, en boucle (Building Effective AI Agents). Le workflow est prévisible et bon marché ; l'agent est flexible et coûteux. La plupart des problèmes se résolvent avec le premier — l'agent se réserve aux cas où tu ne peux pas câbler le chemin d'avance mais où tu peux vérifier le résultat.

La brique de base : le « augmented LLM »

La pièce de base n'est pas le modèle nu, mais ce qu'Anthropic appelle le augmented LLM : un modèle avec accès à la recherche (aller chercher des données), aux outils (exécuter des actions) et à la mémoire. Lilian Weng le décrit avec le modèle comme « cerveau » et trois piliers autour — planification (découper en sous-objectifs, se corriger), mémoire (court et long terme) et usage des outils (LLM Powered Autonomous Agents). La boucle est ce qui met tout cela en mouvement.

Penser, agir, observer

Le motif qui structure la boucle vient d'un article de 2022 : ReAct (Reason + Act). L'idée est d'entrelacer raisonnement et action au lieu de les séparer : le modèle raisonne un pas (« il me faut le prix actuel, je ne le connais pas de mémoire »), exécute une action (appelle un outil de recherche), observe le résultat, et ce résultat alimente le raisonnement suivant (Yao et al., 2022). Le raisonnement planifie et gère les exceptions ; l'action apporte de l'information du monde extérieur que le modèle n'avait pas.

1
Penser

Le modèle raisonne sur l'objectif et l'état actuel, et décide l'étape suivante : répondre tout de suite, ou demander un outil.

2
Agir

Si besoin, il émet un appel d'outil (chercher, lire un fichier, exécuter du code). Ton code l'exécute — le modèle ne touche à rien tout seul.

3
Observer

Le résultat de l'outil revient dans le contexte comme une observation. Le modèle le lit et le cycle recommence, désormais avec plus d'information.

L'aller-retour, concrètement

En pratique, cet « agir » a une forme très précise dans les API actuelles. Quand le modèle veut utiliser un outil, il ne l'exécute pas : il arrête son tour avec un signal — dans l'API de Claude, stop_reason: "tool_use" — et renvoie un bloc décrivant quel outil il veut et avec quels arguments. Ton code exécute cette opération et renvoie le résultat dans un bloc tool_result, qui réentre dans le contexte à l'itération suivante (Tool use with Claude). OpenAI documente la même danse en cinq étapes : requête avec outils → le modèle demande un appel → ton app l'exécute → deuxième requête avec la sortie → réponse finale ou d'autres appels (Function calling).

En retirant le détail de chaque fournisseur, toute la boucle tient en quelques lignes :

agent loop
# La boucle d'un agent, en essence
messages = [prompt_utilisateur]

while True:
    reponse = modele.generer(messages, outils)
    messages.append(reponse)

    if reponse.raison_arret == "fin":
        break                        # le modèle a décidé qu'il a terminé

    # le modèle a demandé un ou plusieurs outils : c'est TON code qui les exécute
    resultats = [executer(appel) for appel in reponse.appels]
    messages.append(resultats)       # les observations reviennent dans le contexte

C'est tout. Il n'y a pas plus de magie au cœur : un while qui alterne génération du modèle et exécution d'outils, en accumulant toute la conversation dans messages jusqu'à ce que le modèle signale qu'il a terminé. Ce qui change entre un jouet et un agent sérieux, ce n'est pas la boucle — c'est ce qui entoure ces deux lignes.

Un détail qu'on néglige : c'est toi qui exécutes l'outil, pas le modèle. Le modèle ne fait que demander. Cet écart entre « demander » et « exécuter » est là où tu mets permissions, validation et limites — la seule vraie barrière entre une suggestion du modèle et un vrai rm -rf.

Pourquoi le contexte grossit à chaque tour

Remarque que messages ne fait qu'une chose : grossir. Chaque tour ajoute la réponse du modèle et le résultat de chaque outil. Sur les tâches longues, ça s'accumule vite, et c'est là qu'apparaît le premier vrai problème. Anthropic le dit sans détour : « un agent qui tourne en boucle génère de plus en plus de données… qui doivent être raffinées de façon cyclique » (Effective context engineering). La fenêtre de contexte est un budget d'attention fini, et passé un certain point survient le context rot : plus tu entasses de tokens, moins bien le modèle retrouve ce qui comptait. C'est pourquoi les agents sérieux compactent, résument ou prennent des notes — pas par élégance, mais parce que la boucle, sans gestion, se noie dans son propre historique.

Là où ça casse

La boucle est simple, et pour cette raison même elle a des défaillances prévisibles. À connaître avant de lâcher un agent en production :

  • Le coût grossit à chaque itération. Chaque tour renvoie tout l'historique accumulé et en ajoute. Un agent qui fait vingt tours ne coûte pas vingt petits appels : il coûte vingt appels de plus en plus gros.
  • Les erreurs se propagent. Un raisonnement erroné au tour 3 entre dans le contexte et contamine les tours 4, 5, 6… Le modèle traîne sa propre erreur comme si c'était un fait. C'est pourquoi Anthropic recommande le motif le plus simple qui passe l'évaluation, pas le plus agentique (Building Effective AI Agents).
  • L'arrêt n'est pas gratuit. Le while True de l'exemple dépend du modèle qui émet « fin ». Un agent peut continuer à tourner, répéter des actions, ou ne pas reconnaître qu'il a terminé. Pour de vrai, il faut une limite d'itérations, une détection de boucle et une condition d'arrêt explicite — le but est d'atteindre un objectif, pas d'itérer sans fin.

Ce qu'il faut retenir

Un agent est un while autour d'un modèle qui appelle des outils et accumule ce qu'il observe. Comprendre cette mécanique ne le rend pas moins utile — ça le rend utilisable avec discernement : tu sais que le coût croît avec les tours, que le contexte se dégrade si tu ne le gères pas, qu'une erreur précoce empoisonne le reste, et que tu contrôles le point exact où un outil s'exécute ou non. Rien de tout cela ne se voit de l'extérieur, où il n'y a qu'« un agent qui fait des choses ». Ça se voit de l'intérieur de la boucle. Et regarder à l'intérieur, avant de faire confiance, c'est exactement le juste milieu que ce site vise : ni rejeter les agents par réflexe, ni les exécuter à l'aveugle.