Google Research présente Harness², une méthode qui cherche à améliorer un agent d’IA sans toucher à son modèle, en ajustant le dispositif qui l’entoure. Ce dispositif, appelé « harnais » (harness), regroupe les consignes, les outils, la mémoire et la boucle de contrôle qui encadrent le modèle. L’approche vise à adapter ce harnais au moment de l’exécution, y compris pour des tâches que ses concepteurs n’avaient pas prévues.
- Harness² améliore un agent IA en ajustant son harnais, sans changer le modèle.
- Il modifie huit composants, car réécrire les consignes peut épuiser le budget de tokens.
- Chaque modification est testée et conservée seulement si elle corrige une défaillance concrète.
- Les gains atteignent 11,8 points, mais la plupart des composants restent vides dans la démonstration.
Le point de départ est simple : aucun harnais n’est le meilleur partout. Selon les éléments présentés, Claude Code obtient de meilleurs résultats sur le code et les tableurs, tandis que Codex est en tête sur les tâches web. Un harnais figé laisse donc des performances de côté.
Pourquoi la réécriture automatique des consignes échoue
Laisser un agent réécrire son propre prompt système, c’est-à-dire les instructions de départ qui lui sont données, paraît prometteur. En pratique, cela peut dégrader les résultats. Ces consignes sont relues tout au long de la tâche, et plus elles s’allongent, plus elles consomment de tokens, les unités de texte que traite le modèle. Lorsque ce budget est épuisé, l’agent peut échouer avant d’avoir terminé.
Harness² n’agit donc pas sur le texte des consignes. Il modifie huit composants regroupés en quatre familles : le contexte, l’interface des outils, la délégation à des sous-agents et les « middlewares », des extensions qui interviennent dans la boucle d’utilisation des outils. Une règle inscrite dans un prompt reste un conseil, tandis qu’une règle placée dans la boucle de contrôle est appliquée. Deux correctifs illustrent cette différence : un mécanisme de surveillance qui force l’agent à rédiger avant d’épuiser son budget, et un script qui bloque la fin d’une tâche tant qu’un tableur contient des formules manquantes.
Proposer, tester, composer
Le processus se déroule en trois étapes. L’agent exécute la tâche une fois, puis deux éditeurs analysent le journal d’exécution : l’un examine les rouages du flux de travail, l’autre propose des règles métier. Le harnais modifié est ensuite relancé sur la même tâche, et les deux tentatives sont comparées. Une modification n’est conservée que si elle corrige une défaillance concrète et observable. Selon les travaux, cette étape de test est déterminante : sans elle, les performances auraient baissé d’environ 10 %.
Résultats annoncés et limites
Les tests portent sur trois banches de benchmarks professionnels, dans quatre configurations modèle et harnais, avec GLM-5 et Gemini 3.5 Flash. Les gains rapportés vont jusqu’à 11,5 points sur WorkBuddy-Bench, 4,5 points sur JobBench et 11,8 points de pourcentage sur LAB, en taux de réussite partielle. Un harnais optimisé avec un modèle puissant a aussi amélioré les résultats d’un modèle plus petit, de 17 points. À l’inverse, ReasoningBank, une base de mémoire de référence, a obtenu 6,6 points de moins que le harnais de base sur les tâches de programmation.
L’auteur de l’article source a installé le projet, qui fonctionne sur Linux avec Python 3.12, et lancé sa démonstration, qui s’est achevée sans échec sur deux tâches comptables. Il souligne toutefois que la démonstration n’est pas la méthode : la plupart des composants restent vides ou à l’état de simples espaces réservés, et la partie décrite par l’article n’apparaît qu’une fois un modèle relié.
