Comment fonctionnent les agents IA : la boucle, étape par étape
Les agents ressemblent à de la magie en démo et à de la plomberie en production. La raison : l'intéressant n'est pas la sortie du modèle mais la boucle qui la consomme, et cette boucle est assez courte pour se lire d'une traite.
Ce guide fait passer une seule requête de bout en bout : ce que le modèle voit à chaque tour, ce que votre code fait du résultat, comment un outil en échec revient, et ce qui arrête la boucle. Si vous savez raconter cela pour votre système, vous savez le déboguer. Sinon, aucun réglage de prompt ne le rendra fiable.
Un tour de boucle, dans l'ordre#
- Assembler le contexte : objectif, définitions d'outils, faits récupérés, historique élagué.
- Demander au modèle l'étape suivante. Il répond directement ou demande un appel d'outil avec arguments.
- Valider les arguments avant toute action : types, bornes, et si cet appelant peut toucher cet enregistrement.
- Exécuter l'outil. Capturer les échecs et les traduire en messages courts et factuels, pas en traces de pile.
- Ajouter l'appel et son résultat à l'historique, puis vérifier les conditions d'arrêt.
- Recommencer, ou renvoyer la réponse finale avec ce que l'agent a réellement fait.
Ce que le modèle voit et ne voit pas#
Le modèle n'a aucun souvenir du tour précédent en dehors de ce que vous remettez dans le contexte. Ce seul fait explique l'essentiel des comportements déroutants. S'il oublie une contrainte d'il y a quatre étapes, c'est votre élagage qui l'a supprimée. S'il répète trois fois le même appel en échec, c'est que le message d'erreur n'a pas dit pourquoi en mots exploitables. Assembler le contexte n'est pas le préambule du travail intéressant : c'est le travail intéressant.
Écrivez les erreurs d'outil comme des instructions, pas comme des diagnostics. Pas `HTTP 404`, mais `Aucun client avec cet identifiant. Demandez confirmation du numéro de commande.`
Planifier : explicite ou émergent#
Deux approches se défendent. La planification émergente choisit une étape à la fois sans document de plan : simple, robuste, encline à divaguer sur les tâches longues. La planification explicite demande d'abord un plan numéroté, l'exécute, et ne replanifie qu'en cas d'échec. L'explicite s'audite et se montre plus facilement, au prix d'une fragilité quand la réalité s'écarte à l'étape trois. Sous cinq étapes, l'émergent suffit ; au-delà, le plan explicite se rembourse en traçabilité.
S'arrêter : la partie que les démos ne montrent jamais#
| Condition | Réglage typique | Ce qui se passe |
|---|---|---|
| Plafond d'étapes | 8–15 appels d'outils | Renvoyer le travail partiel avec une explication |
| Plafond de dépense | Coût fixe par exécution | Arrêter et journaliser pour revue |
| Horloge | 30–120 s en interactif | Rendre la main avec ce qui est connu |
| Détection de répétition | Même appel et mêmes arguments deux fois | Forcer une autre branche ou s'arrêter |
| Porte humaine | Toute action irréversible | Mettre en pause et demander validation |
Lire une trace quand ça dérape#
Une trace est l'enregistrement ordonné de chaque contexte, décision, appel et résultat d'une exécution. C'est le seul outil de débogage qui compte et la première chose à construire. La question n'est jamais pourquoi le modèle est mauvais, mais quel tour a dérapé le premier et ce que le modèle pouvait voir à ce moment. Neuf fois sur dix, la réponse est ennuyeuse : un outil a renvoyé une liste vide sans le dire, un fait périmé est resté dans le contexte, ou une erreur de droits est arrivée comme panne générique et a été jugée réessayable.
Questions fréquentes
Combien d'étapes avant l'arrêt ?
En interactif, un plafond de huit à douze appels couvre presque tout ce qui est légitime ; au-delà, l'exécution est généralement bloquée. Les traitements par lots peuvent aller plus haut, avec un plafond de dépense associé.
Planifier d'abord ou décider au fil de l'eau ?
Les tâches courtes vont bien au fil de l'eau. Dès qu'une tâche dépasse régulièrement cinq étapes, un plan explicite rend l'exécution auditable et montre l'avancement ; replanifiez en cas d'échec.
Pourquoi mon agent répète-t-il le même appel en échec ?
Presque toujours parce que le message d'erreur ne contient rien d'exploitable. Renvoyez des erreurs courtes et claires disant ce qui n'allait pas et ce qui serait sensé ensuite, et ajoutez une détection de répétition.
comment fonctionnent les agents iaboucle d'agentraisonner agir observerappel d'outilsarchitecture d'agent
