Google Harness2 ouvre l’auto-amélioration des agents, mais la vérification reste l’épreuve décisive

Google a open source Google Harness2 après avoir signalé des gains allant jusqu’à 11,5 points en modifiant le logiciel qui entoure un agent plutôt que son modèle. Cette distinction crée la tension centrale. Le framework permet à un agent de réviser les prompts, les outils, la mémoire et d’autres instructions opérationnelles, mais il doit évaluer ces révisions sans disposer de réponses connues comme correctes.

Baptisé Harness² par ses auteurs, le projet provient de chercheurs affiliés à Google Cloud AI Research et à Northwestern University. Son code est apparu avec un article de recherche daté du 9 octobre 2026 et utilise la licence Apache 2.0. Cette publication transforme une méthode de recherche en logiciel que les développeurs peuvent inspecter, exécuter et modifier.

Le projet remet aussi en cause une hypothèse courante sur les agents IA. De meilleurs résultats ne nécessitent pas toujours un modèle plus récent ou plus grand. Ils peuvent venir d’une modification du harness, c’est-à-dire du logiciel et des instructions qui transforment un modèle de langage en système capable d’agir.

Cet argument met les frameworks d’agents fixes sous pression. OpenCode, Codex, Claude Code et des systèmes similaires associent des modèles à des prompts, des outils, de la mémoire et de l’orchestration. Google Harness2 demande si ces composants environnants doivent rester figés après le déploiement.

La réponse compte au-delà des classements de benchmarks. Un harness auto-modifiable peut s’adapter à des tâches juridiques, bureautiques, web et de programmation inconnues. Il peut aussi perpétuer une mauvaise hypothèse, sélectionner une révision moins efficace ou consacrer beaucoup plus de calcul à parvenir à une réponse.

Google Harness2 modifie le logiciel autour d’un modèle figé

La publication déplace l’amélioration récursive de l’entraînement du modèle vers huit composants modifiables de l’environnement d’exécution de l’agent.

Un agent IA ne se limite pas au modèle de langage qui répond à ses prompts. Il dépend également d’instructions, d’outils disponibles, de contexte stocké, de règles de délégation et du logiciel qui contrôle chaque action. Ensemble, ces composants constituent le harness de l’agent.

Google Harness2 expose huit composants à la révision : le prompt système, les garde-fous, la mémoire, les consignes relatives aux outils, les sous-agents, les compétences, les scripts et les plugins middleware. Chaque composant est représenté par un fichier monté dans l’environnement d’exécution. Les poids du modèle sous-jacent restent figés.

Cette séparation est importante. Entraîner ou affiner un modèle exige une infrastructure spécialisée, des données préparées et un processus de déploiement distinct. Modifier un prompt, une compétence ou une instruction d’outil peut se faire pendant que l’agent travaille sur une tâche.

Le dépôt open source propose la méthode sous forme de projet Python pour Linux. Il prend en charge Python 3.12, le raffinement parallèle et séquentiel, ainsi que des intégrations avec les exécuteurs OpenCode et Codex. Sa démonstration incluse utilise des éditeurs déterministes et une exécution Python locale, afin que les développeurs puissent examiner le flux de travail sans identifiants de modèle.

Les évaluations appuyées par des modèles exigent davantage d’infrastructure. Le dépôt spécifie Node.js, l’authentification Google Cloud, l’accès aux modèles via Vertex AI et des dépendances propres aux benchmarks. WorkBuddy-Bench requiert Docker, tandis que le benchmark juridique nécessite des utilitaires de traitement de documents.

Cette configuration indique le public visé actuellement par le projet. Il s’agit d’un logiciel de recherche destiné à des équipes prêtes à mener des évaluations contrôlées, et non d’une fonctionnalité grand public qui améliore silencieusement chaque agent. La publication fournit la mécanique nécessaire à l’expérimentation, mais les adopteurs ont toujours besoin de tâches, d’environnements d’exécution, de juges et de limites opérationnelles.

Le framework démarre chaque tâche entrante à partir d’un harness de base commun. Il ne reporte pas simplement la dernière configuration spécifique à une tâche vers l’affectation suivante. À la place, il affine temporairement le harness actuel et enregistre les enseignements réutilisables dans une bibliothèque d’amélioration distincte.

Cette décision répond à une défaillance fréquente des systèmes adaptatifs. Une instruction utile à l’analyse de contrats peut nuire à une tâche sur tableur. Accumuler directement chaque modification réussie rendrait le harness de plus en plus spécialisé et difficile à comprendre.

Harness² cherche plutôt à conserver des éléments expliquant pourquoi une modification a été utile. Une tâche future peut s’appuyer sur cette expérience sans hériter de toute la configuration d’exécution précédente.

Le projet représente ainsi deux formes de logiciel. Un harness réalise le travail, tandis qu’un autre améliore le système qui réalise ce travail. Cette seconde couche explique pourquoi les auteurs décrivent la méthode comme du harnessing récursif d’agents plutôt que comme une optimisation ordinaire de prompts.

Pour les développeurs qui maintiennent déjà manuellement des instructions d’agents, cette publication formalise un flux de travail familier. Les équipes examinent les échecs, révisent les instructions, relancent les tâches et conservent les techniques utiles. Google Harness2 confie une grande partie de cette boucle à des agents et enregistre les modifications qui en résultent sous forme d’artefacts structurés.

Comment Google Harness2 affine un agent sans réponses correctes

Son mécanisme central compare les comportements dans des conditions équivalentes au lieu de demander à un vérificateur parfait d’identifier la bonne sortie.

Le framework appelle son principal processus au niveau de la tâche Propose-Probe-Compose. Un proposeur étudie d’abord l’exécution d’origine et suggère des modifications ciblées du harness. Une sonde relance la même tâche avec ces candidats. Un composeur combine ensuite les changements étayés par les différences entre les trajectoires obtenues.

Une trajectoire est la séquence enregistrée des réponses du modèle, appels d’outils, observations et fichiers générés. Elle donne au système davantage d’éléments qu’une réponse finale seule. L’éditeur peut voir si une révision a trouvé des entrées manquantes, appelé un outil approprié ou vérifié un document avant sa soumission.

Le système répartit les propositions entre deux périmètres. Un éditeur invariant se concentre sur le comportement général d’exécution, par exemple vérifier les sorties après les avoir écrites. Un éditeur de domaine se concentre sur des connaissances, formats ou procédures propres à la tâche.

Cette séparation réduit la probabilité que chaque problème reçoive la même correction générique. Elle permet aussi au composeur de combiner une règle de processus largement utile avec des conseils spécialisés lorsque les deux produisent des changements comportementaux utiles.

Point crucial, le processus en ligne ne reçoit pas le corrigé du benchmark. L’article de recherche décrit un cadre ouvert dans lequel les tâches arrivent après la conception du harness. Aucun vérificateur fiable de vérité terrain n’est forcément disponible pendant l’exécution.

Au lieu de déclarer un candidat correct, le système recherche des contrastes. Supposons que l’agent de base néglige plusieurs fichiers sources. Une révision inventorie chaque entrée, tandis qu’une autre ajoute des conseils de rapprochement de feuilles de calcul. Leurs trajectoires révèlent si ces interventions ont modifié le processus de l’agent.

Le composeur utilise ces éléments pour construire un autre harness et exécuter à nouveau la tâche. L’approche n’élimine pas le jugement. Elle le déplace de la comparaison d’une sortie avec une réponse connue vers la comparaison de comportements observables entre différentes exécutions.

Les développeurs peuvent consacrer du calcul de test supplémentaire de deux façons. La récursion parallèle explore plusieurs révisions candidates à la fois, puis compose les éléments issus de ces tentatives. La récursion séquentielle applique un nouveau raffinement après chaque révision précédente.

La variable k contrôle ce budget d’exploration. Une valeur plus élevée offre au système davantage d’occasions de trouver et tester des modifications, mais chaque occasion ajoute des appels au modèle, de l’utilisation d’outils et du temps d’exécution.

Une fois la tâche terminée, un second niveau de récursion met à jour le harness d’amélioration continue. Un réflecteur stocke le harness adopté et un fichier d’expérience décrivant l’intervention, les éléments probants et le résultat. Les propositions ultérieures peuvent consulter cette bibliothèque.

Cette conception rend l’expérience plus portable qu’un prompt finalisé. Une leçon stockée pourrait indiquer que les tâches de génération de documents tirent profit de la réouverture des fichiers finaux et de la vérification des sections requises. Ce processus peut s’appliquer à différents domaines, même lorsque les documents précis diffèrent.

La distinction relie également le framework au travail de connaissance quotidien. Un agent peut devoir combiner des notes de réunion, des feuilles de calcul, des politiques et des documents de projet avant de produire une note de décision. La difficulté consiste souvent à retracer les affirmations entre les sources, plutôt qu’à générer une prose fluide.

Les équipes peuvent déjà réduire cette charge en créant une base de connaissances consultable. Harness² étend l’idée à la politique d’exécution : l’agent peut réviser la façon dont il collecte, vérifie et utilise ce matériau pour une tâche donnée.

Le mécanisme reste toutefois expérimental. Le contraste comportemental est un élément probant, non une vérité. Deux candidats peuvent partager la même prémisse erronée, et une trajectoire soignée peut encore mener à un mauvais livrable.

Les gains aux benchmarks mettent les harnesses d’agents fixes sous pression

Les résultats rapportés suggèrent que la conception du harness peut modifier les performances autant qu’un changement de modèle, en particulier pour les systèmes de départ les moins performants.

Les chercheurs ont évalué Harness² sur trois benchmarks professionnels. WorkBuddy-Bench couvre des tâches de programmation, web et bureautiques. JobBench teste le travail professionnel, tandis que le Legal Agent Benchmark de Harvey mesure les performances sur des tâches juridiques.

Les tests ont couvert quatre combinaisons de deux modèles et de deux harnesses de départ. Les modèles étaient Gemini 3.5 Flash et GLM-5. Les harnesses d’exécution initiaux étaient OpenCode et Codex, tandis que Claude Opus 4.8 servait d’éditeur par défaut dans les principales expériences.

Une seule étape de raffinement a amélioré chaque combinaison de modèle et de harness testée sur les trois benchmarks, selon les auteurs. Les gains les plus élevés rapportés ont atteint 11,5 points sur WorkBuddy-Bench, 4,5 points sur JobBench et 11,8 points de pourcentage sur le taux de réussite partielle du benchmark juridique.

La plus forte évolution sur WorkBuddy-Bench est apparue avec GLM-5 sous OpenCode. Son score moyen est passé de 64,2 à 75,7 après une étape. Gemini 3.5 Flash sous OpenCode est passé de 72,4 à 77,5.

Ces chiffres étayent une inférence pratique. Le harness peut réduire une partie de l’écart entre les modèles en corrigeant des comportements d’exécution que la capacité brute du modèle ne résout pas.

Les résultats variaient selon la configuration. GLM-5 sous Codex n’a gagné que 1,2 point sur JobBench, passant de 23,6 à 24,8. Gemini sous OpenCode a progressé de 4,5 points sur le même benchmark.

Cette variation compte davantage que le chiffre principal le plus élevé. La méthode n’a pas produit une amélioration uniforme pour chaque modèle, harness et tâche. Sa valeur dépendait du système de départ et du domaine.

Les chercheurs ont également augmenté le budget de récursion. Avec Gemini sous OpenCode, le passage d’une étape de raffinement à une récursion parallèle avec k=5 a encore amélioré les performances de WorkBuddy-Bench. La programmation a atteint 80,8, le web 81,7 et le bureautique 83,4.

L’article indique que les scores parallèles et séquentiels ont augmenté lorsque le budget est passé de un à cinq sur certains domaines de WorkBuddy-Bench. Les méthodes concurrentes ont montré des évolutions plus faibles ou moins cohérentes dans ces tests.

L’exploration accrue n’expliquait pas tout. Dans une étude d’ablation, supprimer la bibliothèque d’amélioration a réduit la performance moyenne sur WorkBuddy-Bench de 3,1 points. Supprimer les rôles d’éditeur délimités a coûté 2,9 points, tandis qu’omettre la composition a coûté 1,6 point.

JobBench a présenté une tendance similaire. Supprimer la bibliothèque a réduit son score de 1,8 point, les éditeurs génériques ont perdu 3,7 points et l’omission de la composition a coûté 1,9 point. Ces résultats indiquent que l’expérience conservée, les propositions spécialisées et la combinaison fondée sur des éléments probants ont chacune contribué.

Une étude de cas JobBench illustre le mécanisme. L’agent de base n’a pas réussi à rapprocher les informations entre les fichiers sources et n’a pas rouvert sa sortie finale pour vérification. Son score était de 43,1.

Une intervention proposée exigeait un inventaire de chaque entrée et une traçabilité explicite des sources. Une autre ajoutait des indications métier pour rapprocher le calendrier, le lieu, la main-d’œuvre et le budget. Le composeur a conservé les quatre modifications introduites par ces interventions, et la nouvelle exécution a obtenu 77,8.

Cet exemple renforce l’argument en faveur de l’amélioration du harness de l’agent, car l’échec était procédural. Le modèle ne manquait ni de compétences linguistiques élémentaires ni d’accès aux fichiers. Il lui manquait une méthode de fonctionnement fiable.

Les harness fixes obtenaient néanmoins des résultats différents selon les domaines. La comparaison de l’article a montré que Claude Code dominait les systèmes fixes sur les tâches de code et de bureautique, tandis que Codex dominait les tâches web. Aucun harness inchangé ne dominait partout.

En partant d’OpenCode avec un budget de récursion plus important, Harness² a dépassé la meilleure alternative fixe de 4,6 points en code, 5,8 sur le web et 4,9 en bureautique. Les auteurs précisent explicitement que ce résultat adaptatif a utilisé davantage de calcul au moment du test.

La pression concurrentielle vise donc l’approche du harness fixe, et non un produit particulier. Un fournisseur peut améliorer son modèle, mais les utilisateurs peuvent encore obtenir des résultats incohérents si les instructions et les outils qui l’entourent ne peuvent pas s’adapter.

Les harness d’agents auto-améliorants nécessitent toujours des contrôles indépendants

Harness² peut améliorer le processus d’un agent, mais ses propres résultats montrent que les modifications récursives sélectionnent parfois un comportement moins performant ou propagent une hypothèse erronée.

Les résultats du benchmark proviennent des auteurs du projet et n’ont pas encore établi leur fiabilité en production à travers des déploiements indépendants. L’article présente des moyennes sur trois exécutions, ce qui aide à mesurer la variabilité sans remplacer une réplication externe.

La méthode consomme aussi davantage de calcul avant de fournir sa sortie finale. Chaque proposition, sonde, composition et nouvelle exécution utilise des tokens et du temps d’exécution. Le traitement parallèle peut réduire le temps écoulé lorsque des capacités sont disponibles, mais il n’élimine pas le coût sous-jacent en ressources.

L’article place les configurations évaluées sur une frontière empirique calcul-performance pour JobBench et WorkBuddy-Bench. Ce résultat signifie que les gains mesurés se comparent favorablement aux alternatives testées. Il ne signifie pas que la récursion sera économique pour chaque charge de travail en production.

Une tâche à faible valeur peut ne pas justifier plusieurs exécutions de modèle. Une note juridique ou une décision opérationnelle peut justifier davantage de vérifications, mais ces domaines exigent également des contrôles plus stricts que ceux fournis par un exécuteur de benchmark.

L’avertissement le plus important provient de l’analyse des échecs menée par les auteurs eux-mêmes. Ils ont examiné neuf régressions et les ont regroupées en échecs de sélection de candidats, prémisses incorrectes partagées, et incertitudes d’évaluation ou d’exécution.

Dans un exemple de programmation, le framework a sélectionné une sortie notée 55 plutôt qu’une alternative notée 95. Dans une tâche juridique, une révision plus restrictive a réduit la couverture et fait tomber le score de 54 à 26.

D’autres échecs ont commencé par une hypothèse incorrecte partagée entre les candidats. Ces erreurs ont entraîné des pertes de 2 à 11 points. Si chaque modification proposée accepte la même prémisse erronée, comparer leur comportement ne révèle pas l’erreur initiale.

L’article identifie également les décisions manquantes des juges et la variabilité ordinaire d’une exécution à l’autre comme des problèmes d’attribution. Un score modifié peut refléter la modification, une exécution stochastique ou du bruit d’évaluation. Davantage de sondes aident, mais augmentent le coût.

L’activité du dépôt a également révélé des risques d’implémentation. Un problème ouvert d’identité du cache indique que les expériences reprises peuvent réutiliser des sorties antérieures après modification des instructions de tâche ou des fichiers sources, tant que les identifiants de tâche restent constants.

L’auteur du problème a reproduit ce comportement sans appels au modèle et a relevé que le contenu des entrées est absent de certaines parties de l’identité d’exécution enregistrée. Le rapport ne quantifie aucun effet sur les scores publiés du benchmark, et aucune résolution par un mainteneur n’était jointe lors de l’examen.

Néanmoins, ce problème illustre le défi opérationnel plus large. Un système récursif a besoin d’une traçabilité fiable des tâches, des sources, des révisions de harness, des sorties mises en cache et des paramètres d’évaluation. Sinon, une amélioration apparente peut refléter des preuves obsolètes.

La sécurité soulève une autre préoccupation. Les huit composants modifiables incluent des garde-fous, scripts, plugins et instructions d’outils. Ces fichiers peuvent influencer ce à quoi un agent accède et les actions qu’il réalise.

Un éditeur autonome ne devrait pas recevoir une autorité sans restriction pour affaiblir les contrôles d’accès, exécuter des scripts non examinés ou conserver des détails de tâche sensibles. L’usage en production nécessite des autorisations au niveau des composants, des limites de sécurité immuables, des journaux d’audit et des mécanismes de restauration.

L’expérience persistante mérite une prudence similaire. Une leçon utile tirée d’un client, d’un service ou d’une affaire juridique peut exposer des informations confidentielles lorsqu’elle est récupérée pour un autre contexte. Une bibliothèque d’améliorations a donc besoin de politiques de séparation et de conservation des données, et pas seulement de pertinence sémantique.

Les équipes doivent aussi distinguer l’optimisation de performance de la validation de sécurité. Un score de benchmark récompense l’achèvement d’une tâche selon son évaluateur. Il ne mesure pas automatiquement la confidentialité, l’autorisation, l’exactitude factuelle ou la résistance aux entrées malveillantes.

Google Harness2 démontre lui-même pourquoi cette distinction importe. Son composeur peut préférer un candidat convaincant sur le plan comportemental mais objectivement plus faible. L’absence de vérité terrain est le problème traité par le framework, mais elle reste une limite que le framework ne peut pas supprimer.

Une conception de production raisonnable permettrait au système de modifier des indications à faible risque tout en protégeant les politiques fondamentales. La formulation des prompts et les listes de contrôle de flux de travail pourraient être modifiables. Les règles relatives aux identifiants, aux limites réseau, aux barrières d’approbation et aux restrictions sur les actions destructrices devraient rester hors de l’autorité de l’agent.

L’examen humain demeure également précieux pour les modifications proposées qui persistent d’une tâche à l’autre. Le framework peut produire des éléments expliquant pourquoi une modification a été adoptée. Les opérateurs peuvent utiliser cet historique pour approuver, rejeter ou restreindre le changement avant son entrée dans une bibliothèque partagée.

Le harness récursif d’agents redéfinit la feuille de route de l’ingénierie des agents

Le prochain test consiste à déterminer si les organisations peuvent reproduire les gains tout en maîtrisant le calcul, les régressions et la mémoire persistante.

Le premier signal à surveiller est la réplication indépendante des benchmarks. Le dépôt expose le code, les configurations, les prompts et les commandes d’évaluation, offrant aux équipes externes un point de départ pratique. Les reproductions devraient rapporter à la fois les scores finaux et l’utilisation totale du modèle.

Une réplication réussie chez différents fournisseurs renforcerait l’affirmation centrale. Elle montrerait que le harness adaptatif n’est pas étroitement lié aux modèles testés, à l’éditeur ou à l’environnement Google Cloud.

L’incapacité à reproduire les gains affaiblirait l’argument de généralité. Les chercheurs devraient déterminer si l’écart provient du comportement des modèles, des versions de benchmark, des environnements d’exécution ou des paramètres d’évaluation.

Le deuxième signal concerne les performances sur des flux de tâches réels plutôt que sur des exécutions de benchmark isolées. La récursion au niveau du harness promet une valeur cumulative, car les leçons des tâches précédentes guident les propositions ultérieures.

L’article fournit des premiers éléments en faveur d’un tel transfert. Une bibliothèque d’expérience construite sur JobBench a amélioré le raffinement en une étape sur WorkBuddy-Bench de 0,6 point pour le code, 0,5 pour le web et 2,9 pour la bureautique.

Ces gains sont plus modestes que les meilleurs résultats au niveau des tâches, et une analyse a utilisé rétrospectivement l’expérience de tâches ultérieures. Un déploiement en conditions réelles devrait montrer que les leçons utiles s’accumulent dans l’ordre chronologique, sans importer d’informations futures.

Les opérateurs devraient mesurer les taux de régression parallèlement aux performances moyennes. Ils devraient également suivre la fréquence des interventions, la latence, la consommation des modèles et le pourcentage de modifications persistantes qui passent l’examen humain.

Le troisième signal est l’existence d’une couche de vérification et de gouvernance plus solide. Les auteurs recommandent des sondes qui remettent en question les hypothèses partagées, des exécutions répétées pour distinguer les modifications de la variabilité, ainsi que de meilleures méthodes de sélection conciliant couverture et précision.

Les corrections apportées au dépôt peuvent fournir un autre indicateur. Des identités de cache tenant compte du contenu, des révisions de benchmark figées et une invalidation fiable faciliteraient la reproduction des expériences. Des limites de sécurité claires pour les composants modifiables rendraient le déploiement plus sûr.

Le domaine de recherche plus large testera également d’autres formes d’adaptation du harness. Meta-Harness recherche des configurations avant le déploiement. ReasoningBank récupère une expérience de raisonnement utile tout en laissant le harness fixe. Harness Scaling révise un harness pour des tâches individuelles.

Harness² combine l’adaptation de tâches en ligne avec un mécanisme d’amélioration persistant. Cette combinaison constitue sa principale distinction, mais elle concentre aussi le risque. Une mauvaise révision au niveau d’une tâche affecte un résultat, tandis qu’une mauvaise leçon conservée peut influencer les tâches ultérieures.

Pour les développeurs, le message pratique n’est pas que chaque agent devrait se réécrire immédiatement. Il est que les prompts, la mémoire, les outils et l’orchestration méritent d’être évalués comme un système connecté.

Les équipes peuvent commencer par des expériences limitées. Elles peuvent sélectionner des tâches représentatives, préserver un harness de base immuable, n’autoriser les révisions que dans un environnement isolé et comparer la qualité des sorties au calcul total. Chaque modification persistante devrait rester attribuable et réversible.

Les travailleurs du savoir devraient s’y intéresser, car la qualité du harness façonne le comportement visible des agents. Un modèle peut sembler peu fiable lorsque ses instructions d’outils sont faibles, que sa mémoire est bruyante ou que son flux de travail omet la vérification. À l’inverse, une meilleure procédure peut améliorer les résultats sans changer le modèle.

La publication ouverte rend ces hypothèses vérifiables. Elle fournit aux chercheurs une implémentation commune pour étudier la façon dont les agents diagnostiquent les échecs, révisent les instructions de fonctionnement et conservent l’expérience.

Google Harness2 déplace finalement le débat sur l’auto-amélioration d’une intelligence abstraite des modèles vers des artefacts logiciels inspectables. C’est un déplacement utile, car les équipes peuvent examiner les fichiers, tracer les révisions et mesurer les exécutions.

Il ne résout pas la question la plus difficile : qui vérifie l’améliorateur lorsqu’aucune réponse de référence n’existe ? Le framework remplace l’édition aveugle par des preuves comportementales structurées, mais ces preuves peuvent toujours induire en erreur.

Au cours des prochains mois, surveillez les réplications indépendantes, les résultats réels inter-tâches et des contrôles plus stricts autour des composants modifiables. Ces signaux détermineront si le harness récursif d’agents devient une couche d’ingénierie fiable ou reste un flux de travail de recherche prometteur.

Pour les équipes qui évaluent actuellement des agents d’IA, l’action immédiate est simple. Testez séparément le modèle et son harness, consignez chaque changement et exigez des preuves claires avant de conserver une révision automatisée. Google Harness2 fournit un cadre concret pour cette expérimentation, tandis que les échecs signalés montrent pourquoi la supervision reste importante.