Agents autonomes : trajectoires et auto-correction¶
Un agent de code autonome ne produit pas une suggestion : il enchaîne des dizaines d'actions (lire, chercher, modifier, lancer des tests) avant de déclarer la tâche finie. La recherche sur ces agents étudie donc leurs trajectoires — la suite des pensées, actions et résultats d'un run. Ce chapitre rassemble ce qu'elle dit de deux questions de contrôle qualité : qu'est-ce qui, dans la conception de l'agent, réduit les défauts ? et l'agent peut-il se contrôler lui-même ?
Ce qui marche dans la conception des agents¶
Les garde-fous dans l'outil (SWE-agent)¶
SWE-agent (Yang et al., NeurIPS 2024, arXiv 2405.15793) a introduit la notion d'interface agent-ordinateur : des commandes conçues pour un modèle plutôt que pour un humain. Ses ablations sur SWE-bench Lite (GPT-4 Turbo, configuration complète à 18,0 %) chiffrent l'apport de chaque choix :
| Variante | Score | Écart |
|---|---|---|
| Configuration complète | 18,0 % | — |
| Commande d'édition sans linter | 15,0 % | −3,0 |
| Pas de commande d'édition | 10,3 % | −7,7 |
| Fichier entier affiché au lieu de 100 lignes | 12,7 % | −5,3 |
| Historique complet au lieu des 5 dernières observations | 15,0 % | −3,0 |
Le linter rejette une modification qui casse la syntaxe avant qu'elle soit appliquée : c'est un poka-yoke au sens strict, et il vaut 3 points. Les auteurs observent aussi l'effet cascade : une tentative d'édition réussit finalement dans 90,5 % des cas, mais seulement dans 57,2 % des cas après un premier échec.
Moins d'autonomie peut suffire (Agentless)¶
Agentless (Xia et al., FSE 2025, arXiv 2407.01489) remplace l'agent autonome par un pipeline fixe en trois phases — localiser, réparer, valider le patch — et obtient 32 % sur SWE-bench Lite pour environ 70 cents de dollar par tâche, le meilleur résultat parmi les agents open source comparés à l'époque. Pour un orchestrateur, c'est un argument en faveur des processus standardisés plutôt que de l'improvisation : un pipeline fixe est plus facile à contrôler, parce que chaque étape a une sortie mesurable.
Les anti-motifs des trajectoires¶
Bouzenia et Pradel (ASE 2025, arXiv 2506.18824) ont analysé 120 trajectoires de trois agents. Ils nomment trois anti-motifs :
- actions identiques répétées — 13,6 % des actions dans les runs échoués de RepairAgent, contre 6,1 % dans les runs réussis ;
- correctifs générés en boucle sans tester ;
- arrêt sans validation par les tests.
Les runs échoués de RepairAgent font en moyenne 40 itérations, contre 22 pour les runs réussis.
Une étude plus large de 2026 (Mehtiyev et Assunção, arXiv 2604.02547, 9 374 trajectoires de 19 agents) nuance un point important : le lien entre longueur de trajectoire et échec disparaît quand on contrôle la difficulté de la tâche. Les tâches difficiles produisent à la fois des trajectoires longues et des échecs. En revanche, les agents qui rassemblent du contexte avant de modifier et qui investissent dans la validation réussissent plus souvent, et le choix du modèle pèse plus que celui du framework.
Erreur fréquente : alerter sur la longueur des runs
Une carte de contrôle sur le nombre de tours par run (proposée dans Instrumenter la chaîne) signalera surtout des tâches difficiles, pas des agents défaillants. Elle reste utile pour détecter une boucle (un run qui atteint la limite de tours), mais elle doit être stratifiée par type de tâche, et les signaux plus spécifiques sont les actions identiques répétées et l'arrêt sans test — deux indicateurs directement mesurables dans la trace.
Trop réfléchir¶
Cuadron et al. (arXiv 2502.08235, avec notamment Graham Neubig et Ion Stoica) identifient sur 4 018 trajectoires un phénomène de sur-réflexion : paralysie d'analyse, actions intempestives, abandon prématuré. Plus le score de sur-réflexion est élevé, plus le taux de résolution baisse, et les modèles de raisonnement sur-réfléchissent davantage. Choisir, parmi plusieurs runs, celui qui sur-réfléchit le moins améliore le résultat d'environ 30 % tout en réduisant le calcul de 43 %.
Où les agents échouent¶
Trois taxonomies de 2025-2026 convergent :
- Liu et al. (arXiv 2509.13941) : sur 150 échecs, les défaillances agentiques viennent surtout d'un raisonnement défaillant et d'impasses cognitives ; un agent « expert » qui supervise l'exécutant résout 22,2 % des tickets jusque-là hors de portée ;
- Jiang et al. (arXiv 2605.12270) : sur 243 échecs de trois modèles de 2025-2026, l'étape la plus fragile est la formulation de la stratégie, la plus fiable la localisation du code — et les harnais d'évaluation rejettent parfois à tort des patchs corrects ;
- Chen, Ma et Jiang (arXiv 2503.12374) : les erreurs d'exécution Python pendant la résolution vont de pair avec un taux de résolution plus faible, et l'étude a mis au jour trois bugs dans la plateforme SWE-bench elle-même.
L'agent peut-il se contrôler lui-même ?¶
C'est la question décisive pour un orchestrateur 100 % automatisé : si un modèle peut vérifier et corriger son propre travail, le contrôle externe devient moins nécessaire. La réponse de la recherche est nette.
Sans signal externe : non¶
Huang et al. (Google DeepMind, ICLR 2024, arXiv 2310.01798) ont demandé à des modèles de revoir et corriger leurs propres réponses, sans aucune information extérieure. La précision baisse :
| Modèle et tâche | Initial | Après 1 correction | Après 2 |
|---|---|---|---|
| GPT-3.5, CommonSenseQA | 75,8 % | 38,1 % | 41,8 % |
| GPT-4, GSM8K | 95,5 % | 91,5 % | 89,0 % |
| Llama-2, GSM8K | 62,0 % | 43,5 % | 36,5 % |
Les gains publiés auparavant reposaient sur une étiquette oracle qui indiquait quand s'arrêter ; « les améliorations disparaissent quand les étiquettes oracles ne sont pas disponibles ». La revue de Kamoi et al. (TACL 2024, arXiv 2406.01297) généralise : l'auto-correction fonctionne quand un retour externe fiable est disponible, ou après un entraînement spécifique ; aucun travail antérieur ne montre d'auto-correction réussie à partir du seul retour du modèle, hors tâches exceptionnellement favorables.
Pour le code : la qualité du retour est le goulot¶
Olausson et al. (MIT et Microsoft Research, ICLR 2024, arXiv 2306.09896) ont étudié l'auto-réparation de code : le modèle lit le message d'échec de ses tests, explique l'erreur, puis corrige. À budget de calcul égal, le gain est modeste et irrégulier — parfois négatif par rapport à simplement tirer plus de solutions. Le facteur limitant est la qualité du diagnostic :
| Diagnostic fourni à GPT-4 | Réparations réussies |
|---|---|
| Écrit par GPT-4 lui-même | 33,3 % |
| Écrit par un humain | 52,6 % |
32 des 80 diagnostics de GPT-4 étaient manifestement faux, contre 7 sur 80 pour les humains.
Avec des tests en boucle : oui¶
Quand le signal externe est un test exécuté, l'effet devient important. Mathews et Nagappan (ASE 2024, arXiv 2402.13521) mesurent le taux de réussite sur des tests cachés selon que le modèle reçoit ou non des tests avec l'énoncé :
| Modèle, banc | Sans tests | Tests dans l'énoncé | Tests + boucle de correction |
|---|---|---|---|
| GPT-4, HumanEval | 78,7 % | 87,8 % | 93,3 % |
| GPT-4, MBPP | 69,7 % | 82,5 % | 87,7 % |
| Llama 3 70B, MBPP | 46,4 % | 75,9 % | 85,0 % |
CodeT (Microsoft, ICLR 2023, arXiv 2207.10397) et AlphaCodium (Qodo, éditeur, arXiv 2401.08500) obtiennent des gains du même ordre en faisant générer des tests pour sélectionner ou corriger les solutions — avec la réserve du chapitre Correction et tests générés : des tests générés à partir du code figent ses bugs.
La règle qui se dégage
Un agent ne se contrôle pas lui-même ; il se corrige quand un contrôle externe lui dit quoi corriger. Le linter de SWE-agent, la phase de validation d'Agentless, les tests de Mathews et Nagappan et l'analyseur statique de Fu et al. (Sécurité) ont tous la même structure : un instrument déterministe et indépendant du modèle produit un signal, et le modèle réagit à ce signal. C'est l'architecture du jidoka : la machine détecte, l'arrêt est automatique, la correction suit. Un agent « relecteur » qui n'a accès qu'au même texte que l'agent producteur n'est pas un contrôle externe.
À retenir
- Les garde-fous intégrés à l'outil (linter à l'édition) apportent des gains mesurables ; un pipeline fixe peut rivaliser avec un agent autonome, pour moins cher et en restant contrôlable.
- Les anti-motifs mesurables dans une trace sont la répétition d'actions et l'arrêt sans test ; la longueur des runs reflète surtout la difficulté.
- Sans signal externe, un modèle qui se corrige se dégrade ; avec un diagnostic humain, il répare 1,6 fois mieux qu'avec le sien ; avec des tests en boucle, il gagne de 10 à 40 points.