Résumé technique : TERMINALWORLD : Évaluation des agents sur des tâches réelles en terminal

Énoncé du problème

Les agents autonomes alimentés par des modèles de langage de grande taille (LLM) sont de plus en plus capables d'automatiser des flux de travail complexes en terminal en émettant des commandes, en composant des outils et en interprétant les retours d'information au sein de sessions d'interface en ligne de commande (CLI) interactives. Cependant, évaluer de manière fiable ces agents sur des tâches réelles et authentiques en terminal reste un défi ouvert.

Les normes d'évaluation actuelles reposent fortement sur des benchmarks manuellement élaborés (par exemple, Terminal-Bench, LongCLI-Bench). Ces benchmarks souffrent de trois limitations principales :

1. Fossé d'authenticité : Les experts privilégient souvent des puzzles adversariaux pour maximiser la difficulté, ce qui entraîne une divergence des tâches par rapport aux flux de travail authentiques et routiniers que les développeurs effectuent réellement.
2. Goulot d'étranglement de l'évolutivité : La curation manuelle est laborieuse et peine à suivre le rythme des pratiques terminales évolutives et des outils émergents divers, conduisant à des benchmarks à portée étroite et rapidement obsolètes.
3. Déficit de validation : Les récentes méthodes de synthèse automatisée tentent de contourner la curation manuelle mais sont principalement conçues pour la génération de données d'entraînement. Elles subissent rarement la validation rigoureuse requise pour garantir une authenticité véritable et une validité des tests.

Par conséquent, il manque un système d'évaluation qui soit à la fois authentique par rapport aux pratiques réelles des développeurs et suffisamment évolutif pour évoluer avec elles.

Méthodologie : Le moteur de données TERMINALWORLD

Pour remédier à ces limitations, les auteurs introduisent TERMINALWORLD, un moteur de données évolutif qui inverse automatiquement l'ingénierie de tâches d'évaluation haute fidélité à partir d'enregistrements de terminal « in-the-wild ». Le moteur opère sur un corpus de 80 870 enregistrements de sessions de terminal récoltés sur la plateforme asciinema, un dépôt public où les développeurs partagent volontairement des transcriptions de sessions.

Le moteur traite les enregistrements bruts à travers quatre étapes systématiques pour transformer des journaux bruyants en benchmarks rigoureux :

1. Collecte et filtrage des enregistrements humains

Le moteur récupère les transcriptions et les métadonnées d'asciinema. Un processus de filtrage multi-étapes assure la qualité et la sécurité des données :

• Vie privée et sécurité : Exclusion des enregistrements contenant des informations personnellement identifiables (PII), des identifiants sensibles ou des commandes malveillantes (par exemple, rm -rf *).
• Définition du périmètre : Rejet des enregistrements impliquant des interfaces utilisateur textuelles (TUI comme vim ou nano) ou des interfaces graphiques (GUI), se concentrant strictement sur les flux de travail CLI purs.
• Reproductibilité : Suppression des sessions dépendantes d'URL inaccessibles, d'environnements Windows ou de logiciels propriétaires qui ne peuvent pas être conteneurisés.
• Évaluation de la qualité : Utilisation d'un LLM pour filtrer les sessions opaques ou purement exploratoires, ne conservant que les flux de travail de haute qualité et déterministes.
• Résultat : 9 492 enregistrements de haute qualité ont été conservés pour la synthèse.

2. Synthèse des tâches terminales

Les transcriptions brutes sont bruyantes, contenant des fautes de frappe, des tentatives de reprise et des sorties système verbeuses. Le moteur utilise un LLM (par exemple, Claude Sonnet 4.6) pour distiller ces éléments en deux artefacts :

• Formalisation de l'instruction de la tâche : Le LLM infère l'intention sous-jacente du développeur pour générer une instruction orientée vers le résultat. Crucialement, l'instruction spécifie l'état final (par exemple, « enregistrer les adresses IP bloquées dans /app/result.txt ») plutôt que le chemin procédural, empêchant ainsi les indices spécifiques à la solution de fuiter dans la tâche.
• Extraction de la solution de référence : Le LLM extrait un script Bash propre et exécutable de la transcription, supprimant les doublons et les tentatives échouées pour créer une solution de référence de vérité terrain.

3. Reproduction des environnements exécutables

Puisque les enregistrements bruts dépendent de l'état système spécifique du développeur original, le moteur doit inverser l'ingénierie de l'environnement d'exécution.

• Synthèse de l'environnement : Un agent LLM (par exemple, Claude Code) infère les dépendances (images de base, paquets système, temps d'exécution) à partir de la solution de référence pour synthétiser un Dockerfile et un docker-compose.yaml.
• Boucle de raffinement basée sur l'exécution : Pour garantir que l'environnement est fidèle et non halluciné, l'agent construit l'image Docker, tente de rejouer la solution de référence et utilise les échecs d'exécution (par exemple, bibliothèques manquantes, variables non configurées) comme retour d'information pour réparer itérativement le Dockerfile.
• Résultat : Cette boucle reproduit avec succès des environnements exécutables pour 5 035 tâches.

4. Génération de suites de tests

Pour juger automatiquement du succès de la tâche, le moteur génère une suite de tests au sein du conteneur Docker reproduit en utilisant une boucle de raffinement basée sur des essais :

• Synthèse des tests : Un agent génère des assertions basées sur l'instruction formalisée et les changements réels du système de fichiers (deltas d'état) causés par la solution de référence.
• Validation en trois essais :
  1. Essai TousRéussis : Exécute la solution de référence ; tous les tests doivent réussir (assure la résolubilité).
  2. Essai Nop : Ne fait rien ; tous les tests doivent échouer (assure la non-trivialité).
  3. Essais Partiels : Exécute des solutions tronquées/ablatées ; au moins un test doit échouer (assure la discriminabilité par rapport aux solutions incomplètes).
• Résultat : Seules les tâches où la suite de tests réussit les trois essais sont admises. Ce processus produit 1 530 tâches terminales validées pour le benchmark complet.

À partir de cet ensemble complet, les auteurs ont élaboré un sous-ensemble VERIFIÉ de 200 tâches, examiné manuellement par les auteurs pour assurer l'alignement sémantique et la correction, servant de terrain d'essai rigoureux pour les modèles de pointe.

Contributions clés

1. Benchmark TERMINALWORLD : Un ensemble de données de 1 530 tâches validées couvrant 18 catégories réelles (par exemple, orchestration de conteneurs, CI/CD, sécurité) et couvrant 1 280 commandes uniques. Notamment, 91 % de ces commandes sont absentes des benchmarks existants comme Terminal-Bench.
2. Moteur de données automatisé : Un pipeline entièrement automatisé qui inverse l'ingénierie des tâches à partir d'enregistrements réels, garantissant que le benchmark est « authentique et évolutif par construction ».
3. Sous-ensemble VERIFIÉ : Un noyau de 200 tâches vérifiées manuellement conçu pour une évaluation haute fidélité de flux de travail complexes.
4. Évaluation complète : Évaluation extensive de huit LLM de pointe et de six agents terminaux leaders sur le sous-ensemble VERIFIÉ.

Résultats expérimentaux

Les auteurs ont évalué des modèles de pointe (par exemple, Claude Opus 4.7, GPT-5.5, Gemini 3.1 Pro) et des agents (par exemple, Terminus-2, Claude Code, OpenHands) sur le sous-ensemble TERMINALWORLD-VERIFIÉ.

• Plafond de performance : Les systèmes actuels peinent considérablement avec les flux de travail terminaux authentiques. Le modèle le plus performant (Claude Opus 4.7) a atteint un taux de réussite de seulement 62,5 %.
• Paradoxe de l'efficacité : Il existe une faible corrélation négative entre la consommation de ressources (tours, jetons) et le succès. Les modèles dépensent souvent un calcul excessif à explorer des environnements sans faire de progrès. Les tentatives échouées consomment significativement plus de ressources (3,3 fois plus de jetons) que les réussites.
• Spécificité du domaine : La performance varie fortement selon le domaine. Les modèles performent bien sur la configuration de l'environnement (87,5 %) mais peinent avec l'optimisation des performances (28,1 %) et le scripting/automatisation (39,1 %).
• Impact du cadre d'agent : Les cadres d'agents influencent principalement le rapport coût-efficacité plutôt que le plafond de capacité sous-jacent. Par exemple, Terminus-2 et mini-SWE-agent ont atteint des taux de réussite similaires à Claude Code mais à une fraction du coût.
• Faible corrélation avec les benchmarks existants : Les scores sur Terminal-Bench 2.0 ne montrent qu'une faible corrélation (Pearson $r = 0,20$) avec les scores TERMINALWORLD-VERIFIÉ. Les modèles qui dominent les défis curatés par des experts (par exemple, GPT-5.5) sous-performent souvent sur les flux de travail réels, suggérant que les benchmarks existants ne capturent pas pleinement les capacités nécessaires.
• Divergence par rapport aux flux de travail humains : Les agents imitent rarement les chemins de commandes spécifiques des enregistrements humains originaux. Le chevauchement médian des ensembles de commandes entre les trajectoires des agents et les solutions de référence humaines n'est que de 21,4 %, indiquant que les agents résolvent souvent les tâches via des stratégies alternatives valides mais distinctes.

Signification et revendications

L'article revendique que TERMINALWORLD établit une nouvelle norme pour l'évaluation des agents terminaux en passant des puzzles adversariaux curatés par des experts aux flux de travail authentiques, évolutifs et réels.

• Authenticité : En inversant l'ingénierie des tâches à partir d'enregistrements réels de développeurs, le benchmark capture les nuances des dépendances réelles, de la diversité des outils et de la complexité des flux de travail que les benchmarks synthétiques ou manuellement conçus manquent.
• Évolutivité : La nature automatisée du moteur permet au benchmark d'évoluer continuellement à mesure que de nouveaux enregistrements sont téléchargés sur asciinema, empêchant l'ensemble de données de devenir obsolète.
• Valeur diagnostique : Le benchmark révèle que les modèles et agents actuels de pointe manquent de capacités robustes d'utilisation d'outils dans des espaces d'action ouverts et réels. Il met en évidence que des scores élevés sur les benchmarks existants peuvent surestimer la compétence d'un agent dans des environnements terminaux pratiques et évolutifs.

Les auteurs concluent que TERMINALWORLD fournit une base nécessaire pour développer des agents fiables dans des environnements terminaux réels, faisant passer la communauté au-delà des évaluations statiques et curatées par des experts.