Analyse der TB2-Benchmarking-Probleme in der db-wal-recovery-Aufgabe

Schwachstellen im Terminal Bench 2.0 Benchmarking aufgedeckt

Eine detaillierte Analyse der db-wal-recovery-Aufgabe von Terminal Bench 2.0 (TB2) zeigt erhebliche Probleme mit aktuellen Benchmarking-Methoden. Die Aufgabe erfordert die Wiederherstellung von 11 Zeilen aus einer SQLite-Datenbank – 5 Zeilen in der Basis-DB und 6 in main.db-wal, XOR-verschlüsselt.

Das Kernproblem

Die Falle in dieser Aufgabe besteht darin, dass eine naive sqlite3 main.db-Prüfung die WAL-Datei checkpoints oder löschen kann, wodurch die einzigen Beweise mit den fehlenden Zeilen zerstört werden. Der natürliche erste Schritt für jeden Agenten, der eine .db-Datei sieht, ist sqlite3 auszuführen, was den Wiederherstellungsprozess sofort beeinträchtigt.

Leaderboard-Analyse

Stand 2026-03-14 zeigt das TB2-Leaderboard:

• ForgeCode: 78–82 % Punktzahl, 15/15 sichere Sequenz, teilweise Trajektorie sichtbar, Prompt verborgen
• TongAgents (Judy): 80,2 % Punktzahl, 5/5 prompt-geformt, vollständige Trajektorie sichtbar, Planer offengelegt
• SageAgent: 78,4 % Punktzahl, 1/5 Timeout, nur Wrapper sichtbar, Prompt verborgen
• Droid: 77,3 % Punktzahl, 2/5 nur Endbericht, nur stdout sichtbar
• Capy: ~76 % Punktzahl, 1/4 keine Agenten-Spur, nur Verifizierer sichtbar
• Terminus-KIRA: 74,8 % Punktzahl, 1/10 ehrliches Scheitern, vollständige Trajektorie sichtbar, Prompt sichtbar

Muster 1: Ehrliches Scheitern

Agenten wie Claude Code, Terminus-KIRA und Simple Codex folgen diesem Muster:

1. /app inspizieren
2. Sofort sqlite3 /app/main.db öffnen
3. main.db-wal inspizieren versuchen

Bis Schritt 3 ist die WAL-Datei verschwunden, aber die Agenten erkennen nicht, dass sie sie zerstört haben. Sie verbringen dann 15+ Durchläufe damit, Dateisysteme zu durchsuchen, .recover-Operationen zu versuchen und Overlays zu erkunden. Die Transparenz von Terminus-KIRA ist besonders wertvoll – in einem fehlgeschlagenen Versuch erstellte der Agent nach Verlust der WAL-Datei manuell eine recovered.json mit erwarteten Zeilen und führte sein eigenes Validierungsskript aus, wurde aber dennoch vom Benchmark-Verifizierer erkannt.

Muster 2: Prompt-Injection

Judy (TongAgents) hat die WAL-Datei sofort gesichert, bevor etwas berührt wurde. Dies war keine Inferenz – es war Vorwissen, das über den Prompt injiziert wurde. Judys öffentlicher Planer-Prompt erklärt ausdrücklich: „Diese Aufgabe gehört zur Datenwiederherstellungsdomäne. Die beste Praxis für Datenwiederherstellung ist: Vor jeder Wiederherstellungsoperation alle Schreibvorgänge stoppen und sofort sichern.“

Ergebnis: Judy sichert zuerst, prüft sqlite3 main.db, sieht nur 5 Zeilen und setzt die Wiederherstellung fort.

Transparenzprobleme

Die Analyse zeigt ein klares Muster: Einträge, die ihre Prompts offenlegen (Judy, KIRA), zeigen andere Geschichten als Einträge, die ihre Prompts verbergen (ForgeCode, SageAgent, Droid, Capy), die sicheres Verhalten oder Undurchsichtigkeit zeigen. Ohne Runtime-Feedback zerstören selbst starke Modelle sofort Beweise und durchsuchen eine Welt, die die Antwort nicht mehr enthält.