Quand un agent déçoit, le premier réflexe est de changer de modèle. Pourtant, un même modèle peut passer de décevant à convaincant selon son prompt système, les outils qu’on lui décrit ou sa façon de relire son travail avant de rendre un livrable. Cet environnement a un nom : le harness. Google Research vient de publier en open source Harness², un framework qui le fait évoluer automatiquement, sans toucher aux poids du modèle. Le papier et le site du projet détaillent la méthode, les chiffres et les limites.
TL;DR
- Harness² optimise le harness d’un agent (prompt, mémoire, outils, sous-agents…) au lieu du modèle.
- Deux boucles : une par tâche (Propose, Probe, Compose), une qui apprend de tâche en tâche.
- Selon Google, une seule étape suffit à améliorer GLM-5 et Gemini 3.5 Flash sur trois benchmarks. Le coût en calcul et la vérification sans réponse de référence restent les points à surveiller.
Nous verrons ce qu’est un harness, comment fonctionnent les deux niveaux de récursion, puis nous lancerons la démo locale avant de regarder les limites.
Le harness : tout ce qui entoure le modèle
Un modèle seul ne fait que produire du texte. Ce qui en fait un agent, c’est le système autour : prompts, outils, mémoire, orchestration. Harness² en expose huit composants modifiables :
- Construction du contexte : prompt système, garde-fous, mémoire, skills
- Interface d’outils : consignes d’utilisation des outils, scripts
- Orchestration : sous-agents
- Middleware : plugins
L’optimisation de ce système s’appelle le harnessing. Les équipes qui maintiennent un AGENTS.md ou des skills à la main font déjà cette boucle : observer un échec, réécrire une consigne, relancer. Harness² la confie à des agents.
Premier niveau : Propose, Probe, Compose
Pour la tâche en cours, le framework enchaîne trois étapes :
- Propose : un éditeur analyse une première exécution et propose des modifications du harness. Il en existe deux familles : des règles générales de comportement (par exemple relire un fichier après l’avoir écrit) et des conseils propres au domaine de la tâche.
- Probe : chaque variante est exécutée sur la même tâche.
- Compose : un composeur compare les trajectoires obtenues (appels d’outils, observations, fichiers produits) et assemble un harness final à partir des changements dont l’effet est observable.
Aucune réponse de référence n’est utilisée : le composeur s’appuie uniquement sur la comparaison des comportements entre exécutions.
Second niveau : apprendre à améliorer
Sans mémoire, chaque tâche repartirait de zéro. Après chaque tâche, Harness² conserve donc deux choses dans un improvement harness persistant : le harness qui a été adopté, et les leçons que les traces d’exécution permettent d’appuyer (par exemple, relire le fichier final avant de le rendre). Ces leçons guident les propositions faites sur les tâches suivantes.
En revanche, une nouvelle tâche ne reprend pas le harness spécialisé de la précédente : elle repart du harness de base. Un réglage pensé pour analyser un contrat pourrait gêner sur une tâche de tableur, donc le framework garde ce qu’il a appris, pas la configuration elle-même.
Parallèle ou séquentiel
Le budget de récursion se règle avec --k, de deux façons :
| Mode | Comportement |
|---|---|
--mode parallel |
Teste K candidats généraux et K candidats de domaine, puis produit K compositions |
--mode sequential |
Enchaîne K étapes Propose, Probe, Compose, en reportant le harness affiné et les preuves |
Le mode parallèle explore plus large, le séquentiel affine plus en profondeur. Dans les deux modes, dès que K dépasse 1, un sélecteur compare à l’aveugle les livrables obtenus et n’en garde qu’un, sans savoir de quel harness il vient.
Essayer en local
La démo ne demande aucun identifiant de modèle : elle lance les deux modes avec des éditeurs déterministes et de vraies exécutions Python. Le dépôt indique Linux et Python 3.12 comme prérequis, mais la démo a aussi tourné sur macOS lors de nos essais.
# Environnement Python 3.12 avec uv
uv venv --python 3.12 .venv
source .venv/bin/activate
# Installation du projet depuis la racine du dépôt cloné
uv pip install -e '.[render]'
# Démo locale, budget de récursion k=2
harness2-demo --output runs/demo --k 2
Pour les benchmarks, Harness² ne remplace pas votre agent : il le pilote. Cet agent s’appelle l’exécuteur. C’est OpenCode par défaut, ou Codex (l’agent de code d’OpenAI) avec l’option --substrate cx. Il faut aussi accéder à des modèles via Vertex AI, et installer Node.js 20+ et gcloud. L’exemple du README lance une tâche du benchmark LAB, puis l’évalue et produit le rapport :
harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel --only-domains antitrust-competition --max-tasks 1
harness2-judge --bench lab --k 1 --mode parallel
harness2-report --bench lab --k 1 --mode parallel
Ces runs consomment des appels API : le README recommande de commencer par une petite sélection. Attention, --max-tasks plafonne le nombre de tâches par domaine, pas sur l’ensemble du run.
Résultats annoncés et limites
Google a évalué Harness² sur trois benchmarks : JobBench (travail professionnel), LAB (tâches juridiques) et WorkBuddy-Bench (bureautique, web et code). Selon ses auteurs, une seule étape améliore GLM-5 et Gemini 3.5 Flash par rapport à leur harness de base : jusqu’à +11,5 points sur WorkBuddy-Bench, +4,5 sur JobBench et +11,8 points de pourcentage sur le taux de réussite partielle de LAB. Un budget de récursion plus élevé (un --k plus grand) apporte des gains supplémentaires.
Deux détails pèsent dans la lecture de ces résultats, détaillés dans le papier. L’éditeur et le sélecteur sont Claude Opus 4.8, et le juge de JobBench aussi : un biais est possible. Les échantillons sont petits : 34 tâches de test pour JobBench et 100 pour LAB, avec des scores moyennés sur 3 runs.
Le calcul d’abord : chaque proposition, chaque sonde et chaque composition est une exécution de plus de l’agent, donc des tokens et du temps. Plus --k est élevé, plus la facture grimpe.
Le choix du meilleur candidat ensuite. Aucune bonne réponse n’est connue pendant l’exécution : le composeur s’appuie sur le comportement observé et, dès que --k dépasse 1, le sélecteur final choisit sans connaître la bonne réponse. Il peut se tromper. Les auteurs relèvent eux-mêmes des régressions : sur une tâche de code de WorkBuddy-Bench, le sélecteur a retenu une sortie notée 55 alors qu’une autre atteignait 95.
La sécurité enfin. Garde-fous, scripts et plugins font partie du harness, donc l’éditeur automatique peut les modifier. Côté exécution, l’agent a un accès réseau sans restriction, et l’exécuteur Codex tourne sans sandbox. Le README demande de restreindre le réseau avant toute évaluation, car les critères de notation des benchmarks peuvent se trouver en ligne.
Reste le statut du projet : le README précise que ce n’est pas un produit officiellement supporté par Google. À traiter comme un projet à expérimenter avant de l’envisager en production.
Et ensuite ?
Harness² propose de traiter le harness comme un ensemble de fichiers que l’on peut lire et mesurer, plutôt que comme un réglage fait une fois à la main. Son point faible est la vérification : sans bonne réponse connue, rien ne garantit qu’un harness « amélioré » le soit vraiment. Pour tester sans risque, une équipe peut garder un harness de base figé, laisser les révisions se faire dans un environnement isolé, puis comparer la qualité obtenue au calcul dépensé.
🎓 Aller plus loin avec les agents
Vous voulez construire votre propre agent IA ? En une journée, la formation Développer son propre agent de TechTown couvre :
- la différence entre un agent et un chatbot ;
- l’architecture d’un agent : sessions, mémoire, grounding et MCP ;
- les tests, les guardrails et le déploiement ;
- trois ateliers pour créer un agent avec ADK, lui ajouter des tools et le brancher à un serveur MCP.
Top comments (0)