💻 computer science

From Failed Trajectories to Reliable LLM Agents: Diagnosing and Repairing Harness Flaws

Cet article présente HarnessFix, un cadre guidé par les traces qui diagnostique les défaillances d'agents en analysant les traces d'exécution et le code de l'harnais pour générer des correctifs ciblés et validés qui améliorent considérablement la fiabilité des agents LLM à travers plusieurs benchmarks.

Auteurs originaux : Mengzhuo Chen, Junjie Wang, Zhe Liu, Yawen Wang, Qing Wang

Publié 2026-06-05

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Mengzhuo Chen, Junjie Wang, Zhe Liu, Yawen Wang, Qing Wang

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 assistant brillant mais parfois confus (l'Agent LLM) essayant de résoudre des énigmes complexes, comme réparer un programme informatique défectueux ou planifier un voyage. Cet assistant ne travaille pas seul ; il travaille à l'intérieur d'une « salle de contrôle » construite par des ingénieurs. Cette salle de contrôle s'appelle le Harness (le Harnais).

Le Harness est l'ensemble des règles, des outils et des contrôles de sécurité qui disent à l'assistant :

Quels outils il peut utiliser (comme un tournevis ou un moteur de recherche).
Quelles informations il peut voir (comme une carte ou un manuel).
Comment rapporter ses progrès.
Quand s'arrêter et dire : « J'ai fini ».

Le Problème : La « Boîte Noire » de l'Échec

Parfois, l'assistant échoue. Par le passé, lorsque les choses tournaient mal, les ingénieurs essayaient de le réparer en :

Ajustant les instructions de l'Assistant : « Hé, essaie d'être plus prudent ! » (C'est comme dire à un conducteur de « mieux conduire » sans réparer les freins cassés).
Devinant : Regarder le résultat final en espérant qu'un changement aléatoire aide.

Le problème est que ces méthodes passent souvent à côté du véritable problème. L'échec n'est peut-être pas la faute de l'assistant ; il se peut que le Harness ait donné le mauvais outil à l'assistant, ait caché un message d'erreur crucial ou ait laissé l'assistant abandonner avant d'avoir terminé le travail. Comme les actions de l'assistant se déroulent dans une chaîne d'événements longue et désordonnée, il est difficile de déterminer précisément où la salle de contrôle a fait défaut.

La Solution : HARNESSFIX (Le Détective)

Les auteurs de ce document ont créé un nouveau système appelé HARNESSFIX. Considérez-le comme un détective médico-légal pour la salle de contrôle. Au lieu de deviner, il enquête sur la scène du crime (la tentative ratée) étape par étape pour trouver la pièce exacte du Harness qui est défectueuse.

Voici comment fonctionne HARNESSFIX, en utilisant une analogie simple :

1. Le « Traducteur » (HTIR)

D'abord, le détective prend le journal de bord (le « trace ») confus et désordonné de ce qui s'est passé et le code de la salle de contrôle, puis les traduit en une carte propre et organisée appelée HTIR.

Analogie : Imaginez une scène de crime chaotique avec des indices éparpillés. Le détective les organise en une chronologie claire : « À 10h00, l'agent a demandé un outil. À 10h01, l'outil a renvoyé une erreur. À 10h02, l'agent a ignoré l'erreur. » Cette carte connecte directement les actions de l'agent aux règles qui les régissaient.

2. Le « Diagnostic » (Trouver le Coupable)

Ensuite, le détective examine la carte pour trouver l'endroit exact où la chaîne s'est brisée.

Analogie : Le détective demande : « L'agent a-t-il échoué parce qu'il ne connaissait pas le mot de passe ? Ou parce que la porte était verrouillée par le système de sécurité (le Harness) ? »
HARNESSFIX identifie si le problème venait de l'Interface de l'Outil (mauvaises instructions), du Cycle de Vie (laissant l'agent abandonner trop tôt) ou de l'Observabilité (cachant les messages d'erreur). Il crée un « Rapport de Défaut » spécifique pour les problèmes récurrents.

3. L'« Atelier de Réparation » (Corrections Ciblées)

Une fois le défaut identifié, HARNESSFIX ne laisse pas n'importe qui réécrire toute la salle de contrôle. Cela serait dangereux et pourrait casser d'autres éléments. Au lieu de cela, il utilise un ensemble d'Opérateurs de Réparation.

Analogie : Pensez à ces opérateurs comme des outils spécifiques dans une trousse de mécanicien. Si le problème est un boulon desserré, le mécanicien utilise une clé. Si le problème est un pneu crevé, il utilise un cric. HARNESSFIX n'utilise que la « clé » spécifique nécessaire pour ce défaut précis. Il écrit un correctif (patch) petit et précis pour réparer uniquement cette partie défectueuse, garantissant qu'il ne casse pas accidentellement le moteur.

4. L'« Inspecteur de Sécurité » (Validation)

Avant que le nouveau correctif ne soit installé, un inspecteur de sécurité le vérifie.

Analogie : L'inspecteur pose deux questions :
1. « Est-ce que ce correctif a résolu le problème spécifique que nous avons trouvé ? »
2. « Est-ce que ce correctif a accidentellement cassé autre chose qui fonctionnait bien ? »
Si la réponse à la deuxième question est « Oui », le correctif est rejeté. Cela empêche le système de s'empirer en essayant de s'améliorer.

Qu'ont-ils découvert ?

Les chercheurs ont testé ce système de détective sur quatre types différents de tâches difficiles (réparer des logiciels, utiliser des lignes de commande, faire de la recherche et automatiser des applications).

Les Résultats : HARNESSFIX a amélioré le taux de réussite des agents de 15 % à 50 % par rapport à la configuration originale.
La Comparaison : Il a été plus performant que :
- Des experts humains qui concevaient manuellement les salles de contrôle.
- D'autres systèmes d'IA qui tentaient de se réparer eux-mêmes en changeant simplement les instructions ou en devinant.
La Découverte : Ils ont découvert que de nombreux échecs n'étaient pas dus au fait que l'IA était « stupide », mais parce que la « salle de contrôle » présentait des défauts cachés, comme le fait de masquer des messages d'erreur ou de laisser l'IA abandonner trop tôt. HARNESSFIX a trouvé ces défauts cachés et les a corrigés.

En Résumé

HARNESSFIX est un système qui traite une tentative ratée de l'IA comme une scène de crime. Il ne se contente pas de blâmer l'IA ; il enquête sur l'environnement dans lequel l'IA travaillait, trouve la règle ou l'outil spécifique qui est défectueux, et applique un correctif précis et sûr. Cela rend l'IA beaucoup plus fiable sans avoir besoin de réentraîner le cerveau de l'IA ou de deviner ce qui s'est mal passé.

Résumé technique : Des trajectoires défaillantes aux agents LLM fiables : Diagnostiquer et réparer les failles de l'infrastructure (harness)

1. Énoncé du problème

Les agents basés sur les LLM s'appuient de plus en plus sur des harnesses (infrastructures d'exécution) qui fournissent des environnements d'exécution, des interfaces d'outils, la gestion du contexte, l'orchestration du cycle de vie, l'observabilité, la vérification et la gouvernance (résumées par la taxonomie ETCLOVG). Bien que les méthodes existantes d'auto-amélioration des agents et d'évolution automatique des harnesses tentent d'améliorer les performances via la supervision au runtime, l'optimisation des prompts ou la recherche de flux de travail, elles échouent souvent à diagnostiquer efficacement les causes profondes des échecs.

Les approches actuelles souffrent de trois limitations principales :

Preuves fragmentées : Les preuves d'échec sont dispersées à travers des trajectoires d'exécution hétérogènes, riches en langage et non déterministes, ce qui rend le diagnostic précis difficile.
Écart de cartographie : Même lorsqu'un échec est localisé dans une trajectoire, le mapper vers l'implémentation statique spécifique de l'harness (code source, prompts, configurations) responsable de celui-ci est complexe, car le comportement au runtime et les artefacts statiques ne sont souvent pas explicitement alignés.
Modifications non ciblées : Sans un diagnostic causal ciblé, les améliorations sont souvent larges, indirectes ou mal délimitées. De plus, modifier les mécanismes de l'harness pour corriger une faile risque d'introduire des régressions ailleurs, un défi exacerbé par les dépendances implicites dans les systèmes d'agents.

Les méthodes existantes optimisent souvent sur la base des résultats finaux sans identifier où dans la trajectoire se trouve la preuve ou quel niveau de l'harness a échoué, menant à des corrections superficielles qui ne traitent pas les failles structurelles sous-jacentes.

2. Méthodologie : HARNESSFIX

Le papier propose HARNESSFIX, un cadre guidé par les traces conçu pour diagnostiquer les échecs des agents et réparer les harnesses via un pipeline à quatre agents. La philosophie centrale est de piloter la réparation de l'harness à partir de diagnostics de défaillance précis et ancrés dans les traces.

A. Représentation intermédiaire de trace sensible à l'harness (HTIR)

Pour traiter l'hétérogénéité des traces brutes, HARNESSFIX compile les traces brutes et le code de l'harness en une HTIR unifiée. Cette représentation normalise les preuves fragmentées et capture :

Nœuds (TraceSteps) : Étapes d'exécution récupérables (appels de modèles, actions d'outils, validations) avec des identifiants uniques.
Attributs : Messages de requête/réponse, statut d'exécution, et effets sur les artefacts/états (lecture/écriture/inconnu).
Liens :
- Liens temporels : Préservent l'ordre d'exécution.
- Liens de provenance des entrées : Tracent comment une requête a été construite à partir du contenu de la trajectoire précédente et de la logique de l'harness (ex: assemblage de la mémoire, construction du prompt).
- Liens de flux de contrôle : Expliquent pourquoi une étape a été déclenchée par le contrôleur de l'harness (ex: tentative de réessai, délégation, terminaison).
Preuve de diagnostic locale au nœud : Une vue localisée pour chaque étape combinant la provenance des entrées, le flux de contrôle et les effets sur les artefacts.
Facet de responsabilité de la couche de l'harness : Mappe chaque étape à la couche ETCLOVG pertinente (Exécution, Outillage, Contexte, Cycle de vie, Observabilité, Vérification, Gouvernance) basée sur la preuve attachée.

B. Diagnostic de faille de l'harness

Un Agent de Diagnostic traite la HTIR pour produire des enregistrements de diagnostic structurés :

Localisation du symptôme : Identifie le symptôme de l'échec à partir du résultat de l'évaluation finale.
Rétro-traçage de l'évidence : Utilise les liens temporels, de provenance et de flux de contrôle pour générer un ensemble classé d'étapes responsables candidates.
Adjudication des candidats : Inspecte les preuves locales au nœud et les références au code de l'harness pour sélectionner l'étape (ou les étapes) responsable(s) finale(s).
Mapping de couche : Assigne les couches ETCLOVG impliquées aux étapes responsables.
Consolidation des failles : Groupe les enregistrements de diagnostic à travers plusieurs exécutions pour identifier les schémas de failles récurrents, les résumant en Enregistrements de Failles exploitables.

C. Réparation délimitée (Scoped Repair)

Pour éviter les éditions instables et les ruptures architecturales, HARNESSFIX emploie des Opérateurs de Réparation plutôt qu'une auto-édition libre.

Mapping : Les enregistrements de failles sont mappés vers des opérateurs de réparation spécifiques (ex: "réduction du schéma d'outil", "garde de boucle") distillés à partir des enregistrements de changements de version dans les dépôts d'agents.
Spécification de réparation : L'opérateur sélectionné est instancié en une spécification propre à la faille qui définit :
- Cible et Portée : Artefacts concrets de l'harness à modifier.
- Contraintes d'édition : Ressources interdites (ex: données de benchmark, évaluateurs).
- Comportement requis : Le comportement spécifique que le patch doit implémenter.
- Validation et Risque : Critères d'acceptation, incluant la réduction de la cible de la faille et les limites de régression.

D. Validation du patch et Mémoire de l'harness

Un Agent de Validation assure la sécurité et l'efficacité :

Pré-validation : Vérifie la conformité du diff candidat à la spécification de réparation et la syntaxe de base.
Évaluation de l'ensemble de validation : Évalue le patch sur un ensemble de validation isolé pour s'assurer qu'il réduit l'occurrence de la faille cible ( $\Delta D_{target} \ge \delta_{min}$ ) sans introduire de régressions inacceptables ( $R_{new} \le r_{max}$ ).
Mémoire de l'harness : Enregistre les résultats (acceptés ou rejetés) pour informer les itérations futures, fournissant des exemples pour des failles similaires ou expliquant les raisons du rejet.

3. Contributions clés

Framework HARNESSFIX : Un cadre ancré dans les traces, piloté par le diagnostic, qui connecte explicitement les preuves d'échec au diagnostic sensible à l'harness et aux changements délimités de l'harness, allant au-delà de l'évolution de prompt pilotée par les résultats.
HTIR : Une représentation de trace sensible à l'harness qui normalise les trajectoires d'agents hétérogènes en structures de preuves au niveau de l'étape, permettant une attribution et une planification de réparation précises.
Évaluation empirique : Évaluation complète sur quatre benchmarks (SWE-Bench Verified, Terminal-Bench 2.0 Verified, GAIA, AppWorld) démontrant des gains de performance significatifs.
Analyse systématique : Une analyse détaillée des réparations acceptées révélant des schémas de failles d'harness récurrents à travers les couches ETCLOVG et les points de tension spécifiques des différents réglages de tâches.

4. Résultats expérimentaux

Les auteurs ont évalué HARNESSFIX sur quatre benchmarks, comparant ses performances aux harnesses initiales ( $H_0$ ), aux harnesses conçues par des humains, et aux bases d'auto-évolution (GEPA, SCOPE, ReCreate).

Gains de performance : HARNESSFIX a amélioré la performance sur l'ensemble de test par rapport aux harnesses initiales de 15,2 % à 50,0 % à travers les benchmarks :
- SWE-Bench Verified : 45,0 % $\to$ 57,0 % (amélioration relative de 26,7 %).
- Terminal-Bench 2.0 Verified : 17,6 % $\to$ 26,5 % (amélioration relative de 50,0 %).
- GAIA : 43,3 % $\to$ 61,7 % (amélioration relative de 42,3 %).
- AppWorld : 36,7 % $\to$ 42,2 % (amélioration relative de 15,2 %).
Comparaison avec les bases de référence : HARNESSFIX a surpassé toutes les bases d'auto-évolution et les harnesses humaines les plus fortes sur chaque benchmark. Par exemple, sur SWE-Bench, il a résolu 57 tâches contre 48 pour la meilleure harness humaine (Trae-Agent).
Étude d'ablation : Le retrait de composants clés a considérablement dégradé les performances :
- La réparation par prompt seul n'a pas réussi à améliorer Terminal-Bench et a produit des gains minimes ailleurs, soulignant l'insuffisance d'un simple guidage "soft".
- Sans diagnostic ancré dans la trace, les améliorations intermédiaires étaient possibles mais restaient en retrait par rapport au système complet, confirmant le besoin d'une attribution précise au niveau de l'étape.
- Sans opérateurs de réparation délimités, des régressions sont survenues, démontrant la nécessité de contraindre les éditions à des opérateurs spécifiques.
- Sans acceptation sensible à la régression, les scores finaux ont diminué, prouvant que la validation est critique pour convertir des candidats utiles en changements d'harness sûrs.

5. Signification et affirmations

Le papier affirme que la réparation de l'harness est un défi distinct et critique de l'optimisation de prompt. La signification de HARNESSFIX réside dans sa capacité à :

Combler l'écart Runtime-Statique : En utilisant la HTIR, il mappe efficacement les échecs d'exécution dynamiques vers les artefacts d'implémentation statique de l'harness.
Permettre une réparation ciblée et sûre : L'utilisation d'opérateurs de réparation délimités et d'une validation sensible à la régression permet des modifications profondes des mécanismes de runtime (interfaces d'outils, gardes de cycle de vie, observabilité) sans l'instabilité associée à l'auto-édition récursive.
Se généraliser à travers les domaines : Le succès du framework dans divers domaines (ingénierie logicielle, flux de travail terminaux, questions de recherche et automatisation d'applications) suggère que la réparation d'harness ancrée dans les traces est une approche généralisable pour améliorer la fiabilité des agents.
Révéler les failles systémiques : L'analyse montre que différents domaines de tâches sollicitent différentes couches de l'harness (ex: AppWorld sollicite la Vérification et le Cycle de vie, tandis que GAIA sollicite l'Interface d'Outil et l'Observabilité), suggérant qu'une ingénierie d'agent efficace nécessite un ajustement de l'harness spécifique au domaine plutôt qu'un "one-size-fits-all" de l'ingénierie de prompt.

Les auteurs concluent qu'à mesure que les agents s'attaquent à des tâches de plus en plus complexes, l'harness devient un déterminant primaire de la fiabilité du système, et que HARNESSFIX fournit une méthode systématique pour diagnostiquer et réparer ces failles infrastructurelles.