Harness² : Google Research laisse les agents réécrire le système qui les entoure

Harness² : Google Research laisse les agents réécrire le système qui les entoure

🔎 Un framework qui ne touche jamais au modèle — et pourtant ça marche

La course aux agents IA s'est longtemps résumée à une seule question : quel modèle mettre sous le capot ? Google Cloud AI Research vient de proposer une autre réponse, plus dérangeante. Et si le vrai levier de performance n'était pas le modèle, mais tout ce qui l'entoure — les prompts, les outils, la mémoire, les scripts ?

C'est la thèse de Harness², un framework open-source publié début octobre 2026 sous licence Apache 2.0, accompagné d'un paper sur arXiv (2610.14224). Le principe tient en une phrase : au lieu d'améliorer les poids du modèle, on laisse l'agent réécrire son propre harness — la couche logicielle qui le fait fonctionner. Le repo google-research/harness2 affiche déjà 16 700 étoiles et s'est hissé dans le trending GitHub dès sa publication.

Les chiffres annoncés méritent qu'on s'y attarde : jusqu'à +11,5 points sur WorkBuddy-Bench, +4,5 sur JobBench et +11,8 points sur LAB, avec des modèles aussi différents que GLM-5 et Gemini 3.5 Flash. Sans fine-tuning. Sans réentraînement. À poids figés.

L'essentiel

• Harness² est un framework de "recursive agent harnessing" : l'agent optimise itérativement les huit composants qui l'entourent (system prompt, guardrails, mémoire, tool guidance, subagents, skills, scripts, plugins) plutôt que ses propres poids.
• Deux mécanismes de récursion : une boucle Propose-Probe-Compose qui fonctionne sans aucune vérité terrain, puis une boucle d'expérience persistante qui conserve les leçons de chaque tâche exécutée.
• Gains mesurés : +11,5 points sur WorkBuddy-Bench, +4,5 sur JobBench, +11,8 points sur LAB avec GLM-5 et Gemini 3.5 Flash ; la récursion parallèle à k=5 apporte +3,9 points sur WorkBuddy-Bench et +6,7 sur LAB Partial.
• Ouvert et pragmatique : Apache 2.0, exécuteurs OpenCode et Codex, harness par défaut édité par Claude Opus 4.8.
• Signal de marché : la couche harness devient une infrastructure à part entière — comme l'analyse la couche harness devient une infrastructure : deux des trois repos trending GitHub.

Outils recommandés

Le harness, cette couche invisible que tout le monde sous-estime

Réponse directe : le harness est l'ensemble des composants logiciels qui transforment un LLM brut en agent fonctionnel — et Harness² démontre qu'optimiser cette couche rapporte autant que changer de modèle.

Concrètement, un agent n'est jamais "juste un modèle". Entre le LLM et le monde extérieur, il y a un system prompt, des guardrails de sécurité, une gestion de mémoire, des instructions d'usage des outils, des subagents délégués, des skills réutilisables, des scripts et des plugins. Harness² structure ces éléments en huit composants éditables, tous modifiables par l'agent lui-même.

L'idée n'est pas totalement neuve — le prompt engineering et les méta-prompts existent depuis des années. Ce qui change, c'est la méthodologie de récursion. Comme le résume Marktechpost : au lieu d'améliorer les poids du modèle, l'agent réécrit son propre harness. C'est une inversion du paradigme dominant, où l'effort d'optimisation se concentre presque exclusivement sur l'entraînement.

Pour situer le contexte : cette publication s'inscrit dans une tendance plus large, où plusieurs repos dédiés à la couche harness ont percé simultanément sur GitHub, un phénomène que nous avons détaillé dans notre analyse sur le harness comme nouvelle infrastructure des agents IA.

Comment fonctionne la récursion Propose-Probe-Compose

Réponse directe : l'agent propose des modifications de son harness, les teste en conditions réelles, puis compose la meilleure configuration — sans jamais avoir accès à une vérité terrain.

Le paper décrit deux niveaux de récursion, tous deux à poids figés :

Niveau 1 : Propose-Probe-Compose

Le cycle se déroule en trois temps :

1. Propose : l'agent génère des variantes de son harness — un system prompt retravaillé, une nouvelle stratégie de mémoire, un tool guidance affiné.
2. Probe : chaque variante est exécutée sur des tâches réelles, et les résultats sont observés sans feedback de vérité terrain. C'est le point le plus intéressant : pas besoin de jeux de données annotés, ce qui rend la méthode applicable à des tâches ouvertes, là où personne n'a de "bonne réponse" pré-étiquetée.
3. Compose : l'agent assemble les composants qui ont le mieux performé en une configuration finale.

Le harness par défaut est lui-même édité par Claude Opus 4.8 sous OpenCode, ce qui dit beaucoup sur la maturité de l'approche : ce n'est pas un prototype de labo, c'est un pipeline qui tourne sur des exécuteurs de production.

Niveau 2 : la boucle d'expérience persistante

Le deuxième niveau va plus loin. Au lieu de repartir de zéro à chaque tâche, l'agent maintient une bibliothèque d'expériences : chaque tâche exécutée laisse une trace — ce qui a marché, ce qui a échoué, quelles variantes de harness ont produit quel résultat.

L'effet le plus spectaculaire documenté dans le paper : une bibliothèque transférée de JobBench améliore les résultats sur WorkBuddy sans aucun probing supplémentaire. Autrement dit, les leçons apprises sur un domaine se transfèrent vers un autre domaine. C'est exactement le genre de généralisation que l'on attendait du fine-tuning — obtenue ici avec un simple stockage persistant de leçons.

Les chiffres : ce que valent +11,5 points à poids figés

Réponse directe : les gains sont substantiels et mesurés sur trois benchmarks distincts, avec deux familles de modèles très différentes — ce qui suggère que la méthode n'est pas surajustée à un LLM particulier.

Trois observations s'imposent.

Première : les gains varient fortement selon le benchmark (+4,5 vs +11,5 sur WorkBuddy). Cela suggère que le harnessing profite davantage aux tâches où la structure du prompt et la gestion d'outils sont déterminantes — typiquement les workflows de type "buddy" de travail — qu'aux tâches où la capacité brute du modèle domine.

Deuxième : la récursion parallèle à k=5 (cinq variantes explorées simultanément) donne des gains plus modestes que la récursion complète. Le coût de calcul de la version complète est donc probablement significatif — un point que les équipes devront arbitrer.

Troisième : le fait que la méthode fonctionne à la fois sur GLM-5 (un modèle self-hostable, que nous classons à 82 sur notre indice agentic) et Gemini 3.5 Flash (un modèle propriétaire léger) est peut-être son argument le plus fort. Si vous hésitez sur le meilleur LLM pour vos agents IA, Harness² change la question : le modèle devient une variable parmi huit, pas LA variable.

Pourquoi c'est une bonne nouvelle pour les agents open source et locaux

Réponse directe : Harness² rend l'optimisation d'agents accessible sans GPU d'entraînement ni budget de fine-tuning — un levier démocratisant pour l'écosystème local.

Le fine-tuning reste réservé à ceux qui ont des clusters, des données et des équipes ML. Le recursive harnessing, lui, ne demande qu'un LLM — n'importe lequel — et un exécuteur. Pour les développeurs qui font tourner des agents en local avec Ollama, c'est une porte qui s'ouvre : la méthode est documentée pour fonctionner avec des modèles self-host comme GLM-5.

Cela s'articule naturellement avec les approches que nous couvrons sur les agents IA open source en local avec Ollama : Harness² apporte une méthodologie d'optimisation systématique là où la plupart des setups locaux reposent encore sur du prompt engineering artisanal, ajusté à la main, sans boucle de mesure.

Autre point d'architecture intéressant : Harness² s'appuie sur des exécuteurs (OpenCode, Codex) qui se connectent au modèle via des interfaces standardisées. Si vous voulez brancher le harness sur un modèle autre que ceux prévus par défaut, des passerelles comme Magpie, le gateway local qui connecte 60 coding agents à n'importe quel modèle permettent précisément ce découplage entre harness, exécuteur et LLM. C'est la même philosophie : chaque couche doit rester remplaçable.

Ce que ça ne résout pas : les limites du paper

Réponse directe : Harness² optimise la couche logicielle, pas les capacités cognitives du modèle — et les gains dépendent du benchmark choisi.

Soyons précis sur ce que ces chiffres ne disent pas.

Un gain de +11,5 points sur WorkBuddy-Bench n'est pas un gain de +11,5 points sur toutes les tâches. Les benchmarks cités (WorkBuddy, JobBench, LAB) sont des environnements de travail agentique structurés. Sur des tâches de raisonnement pur, où le modèle est déjà le facteur limitant, réécrire le system prompt ne fera pas de miracles. Un modèle à 82 ne deviendra pas un modèle à 95 par magie de harnessing.

La récursion coûte du calcul. Proposer, tester et composer des variantes signifie exécuter l'agent plusieurs fois par cycle d'optimisation. À k=5, vous multipliez vos appels API ou votre charge d'inférence locale par cinq — avant même d'avoir produit la configuration finale. Pour un usage personnel, c'est gérable. Pour une flotte d'agents en production, il faut budgétiser.

La boucle d'expérience persistante pose des questions de gouvernance. Un agent qui accumule des leçons sur ses propres exécutions, et qui les réinjecte dans son comportement futur, est un agent dont le comportement dérive dans le temps. C'est exactement le genre de problème que soulève le chantier d'encadrement des agents en entreprise porté par Google et SAP sur l'agentic AI governance : un harness auto-modifié doit être auditable, versionné, et réversible. Harness² publie son code sous Apache 2.0, ce qui aide — mais l'auditabilité n'est pas automatique, elle se construit.

OpenCode, Codex et l'écosystème d'exécuteurs

Réponse directe : Harness² ne réinvente pas l'exécution agentique, il s'branche sur deux exécuteurs existants — OpenCode et Codex — ce qui accélère l'adoption.

Le choix de ces deux exécuteurs est stratégique :

• OpenCode est l'exécuteur de référence de la scène open source, avec un support multi-modèles natif. C'est lui qui héberge le harness par défaut édité par Claude Opus 4.8 dans les expériences du paper.
• Codex (OpenAI) couvre l'écosystème propriétaire, et permet de tester la méthode sur les modèles GPT-5.x — dont le GPT-5.5, actuellement en tête de notre classement des LLM agentic.

Cette architecture modulaire — harness d'un côté, exécuteur de l'autre, modèle en dessous — est le vrai apport architectural du projet. Elle permet de répondre à une question que peu de frameworks se posent honnêtement : quelle part de la performance vient du modèle, et quelle part vient du reste ? Les résultats de Harness² suggèrent que "le reste" pèse lourd.

Pour les développeurs qui veulent expérimenter sans engager de budget API, les API IA gratuites de Groq, Google et OpenRouter offrent un point d'entrée à coût nul pour faire tourner des cycles de probing sur des modèles légers — l'idéal pour valider la méthode avant de la pousser en production.

❌ Erreurs courantes

Erreur 1 : confondre harnessing et fine-tuning

Le recursive harnessing ne modifie aucun poids. Si votre tâche exige des capacités que le modèle n'a pas (raisonnement mathématique avancé, multilinguisme de niche), réécrire le harness ne les créera pas. La solution : choisir d'abord un modèle adapté à la tâche, puis optimiser le harness. Pas l'inverse.

Erreur 2 : ignorer le coût de la récursion

Les gains de +11,5 points sont obtenus avec une récursion complète — donc coûteuse. Beaucoup d'équipes copient les chiffres du paper sans anticiper que chaque cycle de Propose-Probe-Compose multiplie les exécutions. La solution : commencer par la récursion parallèle à k=5 (+3,9 à +6,7 points selon le benchmark), mesurer le rapport gain/coût, puis monter en puissance si le ROI le justifie.

Erreur 3 : déployer un harness auto-modifié sans audit

Un agent qui réécrit son propre system prompt et sa propre mémoire peut dériver. En entreprise, c'est un risque de conformité, pas un détail technique. La solution : versionner chaque itération du harness, loguer les modifications, et garder un humain dans la boucle pour valider les changements structurels — dans l'esprit des cadres de gouvernance émergents.

Erreur 4 : extrapoler les benchmarks

WorkBuddy-Bench, JobBench et LAB sont des environnements spécifiques. Un gain de +11,8 points sur LAB ne garantit rien sur votre cas d'usage. La solution : reproduire la méthode sur un petit échantillon de vos propres tâches avant tout déploiement.

❓ Questions fréquentes

Harness² est-il vraiment gratuit et utilisable commercialement ?

Oui. Le code est publié sous licence Apache 2.0 sur GitHub, ce qui autorise l'usage commercial, la modification et la redistribution. Vous payez uniquement l'inférence du modèle et les coûts de calcul de la récursion. La documentation et les résultats détaillés sont disponibles sur la page projet.

Faut-il un modèle puissant pour que la méthode fonctionne ?

Le paper documente des gains avec GLM-5 et Gemini 3.5 Flash — deux profils très différents en taille et en coût. La logique du harnessing est justement de compenser partiellement les faiblesses d'un modèle par une meilleure couche d'orchestration. Un modèle moyen bien harnessed peut battre un modèle fort mal orchestré sur les tâches agentiques structurées.

Quelle différence avec le prompt engineering classique ?

Le prompt engineering est manuel, statique et ponctuel : un humain écrit un prompt, le teste, l'ajuste. Le recursive harnessing est automatisé, itératif et systématique : l'agent lui-même propose, teste et compose des variantes, et conserve les leçons dans une bibliothèque persistante. C'est la différence entre bricoler et industrialiser.

La bibliothèque d'expériences se transfère-t-elle entre domaines ?

Oui, et c'est l'un des résultats les plus prometteurs du paper : une bibliothèque construite sur JobBench améliore les performances sur WorkBuddy sans aucun probing supplémentaire. Cela suggère que certaines leçons du harness (gestion d'erreurs, structure des tool calls) sont génériques et se transfèrent au-delà du domaine d'origine.

Peut-on utiliser Harness² avec des modèles en local ?

Oui, à condition de passer par un exécuteur compatible (OpenCode notamment) et un modèle self-hostable comme GLM-5. La méthode étant à poids figés, elle ne nécessite aucun GPU d'entraînement — seulement de l'inférence, ce qui la rend viable sur des setups locaux.

✅ Conclusion

Harness² ne propose pas un meilleur modèle — il propose de cesser de tout attendre du modèle. Avec des gains de +11,5 points à poids figés, une licence Apache 2.0 et une architecture modulaire harness/exécuteur/LLM, Google Cloud AI Research vient de légitimer une conviction qui monte dans l'écosystème : la couche harness est devenue une infrastructure de premier ordre. Le code est sur GitHub, le paper sur arXiv — et si vous voulez choisir le bon modèle à placer sous votre harness, notre guide des meilleurs LLM pour les agents IA est le point de départ logique.