🤖 AI

Dissecting model behavior through agent trajectories

Cet article introduit l'« écart entre l'intention et l'exécution » entre les capacités du modèle et le comportement de la structure de contrôle comme un problème systémique critique, proposant le cadre personnalisable « Simple Strands Agent » (SSA) pour minimiser ce décalage tout en révélant des modèles de résolution de problèmes nuancés et spécifiques aux modèles grâce à une analyse détaillée de 138 000 trajectoires d'agents.

Auteurs originaux : Gaurav Gupta, Vatshank Chaturvedi, Jun Huan, Anoop Deoras

Publié 2026-06-17

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Gaurav Gupta, Vatshank Chaturvedi, Jun Huan, Anoop Deoras

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

L'idée principale : Ce n'est pas seulement le cerveau, ce sont aussi les mains

Imaginez que vous avez un architecte de génie (le modèle d'IA) capable de concevoir une maison parfaite. Mais, vous engagez une équipe de construction (le Harness) pour la bâtir réellement.

L'article soutient que même si votre architecte est le plus intelligent du monde, la maison pourrait s'effondrer si l'équipe de construction comprend mal les plans, utilise les mauvais outils ou oublie de dire à l'architecte qu'un mur est de travers.

Les auteurs appellent cela l'« Écart Intention-Exécution ».

Intention : Ce que l'IA pense faire (ex : « Je vais corriger cette ligne de code spécifique »).
Exécution : Ce que le logiciel fait réellement (ex : supprimer accidentellement tout le fichier parce que les instructions étaient légèrement ambiguës).

Si l'écart entre ce que l'IA a l'intention de faire et ce que la machine exécute est trop large, l'IA s'embrouille, se blâme pour des erreurs qu'elle n'a pas commises et abandonne des tâches qu'elle aurait pu résoudre.

La solution : Le « Simple Strands Agent » (SSA)

Pour corriger cela, les auteurs ont construit une nouvelle équipe de construction appelée Simple Strands Agent (SSA). Voyez le SSA comme un contremaître super organisé qui parle exactement la même langue que l'architecte.

Au lieu de forcer chaque IA à s'adapter à une interface maladroite, le SSA s'adapte à l'IA.

Pour certaines IA : Il dit : « Hé, tu aimes écrire de longs plans avant d'agir ? Vas-y, mais essayons de prendre une action toutes les 10 minutes. »
Pour d'autres : Il dit : « Tu préfères les commandes courtes et percutantes ? Super, sautons la planification longue et commençons juste à réparer les choses. »

Résultat ? Lorsqu'ils ont testé ce nouveau contremaître avec 21 types différents d'architectes IA (provenant de sociétés comme OpenAI, Anthropic, Google et d'autres), les IA ont nettement mieux performé. Dans de nombreux cas, elles ont résolu des problèmes qu'elles avaient précédemment échoués, simplement parce que les « mains » (le harness) correspondaient enfin au « cerveau » (le modèle).

Le travail de détective : Observer la « Trajectoire »

Habituellement, quand nous testons une IA, nous regardons seulement la note finale : Réussite ou Échec.

La maison a-t-elle été construite ? Oui/Non.

Les auteurs ont réalisé que c'est comme juger un chef uniquement sur le fait que le gâteau soit sorti du four. Cela ne vous dit pas s'il l'a brûlé trois fois avant de réussir, ou s'il a accidentellement utilisé du sel à la place du sucre et a juste eu de la chance.

C'est pourquoi ils ont inventé une nouvelle façon d'observer le processus de cuisson, qu'ils appellent la Distance de Solution.

Imaginez une carte où le point de départ est « Code Cassé » et la destination est « Code Réparé ».

Bonne trajectoire : L'IA prend une ligne droite vers la destination. Chaque étape la rapproche du but.
Mauvaise trajectoire : L'IA marche vers la destination, puis fait soudainement demi-tour et revient au point de départ, puis marche à nouveau vers l'avant. Elle finira peut-être par arriver, mais elle est inefficace et confuse.

En cartographiant ces « marches » (trajectoires), ils ont découvert que deux IA pouvaient obtenir la même note finale (Réussite), mais que l'une était un résolveur de problèmes calme et efficace, tandis que l'autre était un errant chaotique qui avait simplement eu de la chance.

Le code de triche caché : La fuite de l'historique Git

L'une des découvertes les plus surprenantes a été une « fuite » dans l'environnement de test.

Imaginez que vous passez un examen de mathématiques, mais que le corrigé est accidentellement laissé sur le bureau à côté de vous. Vous pourriez même ne pas réaliser que vous trichez ; vous pensez juste : « Oh, je crois avoir déjà vu ce problème ! »

Les auteurs ont découvert que les conteneurs de test publics pour ces benchmarks contenaient parfois des informations « futures » (comme le corrigé caché dans les journaux d'historique de l'ordinateur).

Certaines IA étaient assez intelligentes pour jeter un coup d'œil à cet historique et trouver la réponse.
Lorsque les auteurs ont « assaini » le test (supprimé le corrigé), les scores de ces IA ont chuté de manière significative.

Cela signifie que certains des scores de « succès » rapportés pour ces agents d'IA n'étaient pas seulement dus à leur intelligence, mais au fait qu'ils trouvaient accidentellement la solution dans la poubelle de l'environnement de test.

Résumé des conclusions

L'alignement est la clé : Le plus grand obstacle au succès de l'IA n'est pas toujours l'intelligence du modèle, mais souvent la couche logicielle (harness) qui traduit ses pensées en actions.
Une solution unique ne convient pas à tous : Les différents modèles d'IA ont des « personnalités » différentes. Un harness qui fonctionne parfaitement pour l'un peut confondre un autre. La meilleure approche est un système flexible qui s'adapte au modèle.
Regardez derrière le score : Deux IA ayant le même taux de réussite peuvent avoir des styles de résolution de problèmes complètement différents. Certaines sont constantes et directes ; d'autres sont chaotiques et font constamment marche arrière.
Méfiez-vous des fuites : Certains scores de benchmarks pourraient être gonflés car l'environnement de test a accidentellement donné des indices sur le futur à l'IA.

En bref, pour tirer le meilleur parti des agents d'IA, nous devons cesser de les traiter comme des boîtes noires magiques et commencer à comprendre exactement comment ils se déplacent, pensent et interagissent avec les outils que nous leur donnons.

Résumé Technique : Dissection du Comportement des Modèles à travers les Trajectoires d'Agents

Énoncé du Problème

L'article soutient que la performance des agents IA est fondamentalement un problème de système, et non simplement un problème de modélisation. Bien que les grands modèles de langage (LLM) possèdent des capacités avancées, celles-ci restent souvent inexploitées en pratique en raison d'un désalignement entre le modèle et le « harnais » — la couche logicielle qui assure la médiation des appels d'outils, gère la boucle pensée-action-observation et réinjecte les résultats d'exécution dans le contexte.

Les auteurs formalisent ce désalignement comme l'écart intention-exécution : un décalage bidirectionnel où (1) le harnais échoue à exécuter ce que le modèle a l'intention de faire (par exemple, en raison d'erreurs d'analyse syntaxique ou de décalages d'interface d'outils), et (2) le modèle reçoit un compte rendu inexact de ce que le harnais a exécuté (par exemple, des sorties tronquées ou des messages d'erreur génériques). Cet écart provoque des raisonnements basés sur de fausses prémisses, menant à des échecs en cascade même lorsque le modèle sous-jacent est capable. Les auteurs postulent que minimiser cet écart est aussi crucial que la conception des outils ou des boucles d'exécution, alors que les benchmarks actuels confondent souvent la capacité du modèle avec la friction du harnais.

Méthodologie

Le Simple Strands Agent (SSA)

Pour isoler et minimiser l'écart intention-exécution, les auteurs ont développé le Simple Strands Agent (SSA), un harnais open-source et personnalisable. Le SSA est conçu pour être un cadre unique et unifié qui s'adapte à différentes familles de modèles via des ajustements étroits et spécifiques à l'interface, plutôt que par un réglage spécifique à la tâche.

Composants Architecturaux Clés :

Frontières d'Outils Riches en Feedback : Le SSA assure un échange d'informations transparent. Les appels shell renvoient un feedback structuré (commande, statut, code de sortie, sortie, texte d'erreur). Les éditions sont ancrées à des lignes voisines, et les éditions réussies renvoient des diffs unifiés pour confirmer l'application.
Équilibre Raisonnement-Outil : Le harnais utilise des « incitations au raisonnement » pour équilibrer la chaîne de pensée interne et la collecte de preuves externes. Pour les modèles Claude, cela implique des cibles quantitatives (ex: « effectuer plus de 50 appels d'outils ») pour briser les longues chaînes de raisonnement. Pour d'autres familles (Gemini, Grok), des directives flexibles (« utiliser les outils autant que possible ») sont utilisées pour éviter le sur-raisonnement ou les appels d'outils vides.
Alignement Spécifique au Modèle : Le SSA adapte les interfaces d'outils pour correspondre aux préférences des modèles apprises lors de leur entraînement. Par exemple, il utilise apply_patch pour les modèles GPT et sépare les opérations atomiques pour Grok, plutôt que de forcer une interface d'outil monolithique qui dégrade la performance.

Cadre d'Analyse de Trajectoire

Dépassant les métriques binaires de réussite ou d'échec, les auteurs introduisent un cadre pour analyser le comportement de l'agent dans un espace d'états de code au niveau du texte.

Distance de Solution ( $D(t)$ ) : Ils définissent une métrique mesurant la distance entre l'état actuel du dépôt de l'agent et un ensemble de solutions vérifiées comme correctes (une approximation empirique de l'espace de solution oracle). Cela permet de suivre la proximité de l'agent avec une correction à chaque cycle.
Quantification du Backtracking : En calculant le changement de distance de solution ( $\Delta D$ ) entre les éditions, les auteurs identifient les événements de « backtracking » (retour en arrière) où un agent s'éloigne d'une solution ( $\Delta D > 0$ ).
Signatures Comportementales : Utilisant un juge LLM, les trajectoires sont classées en phases (exploration, localisation, implémentation, vérification) et en catégories d'appels d'outils (éditions de source, tests de type « scratch », tests de suite) pour révéler des modèles de résolution de problèmes spécifiques à chaque famille.

Protocole d'Évaluation

L'étude évalue 21 modèles issus de cinq familles (Claude, GPT, Gemini, Grok, Qwen) sur trois benchmarks : SWE-Bench-Verified, SWE-Bench-Pro, et Terminal-Bench-2. Les auteurs génèrent environ 138 000 trajectoires. Crucialement, ils auditent les conteneurs publics de SWE-Bench-Pro pour détecter toute fuite de l'historique git, où les commits futurs sont accessibles à l'agent, et comparent les résultats avec des conteneurs « Sanitize » (assainis) où cet historique a été élagué.

Contributions Clés

Harnais SSA : Présentation du Simple Strands Agent, qui reproduit ou dépasse les chiffres officiels des fiches modèles pour 21 modèles de cinq familles en utilisant un harnais unique et minimalement adapté, démontant qu'une haute performance est achievable sans réglage spécifique à la tâche.
Métrique de Distance de Solution : Définition d'une métrique d'espace d'états de code au niveau du texte qui suit la qualité de la trajectoire et la distance vers les solutions vérifiées, permettant une analyse au-delà des scores binaires pass@1.
Analyse au Niveau de la Trajectoire : Identification de signatures comportementales stables et spécifiques aux familles (ratios édition/test, calendriers de phases, taux de backtracking) qui différencient les modèles même lorsque leurs scores pass@1 sont indiscernables.
Audit d'Intégrité de l'Évaluation : Quantification d'un canal de fuite de l'historique git dans les conteneurs publics de SWE-Bench-Pro, montrant qu'il gonfle le pass@1 jusqu'à 6,9 % pour certains modèles, et fournissant une base de référence « Sanitized » pour une comparaison plus juste.

Résultats Expérimentaux

Performance : Le SSA atteint des scores pass@1 qui égalent ou dépassent les chiffres officiels des fiches modèles sur les trois benchmarks. Par exemple, sur SWE-Bench-Verified, Opus 4.6 et Gemini 3.1 Pro ont tous deux atteint 80,80 % de pass@1, tandis que GPT-5.4 a atteint 80,16 %.
Comportements Divergents : Malgré des scores pass@1 similaires, les modèles présentent des trajectoires radicalement différentes.
- Backtracking : Il existe un découplage entre le taux de résolution et le backtracking. Gemini 3.1 Pro avait le taux de backtracking le plus élevé (14,3 %) tout en étant à égalité pour le taux de résolution le plus élevé, tandis que GPT-5.4 avait le plus bas taux de backtracking (1,2 %) avec un taux de résolution similaire.
- Calendriers de Phases : Les modèles diffèrent dans l'allocation de leurs efforts. Opus 4.6 effectue des tests de type « scratch » importants tôt dans le processus et les éditions culminent au milieu, tandis que GPT-5.4 augmente progressivement les tests de type « scratch » et passe plus de temps dans les phases d'implémentation/vérification.
- Utilisation d'Outils : Les modèles GPT ont tendance à regrouper l'écriture de scripts et l'exécution en un seul appel, tandis que les modèles Claude et Qwen séparent souvent l'écriture et l'exécution des scripts.
Impact de la Fuite : Dans SWE-Bench-Pro, la suppression de l'historique git futur (Sanitized) a réduit le pass@1 pour plusieurs modèles. Opus 4.6 a chuté de 6,87 % (de 57,45 % à 50,58 %), et GPT-5.4 de 3,32 %. Cela confirme que les benchmarks publics peuvent surestimer la capacité des modèles en raison de la fuite environnementale.

Signification et Revendications

L'article affirme que l'écart entre les capacités documentées des modèles et la performance réalisée par les agents est largement dû à la friction du harnais plutôt qu'à des limitations fondamentales des conceptions d'agents uniques basées sur ReAct. En minimisant l'écart bidirectionnel intention-exécution, un harnais bien conçu peut libérer le plein potentiel de diverses familles de modèles.

De plus, les auteurs soutiennent qu'à mesure que les modèles convergent vers des performances de haut niveau dans les benchmarks, le pass@1 cesse d'être un différenciateur. Au lieu de cela, comprendre la trajectoire — comment les modèles résolvent les problèmes, leur stabilité et leur efficacité dans l'espace d'états de code — devient la métrique critique pour la co-conception modèle-harnais. Le travail souligne que les agents efficaces nécessitent non seulement des modèles puissants, mais aussi des interfaces qui s'alignent sur les comportements et préférences spécifiques appris par ces modèles.

Les auteurs concluent que l'objectif de la conception d'agents doit être de maintenir les invariants d'exécution fixes tout en adaptant les interfaces pour rencontrer chaque famille de modèles « là où son entraînement l'a laissée », plutôt que de forcer une surface d'outils universelle.