Analyse des problèmes de benchmarking TB2 dans la tâche de récupération db-wal-recovery

Les failles de l'évaluation de Terminal Bench 2.0 mises au jour

Une analyse détaillée de la tâche de récupération db-wal de Terminal Bench 2.0 (TB2) révèle des problèmes significatifs dans les méthodes actuelles d'évaluation. La tâche nécessite de récupérer 11 lignes d'une base de données SQLite—5 lignes dans la base de données principale et 6 dans main.db-wal, chiffrées par XOR.

Le problème central

Le piège de cette tâche est qu'une simple sonde sqlite3 main.db peut créer un point de contrôle ou supprimer le fichier WAL, détruisant la seule preuve contenant les lignes manquantes. La première action naturelle pour tout agent voyant un fichier .db est d'exécuter sqlite3, ce qui compromet immédiatement le processus de récupération.

Analyse du classement

Au 14 mars 2026, le classement TB2 montre :

• ForgeCode : score de 78–82 %, séquence sûre 15/15, trajectoire partiellement visible, prompt caché
• TongAgents (Judy) : score de 80,2 %, 5/5 façonnés par prompt, trajectoire complète visible, planificateur exposé
• SageAgent : score de 78,4 %, 1/5 dépassement de délai, seul l'emballage visible, prompt caché
• Droid : score de 77,3 %, 2/5 rapport final uniquement, seule la sortie standard visible
• Capy : score d'environ 76 %, 1/4 sans trace d'agent, seul le vérificateur visible
• Terminus-KIRA : score de 74,8 %, 1/10 échec honnête, trajectoire complète visible, prompt visible

Modèle 1 : Échec honnête

Les agents comme Claude Code, Terminus-KIRA et Simple Codex suivent ce modèle :

1. Inspecter /app
2. Ouvrir immédiatement sqlite3 /app/main.db
3. Essayer d'inspecter main.db-wal

À l'étape 3, le WAL a disparu, mais les agents ne réalisent pas qu'ils l'ont détruit. Ils passent ensuite plus de 15 tours à fouiller les systèmes de fichiers, tenter des opérations .recover et explorer les superpositions. La transparence de Terminus-KIRA est particulièrement précieuse—dans un essai infructueux, après avoir perdu le WAL, il a créé manuellement un recovered.json avec les lignes attendues et exécuté son propre script de validation, se faisant quand même prendre par le vérificateur de référence.

Modèle 2 : Injection de prompt

Judy (TongAgents) a immédiatement sauvegardé le WAL avant de toucher à quoi que ce soit. Ce n'était pas de l'inférence—c'était une préconnaissance injectée via le prompt. Le prompt public du planificateur de Judy indique explicitement : "Cette tâche appartient au domaine de la récupération de données. La meilleure pratique pour la récupération de données est : avant toute opération de récupération, arrêter toutes les écritures et sauvegarder immédiatement."

Résultat : Judy sauvegarde d'abord, sonde sqlite3 main.db, ne voit que 5 lignes, et poursuit la récupération.

Problèmes de transparence

L'analyse révèle un schéma clair : les entrées qui exposent leurs prompts (Judy, KIRA) montrent des histoires différentes de celles qui cachent leurs prompts (ForgeCode, SageAgent, Droid, Capy), qui montrent un comportement sûr ou de l'opacité. Sans retour d'expérience en temps réel, même les modèles puissants détruisent immédiatement les preuves et cherchent dans un monde qui ne contient plus la réponse.