🤖 AI

Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows

Harness-Bench est un benchmark diagnostique comprenant 106 tâches réalistes et isolées dans un bac à sable qui évalue comment différentes configurations de la couche système (harnesses) influencent les performances des agents LLM, révélant que les résultats d'exécution varient considérablement selon les associations modèle-harness et soulignant la nécessité de rapporter les capacités des agents au niveau de la configuration plutôt que de les attribuer uniquement au modèle de base.

Auteurs originaux : Yilun Yao, Xinyu Tan, Chao-Hsuan Liu, Yaoming Li, Zhengyang Wang, Wenhan Yu, Zhewen Tan, Yuxuan Tian, Guangxiang Zhao, Lin Sun, Xiangzheng Zhang, Tong Yang

Publié 2026-05-28

📖 4 min de lecture☕ Lecture pause café

CC BY 4.0

Auteurs originaux : Yilun Yao, Xinyu Tan, Chao-Hsuan Liu, Yaoming Li, Zhengyang Wang, Wenhan Yu, Zhewen Tan, Yuxuan Tian, Guangxiang Zhao, Lin Sun, Xiangzheng Zhang, Tong Yang

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous avez un chef brillant, de classe mondiale (le Modèle IA). Ce chef peut cuisiner n'importe quoi s'il reçoit les bonnes instructions. Mais dans le monde réel, un chef ne se contente pas de se tenir dans le vide ; il travaille dans une cuisine équipée d'outils spécifiques, d'un ensemble de règles, d'un manager qui vérifie les commandes et d'un système pour gérer les erreurs.

Ce papier, Harness-Bench, porte sur le test de ce système de cuisine (appelé le « harnais »), et non pas seulement du chef.

Le Problème : Nous avons Ignoré la Cuisine

Jusqu'à présent, lorsque les gens testaient des agents IA, ils demandaient surtout : « Quelle est la qualité du chef ? » Ils regardaient le plat final (l'IA a-t-elle terminé la tâche ?) mais ignoraient comment la cuisine était configurée.

Le chef avait-il les bons couteaux (les outils) ?
Le chef savait-il gérer une poêle brûlée (la récupération) ?
Le manager de la cuisine (le système) empêchait-il le chef d'utiliser les mauvais ingrédients (les permissions) ?

Les auteurs soutiennent que l'on ne peut pas juger la capacité d'une IA en regardant uniquement le modèle. Il faut examiner le Modèle + Le Système de Cuisine ensemble. Un grand chef dans une cuisine désordonnée et cassée échouera, tandis qu'un bon chef dans une cuisine parfaite et bien organisée pourrait réussir.

La Solution : Un « Simulateur de Cuisine » pour l'IA

Les chercheurs ont construit Harness-Bench, un immense terrain d'essai avec 106 défis culinaires différents (tâches). Il ne s'agit pas de simples questions ; ce sont des travaux complexes comme la correction de code, l'analyse de données financières ou la gestion d'un projet.

Voici comment ils l'ont testé :

Les mêmes Ingrédients, Différentes Cuisines : Ils ont pris les mêmes 106 tâches et les ont données à différents modèles d'IA.
La Variable : Ils ont gardé la tâche exactement identique mais ont remplacé le « système de cuisine » (le harnais) à chaque exécution. Certaines cuisines étaient high-tech et strictes ; d'autres étaient souples et simples.
Le Résultat : Ils ont mené plus de 5 000 expériences.

Ce qu'ils ont Découvert

Les résultats étaient surprenants et clairs : La cuisine compte autant que le chef.

Des Différences Colossales : Lorsqu'ils ont utilisé le même modèle d'IA mais l'ont placé dans différentes « cuisines », le taux de réussite variait énormément. Un système de cuisine a obtenu un taux de réussite de 76 %, tandis qu'un autre n'en a obtenu que 52 % avec exactement le même modèle.
La Cuisine « Intelligente » Gagne : Les systèmes les plus performants n'étaient pas seulement ceux avec les modèles d'IA les plus intelligents. C'étaient ceux où le système aidait l'IA à rester sur la bonne voie, à récupérer après des erreurs et à utiliser correctement les outils.
Le Problème de la « Dérive » : Les chercheurs ont constaté que l'IA commence souvent avec un bon plan, puis « dérive ». Elle peut penser logiquement mais oublier d'enregistrer réellement le fichier, ou ignorer une erreur d'outil et continuer à essayer la même chose. Les meilleurs « systèmes de cuisine » ont détecté ces dérives et les ont corrigées.

La Grande Conclusion

Le papier conclut que nous devons arrêter de dire « Ce modèle d'IA est bon à 90 % ». À la place, nous devrions dire : « Ce modèle d'IA est bon à 90 % lorsqu'il est couplé à ce système spécifique ».

Si vous voulez construire un agent IA fiable, vous ne pouvez pas simplement choisir le cerveau le plus intelligent ; vous devez construire le meilleur corps et le meilleur système nerveux (le harnais) pour l'accompagner. Harness-Bench est l'outil qu'ils ont créé pour aider les ingénieurs à mesurer et améliorer ce corps.

En Bref

Pensez-y comme au test d'une voiture de course. Vous ne pouvez pas simplement regarder le moteur (le modèle d'IA) et dire qu'il est rapide. Vous devez tester le moteur sur différents circuits avec différents pneus et différents pilotes (le harnais). Harness-Bench est le nouveau circuit qui prouve que la vitesse de la voiture dépend fortement du circuit et des pneus, et pas seulement du moteur.

Résumé Technique : Harness-Bench

Énoncé du Problème

Les agents de modèles de langage (LLM) sont de plus en plus déployés en tant que systèmes exécutables interagissant avec des environnements externes, utilisant des outils, modifiant des espaces de travail et produisant des artefacts concrets. Dans ces flux de travail, la performance pratique ne dépend pas uniquement des capacités de raisonnement du modèle de base, mais aussi de manière critique du harness : la couche système qui gère le contexte, les outils, l'état, les contraintes, les permissions, le traçage et la récupération.

Les benchmarks existants font face à une limitation significative : ils abstrait généralement les détails d'exécution, confondent le harness avec le système complet de l'agent, ou maintiennent le harness fixe lors de la comparaison des modèles. Par conséquent, il manque des protocoles de diagnostic pour étudier comment des configurations modèle–harness spécifiques affectent les taux de réussite, les coûts en jetons, la robustesse et la traçabilité dans des flux de travail réalistes. Cela obscurcit la variation de la couche d'exécution qui détermine souvent si un agent réussit ou échoue.

Méthodologie

Les auteurs introduisent Harness-Bench, un benchmark de diagnostic conçu pour évaluer les effets de configuration au niveau du harness dans des conditions externes partagées.

Conception du Benchmark

Suite de Tâches : Le benchmark est composé de 106 tâches hors ligne en bac à sable construites à partir de modèles d'utilisation pratique d'agents. Ces tâches couvrent huit catégories, notamment l'ingénierie logicielle, l'analyse de données, les opérations d'espace de travail, le travail intellectuel, la communication de bureau, les flux de travail professionnels verticaux, l'autonomie de longue durée et le DevOps.
Validation : Chaque tâche est examinée manuellement selon quatre critères : Réalisme (flux de travail utilisateur plausible), Solubilité (complétable avec les ressources fournies), Vérifiabilité par oracle (vérifiable via des contrôles déterministes ou des grilles d'évaluation) et Intégrité (empêchant les agents de contourner les contraintes).
Protocole d'Évaluation : Le benchmark fixe les conditions externes de la tâche (invite de tâche, état initial du bac à sable, budget, délai d'expiration et évaluateur) tout en variant la configuration du harness et le backend du modèle.
- Contrairement aux travaux antérieurs qui forcent les systèmes à adopter une politique interne commune, Harness-Bench préserve le comportement d'exécution natif de chaque harness (invites, interfaces d'outils, gestion de l'état et mécanismes de récupération).
- Cette approche traite le harness comme la variable principale d'intérêt, mesurant la performance du couplage Modèle + Harness plutôt que d'isoler des mécanismes individuels.

Exécution et Notation

Collecte de Données : Chaque exécution enregistre les artefacts finaux, les traces d'exécution, les statistiques d'utilisation et les sorties des validateurs. L'étude a analysé 5 194 trajectoires d'exécution à travers 6 harness configurables et 8 backends de modèles (plus une évaluation de référence de Codex).
Métriques de Notation : Le score global est une combinaison multiplicative de trois composantes :
1. Sécurité ( $S$ ) : Une porte binaire (0 ou 1) pour les violations de permission ou de sécurité.
2. Achèvement ( $C$ ) : Mesuré via des validateurs déterministes spécifiques à la tâche ou un jugement basé sur une grille d'évaluation.
3. Processus ( $P$ ) : Un agrégat de Robustesse, d'adéquation de l'utilisation des outils et de Cohérence, évalué via des grilles de processus basées sur des LLM.
- Formule : $ScoreTâche = S \cdot C \cdot P$ .
- Cette notation conservatrice garantit qu'un crédit agrégé élevé nécessite l'achèvement de la tâche, l'absence de violations de sécurité et un comportement d'exécution fiable.

Contributions Clés

Actif de Benchmark : La publication de Harness-Bench, une suite de 106 tâches hors ligne en bac à sable avec des manifests de tâche, des éléments de fixation, des évaluateurs et des traces d'exécution conçus pour des flux de travail d'agents de bout en bout réalistes.
Protocole d'Évaluation : Un protocole novateur qui fixe les conditions externes de la tâche tout en préservant les comportements natifs des harness, permettant des comparaisons au niveau de la configuration à travers des harness et des backends de modèles représentatifs.
Analyse Diagnostique : Une analyse à grande échelle de 5 194 trajectoires révélant une variation substantielle dans l'achèvement, la qualité du processus, l'efficacité et les modes d'échec à travers différents couplages modèle–harness.

Résultats Clés

Variation au Niveau de la Configuration : Sous le même ensemble de tâches et le même pool de backends de modèles, les scores agrégés variaient considérablement entre les harness. NanoBot a obtenu le score le plus élevé (76,2 %), tandis que OpenClaw a obtenu le plus bas (52,4 %), soit un écart de 23,8 points. Cela démontre que le choix du harness est un déterminant critique de la performance.
Dépendance Modèle-Harness : Les backends de modèles plus puissants tendaient à présenter une variance inter-harness plus faible, suggérant qu'ils sont plus tolérants aux différences d'invites et de gestion de l'état. À l'inverse, les backends plus faibles montraient une sensibilité plus élevée au substrat d'exécution.
Efficacité : Les harness obtenant des scores plus élevés démontraient souvent de meilleurs profils de processus (utilisation des outils, cohérence, robustesse) et, dans certains cas, une efficacité supérieure (moins de jetons/tours) par rapport à leurs homologues obtenant des scores inférieurs.
Modes d'Échec : L'analyse des trajectoires échouées a identifié des « échecs d'alignement d'exécution » récurrents où un raisonnement plausible se découplait des retours d'outils ou des sorties vérifiables. L'échec le plus courant était les violations de Contrat/Format (36,4 %), suivies par les problèmes d'Outils/Récupération (24,6 %) et les lacunes de Preuve/Ancrage (14,6 %).

Importance et Affirmations

L'article soutient que la capacité de l'agent doit être rapportée au niveau de la configuration modèle–harness plutôt qu'attribuée au modèle de base seul. Les résultats suggèrent que la couche d'exécution n'est pas simplement un détail d'implémentation, mais un composant fondamental de la performance de l'agent qui façonne la manière dont la capacité est exposée, contrainte et réalisée.

Harness-Bench fournit une base reproductible pour :

Diagnostiquer les échecs d'alignement d'exécution récurrents où le raisonnement se découple de la preuve ou de l'état.
Améliorer les piles d'exécution d'agents fiables, efficaces, conscientes des permissions et auditable.
Déplacer le paradigme d'évaluation des métriques « modèle uniquement » vers des diagnostics « niveau système » qui prennent en compte l'interaction entre le raisonnement du modèle et l'environnement d'exécution.

Les auteurs adoptent une position modeste, notant que le benchmark évalue des configurations complètes de harness dans des conditions contrôlées et en bac à sable. Par conséquent, les résultats sont présentés comme des mesures diagnostiques sous un protocole fixe plutôt que comme des garanties statistiques pour tous les déploiements réels possibles.