Harness² ne réentraîne pas un modèle pour améliorer un agent IA. Le framework open source de Google Research modifie plutôt l’environnement qui l’entoure : prompts, garde-fous, mémoire, outils, sous-agents, scripts et plug-ins. Son code est publié sous licence Apache 2.0 et son mécanisme a obtenu jusqu’à 11,8 points de gain sur un benchmark juridique, selon les résultats publiés par Google Research.
Ce tutoriel montre comment installer Harness², lancer la démonstration fournie et comprendre la boucle d’amélioration. L’objectif est d’obtenir un agent capable de corriger progressivement son comportement sans modifier les poids du modèle.
À retenir : Harness² améliore le « harness », c’est-à-dire tout ce qui encadre le modèle, plutôt que le modèle lui-même. Chaque modification peut être testée, comparée et conservée lorsqu’elle produit un comportement différent et utile.
Étape 1 : vérifier les prérequis avant l’installation
Harness² est distribué comme un projet open source sur GitHub. Le dépôt public contient le code du framework et les instructions nécessaires pour lancer les exemples.
Avant de commencer, préparez :
- Un ordinateur capable d’exécuter un environnement de développement local.
- Un navigateur web récent pour consulter le dépôt et la démonstration.
- Un compte GitHub pour récupérer le code.
- Un accès à un modèle compatible avec l’exemple choisi.
- Un terminal, comme Terminal sur macOS et Linux ou PowerShell sur Windows.
Le dépôt est publié sous licence Apache 2.0. Cette licence autorise l’utilisation, la modification et la redistribution du code sous les conditions prévues par cette licence.
Ouvrez le dépôt GitHub google-research/harness2, puis cliquez sur le bouton vert Code. Dans le menu qui apparaît, sélectionnez Local, copiez l’adresse de clonage HTTPS et revenez dans votre terminal.
Saisissez ensuite :
bash git clone https://github.com/google-research/harness2.git cd harness2
Attention : le fonctionnement exact des exemples dépend des instructions présentes dans le dépôt et des modèles configurés pour l’expérience. N’ajoutez pas de clé d’API dans un fichier versionné ou dans un prompt partagé publiquement.
Astuce : créez un environnement virtuel dédié au projet afin d’éviter les conflits avec les bibliothèques déjà installées sur votre ordinateur.
bash python -m venv .venv source .venv/bin/activate
Sous Windows PowerShell, utilisez :
powershell .venv\Scripts\Activate.ps1
Étape 2 : installer Harness² et repérer les composants modifiables
Une fois le dépôt cloné, suivez les commandes d’installation indiquées dans son fichier de présentation. Les noms exacts des dépendances et des scripts peuvent évoluer avec les mises à jour du projet ; utilisez donc les commandes publiées dans la version du dépôt que vous avez téléchargée.
La logique de Harness² repose sur trois phases : Propose, Probe et Compose. Un éditeur propose des modifications, le système exécute l’agent dans des conditions comparables, puis un compositeur conserve les changements appuyés par une différence de comportement observée.
Dans la pratique, le harness peut modifier plusieurs éléments autour du modèle :
- Le prompt système.
- Les garde-fous.
- La mémoire.
- Les consignes associées aux outils.
- Les sous-agents.
- Les compétences spécialisées.
- Les scripts.
- Les plug-ins.
Cette séparation est essentielle. Le modèle de base reste fixe, tandis que l’agent dispose d’un cadre de travail qui peut évoluer.
Pour comprendre la structure du projet, ouvrez le dépôt dans votre éditeur de code et recherchez les termes harness, propose, probe et compose. Consultez ensuite le fichier de démonstration recommandé par le dépôt, sans modifier les scripts d’origine lors du premier lancement.
Astuce : copiez le projet dans un nouveau répertoire avant vos essais. Vous pourrez ainsi comparer le harness initial avec la version améliorée.
Étape 3 : configurer le modèle et la tâche à résoudre
Harness² ne remplace pas le modèle utilisé par l’agent. Il agit sur la configuration qui détermine la façon dont ce modèle raisonne, utilise ses outils et conserve les informations utiles.
Ouvrez le fichier de configuration indiqué par le dépôt, puis repérez les champs associés au modèle, à la tâche et aux outils. Lorsque le projet utilise des variables d’environnement, créez le fichier local prévu par les instructions et renseignez la clé dans votre environnement plutôt que directement dans le code.
Un exemple de tâche de départ peut prendre la forme suivante :
text Vous êtes un agent chargé d’analyser un problème comptable dans une application.
Objectif : identifier la cause d’une écriture incorrecte, proposer une correction minimale, exécuter les vérifications disponibles et expliquer les fichiers modifiés.
Contraintes :
- ne modifiez pas les données de production ;
- conservez une trace de chaque commande exécutée ;
- demandez une confirmation avant toute opération irréversible ;
- signalez les tests qui échouent après la correction.
Ajoutez ensuite un contexte reproductible : un petit dépôt de test, un fichier comptable d’exemple et une procédure de validation. Plus la tâche est stable, plus la comparaison entre le harness initial et ses variantes est lisible.
Un bon problème de départ contient :
- Une erreur observable.
- Un objectif vérifiable.
- Des outils autorisés.
- Des limites clairement définies.
- Une procédure permettant de comparer deux exécutions.
Attention : une amélioration mesurée sur une tâche particulière ne prouve pas qu’un agent sera meilleur partout. Conservez des cas de test distincts pour éviter d’optimiser uniquement le scénario utilisé pendant la démonstration.
Étape 4 : lancer l’agent avec le harness de référence
Avant toute amélioration, exécutez la tâche avec le harness initial. Cette exécution sert de référence : elle permet de savoir ce que l’agent faisait avant la modification.
Dans le terminal, lancez la commande indiquée par l’exemple du dépôt. Selon le scénario fourni, elle peut suivre cette logique :
bash python <script_de_demonstration>.py --task <fichier_de_tache>
Remplacez les noms entre chevrons par ceux indiqués dans la documentation du dépôt. Enregistrez les éléments suivants :
- Le résultat produit par l’agent.
- Les outils qu’il a utilisés.
- Les fichiers qu’il a modifiés.
- Les erreurs rencontrées.
- Le temps d’exécution affiché par le programme.
- Les tests réussis et échoués.
Pour l’exemple comptable, le résultat attendu est une correction documentée du bug, accompagnée des étapes suivies par l’agent. La démonstration gratuite publiée autour de Harness² présente cette correction étape par étape.
Si l’agent échoue, ne corrigez pas immédiatement le prompt. Conservez d’abord la sortie complète. Harness² a besoin de cette situation de départ pour proposer et évaluer des modifications utiles.
Astuce : stockez chaque exécution dans un dossier séparé, par exemple runs/base, runs/probe-1 et runs/composed. Vous pourrez ainsi comparer les sorties sans écraser les résultats précédents.
Étape 5 : demander une amélioration ciblée du harness
La première phase, Propose, cherche des modifications applicables au harness. Ces modifications peuvent concerner le prompt, la mémoire, les outils, les garde-fous ou d’autres composants de l’agent.
Pour obtenir une amélioration exploitable, formulez une demande précise. Utilisez par exemple le prompt suivant dans le point d’entrée prévu par la démonstration :
text Analyse l’échec de l’exécution précédente.
Propose deux changements indépendants du harness :
- un changement général qui réduit les erreurs de diagnostic ou d’utilisation des outils ;
- un changement spécifique à la tâche comptable actuelle.
Pour chaque changement, indique :
- le composant modifié ;
- le contenu exact avant modification ;
- le contenu exact après modification ;
- le problème observé qui justifie ce changement ;
- le risque introduit par la modification.
Ne modifie pas les poids du modèle et ne supprime aucune vérification existante.
Cette consigne sépare les améliorations générales des corrections liées à une tâche précise. La distinction aide à éviter qu’un correctif ponctuel ne devienne une règle globale appliquée à tort.
Harness² est conçu pour proposer des changements sans dépendre nécessairement d’une réponse de référence exacte. Le système compare plutôt les comportements produits par les différents harnesses.
Attention : une modification qui augmente la longueur de la réponse n’est pas automatiquement une amélioration. Évaluez la précision, la sécurité, l’utilisation correcte des outils et la réussite de la tâche.
Étape 6 : sonder chaque variante avec la phase Probe
La phase Probe exécute les variantes proposées afin d’observer leurs effets. Le principe consiste à comparer le harness de référence et les versions modifiées dans des conditions aussi proches que possible.
Pour chaque variante, vérifiez que les éléments suivants restent identiques :
- Le modèle utilisé.
- La tâche d’entrée.
- Les données accessibles.
- Les outils autorisés.
- Les paramètres d’exécution.
- La procédure de validation.
Une grille de comparaison simple peut être organisée ainsi :
| Élément évalué | Harness de référence | Variante proposée | Version composée |
|---|---|---|---|
| Diagnostic du bug | Cause identifiée | Cause identifiée ou corrigée | Cause retenue après comparaison |
| Utilisation des outils | Commandes exécutées | Commandes exécutées | Procédure conservée |
| Tests | Résultats de départ | Résultats de la variante | Résultats après composition |
| Traçabilité | Journal initial | Journal de la variante | Journal final |
Harness² compare les comportements observés afin d’identifier les modifications qui produisent une différence étayée par l’exécution. Le framework ne se contente donc pas de générer un nouveau prompt sans le tester.
Pour un agent de correction comptable, examinez notamment si la variante :
- Vérifie le schéma des données avant de modifier un fichier.
- Repère la ligne comptable réellement fautive.
- Exécute les tests concernés.
- Évite les changements sans rapport avec le bug.
- Explique clairement la correction appliquée.
Astuce : ajoutez au moins un cas où l’agent doit refuser une action dangereuse. Un harness performant doit améliorer l’exécution utile sans affaiblir les garde-fous.
Étape 7 : composer une version améliorée avec Compose
La phase Compose rassemble les modifications qui ont produit les différences les plus utiles lors des sondes. Elle construit un successeur du harness de départ à partir des changements validés par les observations.
Lancez la commande de composition indiquée dans l’exemple, puis exportez le résultat dans un nouveau dossier. Une séquence typique suit cette logique :
bash
python <script_de_composition>.py
--baseline <dossier_harness_initial>
--probes <dossier_variantes>
--output <dossier_harness_ameliore>
Remplacez les paramètres par ceux attendus par le dépôt. Ne remplacez pas le dossier de référence tant que la version composée n’a pas été testée sur l’ensemble de vos cas.
Demandez au système de produire un résumé de composition avec ce prompt :
text Compose un harness successeur uniquement à partir des changements dont l’effet est observé.
Pour chaque changement conservé, indique :
- le fichier ou composant modifié ;
- la justification expérimentale ;
- le comportement amélioré ;
- les effets secondaires possibles ;
- le test à exécuter pour le contrôler.
Conserve les garde-fous existants et n’ajoute aucune capacité d’écriture irréversible.
Une bonne version composée doit être lisible. Si personne ne peut expliquer pourquoi une consigne, un outil ou une règle mémoire a été conservé, la modification mérite un nouvel examen.
À retenir : la valeur de Harness² vient de la boucle complète, proposer, exécuter, comparer, composer. L’agent ne devient pas fiable parce qu’il réécrit son environnement, mais parce que les changements sont confrontés à des résultats observables.
Étape 8 : valider l’agent sur plusieurs tâches
Ne déployez pas immédiatement le harness composé. Relancez d’abord la tâche d’origine, puis utilisez des cas différents qui vérifient les mêmes compétences.
Préparez par exemple :
- Un bug de format dans une écriture.
- Une erreur de totalisation.
- Une donnée manquante qui doit provoquer une demande de clarification.
- Un cas où l’agent doit refuser de modifier une donnée de production.
- Un cas sans erreur, pour vérifier qu’il ne fabrique pas de correction.
Comparez le harness initial et le harness composé avec les mêmes critères. Une évaluation utile doit mesurer la réussite de la tâche, mais aussi la sécurité et la traçabilité.
Le dépôt Harness² rapporte des gains sur trois benchmarks professionnels. Une étape d’amélioration a produit jusqu’à 11,5 points sur WorkBuddy-Bench, 4,5 points sur JobBench et 11,8 points de taux de réussite partielle sur le benchmark juridique LAB, selon la configuration testée.
| Benchmark | Gain maximal rapporté | Domaine |
|---|---|---|
| WorkBuddy-Bench | 11,5 points | Flux de travail en entreprise |
| JobBench | 4,5 points | Travail de connaissance professionnel |
| LAB | 11,8 points de taux de réussite partielle | Agent juridique |
Ces chiffres décrivent les résultats publiés pour les configurations évaluées, pas une garantie de performance pour chaque modèle ou chaque tâche. Les performances observées dépendent du modèle, du harness initial, des outils et du protocole d’évaluation.
Attention : ne mesurez pas uniquement le nombre de tâches terminées. Vérifiez aussi les modifications de fichiers, les appels d’outils, les refus appropriés et la conservation des contraintes métier.
Étape 9 : conserver une version contrôlée et réversible
Un harness auto-améliorant doit rester gouvernable. Utilisez un système de versions pour enregistrer chaque proposition, chaque sonde et chaque composition.
Créez un commit après chaque état validé :
bash git add . git commit -m "Ajout du harness compose pour le cas comptable"
Associez à chaque version un fichier de suivi contenant :
- La date de l’exécution.
- Le modèle utilisé.
- La tâche évaluée.
- Les changements acceptés.
- Les tests exécutés.
- Les erreurs restantes.
- La décision de déploiement.
Ajoutez une validation humaine avant toute mise en production. Un agent peut proposer une amélioration pertinente tout en introduisant un comportement indésirable dans un autre contexte.
Astuce : limitez les droits des outils pendant les premiers essais. Un agent peut analyser et préparer une correction avant d’obtenir l’autorisation de l’appliquer.
Ce que Harness² change pour le développement d’agents
Harness² déplace une partie de l’amélioration des agents vers les composants qui entourent le modèle. Les équipes peuvent donc travailler sur les instructions, les outils, la mémoire et les scripts sans disposer des poids du modèle ni d’un jeu de données pour le réentraîner.
Cette approche réduit le périmètre technique nécessaire pour expérimenter. Elle ne supprime toutefois ni le besoin d’évaluation, ni celui de contrôler les accès, ni les coûts éventuels liés à l’utilisation du modèle et des outils.
Le framework est particulièrement intéressant lorsque les erreurs proviennent de l’orchestration : mauvais choix d’outil, mémoire mal structurée, consigne ambiguë, absence de vérification ou mauvaise coordination entre sous-agents.
Il est moins pertinent lorsqu’une tâche exige une connaissance absente du modèle ou une capacité fondamentale que les prompts et les outils ne peuvent pas fournir. Dans ce cas, modifier le harness ne remplace pas l’amélioration du modèle, l’ajout de données ou la conception d’un outil spécialisé.
Notre avis : commencez par un cas de test réversible
Harness² mérite d’être testé par les équipes qui construisent des agents métier et veulent améliorer leur comportement sans réentraîner le modèle. Son intérêt le plus concret tient à la traçabilité de la boucle Propose, Probe, Compose et à la possibilité de conserver uniquement les changements soutenus par une exécution.
Le meilleur premier projet n’est pas un agent critique en production. Choisissez une tâche locale, reproductible et réversible, comme la correction d’un bug comptable dans un dépôt de test. À la fin, vous devez pouvoir montrer le harness initial, la variante proposée, les résultats comparés et la version composée.
Dans les six prochains mois, la question décisive sera moins de savoir si un agent peut réécrire son environnement que de déterminer quelles évaluations permettent de distinguer une vraie amélioration d’une adaptation fragile à un seul scénario. Harness² fournit une méthode pour expérimenter cette question, à condition de conserver des tests indépendants et une validation humaine.
Quel agent métier pourriez-vous améliorer dès maintenant sans lui donner le droit de toucher à vos données de production ?