En bref
Un LLM seul répond à une requête : il génère du texte à partir d’un contexte. Un harness est la couche de contrôle qui l’entoure pour en faire un agent capable d’exécuter des tâches longues, multi-étapes, avec des outils et une mémoire persistante. Sans harness, le modèle n’a pas de boucle, pas d’état durable, pas de mécanisme de vérification, et aucune façon de déléguer du travail. La performance d’un agent dépend autant du harness que du modèle lui-même — c’est ce que montre la recherche récente sur ce sujet (Pan et al., 2026 ; Anthropic, 2025b).
En clair : un LLM, c’est un musicien virtuose. Un harness, c’est l’orchestre qui lui donne une partition, un chef, une scène, des éclairages, une régie son. Sans le harness, le virtuose joue magnifiquement… pour personne, sans suite, sans capacité à reprendre après un faux départ. La performance d’un concert dépend du musicien ET de la mise en scène. Pour un agent IA, c’est pareil : doubler la qualité du harness peut produire plus de gain que doubler la taille du modèle.
Pourquoi le LLM seul ne suffit pas
Un appel de modèle est une fonction sans mémoire : entrée → sortie. Cette propriété est bien adaptée aux tâches de traduction, résumé ou génération ponctuelle. Elle devient un obstacle dès que la tâche requiert plusieurs étapes, des outils externes, ou la coordination de plusieurs agents.
Trois problèmes apparaissent immédiatement :
L’état est éphémère. Les informations produites à l’étape 3 ne sont disponibles à l’étape 7 que si elles ont été explicitement transmises dans le contexte. À mesure que la tâche s’étend, le contexte se remplit, des informations tombent hors de la fenêtre (phénomène dit de context rot), et l’agent perd le fil de son propre travail (Liu et al., 2024 ; Chroma Research, 2025).
La progression n’est pas garantie. Le modèle ne sait pas quand arrêter, quand recommencer, ni comment récupérer d’un outil qui échoue. Il n’y a pas de gate de validation, pas de taxonomie d’erreurs, pas de logique de retry.
La décomposition est implicite. Le modèle peut produire un plan en texte, mais rien ne le contraint à l’exécuter étape par étape ni à déléguer des sous-tâches à des agents spécialisés.
Le harness résout ces trois problèmes en externalisant la logique de contrôle.
Ce qu’un harness spécifie
Pan et al. (2026) formalisent un harness comme une couche qui gouverne trois dimensions pour une famille de tâches :
Contrôle — comment le travail est décomposé et ordonnancé. Exemples classiques : la boucle reason–act (ReAct, Yao et al., 2023), un pipeline plan → execute → verify → repair, ou une topologie multi-agents en parallèle.
Contrats — quels artefacts doivent être produits, quelles conditions doivent être satisfaites avant de passer à l’étape suivante, et quand le run doit s’arrêter. Un contrat définit des entrées et sorties requises, des contraintes de format, des règles de retry, et des périmètres de permission.
État — ce qui doit persister entre les étapes, les branches et les agents délégués. Sans état durable, chaque étape repart de zéro.
Les composants d’un harness exécutable
Un harness complet expose au minimum six composants (Pan et al., 2026) :
- Rôles : solver, verifier, researcher, orchestrator — avec des responsabilités non chevauchantes.
- Structure de stages : la topologie de travail explicite (plan → execute → verify → repair).
- Adaptateurs et scripts : les hooks déterministes — tests, linters, parsers, vérificateurs — qui ne sont pas délégués au LLM.
- Sémantique d’état : ce qui persiste (artefacts, ledgers, workspaces d’agents enfants) et comment le retrouver (chemins, manifestes).
- Taxonomie des échecs : les modes d’erreur nommés qui déclenchent une récupération (artefact manquant, erreur outil, timeout, verifier failure).
- Contrats d’exécution : les gates qui valident les sorties avant de passer à l’étape suivante.
En clair : ces six composants sont les rôles d’une équipe de tournage. Les rôles, ce sont le scénariste, le réalisateur, le chef opérateur — chacun spécialisé. La structure de stages, c’est le découpage en jours de tournage. Les adaptateurs, ce sont les techniciens (régleurs son, monteurs) qui ne sont pas des artistes. La sémantique d’état, c’est le dossier production qu’on consulte chaque matin. La taxonomie des échecs, ce sont les protocoles “que faire si la météo tourne”. Les contrats d’exécution, ce sont les rushes qu’on valide avant de démonter le décor.
Patterns architecturaux courants
La recherche a convergé vers un ensemble de patterns bien documentés :
Reason–Act (ReAct)
Le modèle alterne raisonnement et action : il produit une pensée, appelle un outil, observe le résultat, produit une nouvelle pensée. C’est le pattern fondateur de la plupart des agents actuels (Yao et al., 2023).
Retrieval-augmented generation (RAG)
Un module de récupération injecte des documents pertinents dans le contexte avant chaque génération. Le harness gère la sélection des sources, le formatage et la cohérence entre ce qui est récupéré et ce qui est attendu (Lewis et al., 2021).
Reflexion / auto-critique
Après une tentative, un agent verifier inspecte le résultat et génère un feedback textuel. L’agent solver utilise ce feedback pour corriger sa sortie sans modifier les poids du modèle (Shinn et al., 2023).
État persistant par fichiers
Pour les tâches longues, l’état est écrit dans des artefacts path-addressables plutôt que maintenu uniquement en contexte. Trois propriétés sont requises : externalisé (écrit sur disque), adressable par chemin (réouverture exacte), et stable à la compaction (survit aux truncations de contexte) (Pan et al., 2026 ; Anthropic, 2025b).
Orchestration multi-agents
Le harness peut déléguer des sous-tâches à des agents enfants (spawn_agent, wait_agent). Le parent gère les contrats de handoff et l’intégration des artefacts retournés. Sur des benchmarks de code, environ 90 % des tokens et appels d’outils se déroulent dans les agents enfants, non dans l’orchestrateur parent (Pan et al., 2026).
Matrice de décision : quel pattern de harness choisir
| Contexte | Recommandation | Pourquoi |
|---|---|---|
| Tâche moyenne (≤ 10 étapes), itérations rapides | ReAct seul | Pattern fondateur, traçable, faible overhead. |
| Génération de code ou de texte critique avec critique possible | ReAct + Reflexion | Auto-critique +5 à +20 pts sur benchmarks, sans ré-entraînement. |
| Pipeline long (≥ 30 étapes) ou contexte qui sature | État persistant par fichiers | Survit aux compactions, lecture/écriture path-addressables. |
| Tâche composite avec expertises hétérogènes | Orchestration multi-agents | Spécialisation par rôle, ~90 % du compute dans les enfants. |
| Harness à porter / auditer / comparer | NLAH (langage naturel structuré) | Lisible, modifiable, mais perd la précision du code pour les hooks. |
| Question fermée ou retrieval-bound | RAG comme socle | Documents injectés en amont, gain factualité immédiat. |
Harness en code vs harness en langage naturel
Historiquement, le harness est du code Python ou TypeScript : des fonctions, des boucles while, des appels conditionnels. C’est puissant mais opaque — la logique de contrôle est dispersée entre le code du contrôleur, les conventions du framework et les scripts de vérification. Comparer deux harnesses ou en extraire un composant est difficile.
Une approche alternative émerge : exprimer la logique de contrôle en langage naturel structuré (Natural-Language Agent Harnesses, NLAHs). Le harness devient un artefact lisible, portable et modifiable. Un runtime interprète ce texte à chaque étape (Pan et al., 2026).
Avantages : portabilité entre runtimes, auditabilité, comparaison modulaire, migration facilitée.
Limites : le langage naturel est moins précis que le code. Certains mécanismes ne peuvent pas être reproduits fidèlement depuis du texte, en particulier ceux qui dépendent d’un état côté service caché ou de comportements induits par le training. Le risque de contamination par le runtime existe : un charter partagé fort peut absorber une partie du comportement qu’on attriburait au harness [NON VÉRIFIÉ pour la proportion exacte de cet effet].
Ce que l’architecture ne garantit pas
Ajouter des composants n’améliore pas mécaniquement les résultats. Les expériences sur SWE-bench Verified et OSWorld montrent :
- Plus de structure peut créer de la friction sur des tâches qui bénéficiaient du chemin le plus court.
- Un verifier local peut diverger de la gate finale du benchmark : une run rapporte “solved”, le benchmark rejette quand même.
- La recherche multi-candidats est coûteuse en tokens sans gain proportionnel sur les métriques agrégées.
- L’évolution automatique (self-evolution) est le module le plus efficace — non parce qu’il génère plus de tentatives, mais parce qu’il discipline la boucle d’acceptation autour d’un critère clair (Pan et al., 2026).
L’interprétation correcte : les modules aident quand ils resserrent le chemin entre le comportement intermédiaire et la condition d’acceptation finale. Ils nuisent quand ils ajoutent des couches de validation dont la notion de succès est faiblement alignée avec l’évaluateur.
En clair : la complexité d’un harness ne se monte pas par défaut. Chaque module qu’on ajoute (verifier local, recherche multi-candidats, validation intermédiaire) doit prouver qu’il rapproche du succès final tel que mesuré. Sur SWE-bench, des verifiers locaux disent “résolu” quand le benchmark dit “non résolu” — pire qu’inutile, c’est trompeur. La règle empirique de Pan et al. : ajouter un module si et seulement si la cible d’acceptation intermédiaire est exactement alignée avec celle du livrable final.
Ce qu’il faut retenir
- Un harness est la couche de contrôle entre le LLM et la tâche : boucle, état, outils, rôles, contrats, gestion d’erreurs.
- Sans harness, le LLM n’a pas de mémoire persistante, pas de gate de validation, et aucun mécanisme de récupération sur des tâches longues.
- Les composants fondamentaux sont : rôles distincts, structure de stages, adaptateurs déterministes, état externalisé, taxonomie d’échecs.
- Plus de structure n’est pas toujours mieux — l’alignement entre les portes de contrôle intermédiaires et la condition finale de succès détermine la valeur réelle d’un module.
- La tendance émergente est d’exprimer la logique de harness en langage naturel pour la rendre portable et auditable, tout en conservant du code pour les opérations déterministes.