Concevoir un harness qui transforme les erreurs en comportements vérifiables

Partir de l’erreur observée

Un harness utile ne commence pas par une collection de consignes. Il commence par une erreur que l’équipe sait décrire : état final faux, fichier non relu, appel répété, sortie incomplète ou action effectuée avec une permission trop large. Cette formulation évite de confondre une préférence de style avec un comportement qui mérite une protection.

Le travail de Harness-Zero apporte un point de comparaison intéressant : un harness optimisé peut fournir des règles de comportement, mais ces règles doivent être adaptées à l’espace d’action du student avant de devenir des exemples d’entraînement. Pour une équipe qui ne cherche pas à entraîner un modèle, la même idée peut guider la conception d’un contrôle exécutable : traduire une règle abstraite en condition visible, puis en action native et en preuve.

La chaîne de vérification

Pour chaque erreur, écrivez une fiche courte avec six cases :

1. Erreur : que s’est-il passé, avec une trace minimale ?
2. Condition : quel signal observable indique que le risque est présent ?
3. Guidance : quelle règle explique l’action attendue, sans demander de raisonnement privé ?
4. Action native : quelle commande ou réponse l’agent peut-il produire avec ses permissions réelles ?
5. Preuve : quelle observation confirme que l’action a bien eu l’effet attendu ?
6. Régression : quel cas négatif garantit que la protection reste active après une évolution ?

La fiche doit rester dans le vocabulaire du harness cible. Une règle qui exige un outil absent ou un état invisible n’est pas encore une règle transférable. Il faut soit ajouter explicitement la capacité manquante, soit reformuler l’attente autour d’une preuve disponible.

Séparer guidance et décision

Une guidance peut dire « relire l’état après une mutation ». Elle ne doit pas masquer la décision qui suit : accepter, corriger ou arrêter. Cette séparation rend le contrôle auditable et évite de laisser une phrase générale remplacer une vérification.

Dans un harness minimal, on peut distinguer quatre couches :

• la mémoire conserve les erreurs et leurs conditions, pas des secrets ou des conversations entières ;
• la compétence décrit une règle courte et son domaine d’application ;
• le middleware déclenche la revue au moment où la condition est détectée ;
• le guard impose la limite dure : permissions, chemin, nombre d’essais ou validation humaine.

Le journal de provenance relie ensuite chaque décision à une version de règle, à une action et à une observation. Il doit être assez précis pour expliquer un refus, mais ne doit pas exposer une discussion privée du reviewer dans le contexte du student ou dans une sortie publique.

Rendre la correction exécutable

Une correction utile est complète du point de vue de l’interface cible. Dire « vérifie le fichier » ne suffit pas si le student doit produire une commande. Dire « utilise l’outil spécialisé » ne suffit pas si cet outil n’existe pas dans son harness. La correction doit rester dans les actions autorisées et être suivie d’une observation attendue.

Prenons un cas synthétique : l’agent veut déclarer une fiche terminée après avoir écrit une valeur dans un document local. La règle n’est pas « sois prudent ». Elle peut être : si une mutation vient d’être demandée, relire la cellule ou la ligne concernée avant de conclure ; si la valeur attendue ne correspond pas, arrêter la trajectoire et signaler l’écart. La preuve est la lecture après mutation, et la régression vérifie que l’état faux n’est jamais annoncé comme terminé.

Ce niveau de précision protège aussi contre les corrections trop puissantes. Le reviewer ne doit pas ouvrir une nouvelle surface d’action pour résoudre un problème qu’une lecture suffit à diagnostiquer. La moindre action cohérente est généralement plus facile à contrôler qu’une réécriture complète de la trajectoire.

Définir ce qui est visible, privé et conservé

Un student doit recevoir la tâche, les réponses acceptées et les observations de l’environnement. La revue peut conserver une décision privée et une justification courte pour l’audit, mais cette justification ne doit pas devenir une solution cachée injectée dans la trajectoire. Les données d’entraînement, elles, doivent contenir uniquement ce qui est nécessaire pour reproduire le comportement attendu.

Cette séparation n’est pas seulement une question de confidentialité. Elle empêche un contrôle de paraître performant parce qu’il a accès à une information que l’agent n’aurait pas en production. Toute donnée privilégiée doit donc être recensée, limitée et exclue des tests qui prétendent mesurer un transfert sous le harness cible.

Mesurer le contrôle

Un nouveau guard mérite au moins cinq mesures : taux de détection, faux refus, remplacements, coût d’appels supplémentaires et réussite après vérification. Ajoutez la durée et le nombre de fichiers touchés lorsque l’agent agit sur un dépôt. Un score final unique peut cacher un contrôle qui évite une erreur mais multiplie les interruptions.

Les résultats rapportés par Harness-Zero illustrent cette prudence. Le papier annonce des améliorations sur trois domaines et une récupération de comportements exclusifs au harness, mais précise aussi que la revue dépend du modèle reviewer et que certaines connaissances profondes ou opérations de contexte restent externes. Pour un projet réel, ces limites deviennent des critères de sortie : le contrôle est-il utile avec le modèle effectivement déployé ? Son coût est-il acceptable ? Les permissions et la sandbox restent-elles inchangées ?

Tester les cas difficiles

Un test positif confirme que la règle sait reconnaître un bon comportement. Les tests négatifs vérifient les frontières : observation manquante, réponse partielle, permission insuffisante, répétition d’un échec ou demande hors périmètre. Il faut aussi tester la panne du reviewer. Si la revue est indisponible, le comportement sûr doit être l’arrêt ou le retour à une voie explicitement approuvée, jamais le passage silencieux.

Ne mélangez pas plusieurs protections dans un même essai. Changez une règle, gardez le modèle, la tâche, le budget et le harness constants, puis comparez la trajectoire complète. Une protection qui améliore le taux de réussite en relâchant la limite de fichiers n’est pas une amélioration gratuite ; son coût doit apparaître dans le rapport.

Conserver la réversibilité

Versionnez les règles, les conditions et les fixtures de test. Préparez un retour arrière qui retire la guidance ou le middleware sans modifier les données de production. Les guards critiques doivent rester actifs pendant une expérience de collecte, même si un futur entraînement cherche à internaliser un comportement. La distillation éventuelle peut réduire une dépendance à un harness spécialisé ; elle ne remplace pas la vérification de l’environnement.

Un harness devient robuste lorsque l’équipe peut répondre à trois questions : quelle erreur a motivé la règle ? Quelle observation prouve que l’action est correcte ? Que se passe-t-il quand la preuve manque ? Si la réponse n’est pas traçable, il faut réduire l’ambition du contrôle avant d’augmenter la complexité du système.

Source et limites

Cette méthode est une adaptation éditoriale originale inspirée de Haoran Ye, Yuxing Lu, Haonan Dong, Zhaochen Su et Guojie Song, « Harness-Zero: Harness Distillation via Agent-as-Harness », arXiv:2609.24974v1 : résumé et preprint, PDF. Le papier est un preprint : ses chiffres ne garantissent ni l’efficacité ni la sûreté d’un harness différent. Aucun prompt, inventaire, tableau, code ou figure du papier n’est reproduit ici.