Explication du agent harness : les composants qui transforment un LLM en agent.

En 2023, il était facile de décrire le fonctionnement d’un modèle de langage : on tapait une question, comme « écrivez une fonction Python qui trie un tableau de nombres », et une réponse arrivait presque instantanément. Le modèle ne montrait aucun mode de réflexion visible ; il s’agissait d’un simple LLM, sans les fonctionnalités supplémentaires présentes dans les systèmes agents d’aujourd’hui : outils, mémoire, compétences, etc. Ce sont précisément ces éléments qui transforment un simple LLM en un agent IA.

Comment la course a changé

Pendant 2023 et 2024, la concurrence portait sur les modèles eux-mêmes. OpenAI disposait d’un modèle polyvalent de pointe, Anthropic en avait un pour le codage, et tous se disputaient la première place sur des benchmarks tels que MMLU et SWE-bench. Finalement, cette course a commencé à se stabiliser, la capacité de raisonnement et la gestion de longs contextes sont devenues prioritaires. Un indicateur « en train de réfléchir... » a commencé à apparaître dans les interfaces de chat, suscitant la curiosité quant à ce qui se passait derrière.

Les utilisateurs changeaient également. À mesure que les modèles s’amélioraient, les gens cessaient de poser des questions et commençaient à leur confier des tâches. Une tâche exige que le système fixe des objectifs, utilise des outils externes tels qu’un navigateur, se souvienne des conversations précédentes et des faits enregistrés, puis produise un résultat.

Comparons ces deux époques à l’aide d’un exemple. Au début, quelqu’un pourrait prendre une capture d’écran de la page d’accueil d’Amazon, la donner à un modèle de programmation et demander un site ayant le même aspect, tout en une seule étape. Le résultat serait une interface utilisateur acceptable. Imaginez maintenant vouloir que l’interface utilisateur, le backend, l’infrastructure et tout le reste soient mis en place d’un seul coup.

D’ici 2026, le même utilisateur pourrait écrire « corrigez la faille signalée dans l’issue #122 sur GitHub ». Cette seule phrase cache plusieurs étapes. Un modèle de 2023 aurait répondu qu’il ne pouvait pas accéder à votre repository. Un modèle intégré dans un bon framework entre dans un cycle de réflexion : raisonner, planifier, choisir un outil ou une action, l’exécuter, observer le résultat, puis répéter ou s’arrêter.

Qu’est-ce qu’un framework

Tous ces compléments autour d’un LLM (contexte, outils, mémoire, etc.) ont besoin d’une méthode organisée pour interagir avec le modèle. Cette discipline a un nom, et sa définition habituelle est concise : il s’agit de la couche d’infrastructure entourant un agent IA, chargée de l’envelopper, de le guider, de le tester, de le surveiller et d’évaluer ses résultats. En termes simples, c’est le système d’exploitation autour du LLM.

Cette couche couvre l’architecture des agents, le cadre d’orchestration qui coordonne les sous-agents, le système d’évaluation qui notifie les résultats, l’infrastructure de exécution, la sécurité, la gouvernance et l’observabilité.

Pourquoi c’est nécessaire

Les tâches confiées aux agents deviennent de plus en plus complexes, tout comme le temps qu’ils y consacrent. Les données d’Anthropic montrent que les temps d’exécution augmentent à un rythme rapide. Il y a un an, en 2025, un agent pouvait travailler environ une heure sur une tâche donnée. Aujourd’hui, ce chiffre se situe plutôt autour de douze heures.

Les travaux à long terme entraînent leurs propres échecs. Les agents peuvent entrer en boucle indéfiniment, inventer des outils qui n’existent pas, corrompre leur propre état, épuiser leurs budgets de tokens, perdre le contexte, réessayer des actions inefficaces, échouer sans en informer quiconque, abuser de leurs permissions ou même oublier l’objectif.

Ces échecs coûtent de l’argent réel. Un agent bloqué dans une boucle infinie pendant douze heures consommerait une quantité énorme de tokens et de ressources de calcul. Un cadre de contrôle peut limiter cela en imposant un budget par tâche, mesuré en temps, en tokens ou en ressources de calcul.

La sécurité est la préoccupation majeure. Si le modèle choisit un outil destructeur, par exemple celui qui efface le système de fichiers, c’est dans le cadre de contrôle que l’on décide de ce qu’il peut toucher. En bref, le cadre de contrôle vous donne un contrôle sur l’agent et, avec lui, la certitude que celui-ci fait ce que vous avez prévu.

Les composants

Quel que soit le nom donné par une équipe à son cadre de contrôle, ses éléments se répartissent en huit groupes. Chacun représente une question à laquelle l’agent doit être capable de répondre.

• État de l’agent : où en est l’exécution en ce moment ? Il suit la tâche actuelle, les étapes, les observations et les décisions. Si un plan comporte quatre étapes, il enregistre celles qui ont été terminées, celle qui est en cours et celles qui n’ont pas encore commencé. Sans cela, un agent interrompu ne peut pas reprendre là où il s’était arrêté.
• Outils : quelles actions sont disponibles ? C’est la partie la plus visible. L’exécution de code, un navigateur, des API, des bases de données et une console se trouvent ici. Pour un agent de programmation, la fonction read_file fait partie des éléments fondamentaux.
• Planification : quoi faire ensuite ? Il décide de la suite des opérations et rédige ou modifie le plan. Pour une tâche de programmation, il peut générer une séquence de quatre ou cinq étapes.

Mémoire : que sait-on déjà ? Elle stocke et récupère des informations au cours de différentes étapes ou sessions. Lorsque du contenu est extrait d’une base de données vectorielle pour être intégré dans le contexte, le fait de le résumer au préalable peut permettre d’économiser de l’espace, tâche qui revient au composant mémoire.

Orchestration : comment le processus s’exécute-t-il ? Il contrôle la boucle d’exécution, les appels aux outils, les tentatives de répétition, les sous-agents, le parallélisme ainsi que les transferts de responsabilités. Dans un flux d’achat, un sous-agent chargé du paiement peut fonctionner en même temps qu’un agent gérant les stocks met à jour ces derniers, ou bien l’agent des stocks peut être prié d’attendre que le paiement réussisse.

Gestion du contexte : que l’LLM doit voit-il en ce moment ? Il décide de ce qui est inclus dans la fenêtre de contexte à chaque étape.

Sécurité et gouvernance : qu’est-ce qui est autorisé ? Les permissions, le sandboxing, les mécanismes d’approbation, les politiques, les limites et l’authentification entrent en jeu ici. Même si le modèle est autorisé à modifier des fichiers, il est judicieux d’interdire leur suppression.

Observabilité et évaluation : a-t-il vraiment fonctionné ? Cela permet de suivre ce qui s’est passé et d’évaluer le succès, l’échec ou les contraintes violées. Si une tâche nécessite trois des dix outils disponibles, il est utile de voir comment ils ont été utilisés. Lorsqu’un outil échoue, la cause peut être un outil que le modèle n’a jamais eu, ou des données qui n’ont jamais atteint son contexte. Les traces permettent de faire la distinction entre ces cas.

La pratique consistant à concevoir, développer et exécuter ces éléments afin que l’agent performe au mieux s’appelle l’ingénierie de harness. Il s’agit d’une discipline relativement nouvelle, et la plupart des équipes sont encore en train de déterminer quelles responsabilités incombent à chacun.

Un agent de codage du début à la fin

Prenez un agent de codage équipé d’un harnais et donnez-lui l’instruction « résolvez le bug du problème n°122 sur GitHub ». Il ne s’agit pas d’une demande de type « expliquez-moi cela ». C’est une tâche réelle qui nécessite de la planification, l’utilisation d’outils et le maintien en mémoire des informations. Un flux logique possible est le suivant :

1. Les informations fournies par l’utilisateur entrent dans le contexte. Le modèle analyse ces données et définit un objectif, qui reste dans le contexte jusqu’à ce qu’il soit atteint.
2. Le modèle planifie les actions : il examine les bugs similaires, modifie le bon fichier, compile le code, exécute les tests et met à jour sa mémoire.
3. Pour la première étape, l’harnais récupère des informations dans une base de données vectorielle, à savoir des détails de bugs antérieurs pertinents pour celui-ci. Les notes relatives à l’authentification sont considérées comme les correspondances les plus proches et intégrées au contexte.

Au vu de ce contexte, le modèle décide d’ouvrir auth.py pour corriger la faille d’authentification. Cela nécessite les outils read_file et write_file, qu’il utilise pour modifier et enregistrer le fichier.

Ensuite, il teste la modification depuis le terminal, en utilisant un outil de terminal parmi ceux qui lui sont disponibles. Le système de gestion s’assure qu’il dispose du niveau d’accès approprié tant au terminal qu’aux fichiers.

Le modèle passe à l’étape suivante du plan et exécute les cas de test, ce qui requiert d’autres outils. Chaque étape met à jour le contexte afin que le modèle sache où il en est et ce qui reste à faire.

Pendant tout le processus, les journaux d’observabilité enregistrent tout : les outils utilisés, le temps écoulé, la mémoire consommée, ainsi que les échecs survenus.

L’évaluation n’a pas encore été abordée, et elle mérite un traitement distinct. Elle va au-delà de la précision et peut prendre en compte plusieurs indicateurs liés au comportement réel de l’agent.

Où cela mène

La fiabilité à long terme est l’un des plus grands problèmes non résolus. Comme les agents fonctionnent pendant des heures, voire des jours, leurs exécutions doivent être fiables. Un agent bloqué dans une boucle ou se trouvant dans un état corrompu gaspille des ressources et peut compromettre la sécurité.

L’évaluation devient également plus difficile à mesure que les outils utilisés deviennent plus complexes. Chaque tâche laisse derrière elle des données, comme l’utilisation de la mémoire, et les équipes doivent décider s’il convient d’échanger le modèle ou de retravailler les outils, d’ajouter de nouveaux outils ou de réparer ceux existants. La communauté travaille activement à résoudre ces problèmes.