Ingénierie des outils d’agent : état, vérification et contrôle autour du modèle
Une vue en temps réel des agents de production : pourquoi les prompts et le contexte ne suffisent pas, et comment l’état durable, la mise en œuvre, la vérification et l’observabilité comblent cette lacune.
Sources: Agent Harness Engineering: The Runtime Architecture Behind Reliable AI Agents
Lorsqu’un modèle performant échoue encore
Imaginez un agent disposant du meilleur modèle sur le marché, d’un prompt de système soigneusement ajusté, de dizaines d’outils et d’une fenêtre de contexte suffisamment grande pour accueillir toute une base de code. Il peut néanmoins échouer sur une tâche que n’importe quel ingénieur compétent qualifierait de routinière. Il choisit la bonne action mais l’exécute incorrectement. Il trouve le fait clé, puis le perd lorsque le contexte est réinitialisé. Il modifie correctement dix fichiers, mais introduit une régression discrète dans le onzième. Il passe une heure à déboguer un problème qu’il a lui-même créé. Il peut même rédiger un rapport convaincant indiquant que le travail est terminé, alors qu’aucune vérification n’a été effectuée.
La réaction habituelle consiste à travailler sur l’instruction : une autre instruction, un autre exemple, plus de contexte, une demande de prudence. Cela aide temporairement, mais finit par ne plus suffire. Le défaut fondamental réside dans le modèle mental qui considère le modèle comme l’agent et tout ce qui l’entoure comme des paramètres. Cette vision s’effondre dès qu’un agent doit fonctionner en continu dans un environnement réel.
Un agent de production n’est pas simplement un modèle entouré d’instructions. C’est un système en temps réel : il gère l’état, exécute des actions, communique avec des systèmes externes, fait face aux pannes, prend en compte les retours d’information et a besoin de moyens pour se rétablir, s’authentifier et être contrôlé. La discipline qui se développe autour de ce fonctionnement en temps réel est appelée ingénierie des environnements d’agent. Comparez-la au travail lié aux instructions textuelles. L’ingénierie des instructions cherche à savoir comment guider le modèle dans son comportement, tandis que l’ingénierie des environnements cherche à créer un cadre dans lequel le modèle peut atteindre de manière fiable un objectif. Il ne s’agit pas d’améliorer les instructions, mais d’une abstraction différente qui couvre à la fois ce que le modèle écrit et ce que le système peut faire, ce qui survit à une panne, ce qui est autorisé et ce qui constitue une tâche terminée.
Un environnement en temps réel autour d’un modèle probabiliste
La représentation la plus simple d’un agent est un modèle doté d’une instruction et de quelques outils. Cela suffit pour comprendre une seule inférence, mais cela est insuffisant pour un agent opérationnel, qui doit plutôt être envisagé comme un environnement de exécution basé sur un modèle probabiliste.
Le modèle effectue le raisonnement. Le cadre de travail détermine les conditions dans lesquelles ce raisonnement se transforme en exécution : ce que le modèle perçoit, à quoi il peut accéder, quelles actions sont autorisées, quel état persiste et quelles preuves sont nécessaires avant que le succès ne puisse être déclaré.
Prenez un agent de codage dont l’instruction stipule d’abord d’examiner l’architecture, d’exécuter les tests et de laisser de côté les composants non liés. Ces lignes définissent l’intention mais n’imposent rien. Un outil de gestion peut rendre certains fichiers écrivables et d’autres non, exécuter des validations après chaque modification, bloquer les opérations interdites, enregistrer les progrès et refuser de fermer la tâche sans preuves. Ainsi, l’instruction indique ce que l’agent doit faire, tandis que l’outil de gestion décide de ce que le système autorisera et de ce qui sera considéré comme terminé. Le modèle fournit l’intelligence, et l’outil de gestion la transforme en quelque chose qui peut être mis en œuvre.
Trois niveaux d’ingénierie
L’ingénierie des agents a évolué à travers trois niveaux d’abstraction de plus en plus larges : les instructions, puis le contexte, enfin l’outil de gestion.
L’ingénierie des prompts consiste à définir ce que le modèle doit faire. Elle améliore les instructions, les exemples, les descriptions des outils ainsi que les limites de comportement, et pour les tâches simples elle fonctionne remarquablement bien. Cependant, un prompt n’est qu’une instruction et ne possède aucun pouvoir de contrainte. Un agent à qui l’on demande d’exécuter des tests peut toujours prétendre avoir réussi sans les exécuter réellement. Lui demander de ne pas toucher aux fichiers en production ne sert à peu de chose si le système lui accorde un accès illimité. Lui demander de se souvenir d’une décision pendant six heures met cette requête en concurrence avec tout le reste qui alimente son contexte.
L’ingénierie du contexte s’occupe du problème suivant, à savoir ce que le modèle doit connaître au moment de la prise de décision. La récupération d’informations, les compétences, la mémoire, les résultats des outils, l’état structuré, la divulgation progressive et la compression contribuent tous à créer un contexte de décision plus optimal, l’objectif passant d’un simple volume accru de contexte à un contexte de meilleure qualité. Néanmoins, le modèle peut choisir une action erronée, corrompre l’état, sauter les validations, se retrouver bloqué dans une boucle ou déclarer trop tôt le succès.
C’est à ce stade que commence l’ingénierie de gestion, avec la question de savoir quel système doit entourer le modèle afin que la tâche soit accomplie de manière fiable. Elle fournit ce que les prompts et le contexte seuls ne peuvent pas offrir : un état durable, des outils contraints, des permissions, de l’isolation, une vérification, une récupération, une évaluation et une capacité d’observation. Elle modifie également le cycle d’ingénierie. Une panne ne nécessite plus seulement une reformulation du prompt ; elle soulève la question de savoir quel contrôle manquait, et la réponse peut être un validateur, un contrat d’outil plus strict, une limite de politique, un point de contrôle, une stratégie de récupération ou une meilleure visibilité. Chaque panne se termine par un changement dans le système.
Le résultat est une griffe de harnais : échec, puis absence de contrôle, puis amélioration du harnais, puis vérification, puis une base plus solide. L’ingénierie des prompts améliore ce qui est dit au modèle, tandis que l’ingénierie du contexte améliore ce qu’il sait. L’ingénierie du harnais améliore les conditions dans lesquelles le modèle fonctionne et rend le système de plus en plus difficile à faire échouer de la même manière à deux reprises.
Responsabilités du temps d’exécution
Si le harnais représente le temps d’exécution, que contient-il ? Plutôt que de lister les prompts, les outils, la mémoire et le code d’orchestration, il est plus utile de définir les responsabilités du temps d’exécution.
- Le contexte détermine ce que le modèle doit savoir pour sa prochaine décision : instructions, matériel récupéré, compétences, résultats des outils pertinents et observations actuelles.
Ce ne sont pas sept fonctionnalités indépendantes, et il n’est pas nécessaire qu’il s’agisse de sept services. Ensemble, ils forment une boucle de contrôle autour d’un modèle probabiliste. Lorsque cette boucle fonctionne pendant des heures plutôt que des minutes, en surmontant les limites de contexte, les pannes, les tentatives de réessai et les changements d’agent, l’architecture commence à ressembler à quelque chose que les ingénieurs connaissent déjà bien : un système distribué.
La fenêtre de contexte n’est pas un stockage d’état
L’une des erreurs les plus courantes dans la conception d’agents est de traiter la fenêtre de contexte comme une mémoire.
C’est une habitude tentante. Le modèle peut voir toute la conversation, les appels d’outils précédents, les décisions et les résultats intermédiaires, donc ajouter davantage de contenu semble inoffensif. Pourtant, cette fenêtre constitue un ensemble de travail et non une base de données. Rien à l’intérieur n’est durable : un redémarrage, une troncature ou une opération de compactation peut la réduire ou même la remplacer complètement. L’agrandir augmente sa capacité sans améliorer sa durabilité.
Pour un agent qui fonctionne sur le long terme, l’état officiel de la tâche doit être stocké ailleurs : l’objectif, le travail terminé ou en attente, les décisions, les artefacts, les points de contrôle, les résultats de validation ainsi que des liens vers des ressources externes. Le contexte est ensuite reconstruit à partir de cet état en fonction des besoins actuels du modèle. La distinction est simple : le contexte correspond à ce que voit le modèle, tandis que l’état représente ce que sait le système.
La compactation rend cela évident. Un agent qui a passé trois heures à modifier un répertoire peut accumuler des centaines d’appels d’outils, des approches abandonnées et des observations en cours. Compresser cette histoire peut rendre le contexte suivant utilisable, mais un résumé reste une interprétation de ce qui s’est passé ; par conséquent, l’état critique ne devrait pas dépendre de ce que le compresseur a conservé. L’outil peut plutôt créer un contexte frais à partir de l’état durable, dans cet ordre : état de la tâche, artefacts pertinents, observations actuelles, compétences, et enfin le contexte du modèle.
Les points de contrôle appliquent le même principe en cas de panne du processus, et les transferts structurés l’appliquent entre agents ou travailleurs. Un successeur a besoin de l’état requis pour continuer correctement, et non de toute la conversation de son prédécesseur. La question architecturale devient de savoir quelles informations doivent survivre indépendamment du contexte, et une fois cette question posée, la gestion du contexte se transforme en un problème de gestion d’état.
Les agents à long terme sont des systèmes distribués
Lorsqu’un agent fonctionne pendant des heures ou des jours, le modèle familier de demande-réponse cesse de fonctionner. Un processus peut s’arrêter, un outil peut atteindre son délai de réponse maximal, ou un travailleur peut disparaître après avoir terminé une opération mais avant de la signaler. Deux travailleurs peuvent s’emparer de la même tâche, et le contexte d’un modèle peut disparaître en cours de route. Rien de tout cela n’est inhabituel, car il s’agit de problèmes classiques des systèmes distribués, et un outil conçu pour fonctionner sur de longues périodes a besoin de sémantiques d’exécution explicites pour les gérer.
Si le travail peut survivre au travailleur, il est nécessaire de fixer des limites à la propriété de cette tâche. Un bail permet à un travailleur d’occuper une tâche pendant une durée définie, tandis que les signaux périodiques envoient un indicateur de disponibilité à un observateur extérieur. Lorsque le travailleur disparaît, le bail expire et un autre peut reprendre le travail à partir de l’état persistant.
Les tentatives de réessai exigent une attention égale. Imaginez un agent qui soumet une déploiement et dont la tentative expire avant qu’un résultat ne soit obtenu. Une réessai automatique pourrait exécuter le déploiement deux fois. Par conséquent, les outils destinés aux agents ont besoin des garanties présentes ailleurs dans les systèmes distribués : des identifiants d’opération, de l’idempotence, des états d’échec explicites et un responsable clair pour le comportement de réessai.
Il y a ensuite la reprise. Une tâche longue doit être représentée comme un progrès durable et non comme une conversation en mémoire, suivant un cycle de vérification des points d’état, d’exécution, d’observation, de persistance et de continuation. Si l’exécution s’arrête en cours de route, le système doit déterminer si l’étape actuelle peut être reprise en toute sécurité, si elle a déjà été enregistrée, si elle est partiellement terminée ou s’il est nécessaire de compenser des erreurs. La reprise ne signifie pas rejouer tout le processus ; elle consiste à reconstruire l’état minimal requis pour continuer en toute sécurité. Les transferts suivent le même schéma : un nouvel agent reçoit l’objectif, les décisions, les résultats obtenus, l’état de validation ainsi que le travail en attente, sans rien recevoir de l’historique de conversation d’un autre agent.
Cela définit la limite fondamentale de fiabilité. Une fois qu’un agent peut survivre à son processus, ce dernier n’est plus l’unité de fiabilité ; c’est plutôt la tâche durable qui le devient.
La vérification est l’autre moitié de l’agentivité
Un agent peut écrire du code, exécuter une déploiement, construire une requête de base de données ou modifier l’infrastructure. Générer quelque chose n’est pas la même chose que le faire correctement, et le schéma risqué consiste à laisser l’agent décider seul si son travail a réussi, comme dans un message indiquant que le flux d’authentification est terminé et que tous les tests passent. Le système de gestion ne devrait pas accepter cela comme preuve ; il devrait plutôt exécuter les tests. De même, une affirmation selon laquelle le service est en bon état devrait déclencher des vérifications de santé sans mettre fin à la tâche, et une migration de données devrait être évaluée en fonction du schéma et des invariants des données, et non selon l’interprétation par le modèle de ses propres appels d’outil. La conviction d’un agent selon laquelle il a réussi n’est pas un signal fiable de finition.
C’est pourquoi la production utilise trois rôles distincts. Le planificateur décide de ce qui doit être fait. L’exécutant effectue des tâches définies. L’évaluateur détermine si l’état du système résultant répond aux exigences. Un seul modèle peut assumer ces trois rôles, mais leurs responsabilités restent distinctes.
La vérification doit reposer sur des éléments observables, et les preuves déterministes constituent le premier choix dès lors qu’elles sont disponibles : compilateurs, exécutateurs de tests, validateurs de schémas, contrôles de santé, état du déploiement, vérifications de politiques ou simples assertions. La notation basée sur des modèles est utile lorsque la correction est intrinsèquement sémantique, mais elle nécessite des critères concrets plutôt qu’une question vague concernant l’aspect visuel du résultat. La complétude devient alors une propriété du système et non quelque chose que le modèle affirme : les exigences sont remplies, la validation est réussie, les artefacts requis sont présents, les vérifications de politiques sont validées, et ce n’est qu’après cela que la tâche est considérée comme terminée. En d’autres termes, la vérification produit des preuves que l’évaluateur lit pour décider si l’exécution peut continuer ; l’évaluateur agit donc comme le capteur dans le cycle de rétroaction du système. L’agent assure l’avancement tandis que le système établit les preuves nécessaires.
Des instructions à l’application
On peut demander à un agent de ne pas faire quelque chose sans pour autant l’empêcher de le faire. Des directives telles que « ne modifiez pas la production », « écrivez uniquement dans l’espace de travail » et « ne divulguez jamais les identifiants » sont utiles, mais aucune ne constitue une barrière de sécurité si l’environnement d’exécution autorise encore cette opération. Les instructions communiquent l’intention, tandis que l’application établit des invariants.
La conception des outils met clairement en évidence cette différence. Lorsqu’on donne à un agent une fonction générique execute_sql(), son champ d’action est très différent de celui d’un agent disposant d’une interface de requête restreinte et en lecture seule. Cette dernière permet de vérifier les autorisations, de valider les paramètres, d’auditer les opérations et de réduire l’impact potentiel. Les outils MCP, les API, les systèmes de fichiers, les shells ainsi que les services externes fonctionnent de la même manière : le modèle propose une action, tandis que l’outil centralisé décide si cette action peut être exécutée et sous quelle identité, avec quels droits, dans quel environnement et conformément à quelles politiques.
Une règle pratique consiste à classer les contraintes en fonction de leur coût :
- Si enfreindre une contrainte est tolérable, une instruction suffit souvent.
- Si son enfreinte est coûteuse, il convient d’ajouter des vérifications.
- Si son enfreinte est dangereuse, il faut la faire respecter dès le niveau de contrôle initial.
Le sandboxing introduit une deuxième dimension. L’autorisation détermine si une action est autorisée. Un sandbox définit ce qui se passe lorsque l’agent se comporte mal, quelles que soient les circonstances. Les limites du système de fichiers et du réseau, les contraintes de ressources ainsi que des identifiants à portée restreinte permettent de limiter les conséquences d’un comportement inattendu. Les solutions plus avancées imposent également des transitions de flux de travail, et non seulement des appels à des outils isolés. Un déploiement en production ne peut avoir lieu que lorsque les tests sont réussis, que l’environnement de préparation est stable et qu’une personne l’a approuvé. Le modèle peut suggérer ce passage, mais ce sont les règles en temps réel qui en déterminent la légalité. Cela ressemble davantage à une machine d’états qu’à la confiance accordée à une phrase en langue naturelle. L’objectif n’est pas de restreindre l’intelligence, mais plutôt les capacités et l’impact potentiel.
On ne peut pas gérer ce que l’on ne peut pas observer
L’observabilité classique se demande si un service est en bon état, où la latence augmente et quelle dépendance échoue. Les systèmes à agents ont besoin d’une couche supplémentaire. Lorsqu’un agent échoue, la question est de savoir ce qui s’est passé et pourquoi son parcours l’a mené là. Que tentait-il d’accomplir ? Quel contexte avait-il à sa disposition ? Quels outils a-t-il utilisés ? Quelles politiques ont autorisé ou bloqué ces appels ? Quel état a changé ? Quelles preuves l’ont convaincu qu’il avait accompli sa tâche ? C’est cela, l’observabilité du parcours.
Les métriques standard des LLM telles que le nombre de tokens, la latence, le coût, la version du modèle ainsi que les entrées et sorties sont nécessaires mais insuffisantes, car une seule appel au modèle représente un événement parmi une chaîne plus large : intention, contexte, décision, action, observation, état, vérification et résultat. Supposons qu’un agent passe quarante minutes à migrer un service avant d’échouer. Savoir qu’il a consommé 80 000 tokens ne dit presque rien. Une trajectoire utile montrerait par exemple que l’outil utilisé a récupéré un guide de migration obsolète, que l’agent a choisi une API dépréciée, que le déploiement a techniquement réussi, que les vérifications d’intégration ont échoué et que la récupération a tenté exactement la même stratégie. C’est là une véritable diagnosis.
Cela signifie que le contexte doit indiquer sa provenance : un moyen de savoir quels compétences, documents, états et résultats d’outils ont influencé une décision donnée. Les appels aux outils nécessitent également un contexte causal, couvrant l’étape de la tâche qui les a déclenchés, l’identité utilisée, la politique évaluée ainsi que les conséquences. Les décisions de politique et les transitions d’état doivent également être visibles, tout comme les actions qui ont abouti au succès. Les indicateurs les plus révélateurs se révèlent être de nature comportementale : le taux de réussite des tâches, les échecs de vérification, la réussite des tentatives de récupération, les terminations prématurées, les refus de politique, les schémas d’échec récurrents, les escalades humaines et le nombre d’étapes par tâche réussie.
L’observabilité est ce qui complète le mécanisme de verrouillage. Une panne ne devrait pas se limiter à une simple entrée dans le journal des événements ; son parcours doit permettre de déterminer ce qui a mal tourné et d’identifier le contrôle manquant, qu’il s’agisse d’une source de contexte, d’un évaluateur, d’une politique, d’une limite d’outil, d’un point de contrôle ou d’une stratégie de récupération. L’objectif est un système qui ne peut pas échouer de la même manière à deux reprises.
Une nouvelle discipline systémique
Lorsqu’on demande comment améliorer les performances des agents, la réponse s’élargit à mesure que l’autonomie augmente. L’ingénierie des instructions permet d’ajuster les directives données. L’ingénierie du contexte permet d’optimiser les informations disponibles au moment de la décision. L’ingénierie du mécanisme de verrouillage permet d’ajuster l’ensemble du parcours d’exécution : état, actions, limites, retours d’information, récupération, vérification et observabilité. Ces approches ne se remplacent pas ; elles représentent simplement des domaines de plus en plus larges.
Une répartition judicieuse des tâches permet de structurer l’ensemble : le modèle s’occupe du raisonnement en situation d’incertitude, tandis que le système d’exécution gère les invariants. Un fichier qui ne doit jamais changer dispose d’une limite définie par le système de fichiers. Un système de production qui ne doit pas être modifié fait l’objet de vérifications d’autorisation. Une migration qui doit réussir est vérifiée par rapport à l’état final, et l’état des tâches qui doivent survivre à un redémarrage est persisté. Il ne faut pas demander au modèle de fournir des garanties d’exécution plus fiables.
Les agents de production vont échouer, et le signe d’un harnais mature réside dans ce qu’il fait ensuite. Chaque échec a un impact sur le fonctionnement en temps réel. Si la même erreur se reproduit, elle donne naissance à son propre évaluateur. Si une action s’avère risquée, la capacité qui la sous-tend se restreint. Si des progrès ont été perdus, un point de contrôle apparaît à l’endroit où ils manquaient, et si les tentatives de récupération échouent continuellement, une politique d’escalade prend le relais. L’exécution produit des preuves, ces preuves révèlent l’absence de contrôles, et ces contrôles rendent la prochaine exécution plus fiable.
Cela modifie également la manière dont les agents sont évalués. La question n’est plus de savoir à quel point le modèle est performant, mais plutôt dans quelle mesure l’ensemble du système parvient à accomplir ce type de tâche de manière fiable. L’ingénierie de Harness n’est pas un simple cadre d’orchestration supplémentaire ; c’est une discipline systémique visant à rendre l’intelligence probabiliste fiable. Une démonstration prouve qu’un agent peut effectuer une action une fois. Un système en production doit le faire de manière fiable, vérifiable, réparable et de façon répétée, chaque échec améliorant la performance des exécutions suivantes. Une grande partie du travail le plus difficile se trouve en réalité en dehors des instructions fournies, dans l’architecture des boucles d’état, de rétroaction, de vérification, de récupération et de contrôle qui transforment le raisonnement de l’agent en un comportement systémique durable.