Le Harness est le produit : un guide pratique sur les harnesss en intelligence artificielle agente.
Découvrez ce qu’est un agent harness et ses sept composants, allant des outils et du contexte aux garde-fous et aux évaluations, ainsi que des sous-agents, des modes de défaillance et des cadres à connaître.
Sources: The Harness Is the Product: An End-to-End Guide to Harnessing in Agentic AI
Imaginez donner le même modèle de langage à deux équipes différentes. L’équipe A crée un agent qui corrige les erreurs dans un vaste répertoire, exécute le jeu de tests et soumet une demande de fusion bien organisée. L’équipe B développe un assistant de chat qui perd le fil de la conversation après quelques messages et invente joyeusement des politiques internes. Les poids sont identiques, pourtant les résultats sont complètement opposés.
Le « harness » est l’ensemble des éléments qui entourent le modèle : il comprend le mécanisme qui permet au modèle d’agir, les outils qu’il peut utiliser, la manière dont sa fenêtre de contexte est gérée, les contrôles qui l’empêchent de faire des erreurs, ainsi que les retours d’information indiquant s’il réussit ou non. Ce qui suit part de zéro, explique ce qu’est un agent, puis aborde les composants du « harness », les modèles de production tels que les sous-agents et la compression, quelques systèmes bien connus ainsi que les frameworks disponibles aujourd’hui. Aucune expérience préalable avec les agents n’est requise.
Les bases
Que signifie l’IA agente
En dehors du bruit médiatique, un agent est simple :
Un agent est un modèle de langage qui fonctionne en boucle, en utilisant des outils, jusqu’à ce qu’un objectif soit atteint.
Cela nécessite trois éléments : un modèle capable de raisonner et de choisir la prochaine étape, des outils que le modèle peut activer, tels que des recherches sur le Web, l’accès à des fichiers, l’exécution de code, des recherches dans une base de données ou l’envoi d’e-mails, ainsi qu’une boucle qui renvoie le résultat de chaque outil afin que le modèle puisse décider de ce à faire ensuite.
Un chatbot répond une fois et s’arrête. Un agent, lui, continue : il entreprend une action, examine le résultat, puis en entreprend une autre. C’est ce cycle qui permet à un prédicteur de texte d’accomplir réellement des tâches, et le reste de ce texte développe ce concept.
Qu’est-ce qu’un harness ?
Pensez au harness comme au moteur de exécution de cette boucle. Le modèle choisit ce qui doit se passer ensuite, tandis que le harness met cela en œuvre et assure que tout le processus reste sûr, abordable, visible et contrôlable. Ce nom fait écho à un test harness dans le logiciel, ou aux éperons d’un cheval : une puissance brute a besoin d’une structure pour être orientée vers des tâches utiles.
En termes concrets, le framework exécute les appels de fonction demandés par le modèle, contrôle ce que le modèle voit à chaque étape, applique les permissions, gère les pannes, les tentatives répétées et les boucles infinies, suit les progrès et sait quand le travail est terminé ou quand il faut s’arrêter et demander de l’aide à un humain.
Une façon utile de l’imaginer : le modèle n’a pas de mémoire entre les différentes interactions. Chaque fois qu’il est sollicité, il commence à zéro, lit le texte qui lui est donné et produit un seul résultat. Tout le reste – le script, les éléments d’accompagnement, la « scène » et le filet de sécurité – fait partie du framework. En modifiant ces éléments, le même « acteur » se comporte complètement différemment.
Pourquoi le framework est important
Trois raisons pratiques se détachent.
Les améliorations du modèle convergent, tandis que celles du cadre d’accompagnement ne le font pas. Les modèles de pointe se rapprochent de plus en plus en termes de capacités brutes. Sur les benchmarks d’agents qui évaluent la résolution de problèmes logiciels réels, le même modèle peut obtenir des résultats nettement différents en fonction uniquement du cadre qui l’entoure, grâce à de meilleurs outils, des prompts et des boucles de feedback. À un certain stade, c’est le cadre d’accompagnement qui devient le facteur déterminant.
Les tâches longues amplifient les petites erreurs. Si un modèle est fiable à 99 % à chaque étape, une tâche de 50 étapes aboutit avec succès seulement dans environ 60 % des cas, car 0,99 élevé à la puissance 50 est d’environ 0,605. La vérification, les tentatives répétées, les points de contrôle et la correction de trajectoire constituent les mécanismes du cadre d’accompagnement qui luttent contre cet effet cumulatif. Ce sont eux qui distinguent une démonstration d’un produit réel.
La liberté a besoin de limites. Tout agent capable d’exécuter des commandes shell, de transférer de l’argent ou d’écrire aux clients doit disposer de limites de permission, de sandbox et de journaux d’audit. Ceux-ci font partie intégrante du framework, et le modèle ne contribue en rien à leur mise en place.
Anatomie d’un framework
Les agents de codage, les agents de recherche et les agents de support partagent généralement sept composants. Voici ceux-ci, un par un.
1. L’instruction système, les directives générales
C’est ici que l’agent est informé de son rôle, de ses limites, de ses règles de conduite ainsi que de la fonction de chaque outil. Dans les produits matures, ce texte compte des milliers de mots et est entretenu avec le même soin que le code source, en veillant au ton, à la sécurité, au moment opportun pour poser des questions et à la manière de gérer les instructions peu claires.
Un débutant pourrait écrire une seule ligne indiquant que l’agent est un assistant de codage utile. En revanche, une instruction de production précise les procédures : ouvrir un fichier avant de le modifier, privilégier de petites modifications, exécuter des tests après chaque modification, s’arrêter et faire un rapport après deux échecs de test, et ne jamais envoyer directement les modifications sur la branche principale, puis elle continue avec de nombreuses autres règles similaires.
2. La couche des outils, les mains
Un outil est une fonction que le modèle peut appeler, définie par un nom, une description et un schéma de types pour ses arguments. Le modèle demande une exécution sous forme de sortie structurée, puis le système d’orchestration l’exécute et renvoie le résultat.
La conception des outils est un métier sous-estimé. Il s’agit en fait de la conception d’une API destinée à un utilisateur très littéral :
- Les descriptions servent de prompts. Le modèle choisit les outils en se basant sur leurs descriptions, donc une description vague mène au mauvais outil.
- Quelques outils bien conçus valent mieux que de nombreux outils superposés. Une multitude d’outils embrouille les modèles, tout comme un menu de quarante plats embrouille les clients.
- Renvoyez des erreurs sur lesquelles le modèle peut agir. Un message indiquant que le fichier est en lecture seule et qu’un accès doit d’abord être demandé vaut mieux qu’une trace d’erreur brute.
- Réduisez la portée des outils dangereux. Un outil qui n’envoie que des drafts préapprouvés est bien plus sûr qu’un outil qui exécute du code arbitraire.
Un développement majeur dans ce domaine est le Model Context Protocol, que Anthropic a rendu open source à la fin de 2024 et que de nombreux acteurs du secteur ont adopté. Il standardise la manière dont un fournisseur d’outils expose ses outils à n’importe quel agent, agissant comme un connecteur universel : il suffit d’écrire l’intégration une seule fois pour l’utiliser avec n’importe quel système.
3. Gestion du contexte, la mémoire de travail
La fenêtre de contexte représente l’ensemble du monde perceptif du modèle. Ces fenêtres comprennent généralement de centaines de milliers à un million de tokens, ce qui semble énorme jusqu’à ce qu’un agent ait lu quarante fichiers et exécuté soixante commandes.
Choisir ce que le modèle peut voir à chaque étape est probablement le levier le plus important du système ; les professionnels appellent cela aujourd’hui l’ingénierie de contexte, qui a en grande partie remplacé l’ingénierie de prompts en tant que compétence centrale. Les techniques vont de simples à sophistiquées : la troncation (ne conserver que les messages récents ou une partie d’un fichier), la récupération (indexer la base de connaissances et ne sélectionner que ce qui est nécessaire au moment présent) et la compression. Avec la compression, lorsque la fenêtre est presque pleine, le modèle rédige un résumé de la session, ce résumé remplace le texte brut, et le travail peut se poursuivre. C’est ainsi que les agents parviennent à rester concentrés sur leur tâche pendant des heures.
4. La mémoire, le stockage à long terme
Le contexte dure une seule session, tandis que la mémoire persiste. Les systèmes l’organisent généralement en plusieurs niveaux :
- la mémoire de projet, comme les fichiers d’instructions dans un répertoire qui enseignent à un agent de codage vos conventions et commandes de construction, et qui sont lus au début de la session,
- la mémoire de l’utilisateur, c’est-à-dire les préférences acquises au fil des conversations,
- la mémoire épisodique, qui conserve des enregistrements des exécutions précédentes, souvent dans un stockage vectoriel, afin de pouvoir les récupérer lorsque des situations similaires se reproduisent.
5. Garde-fous, permissions et sandboxing, les freins
La couche de sécurité vérifie constamment si une action doit réellement être exécutée. En pratique, cela signifie :
- Niveaux de permissions. Les lectures s’effectuent librement, les écritures passent par des contrôles de politique, et les actions irréversibles telles que le déploiement, l’envoi, la suppression ou le paiement nécessitent une approbation explicite humaine.
6. Vérification et retour d’information, les yeux
Rien ne permet d’améliorer un agent de manière plus fiable qu’un moyen de tester ses propres résultats. Les agents de codage compilent, vérifient la syntaxe et exécutent des tests après chaque modification. Les agents de recherche comparent les affirmations provenant de plusieurs sources. Les agents navigateur capturent l’écran pour voir ce qui a réellement été chargé. Certains systèmes ajoutent un examinateur, un deuxième modèle qui évalue la réponse du premier modèle selon des critères définis avant qu’elle ne soit acceptée.
Cela attaque directement le problème des erreurs cumulatives. Un agent qui peut constater qu’il a échoué peut réessayer, tandis qu’un agent qui ne le peut pas livrera sans hésiter des résultats inutilisables.
7. L’observabilité, le journal de vol
Dans un environnement de production, chaque demande de modèle, chaque appel d’outil et chaque token utilisé est enregistré. Grâce à ces traces, il est possible de rejouer une exécution échouée, d’identifier l’étape qui a posé problème et de corriger le prompt, l’outil ou la politique en cause. Une toute nouvelle catégorie de produits a vu le jour autour de ce principe, notamment LangSmith, Langfuse, Braintrust ainsi que les conventions OpenTelemetry pour l’IA générative, car déboguer un agent sans informations est tout aussi difficile que déboguer des services distribués sans journaux d’activité.
Gérer correctement le cycle
Donner un nom aux différentes composantes est la partie la plus simple. La différence entre un système qui fonctionne lors d’une démonstration et un système qui fonctionne correctement au quotidien provient des pratiques décrites ci-dessous.
Planifier, agir, vérifier
Les agents simples s’y mettent immédiatement. Les systèmes plus avancés imposent un rythme : élaborer un plan en décomposant l’objectif en une liste de tâches, effectuer de petits pas, vérifier chaque résultat avant de continuer, puis réviser le plan et recommencer. Le plan écrit remplit deux fonctions : il maintient le modèle concentré sur des tâches longues car il est relu à chaque étape, et il permet à une personne qui observe de voir les progrès en temps réel, ce qui s’avère plus précieux que prévu.
Sorties structurées
Chaque fois qu’un programme va utiliser la sortie du modèle, il convient de la restreindre grâce à un schéma. Les API actuelles prennent en charge des appels d’outils forcés ainsi qu’une génération validée par schéma. La prose est destinée aux humains ; le code, quant à lui, doit avoir une structure.
Coût et latence
Les agents consomment rapidement leurs tokens, ce qui rend l’aspect économique un sujet préoccupant. Stocker en mémoire le grand préfixe statique (l’invite système ainsi que les définitions des outils) entre les tours coûte bien moins cher que de le renvoyer, ce qui représente un avantage majeur pour les sessions longues. Le routage envoie les étapes courantes à un modèle petit et rapide, réservant un modèle avancé pour les étapes nécessitant une réflexion. Les sous-tâches indépendantes, telles que la lecture de dix fichiers ou la vérification de cinq sources, peuvent être exécutées en parallèle.
Systèmes multi-agents et au-delà
Sous-agents et orchestration
Lorsque les tâches dépassent la capacité d’une fenêtre de contexte, les systèmes passent au mode multi-agents. Un orchestrateur divise l’objectif et crée des sous-agents, chacun disposant d’un contexte propre, souvent d’un ensemble d’outils plus restreint et d’une mission bien définie. Chaque sous-agent effectue son travail et ne renvoie que sa conclusion, et non l’ensemble de son historique de travail.
Le véritable avantage est moins évident que la vitesse : chaque sous-agent travaille dans son propre contexte isolé, et non simplement en parallèle. Dix sous-agents peuvent chacun remplir une fenêtre entière avec un sous-système, tandis que l’orchestrateur ne conserve que dix résumés succincts.
Les topologies courantes incluent l’orchestrateur et les travailleurs (de loin la plus courante), des pipelines tels que « brouillon », « critique » et « révision », ainsi que des panels de débat dans lesquels plusieurs agents abordent un problème de manière indépendante et un juge synthétise les réponses. Le débat est coûteux mais convient aux questions à haut enjeu.
Les équipes ayant réalisé ce rapport ont tiré de précieuses leçons :
- Précisez le niveau d’effort attendu pour chaque tâche, sinon même une question anodine peut déclencher des dizaines de recherches.
- Rédigez des documents détaillés et autonomes, car un sous-agent ne peut pas voir le contexte de son agent parent.
Points de contrôle et durabilité
Les agents qui fonctionnent sur de longues périodes échouent en cours de route en raison de pannes, de limites de fréquence et de redémarrages. Les systèmes de production utilisent des points de contrôle pour conserver l’état de la conversation, la liste des tâches et les résultats des outils, permettant ainsi de reprendre l’exécution à partir de l’étape 37 sans tout recommencer. C’est le domaine des moteurs de flux de travail durables, et plusieurs frameworks d’agents sont construits directement sur cette base.
Evals, le jeu de tests du système
Le comportement des agents est probabiliste, de sorte qu’une instruction qui fonctionne un lundi peut échouer un mardi. Les équipes solides disposent d’un ensemble d’évaluation comprenant des dizaines à des milliers de tâches réalistes dont les résultats peuvent être vérifiés automatiquement. Les tests ont-ils réussi ? La bonne réponse a-t-elle été trouvée ? Les coûts sont-ils restés dans les limites du budget ? Toute modification des instructions, tout nouvel outil et tout changement de modèle sont soumis à cet ensemble avant leur mise en production. Il remplit la même fonction que les systèmes CI/CD ailleurs, et l’en omettre signifie travailler sans outils de contrôle.
L’utilisation des ordinateurs, l’examen final
En première ligne, les agents disposent d’un écran, d’un clavier et d’une souris et peuvent exécuter n’importe quelle application, qu’elle dispose ou non d’une API. Cela augmente la difficulté de tous les problèmes précédents : les captures d’écran consomment un nombre énorme de tokens, il faut donc un contrôle strict du contexte ; un clic erroné peut causer de réels dommages, d’où des permissions plus strictes ; et la vérification signifie devoir visualiser réellement l’écran après chaque étape.
Comment les systèmes connus appliquent ces idées
Claude Code, un outil de programmation. C’est une leçon concise de conception. L’ensemble des outils est restreint mais efficace, offrant la lecture, l’écriture et l’édition de fichiers, des commandes de shell et une recherche de code, sans centaines d’outils microscopiques. La vérification est au cœur du système : il exécute des compilateurs, des analyseurs de code et des tests, et itère en cas d’échec. Un fichier d’instructions de projet agit comme mémoire. Rien de tout cela n’est une capacité propre au modèle, et c’est pourquoi le même modèle se comporte différemment à l’intérieur de cet outil.
Produits de recherche approfondie, un harnais de recherche. Les outils de recherche des grands laboratoires transforment une requête en une investigation autonome d’une durée de plusieurs minutes, qui se termine par un rapport cité. Leur particularité réside dans un plan de recherche élaboré à l’avance, parfois présenté pour approbation, ce qui implique l’intervention humaine au stade le moins coûteux avant le travail onéreux. Les boucles de recherche lisent, détectent les lacunes et recherchent à nouveau, et les métadonnées de citation accompagnent les faits tout au long du processus.
Manus et l’école de l’ingénierie de contexte. L’équipe de Manus a publié des notes exceptionnellement franches sur les mécanismes internes de Harness autour de son lancement en 2025, et plusieurs de ces points se sont largement répandus. Considérez la mémoire cache KV comme une contrainte de conception : maintenez la partie initiale du prompt stable (pas d’heure de création en haut du prompt système), car le nombre de tokens d’entrée peut être bien supérieur à celui des tokens de sortie. Évitez d’ajouter ou de supprimer des outils au cours d’une session, car cela rend la mémoire cache invalide et déroute le modèle lorsque des appels précédents mentionnent des outils disparus ; gardez la liste fixe et masquez ce qui peut être sélectionné pour le moment.
Le curseur et l’interface de l’IDE. L’éditeur conçu pour l’IA adopte une philosophie différente en matière d’intégration profonde de l’environnement. Il utilise l’index sémantique de la base de code pour des recherches rapides, affiche les modifications sous forme de différences révisables afin que la personne chargée d’approuver la fusion soit le mécanisme de contrôle d’accès déguisé en interface, exécute des agents en arrière-plan sur des branches distinctes et renvoie les résultats des outils de vérification syntaxique et de type dans le cycle de travail. Ces mêmes sept composants apparaissent sous des formes différentes.
Les agents d’assistance dans les entreprises, où l’objectif principal est le respect des réglementations. Les agents en contact direct avec les clients inversent les priorités : éviter une action erronée est plus important que les capacités techniques brutes. Ils partent donc de règles strictes : champ d’action limité aux connaissances approuvées, actions vérifiées selon les schémas des systèmes métier (remboursements plafonnés, identification confirmée en premier), transmission obligatoire à d’autres personnes lorsque la confiance est faible, ainsi que des journaux d’audit complets. Dans les secteurs réglementés, ce cadre de contrôle constitue en fait le produit lui-même.
Frameworks et outils disponibles actuellement
On construit de moins en moins de tels cadres à partir de simples appels API. Voici les options courantes, regroupées de manière approximative selon leur philosophie :
- Claude Agent SDK. Le cadre sous-jacent à Claude Code, présenté sous forme de bibliothèque incluant des boucles, des outils, des sous-agents, des permissions et des fonctionnalités de compression. Idéal pour créer rapidement des agents performants sur Claude.
- OpenAI Agents SDK. Primitifs légers pour les agents, les transferts de tâches, les contraintes, les sessions et le suivi. Idéal pour les applications multi-agents dans l’écosystème OpenAI.
- LangGraph. Agents en tant que machines à états explicites, avec sauvegardes de points clés, interruptions par un intervenant humain et exécution fiable. Parfait pour des workflows complexes, contrôlables et de longue durée.
- CrewAI. Équipes basées sur des rôles tels que chercheur et rédacteur. Idéal pour des prototypes multi-agents rapides et des pipelines de contenu.
- AutoGen, AG2 et Semantic Kernel. Outils multi-agents axés sur les conversations, convergeant vers des solutions professionnelles. Adapté aux environnements .NET et Azure ainsi qu’aux expériences de recherche.
- smolagents. Une bibliothèque minimaliste où les agents écrivent du code en tant qu’actions. Idéal pour des développements modifiables utilisant des modèles ouverts.
- Pydantic AI. Agents sécurisés par typage, basés sur des schémas, avec des sorties validées. Idéal pour les équipes Python souhaitant un typage strict.
- Vercel AI SDK. Primitifs basés sur TypeScript, avec contrôle du cycle des agents. Parfait pour les ingénieurs web et de produits dans l’écosystème JavaScript.
Autour de ces éléments se trouve le tissu conjonctif : MCP pour les outils standards, des plateformes de suivi et d’évaluation, des moteurs d’exécution durables ainsi que des fournisseurs de sandbox pour une exécution de code sécurisée.
Conseil pour le choix : lors de l’apprentissage, écrivez vous-même le cycle brut une fois, en utilisant une API de modèle, un boucle while et deux outils, sur environ cent lignes. Après cela, aucun framework ne paraîtra magique, ce qui est justement l’objectif. Lors du déploiement, choisissez le framework le plus proche de votre fournisseur de modèles et de votre langage, et consacrez le temps économisé à ce que aucun framework ne peut vous offrir, à savoir vos outils, vos évaluations et vos règles de sécurité.
# The whole idea, in miniature
while not done:
response = model.generate(context, tools) # model decides
if response.tool_calls:
results = execute(response.tool_calls) # harness acts (safely!)
context = manage(context + results) # harness curates memory
else:
done = verify(response) # harness checks the work
Modes de défaillance
Voici les manières typiques dont les agents échouent, chacune accompagnée d’une solution correspondante :
- Dégradation du contexte. La fenêtre se remplit progressivement de résultats obsolètes générés par les outils, ce qui entraîne une baisse de qualité jusqu’à ce que l’objectif soit oublié après quelques heures. Solution : compaction des informations, tenue de notes et reformulation périodique de l’objectif.
- Boucles sans issue. La même commande défaillante est répétée indéfiniment, au prix de quelques centimes à chaque tentative. Remède : détection des boucles, limitation du nombre d’itérations et changement forcé de stratégie.
- Déploiement excessif d’outils. Avec quarante outils similaires, le modèle choisit le mauvais au pire moment. Solution : un ensemble plus restreint d’outils plus efficaces, accompagnés de descriptions claires.
À retenir
Le modèle fournit l’intelligence, tandis que le système de gestion la transforme en actions concrètes. Ce système se compose d’un mécanisme principal et de sept composants : instructions préétablies, outils, gestion du contexte, mémoire, contraintes, vérification et observabilité. Autour de ceux-ci se trouvent des schémas pour exécuter des tâches longues, tels que planifier, agir et vérifier, la compression des données, les points de contrôle, les sous-agents et les évaluations. La plupart des échecs des agents sont dus à des problèmes de leur système de gestion, et la plupart des améliorations viennent également de ce système. Ainsi, lorsque un agent ne performe pas correctement, examinez d’abord son système de gestion avant de changer le modèle.
Lectures complémentaires
- Les subagents en pratique : rôles, budgets, interdictions et échecs silencieux — Comment créer des subagents Claude Code durables : rôles, fichiers de transfert, état d’exécution, budgets, interdictions, vérifications d’échecs silencieux, ainsi qu’un complément Copilot, à partir d’agents utilisés dans une douzaine de dépôts.
- L’analytique agentique, c’est plus que du texte vers SQL : des leçons d’Anthropic — Ce que l’article d’Anthropic sur l’analytique en auto-service révèle sur les couches sémantiques, les compétences, les évaluations et les fondements des données, et pourquoi le texte vers SQL seul donne une fausse impression de précision.