Agents IA : Clarification des Concepts de Harness et Échafaudage

Dans le monde en constante évolution des agents d'intelligence artificielle, le vocabulaire associé se développe souvent à une vitesse qui dépasse la compréhension commune. Les termes se mélangent, sont réutilisés dans divers contextes, ou deviennent des abréviations pour des idées qui ne sont jamais pleinement expliquées. Cette situation est particulièrement visible dans le domaine des agents IA, où certains concepts sont renommés, d'autres sont largement utilisés pendant quelques mois avant de disparaître discrètement.

Cette dynamique peut être écrasante pour les nouveaux venus et même pour les praticiens qui tentent de suivre les derniers développements. Après la conférence ICLR 2026, un participant (@ariG23498) a posé une question qui illustre bien cette confusion : "Que voulez-vous dire par les termes 'exploiter' et 'échafauder' dans le contexte des agents ? J'ai entendu beaucoup d'explications pendant que j'étais à l'ICLR, mais je n'ai pas compris pourquoi elles ne convergeaient pas vers une seule explication."

Ce glossaire est une tentative de clarifier les termes qui reviennent souvent sans explications claires et cohérentes. Il n'est pas destiné à être un dictionnaire complet de chaque terme dans le domaine. Au lieu de cela, il se concentre sur les concepts qui sont souvent confondus, réutilisés de différentes manières, ou supposés évidents alors qu'ils ne le sont pas.

La plupart de ces termes apparaissent que vous construisiez un agent, en déployiez un, ou utilisiez simplement des outils comme Claude Code, Codex ou Hermes Agent. La dernière section couvre des concepts spécifiques à l'entraînement des modèles, ce qui est plus pertinent si vous travaillez dans ce domaine.

Beaucoup de ces termes n'ont pas encore de définitions universellement acceptées, et différents cadres utilisent le même mot de manière différente. L'objectif ici n'est pas d'imposer un vocabulaire correct, mais de fournir un modèle mental pratique qui facilite les discussions.

Ingénierie du Contexte

Le modèle est le LLM : il prend du texte en entrée et produit du texte en sortie (par exemple, Claude, Qwen, GPT, Kimi, DeepSeek…). Par lui-même, il n'a pas de mémoire entre les appels, et pas de boucle. Le modèle peut exprimer l'intention d'appeler un outil, mais il a besoin d'un harness pour l'exécuter réellement. Il répond à une invite et s'arrête. En l'enveloppant dans un échafaudage et un harness, il devient un agent.

La couche définissant le comportement autour du modèle : prompt système, descriptions des outils, comment les réponses du modèle sont analysées, ce qu'il se souvient à travers les étapes (gestion du contexte). Cela façonne la manière dont le modèle perçoit le monde et agit dans celui-ci, que ce soit lors de l'entraînement ou lors de l'inférence.

Des produits comme Claude Code, Codex, et Antigravity CLI appellent l'ensemble de la structure un harness. La documentation de Claude Code le dit directement : "Claude Code sert de harness agentique autour de Claude." C'est l'utilisation large : le harness signifie tout ce qui n'est pas le modèle. La distinction entre échafaudage et harness est particulièrement importante lorsque vous devez les raisonner séparément, comme dans un pipeline d'entraînement. Vous entendrez également "échafaudage" utilisé plus largement pour couvrir toute infrastructure sur laquelle le harness repose : hooks, configuration d'exécution, même structure de répertoire.

Certains produits comme Claude Code et Codex sont étroitement liés aux modèles de leur fournisseur. D'autres comme Antigravity CLI et Hermes Agent vous permettent de brancher n'importe quel modèle.

La couche d'exécution à l'intérieur de l'agent : elle appelle le modèle, gère ses appels d'outils, décide quand s'arrêter. Le harness est ce qui fait fonctionner l'agent. L'échafaudage, défini ci-dessus, est ce à partir de quoi le modèle travaille : ses instructions, ses outils, son format.

L'ingénierie du harness est la discipline de conception de cette couche : décider quand l'agent doit s'arrêter, comment les erreurs sont gérées, et quels garde-fous le maintiennent sur la bonne voie. Cela s'applique à la fois à l'entraînement et à l'inférence. L'article d'Addy Osmani et le compte rendu d'OpenAI sur la construction avec Codex couvrent cela du côté de l'inférence.

Au moment de l'évaluation, le même schéma apparaît sous la forme d'un eval harness : au lieu de collecter des données d'entraînement, il exécute un ensemble fixe de scénarios à un point de contrôle du modèle et enregistre des métriques plutôt que de mettre à jour les poids.

Certains cadres utilisent le terme orchestrateur pour désigner un contrôleur de niveau supérieur qui coordonne le travail entre plusieurs agents. Contrairement à un harness, qui conduit un modèle à travers sa boucle d'exécution, un orchestrateur gère les agents comme des unités, chacune exécutant son propre harness (voir sous-agents ci-dessous).

Le terme vient de l'apprentissage par renforcement, où un agent est simplement une fonction qui prend une observation et renvoie une action. L'environnement prend cette action et renvoie une nouvelle observation, et la boucle se répète. Cette boucle est toujours au cœur du fonctionnement des agents LLM.

Dans le monde des LLM, le terme a été élargi. Un agent est un modèle plus tout ce qui l'entoure qui lui permet d'agir, pas seulement de répondre. Il transforme la génération de texte brut en quelque chose qui peut agir dans une boucle : prenant des informations, décidant quoi faire, et agissant sur les résultats.

Prenez un agent de codage comme exemple concret. Le prompt système, les descriptions des outils, et le format de sortie que le modèle suit forment l'échafaudage. La boucle qui appelle le modèle, gère ses appels d'outils, et décide quand s'arrêter est le harness. Lors de l'entraînement, le harness exécute également beaucoup de ces boucles en parallèle et renvoie les résultats pour mettre à jour le modèle.

Dans la communauté, cela se formule généralement comme Agent = Modèle + Harness (@Vtrivedy10 et le tweet de Will Brown pour référence). Si vous n'êtes pas le modèle, vous êtes le harness. La distinction subtile entre harness et échafaudage qui crée la plupart des confusions est ce que les deux sections ci-dessus abordent.

Lorsque les gens parlent de produits comme Claude Code, Codex, ou Cursor, ils font référence à un harness spécifique construit sur un modèle spécifique, conçu et optimisé ensemble. Deux produits utilisant le même modèle sous-jacent peuvent sembler complètement différents car leurs harness font des choix différents. Et remplacer un meilleur modèle dans le même harness change également l'expérience. Le modèle, le harness, et le produit sont trois choses différentes.

Ingénierie du Contexte

Concevoir ce qui entre dans la fenêtre de contexte de l'agent : ce que le modèle voit à chaque étape, prompt système, descriptions des outils, historique de conversation, connaissances récupérées. Ce n'est pas une décision unique : au fur et à mesure que le modèle fonctionne, les tours précédents façonnent ce qui entre dans les appels futurs, et le harness gère activement cela tout au long de l'exécution. Cela s'applique à la fois à l'entraînement et à l'inférence, mais le coût de se tromper est très différent. Lors de l'entraînement, ce que le modèle voit façonne ce qui est appris. Si vous vous trompez, vous devez réentraîner. Lors de l'inférence, c'est juste du texte : changez un prompt et redéployez. Le cours d'ingénierie du contexte de HF couvre cela en profondeur.

La mémoire fait partie de ce tableau. La mémoire à court terme est ce qui reste dans la fenêtre de contexte pendant une seule exécution : historique de conversation, résultats des outils, raisonnement précédent. La mémoire à long terme persiste entre les sessions, stockée de manière externe et récupérée à la demande, puis injectée à nouveau dans le contexte lorsque cela est pertinent.

Une politique est le comportement qu'un agent suit : face à une situation donnée, elle définit la probabilité de prendre chaque action possible. Dans les systèmes LLM, une partie de cette politique est apprise dans les poids du modèle, mais le comportement dépend également de l'échafaudage et du harness environnants. Le même modèle peut se comporter très différemment selon ses prompts, outils, mémoire et boucle d'exécution.

Une politique n'est pas un agent. La politique définit le comportement ; l'agent est le système complet qui agit dans un environnement. Enveloppé un point de contrôle dans un échafaudage et un harness et déployez-le, et vous obtenez un agent dont le comportement est la politique.

Comment les agents atteignent l'extérieur d'eux-mêmes : APIs, interprètes de code, bases de données, recherche web, systèmes de fichiers. Le modèle exprime l'intention d'utiliser un outil dans un format structuré. Les APIs d'inférence modernes présentent cela comme un objet de première classe : le harness reçoit l'appel directement et le dirige vers la bonne fonction. Le résultat est renvoyé dans le contexte et la boucle continue.

Des paquets de connaissances réutilisables et structurés qui permettent des tâches multi-étapes. Là où un outil est une action ("exécutez cette commande"), une compétence regroupe tout ce qui est nécessaire pour atteindre un objectif ("enquêter sur ce bug, formuler une hypothèse, écrire un correctif"). Elles sont portables entre les agents et chargées à la demande. La ligne entre outil, compétence et sous-agent varie selon les cadres. Le cours d'ingénierie du contexte de HF couvre les compétences en profondeur.

Un agent appelé par un autre agent pour gérer une sous-tâche spécifique. Il a son propre modèle et échafaudage, raisonne de manière indépendante, et renvoie un résultat. L'agent appelant n'a pas besoin de savoir comment il fonctionne en interne. C'est ce qui sépare un sous-agent d'un outil (un appel de fonction) ou d'une compétence (connaissances empaquetées) : un sous-agent peut lui-même raisonner, utiliser des outils, et appeler d'autres sous-agents. L'agent appelant est parfois appelé un orchestrateur.

Les termes ci-dessus s'appliquent que vous soyez en train d'entraîner ou de déployer. Ces quatre sont spécifiques à l'entraînement, où l'agent exécute des tâches, est noté, et les poids de son modèle sont mis à jour. Chaque système d'entraînement RL pour les LLM est construit autour du même pipeline :

• L'environnement est tout ce avec quoi vous pouvez interagir : un objet avec état qui prend une action en entrée, met à jour son état interne, et renvoie une observation. Dans le contexte des LLM, les actions sont généralement des appels d'outils. Un système de fichiers est un exemple simple : l'action touch foo.txt met à jour l'état en créant le fichier, et l'observation pourrait être la liste de fichiers mise à jour. Les définitions varient selon les cadres.

Nous avons récemment publié un guide dédié à ce sujet, donc plutôt que de le compresser ici, consultez Le Guide Ultime des Environnements RL pour une décomposition complète des types, cadres et exemples.

• Le formateur est ce qui rend l'agent meilleur : il exécute de nombreux épisodes d'agents, note les résultats et les utilise pour mettre à jour les poids internes du modèle. Le GRPOTrainer de TRL est un exemple concret : une seule classe qui gère la génération d'épisodes, la notation des récompenses, et les mises à jour des poids.

• Un rollout est une exécution complète de l'agent du début à la fin : ce que l'agent a vu, ce qu'il a fait, et quelle récompense il a reçue à chaque étape. C'est aussi appelé une trajectoire ou un trace, selon le contexte. C'est les données brutes que les algorithmes RL utilisent.