Quelles parties d'un harness de code servent vraiment ?

Ce que l'article étudie

Un agent de programmation n'est pas seulement un modèle de langage. Le modèle tourne à l'intérieur d'un « harness » (une structure d'exécution) : une couche logicielle qui contient une boucle de contrôle, une interface d'outils et des règles qui décident quelles parties de l'historique le modèle conserve. L'article « An Empirical Study of Harness Design for Coding Agents » (arXiv 2609.20804, soumis le 17 septembre 2026) demande quelles parties de cette couche travaillent vraiment. Neuf auteurs de UMass Amherst, d'Emory University et de UNC Charlotte l'ont écrit. L'article précise qu'une partie du travail a été faite pendant des stages chez Zoom Video Communications.

Les auteurs expliquent que les études précédentes comparent le plus souvent des harness complets. Ils citent une évaluation croisée où Claude-Opus-4.5 obtient son meilleur résultat avec OpenHands, alors que Claude-Sonnet-4.5 l'obtient avec SWE-Agent. Un tel résultat ne dit pas si le gain vient de la planification, de la conception des outils, de la gestion du contexte ou de leur interaction avec le modèle. Les auteurs ont donc construit un harness léger à partir de zéro. Sa boucle ReAct reste fixe. Ils ne font varier que trois composants : la planification (planning), l'espace d'actions (action space) et la gestion du contexte (context management). La gestion des permissions, les diagnostics après édition et la détection de blocage restent fixes dans toutes les expériences.

Le dispositif en bref

Le harness repose sur LangGraph, et les benchmarks passent par Harbor. Chaque tâche reçoit au plus 300 étapes. L'article teste quatre modèles : trois tailles de Nemotron-3 (30B, 120B et 550B) et Mistral-Medium-3.5-128B. Il utilise deux benchmarks. SWE-Bench Verified compte 500 issues GitHub vérifiées par des humains. Terminal-Bench 2.1 compte 89 tâches en ligne de commande. L'article rapporte le taux de réussite et le coût moyen par tâche, calculé aux tarifs d'OpenRouter.

La gestion du contexte comporte cinq niveaux. T0 ne fait rien et s'arrête sur une erreur quand la fenêtre déborde. T1 remplace les sorties d'outils périmées par de courtes marques (elision, élision). T2 ajoute un stockage externe et un outil recall_event, si bien que le contenu élidé peut être relu. T3 utilise seulement le résumé par un LLM. T4 combine les trois par étapes : élision d'abord, résumé seulement si l'historique reste trop long. Les seuils souple et dur valent 0,6 et 0,85 de la fenêtre utilisable. Les auteurs exécutent les cinq niveaux avec des fenêtres de 32k, 64k, 96k et 128k tokens. La planification et l'espace d'actions (outils prédéfinis contre bash seul) ne sont isolés qu'avec T4 et une fenêtre de 128k. Au total, cela donne 176 réglages appariés. Les auteurs comparent les taux de réussite avec des tests exacts de McNemar bilatéraux et contrôlent le taux de fausses découvertes à 0,05.

Quatre résultats, avec les chiffres de l'article

1. La gestion du contexte compte le plus quand la fenêtre est étroite. En moyenne sur les modèles, l'écart entre les niveaux gérés (T1 à T4) et T0 passe, sur SWE-Bench, de 35,7 à 15,9, puis 5,5 et 2,7 points de pourcentage quand la fenêtre grandit de 32k à 128k. Sur Terminal-Bench, il passe de 9,5 à 7,5, 4,8 et 2,8. Le taux d'échec par débordement de T0 tombe de 78,7 % à 8,7 % sur SWE-Bench, et de 61,0 % à 12,1 % sur Terminal-Bench. Tous les niveaux gérés ont zéro échec par débordement à chaque budget. Un exemple du tableau 3 : à 32k, Nemotron-3 550B obtient 6,40 % sur SWE-Bench avec T0 et 55,60 % avec T4. L'article conclut que l'essentiel du bénéfice vient de l'évitement d'une troncature prématurée. 2. L'élision suivie du résumé (T4) est la plus efficace ; le rappel apporte peu. T4 atteint des taux de réussite proches de ceux de T1 à T3. Il a le coût le plus bas dans sept des huit panneaux modèle-benchmark, et le coût moyen par tâche le plus bas à chaque budget de fenêtre. Il a aussi le plus faible ratio de contexte maximal pour les quatre budgets. À 32k, T1 et T2 atteignent encore presque toute la fenêtre. Le mécanisme de rappel est une autre histoire. Sur 32 comparaisons appariées, T2 bat T1 dans 15 réglages, perd dans 14 et fait égalité dans trois. L'écart moyen est de moins 0,36 point. Dans 36 des 64 réglages (56,3 %), le modèle n'a jamais appelé recall_event. Le nombre moyen d'appels de rappel par tâche passe de 0,540 à 32k à 0,007 à 128k.

3. La planification passe d'un échafaudage de précision à un outil d'économie. Pour Nemotron-3 30B, la planification a fait gagner 11,6 points sur SWE-Bench et 4,5 points sur Terminal-Bench, avec un coût plus élevé. Pour le modèle 120B, il n'y a pas de gain constant. Pour Nemotron-3 550B et Mistral-Medium-3.5-128B, la planification a réduit le coût sur SWE-Bench d'environ 30 % et 32 %, tandis que la réussite baissait de 2,0 et 0,4 point. 4. Le meilleur espace d'actions dépend du modèle. Pour Nemotron-3 30B, l'ensemble d'outils prédéfinis a augmenté la réussite de 15,0 points sur SWE-Bench et de 10,1 points sur Terminal-Bench. Pour Nemotron-3 550B, bash seul a augmenté la réussite de 3,6 et 5,6 points, et réduit le coût de 53 % et 30 %. Mistral est partagé : l'ensemble complet est meilleur sur SWE-Bench (23,2 points de plus), mais bash seul ajoute 6,7 points sur Terminal-Bench.

Ce que montrent les trajectoires

Les auteurs ont aussi étiqueté chaque tour des exécutions avec une phase de flux de travail, à l'aide d'un juge LLM. Leur lecture explique les quatre résultats. La gestion du contexte allonge surtout les exécutions. À 32k sans gestion, les trajectoires médianes sur SWE-Bench durent 20 à 30 tours, et la plupart des exécutions s'arrêtent pendant la localisation du bogue. Avec la gestion, les longueurs médianes montent à environ 50 à 180 tours, et les exécutions atteignent la vérification. La planification agit différemment sur les modèles faibles et forts. Pour Nemotron-3 30B sur SWE-Bench, désactiver la planification a réduit la trajectoire médiane de 40 à 5 tours. Sans planification, 68,6 % des exécutions se sont terminées sans aucune édition, contre 27,8 % avec. Pour les deux modèles les plus forts, la planification a raccourci l'exécution médiane de 108 à 74 tours (550B) et de 68 à 53 tours (Mistral). Les auteurs attribuent l'essentiel de cette baisse à moins de vérification après édition.

L'espace d'actions change la façon d'écrire le code. Pour Nemotron-3 30B sur Terminal-Bench, 66 % des exécutions en bash seul se sont terminées après que le modèle a émis des appels à des outils absents du registre bash seul. L'exécution moyenne est passée de 71 à 15 tours. Pour le modèle 550B sur Terminal-Bench, bash seul a réduit la trajectoire médiane de 47 à 31 actions et fait passer la part des actions d'écriture de code de 16 % à 27 %. Les corrections répétées de fichiers déjà édités ont baissé pour les quatre modèles, par exemple de 3,3 à 0,4 pour le 30B.

Notre analyse

Notre lecture est que le message principal de l'article porte sur des conditions, pas sur des gagnants. Chaque résultat contient un « si » : si la fenêtre est étroite, si le modèle est faible, si le modèle maîtrise bash. Un seul harness par défaut ne peut pas convenir à tous ces cas. Quiconque écrit « le harness A bat le harness B » devrait aussi nommer le modèle, le budget et le type de tâche.

Un deuxième thème est que la mécanique supplémentaire n'est pas gratuite. L'outil de rappel a ajouté de la mécanique, et les modèles l'ont rarement utilisé. Les outils prédéfinis ont aidé un modèle faible, mais semblent avoir ajouté une charge pour un modèle fort, ce que les auteurs appellent une « surcharge de sélection d'actions et d'interaction ». En même temps, les résultats ne disent pas que « plus simple, c'est toujours mieux ». Bash seul a presque divisé par deux le coût du modèle 550B, mais il a fortement pénalisé le modèle 30B, et il a pénalisé Mistral sur SWE-Bench.

Un troisième point concerne le coût. Les montants en dollars dépendent des prix d'OpenRouter d'août 2026 pour ces modèles précis. Le sens de l'effet, comme la baisse du nombre de tours après planification, se transpose mieux que les valeurs en dollars.

Limites et questions ouvertes

Les auteurs énoncent plusieurs limites. Les résultats portent sur les composants précis qu'ils ont construits, pas sur un harness universellement optimal. La planification et l'espace d'actions ne sont isolés qu'avec T4 et une fenêtre de 128k ; il faudrait donc une étude factorielle complète pour tester d'autres combinaisons. Chaque réglage n'est exécuté qu'une fois par tâche. Terminal-Bench ne compte que 89 tâches, donc beaucoup de contrastes n'y sont pas significatifs au test de McNemar, et les auteurs s'appuient sur des directions cohérentes entre modèles et budgets. SWE-Bench Verified ne contient que du Python. La taille du modèle est un indicateur imparfait de la capacité, et les auteurs disent que les points de croisement doivent être validés avant d'être utilisés sur d'autres familles de modèles, d'autres harness ou d'autres tâches. Ils notent aussi que le changement d'espace d'actions regroupe plusieurs choses : la disponibilité des outils, les prompts, le suivi de l'état des fichiers et les diagnostics automatiques.

Nous ajoutons deux limites liées au fait de n'avoir lu que le texte de l'article. Nous n'avons pas exécuté le code ni revérifié les tableaux. Et l'étude utilise une famille à poids ouverts plus un autre modèle. Elle ne dit rien des modèles fermés de pointe que beaucoup d'outils commerciaux utilisent.

Conseils pratiques

Pour les équipes qui construisent des agents de programmation, l'article suggère quelques habitudes. Mesurez à quelle fréquence les longues exécutions atteignent la limite de contexte avant d'ajouter des fonctions de mémoire sophistiquées, car l'article constate que l'essentiel du bénéfice vient de l'évitement du débordement. Essayez l'élision bon marché, fondée sur des règles, avant de payer pour un résumé par LLM.

Ne supposez pas qu'un outil de rappel sera utilisé : vérifiez les journaux d'appels. Testez la planification séparément pour chaque modèle, car elle peut augmenter le coût d'un modèle faible et le réduire pour un modèle fort. Testez une interface en bash seul pour les modèles forts, mais gardez des outils structurés pour les modèles peu à l'aise avec le shell. Enfin, refaites ces vérifications quand vous changez de modèle ou de budget de contexte.