FR
Une option d’escalade aide les agents de code à s’arrêter face aux blocages
Knowing When to Stop: The Evidence-Action Gap in Coding Agents · arXiv:2610.31895
En termes simples
Un agent de programmation peut rencontrer un problème qu’il ne peut pas résoudre seul, par exemple un environnement de réparation qui refuse les modifications. Cet article présente Impasse Bench, un ensemble de tâches de réparation logicielle avec des obstacles contrôlés, pour mesurer si les agents adaptent leurs actions aux indices recueillis.
Dans les tâches testées avec des obstacles persistants, la plupart des essais ont recueilli assez d’indices, mais beaucoup ont tout de même utilisé les 80 étapes disponibles. Ajouter une option pour demander de l’aide a réduit ces fins d’essai dans les tests comparés. Certains agents ont toutefois demandé de l’aide alors qu’une défaillance temporaire aurait disparu après une nouvelle tentative.
La recherche
Quand les outils d’un agent de programmation montrent que l’environnement bloque une réparation, comment savoir s’il a assez d’indices pour s’arrêter et s’il va agir en conséquence ?
Une mesure utile doit distinguer une transmission prématurée de tentatives qui se poursuivent alors que les preuves d’un obstacle persistant sont déjà suffisantes.
Impasse Bench évalue les agents de programmation à partir des preuves qu’ils recueillent ; les essais appariés montrent qu’une option d’escalade peut réduire leur persistance excessive face aux obstacles durables.
Les auteurs ont comparé des essais avec ou sans outil d’escalade et consignes de transmettre les obstacles persistants de l’infrastructure.
Parmi les 4 271 paires où les preuves étaient suffisantes dans les deux configurations, le nombre moyen d’appels d’outils valides après ce point est passé de 38,9 à 17,5.
Dans l’ensemble des 4 344 paires confrontées à un obstacle persistant, la part des essais terminés à la limite de 80 étapes ou après trois réponses textuelles consécutives est passée de 33,5 % à 6,6 %. Ces résultats indiquent qu’une option de transmission peut aider les agents à s’arrêter après avoir reconnu ces obstacles, même si certains modèles l’ont rarement utilisée.
Ces résultats proviennent de défaillances contrôlées dans des tâches de réparation exécutées dans des environnements isolés, et d’évaluateurs définis. Ils n’établissent pas que les agents sont sûrs en production ou dans des situations autres que les comportements et environnements mesurés.
Ce que montrent les preuves
- Quand faut-il s’arrêter ?
Impasse Bench est un ensemble de tâches de réparation logicielle qui mesure si les agents de programmation tiennent compte des retours de leurs outils lorsque des défaillances de l’environnement bloquent leur progression.
Les tâches restent réalisables, mais une défaillance contrôlée peut empêcher une réparation, limiter sa vérification ou disparaître après une nouvelle tentative. Les auteurs appellent « écart entre preuves et actions » le décalage entre les indices recueillis et le comportement de l’agent : celui-ci peut continuer malgré des indices montrant qu’il a besoin d’aide, ou s’arrêter avant des tentatives raisonnables de récupération.
- Relier les actions aux preuves
Pour distinguer ces deux erreurs, les auteurs associent chaque défaillance à une fiche réservée à l’évaluateur. Elle définit les signaux attendus, les vérifications, les tentatives de récupération et la réponse adaptée. Un annotateur fondé sur des règles utilise cette fiche et les retours enregistrés des outils pour repérer le premier tour où les preuves sont suffisantes.
Ce repère sert à évaluer la suite des événements ; il n’affirme ni que la réparation est impossible, ni que toutes les tentatives de récupération ont été épuisées.
- Les preuves étaient souvent déjà là
Avec l’interface de base, 98,6 % des 4 344 essais confrontés à un obstacle persistant ont recueilli suffisamment de preuves, mais 33,5 % ont atteint la limite de 80 étapes. Tous les essais arrivés à cette limite avaient déjà réuni assez d’indices.
Dans ces cas testés, cela indique que de nombreux agents ne se sont pas arrêtés après avoir reconnu l’obstacle. Ces résultats agrègent huit configurations de modèles et ne décrivent pas chacun des modèles ou des essais.
- La transmission change le comportement
Les auteurs ont comparé des essais appariés avec ou sans outil d’escalade et consignes de transmettre les obstacles persistants. Dans l’ensemble de ces essais, la part des fins à la limite de 80 étapes ou après trois réponses textuelles seules est passée de 33,5 % à 6,6 %.
Parmi les paires où les preuves étaient suffisantes dans les deux configurations, le nombre moyen d’appels d’outils valides effectués après ce point est passé de 38,9 à 17,5. Ces résultats indiquent qu’une option explicite de transmission peut aider les agents à agir en fonction des preuves dans ces tâches.
- Bien s’arrêter demande du discernement
Les résultats montrent aussi que s’arrêter plus tôt ne suffit pas. Dans dix essais avec l’outil d’escalade, les agents ont transmis le problème pendant une défaillance temporaire de l’environnement isolé, qui s’est résorbée après deux appels infructueux ; tous ont produit des correctifs vides et échoué aux tests ciblés. Une comparaison distincte de bancs d’essai a relevé une meilleure réussite en réparation après restauration automatisée lorsque des rappels fondés sur les preuves et un modèle de rapport étaient ajoutés ensemble.
L’évaluation des rapports montre aussi qu’un agent peut nommer l’obstacle sans expliquer clairement son avancement.
Détails
- Auteurs de l’article original
- Tianyu Chen, Xinran Zhao, Vijay Viswanathan, Shoubin Yu, Mingyuan Zhou
- Soumis à arXiv
- Licence
- CC BY 4.0