Remplacez GPT-5 par Claude dans un agent fonctionnel et, la plupart du temps, le comportement change à peine. Modifiez la gestion des tentatives, ce que vous injectez dans sa fenêtre de contexte, ou le moment où il décide de s'arrêter, et l'agent entier se comporte différemment. Cet écart est révélateur : le modèle est la partie la plus petite et la plus interchangeable d'un agent opérationnel. L'ingénierie intéressante réside dans tout ce qui l'entoure.
Ce wrapper a désormais un nom. Les praticiens ont adopté le terme « harness » pour désigner la couche qui transforme un générateur de texte en quelque chose qui effectue des actions au fil du temps plutôt que d'exécuter un script fixe. Le terme s'est répandu rapidement sur Twitter et dans les blogs d'ingénierie début 2026, ce qui signifie qu'il a aussi été utilisé de manière imprécise, le même mot faisant un travail légèrement différent dans chaque article que vous lisez. Cet article le définit clairement : ce qu'est un harness, de quoi il est fait, en quoi il diffère d'un « framework » et d'un « scaffold », et pourquoi la plupart de la qualité de votre agent se cache dans le harness, pas dans le modèle.
La version courte
- Un agent harness est le logiciel autour d'un LLM qui gère la boucle d'exécution, les outils, la mémoire, le contexte, l'état, la gestion des erreurs et les garde-fous. Le modèle génère du texte ; le harness décide ce que le modèle voit, ce qu'il peut faire, quand s'arrêter et ce qui se passe quand quelque chose se casse.
- En production, l'appel au modèle est souvent la plus petite partie visible de la surface du système. Un modèle plus faible dans un harness bien conçu peut surpasser un modèle plus puissant dans un harness négligé, notamment sur les tâches longues et nécessitant de nombreux outils.
- Un harness comporte environ neuf à onze composants récurrents. La plupart sont des éléments que le modèle ne touche jamais directement.
- « Harness » n'est pas la même chose que « framework ». Un framework (LangGraph, un agents SDK) est la bibliothèque avec laquelle vous construisez ; le harness est la couche en cours d'exécution que cette bibliothèque vous aide à assembler.
Qu'est-ce qu'un Agent Harness ?
Un agent harness est l'infrastructure logicielle entourant un modèle de langage qui gère la boucle d'exécution, l'accès aux outils, la mémoire, le contexte, la persistance de l'état, la gestion des erreurs et les garde-fous. Le modèle génère du texte. Le harness décide ce que le modèle voit à chaque tour, quelles actions il peut entreprendre, quand il s'arrête et ce qui se passe quand une étape échoue.
La formulation la plus claire vient de LangChain, qui le réduit à une équation : Agent = Model + Harness. Le modèle apporte l'intelligence. Le harnais est ce qui permet à cette intelligence d'agir dans le monde.
« Un harness est l'ensemble du code, de la configuration et de la logique d'exécution qui ne fait pas partie du modèle lui-même. »
— LangChain, L'anatomie d'un harness d'agent
Je trouve que la frontière est plus facile à percevoir à travers une seule question : quand votre agent fait une erreur, est-ce que le raisonnement propre du modèle était faux, ou est-ce que le système autour de lui a fourni au modèle le mauvais contexte, les mauvais outils, ou aucun moyen de se corriger ? La plupart du temps, sur un système réel, c'est la deuxième option. Le modèle a raisonné correctement sur des entrées erronées. Le harness est ce qui contrôle les entrées.
Point clé : Le modèle génère ; le harness gouverne. Cette séparation est tout le concept.
Quels sont les composants d'un harness d'agent ?
Chaque harness de production assemble les mêmes éléments récurrents : une boucle d'exécution qui pilote le modèle tour par tour, un accès aux outils qui lui permet d'agir, une mémoire entre les tours, une gestion du contexte pour ce qu'il voit en ce moment, une persistance d'état pour que le travail survive entre les sessions, une gestion des erreurs pour les étapes échouées, et des garde-fous qui contraignent ce qu'il peut faire. Les systèmes de production ajoutent des boucles de vérification et une orchestration de sous-agents.
Un inventaire utile, tiré de la façon dont les praticiens décrivent les systèmes réels :
- Boucle d'exécution / de contrôle : ce qui pilote l'agent tour par tour. Appeler le modèle, lire sa sortie, exécuter l'outil demandé, renvoyer le résultat, répéter jusqu'à la condition d'arrêt.
- Accès aux outils : les fonctions, API, exécutions de code et système de fichiers accessibles au modèle.
- Mémoire : ce que l'agent conserve d'un tour à l'autre et d'une session à l'autre.
- Gestion du contexte : ce qui est chargé dans la fenêtre du modèle à chaque tour, et ce qui est compacté lorsqu'elle déborde.
- Persistance d'état / points de contrôle : sauvegarder l'état de l'agent pour reprendre une exécution interrompue ou en pause.
- Gestion des erreurs : tentatives, replis et récupération lorsqu'un appel d'outil ou un appel au modèle échoue.
- Garde-fous : limites sur ce que l'agent peut faire, comme les outils autorisés, les plafonds d'étapes et la validation des sorties.
- Boucles de vérification : le fait que l'agent (ou le harnais) vérifie son propre travail avant de le déclarer terminé.
- Orchestration de sous-agents : instancier des sous-agents, leur déléguer des tâches et collecter leurs résultats pour les tâches plus importantes.
Ces éléments ne sont pas tous universels. La boucle d'exécution, les outils, la gestion du contexte et la gestion des erreurs apparaissent même dans un prototype de week-end. La persistance d'état, la vérification et l'orchestration de sous-agents sont là où les prototypes et les systèmes de production divergent. Un prototype peut les ignorer ; un agent de production longue durée ne le peut pas. La note d'Anthropic sur agents de longue durée est un tour d'horizon des parties réservées à la production : comment un agent reconstruit sa compréhension à partir d'un fichier de progression après la réinitialisation de sa fenêtre de contexte, et comment les tests sont intégrés dans la boucle.
Pour ceux qui souhaitent le pont académique, un récent panorama des architectures d'agents condense ce même mécanisme en un tuple formel plus petit de composants essentiels. La liste du praticien et le cadrage de l'étude sont deux niveaux de zoom sur la même structure : l'étude compresse, l'inventaire ci-dessus développe. Considérez le comptage de neuf à onze comme les composants que la plupart des harnais de production partagent, et non comme une norme ratifiée ; le domaine n'a encore rien ratifié.
Point clé : La plupart des pièces mobiles d'un agent résident dans le harnais, pas dans le modèle. Le modèle est un composant parmi d'autres.
Pourquoi le harnais compte-t-il plus que le modèle ?
Un modèle plus faible dans un harness bien conçu surpasse fréquemment un modèle plus puissant dans un harness mal conçu. La raison est mécanique, pas magique : la fiabilité end-to-end d'un agent est le produit de la fiabilité de chaque étape, et la plupart de ces étapes (sélection d'outil, assemblage du contexte, récupération d'erreur) relèvent du harness, pas du modèle. Améliorez-les et toute la chaîne devient plus fiable, quel que soit le modèle utilisé.
L'arithmétique le rend concret. Supposons que chaque étape d'une tâche en dix étapes réussisse 99 % du temps. Le succès end-to-end n'est pas 99 %. C'est 0,99 à la dixième puissance, environ 90 %. Poussez chaque étape à 99,9 % et le end-to-end passe à environ 99 %. La fiabilité par étape se cumule, et la fiabilité par étape est avant tout une propriété du harness. C'est pourquoi optimiser la gestion des erreurs et la gestion du contexte rapporte davantage que de substituer un modèle légèrement meilleur sur un benchmark.
Il existe un signal de production qui pointe dans le même sens. MongoDB, citant l'étude de cas de Vercel, rapporte que Vercel a réduit la majeure partie des outils de leur agent et a vu son taux de succès grimper fortement sur le même modèle, avec un harness plus petit et plus propre. Considérez-le comme une preuve convergente plutôt qu'une preuve définitive : c'est un cas de production, pas une expérience contrôlée, mais il pointe dans la même direction que l'arithmétique composée et les travaux d'enquête ci-dessus.
C'est l'heuristique à laquelle je reviens sans cesse en tant qu'ingénieur de plateforme : le contexte est le goulot d'étranglement, pas la capacité brute du modèle, et l'échafaudage construit pour masquer les lacunes actuelles des modèles tend à être absorbé au fur et à mesure que les modèles s'améliorent. Construisez les parties durables du harness (la boucle, l'état, la récupération) et laissez le modèle sous-jacent s'améliorer selon son propre calendrier.
Point clé : Quand votre agent échoue, suspectez d'abord le harness avant le modèle. Les probabilités jouent en sa faveur.
Quelle est la différence entre un harness, un scaffold et un framework ?
Ces trois termes sont utilisés de façon interchangeable, et ce ne devrait pas être le cas. Un framework est la bibliothèque ou le SDK avec lequel vous construisez, comme LangGraph ou un SDK d'agents. Un harness est la couche d'exécution et de gouvernance autour du modèle, qu'un framework vous aide à assembler. Un scaffold est le plus flou des trois : parfois quasi-synonyme du harness, parfois la version prototype de celui-ci, parfois spécifiquement la couche de prompt et de description d'outils.
Le vocabulaire est véritablement instable, et la chose la plus claire à faire est de cartographier les usages plutôt que d'en imposer un. Celui de HuggingFace Glossaire des agents le dit directement :
« Beaucoup de ces termes n'ont pas encore de définitions universellement acceptées, et différents frameworks utilisent le même mot différemment. »
— HuggingFace, Glossaire des agents
| Terme | Ce à quoi il fait référence | Relation |
|---|---|---|
| Framework | La bibliothèque ou le SDK avec lequel vous construisez (LangGraph, un SDK d'agents) | Un outil pour assembler un harness |
| Harness | La couche d'exécution autour du modèle : boucle, outils, contexte, état, garde-fous | Ce que vous livrez et exécutez |
| Scaffold | Utilisé de façon approximative : quasi-synonyme de harness, ou la version prototype / couche de prompt | Chevauchement avec harness ; moins précis |
| Boucle | Le cycle d'exécution à l'intérieur du harness | Un composant du harness |
La conclusion pratique pour raisonner sur votre propre système : quand quelqu'un dit « framework », demandez s'il désigne la bibliothèque ou la chose qui s'exécute. Quand quelqu'un dit « scaffold », demandez s'il désigne le harness entier ou seulement la couche prompt-et-outils. La désambiguïsation est la valeur ici, pas une prétention au dernier mot.
Comment LangGraph implémente-t-il le pattern harness ?
LangGraph est une implémentation Python open-source populaire du pattern harness. Il modélise l'exécution d'un agent comme un graphe orienté de nœuds et d'arêtes, avec un état typé circulant entre eux et chaque transition pouvant faire l'objet d'un checkpoint. Si les composants abstraits ci-dessus semblent insaisissables, LangGraph est l'endroit pour les voir prendre forme concrète dans un vrai outil.
Le mappage est proche du un pour un. Les nœuds et les arêtes constituent la boucle d'exécution : chaque nœud effectue du travail, chaque arête décide où le contrôle passe ensuite. L'objet d'état typé passé entre les nœuds est le composant contexte-et-état rendu explicite. Le checkpointing (LangGraph persiste l'état via des savers comme son implémentation basée sur Postgres) est le composant de persistance d'état. Une limite d'étapes configurable est un guardrail de condition d'arrêt, empêchant un agent défaillant de boucler indéfiniment. Mêmes composants, nommés et câblés par une bibliothèque spécifique.
Si vous souhaitez faire tourner un agent LangGraph sur votre propre serveur, en permanence, c'est une question de déploiement plutôt que conceptuelle. Voir notre guide Linux VPS pour cette voie. Ici, LangGraph n'est que l'exemple travaillé : la preuve que « boucle d'exécution », « persistance d'état » et « guardrail » ne sont pas des abstractions, ce sont des choses que vous pouvez montrer du doigt dans du vrai code.
Foire aux questions
Qu'est-ce qu'un Agent Harness ?
Un agent harness est le logiciel autour d'un modèle de langage qui le transforme en agent. Il gère la boucle d'exécution, l'accès aux outils, la mémoire, le contexte, la persistance d'état, la gestion des erreurs et les guardrails. Le modèle génère du texte ; le harness décide ce que le modèle voit, ce qu'il peut faire, quand s'arrêter et ce qui se passe en cas d'échec.
Un harness d'agent est-il la même chose qu'un framework d'agent ?
Non. Un framework est la bibliothèque ou le SDK avec lequel vous construisez, comme LangGraph ou un SDK d'agents. Le harness est la couche d'exécution et de gouvernance active autour du modèle (la boucle, les outils, le contexte, l'état et les garde-fous) qu'un framework vous aide à assembler. Vous utilisez un framework pour construire un harness.
Quels composants possède chaque harness d'agent ?
La plupart des harnesses partagent un noyau récurrent : une boucle d'exécution, l'accès aux outils, la mémoire, la gestion du contexte, la persistance d'état, la gestion des erreurs et les garde-fous. Les harnesses de production ajoutent des boucles de vérification et l'orchestration de sous-agents. Les prototypes peuvent ignorer les éléments réservés à la production, mais la boucle, les outils, la gestion du contexte et la gestion des erreurs apparaissent presque partout.
Que signifie « Le LLM est la plus petite partie de votre système d'agent » ?
Cela signifie que la plupart du comportement et de la fiabilité d'un agent proviennent du harness, pas du modèle. La fiabilité de bout en bout est le produit du taux de succès de chaque étape, et la plupart des étapes sont du travail de harness. MongoDB, citant l'étude de cas de Vercel, rapporte un saut du taux de succès grâce aux seuls changements de harness, sur le même modèle. C'est la preuve que corriger le harness surpasse la correction du modèle.
Où vit la qualité de votre agent
Le harness est l'endroit où réside la plupart de la qualité d'un agent, et vous avez maintenant le vocabulaire pour localiser les problèmes dans votre propre système. Vous pouvez définir un harness, nommer ses composants, le distinguer d'un framework et d'un scaffold, et raisonner sur la question de savoir si un échec donné est un problème de modèle ou un problème de harness.
Alors, la prochaine fois que votre agent se comporte mal, auditez d'abord la couche harness : le contexte que vous lui fournissez, les outils que vous avez exposés, les conditions d'arrêt que vous avez définies, la façon dont il récupère d'une étape échouée. Cherchez un modèle plus grand seulement après que cette couche est vérifiée. La plupart du temps, ce ne sera pas nécessaire.
