Harness² : ton agent s’améliore sans changer de modèle

Le 18 octobre, Google a publié un framework qui n’entraîne rien

Google Research ont ouvert Harness² le 18 octobre, sous licence Apache 2.0. Le dépôt a pris 12,9k étoiles en dix jours, le papier est sur arXiv, le code sur github.com/google-research/harness2. Version 0.1.0, et un chiffre qui résume le projet : zéro paramètre entraîné.

Ce n’est pas un modèle. C’est un cadre qui améliore ce qu’il y a autour d’un modèle, et c’est là que se joue la plupart des projets agentiques que je croise.

Le vocabulaire du papier est utile. Un harnais désigne tout ce qui permet au modèle d’agir : prompts, outils, mémoire, skills, orchestration. Harnacher, c’est optimiser cet ensemble. Harness² le fait à l’exécution, les poids du modèle restant gelés. Leur formulation, dans le README : ton agent peut s’améliorer sans meilleur modèle.

Les huit fichiers qui font un agent

Le framework expose huit composants éditables, chacun monté comme un fichier : system prompt, guardrails, memory, tool guidance, subagents, skills, scripts, plugins (middleware). Ils couvrent quatre rôles à l’exécution : la construction du contexte, l’interface des outils, la délégation, et le comportement dans la boucle d’appel.

Pourquoi ça me parle : ce sont exactement les huit endroits où je passe du temps sur un projet client. Le system prompt qui explique le métier. Les guardrails qui empêchent d’écrire dans la base de production. La mémoire qui garde les décisions déjà prises. La description des outils, qui dit au modèle ce que renvoie chaque appel, ce qu’il coûte, et quoi faire quand il échoue. Le README précise que ce découpage reprend les sept fichiers d’un travail antérieur, Agentic Harness Engineering, et en ajoute un.

Proposer, tester, composer : apprendre sans réponse connue

Le défaut des méthodes d’auto-amélioration, c’est qu’elles supposent des labels ou des cas de test. En production, personne ne te dit si la réponse était bonne. Harness² est construit pour ce cas, ce qu’ils appellent l’open world.

Dans une tâche. L’agent exécute d’abord la tâche avec le harnais de base : c’est la référence. Un éditeur propose ensuite deux candidats. Le candidat « invariant » vise les échecs génériques, la planification, l’usage des outils. Le candidat « domaine » vise les connaissances et les procédures du métier. Les deux tournent sur la même tâche, puis un composeur compare les trajectoires à la référence et ne garde que les modifications adossées à un comportement observé. Rien n’est retenu sur une intuition.

Entre les tâches. Un réflecteur écrit le harnais adopté et un fichier EXPERIENCE.md de leçons. La tâche suivante repart du harnais de base, mais cette bibliothèque guide les propositions suivantes.

Le budget k règle la profondeur de la recherche. En mode parallèle, k candidats invariants et k candidats domaine, puis k compositions. En mode séquentiel, k étapes enchaînées. À k=1, compte une exécution de référence, deux essais et une exécution finale par tâche, donc quatre passages. C’est le prix, et il est réel.

Ce que ça donne sur les benchmarks

Trois benchmarks professionnels (WorkBuddy-Bench, JobBench, le LAB de Harvey), quatre couples modèle et harnais, moyenne sur trois exécutions. Une seule étape améliore les quatre configurations sur les trois benchmarks :

• GLM-5 sous OpenCode : 64,2 vers 75,7 sur WorkBuddy (+11,5 points), 20,6 vers 24,2 sur JobBench, 59,6 vers 71,4 sur le LAB
• Gemini 3.5 Flash sous OpenCode : 72,4 vers 77,5, 31,5 vers 36,0, 79,9 vers 81,9
• GLM-5 sous Codex : 64,4 vers 75,3, 23,6 vers 24,8 (+1,2, le plus faible du lot), 58,1 vers 65,9
• Gemini 3.5 Flash sous Codex : 74,5 vers 77,5, 33,9 vers 35,3, 71,6 vers 75,6

Les exécuteurs les plus faibles gagnent le plus : après une passe, GLM-5 dépasse même le Gemini 3.5 Flash de base sur WorkBuddy, 75,7 contre 72,4. À k=5 en parallèle, Gemini sous OpenCode monte à 80,8 sur ce même benchmark. Sur trois des quatre configurations, la tâche se fait aussi en moins d’étapes (25,4 vers 21,9 pour Gemini sous OpenCode). Face aux autres méthodes, Harness² sort à 77,5 contre 76,4 pour Meta-Harness, 73,4 pour ReasoningBank et 75,3 pour Harness Scaling. Sur le LAB, en revanche, Meta-Harness fait 76,5 contre 75,6. Ce n’est pas un balayage.

Ce que le tableau ne dit pas

Quatre réserves, dans l’ordre de ce qui compte pour un projet réel.

Les scores des méthodes concurrentes ont été mesurés par les auteurs de Harness², et la note du tableau le précise : les autres ne les ont pas publiés eux-mêmes.

L’éditeur par défaut est Claude Opus 4.8. Le gain de GLM-5 vient d’un modèle plus fort qui réécrit son harnais entre deux exécutions. Tu ne supprimes pas la dépense de modèle, tu la déplaces, et tu paies quatre passages au lieu d’un. Sur des tâches longues, la facture se voit.

Les auteurs recommandent eux-mêmes de restreindre l’accès réseau des exécuteurs avant toute évaluation, parce que par défaut il est ouvert et que les grilles d’évaluation sont publiques en ligne. Un agent qui peut lire son propre barème ne mesure plus rien.

Enfin, c’est une version 0.1.0 sous Linux, Python 3.12, uv et Vertex AI, et le dépôt porte le disclaimer habituel : ce n’est pas un produit Google supporté. WorkBuddy-Bench demande Docker, le LAB demande Pandoc et Poppler. Une démo tourne sans credentials (harness2-demo --output runs/demo --k 2) : c’est par là que je commencerais, et ça n’engage rien.

Ce que j’en retiens

Le réflexe, quand un agent se plante, c’est de changer de modèle. Je l’ai eu. La plupart du temps, le problème est dans le harnais : un outil dont la description ne dit pas ce qu’il renvoie, une mémoire qui garde une règle périmée depuis trois semaines, un prompt qui ne dit pas quoi faire quand l’API répond 429, un guardrail qui bloque le cas légitime.

Harness² ne va pas entrer dans mes projets la semaine prochaine, et ce n’est pas le but. Ce que je prends, c’est la méthode, et elle ne demande aucune dépendance : proposer deux modifications précises, une sur le générique et une sur le métier, les faire tourner sur la même tâche, comparer les trajectoires, ne garder que ce qui a changé le comportement, écrire la leçon dans un fichier. Ça se fait à la main sur un agent en production, et ça se livre au client avec le reste du code.

Le second point est plus large. Les benchmarks d’agents mesurent de moins en moins les modèles et de plus en plus les harnais : le même GLM-5 passe de 64,2 à 75,3 selon qu’il tourne sous OpenCode ou sous Codex. Quand un prestataire te dit qu’il « utilise le meilleur modèle », il te parle d’une ligne de configuration.

Ce que ça change pour un e-commerçant

L’agent qui lit ton catalogue, trie tes retours ou réécrit tes fiches produit progressera plus en recevant des règles précises et une mémoire de ce qui a déjà marché qu’en changeant de modèle. Concrètement, la question à poser à celui qui te vend de l’IA n’est plus seulement « quel modèle », mais « où sont écrites les règles, et est-ce que les leçons d’une exécution servent à la suivante ». Et pour les agents qui achèteront à la place de tes clients, le harnais n’est pas le tien : ce que tu contrôles, c’est la propreté de tes données produit et la clarté de tes règles de livraison.