RiseHarness apprend aux agents terminaux à réparer leur propre harness sans réentraînement

Un agent terminal peut résoudre une tâche du premier coup, puis échouer à la seconde tentative, alors que le modèle, le prompt et la configuration n'ont pas changé. C'est cette instabilité que cible RiseHarness : ce framework, décrit dans un article repéré dans les Hugging Face Daily Papers, réécrit itérativement le harness de l'agent alors que les poids du modèle restent entièrement figés. L'abstract ne donne aucun résultat chiffré : on ne peut donc évaluer que l'approche elle-même. Celle-ci est, cela dit, plutôt concrète.

L'écart entre « sait faire » et « fait de façon fiable »

Le point de départ est simple. Dans les tâches longues en terminal, chaque action de l'agent modifie le contexte, et le contexte influence l'action suivante. Une erreur aléatoire à une étape précoce se propage sur toute la trajectoire. Résultat : la même tâche, dans la même configuration, réussit lors d'une exécution et échoue lors d'une autre. Les auteurs appellent cela l'écart entre capacités et exécution fiable.

RiseHarness ne s'acharne donc pas sur les tâches que le modèle ne résout jamais. Il s'intéresse aux tâches « fluctuantes » (flipping tasks), pour lesquelles les exécutions comptent à la fois des réussites et des échecs. L'exécution réussie devient la référence à laquelle on compare l'exécution ratée. Il est ainsi plus facile de distinguer un problème systémique du harness d'un simple coup de malchance.

Le fonctionnement de la boucle

L'analyse repose sur deux types de données : les trajectoires de l'agent et les traces internes du moniteur d'exécution. Ces dernières montrent comment les actions du modèle interagissent avec l'exécution des commandes, le retour d'information, la gestion du contexte et la décision de terminer la tâche. Ce sont les endroits qui cassent le plus souvent sur la longue durée.

Pour relier ces observations au code réel, le framework s'appuie sur le Harness Handbook. Celui-ci met en correspondance les indices relevés dans les exécutions avec le comportement du harness et ses sources. Cela aide à repérer des problèmes récurrents dans des mécanismes communs à de nombreuses tâches, plutôt que de rafistoler des cas isolés.

La suite est plus intéressante. RiseHarness cherche dans d'autres frameworks d'agents des implémentations pertinentes et les adapte comme références de conception au modèle concret et au protocole d'exécution. Les corrections candidates passent des contrôles comportementaux, puis une nouvelle évaluation sur les tâches. Les versions qui apportent un gain mesurable servent de base à l'itération suivante. Au final, un même harness rassemble des mécanismes adaptés issus de différents projets, et les données fraîches des exécutions guident les modifications suivantes.

Ce que l'on sait de la méthode

• Les poids du modèle ne changent pas : seul le harness est optimisé.
• L'unité d'adaptation est un modèle précis, et non un « agent en général » abstrait.
• Les tâches aux résultats mixtes à configuration identique sont traitées en priorité.
• Sources du signal : les trajectoires de l'agent et les traces du moniteur d'exécution.
• Les corrections ne sont acceptées qu'après des contrôles comportementaux et des relances.
• Évaluation : succès et fiabilité sur différents modèles, ablations sur les traces d'exécution et sur la recherche externe, transfert vers des benchmarks inconnus avec le même modèle.

Le dernier point compte. Les améliorations d'un harness risquent facilement le surapprentissage sur l'ensemble de tâches qui a servi à les sélectionner. Tester sur des benchmarks inconnus avec le même modèle indique si la méthode a trouvé des mécanismes d'interaction généraux ou si elle a simplement ajusté le comportement. L'abstract ne fournit pas de chiffres précis pour ces tests : il faut donc se reporter au texte complet de l'article.

Ce que l'on peut en retenir

Pour les équipes qui développent des agents de code et des agents terminaux, trois enseignements sont utiles. Premièrement, mesurer la stabilité, et pas seulement le pass@1 : exécutez chaque tâche plusieurs fois et suivez à part celles qui donnent des résultats mixtes. Deuxièmement, journaliser les événements internes du harness au même titre que les actions du modèle. Sans traces d'exécution, de retour d'information et de décisions de fin de tâche, l'analyse d'un échec relève de la devinette. Troisièmement, revoir le harness à chaque changement de modèle : selon la logique des auteurs, les mécanismes qui fonctionnaient bien avec un modèle ne conviennent pas forcément à un autre.

Les limites sont également visibles. La méthode exige de nombreuses relances, donc un budget de calcul, et dépend de la qualité du moniteur. Les ablations du texte complet diront dans quelle mesure les mécanismes « empruntés » et adaptés cohabitent bien. Mais l'idée elle-même paraît pragmatique : une partie de la fragilité des agents se loge dans le harness, et on peut la corriger par l'ingénierie, sans toucher aux poids.