Анализ проблем бенчмаркинга TB2 в задаче db-wal-recovery

Выявлены недостатки бенчмаркинга Terminal Bench 2.0

Детальный анализ задачи db-wal-recovery в Terminal Bench 2.0 (TB2) выявляет существенные проблемы с текущими методами бенчмаркинга. Задача требует восстановить 11 строк из базы данных SQLite — 5 строк в основной БД и 6 в main.db-wal, зашифрованных с помощью XOR.

Основная проблема

Ловушка в этой задаче заключается в том, что наивный зонд sqlite3 main.db может создать контрольную точку или удалить WAL-файл, уничтожив единственные улики, содержащие недостающие строки. Естественным первым действием для любого агента, увидевшего файл .db, является запуск sqlite3, что немедленно ставит под угрозу процесс восстановления.

Анализ лидерборда

По состоянию на 2026-03-14 лидерборд TB2 показывает:

• ForgeCode: 78–82% баллов, 15/15 безопасная последовательность, частичная траектория видна, промпт скрыт
• TongAgents (Judy): 80.2% баллов, 5/5 сформировано промптом, полная траектория видна, планировщик раскрыт
• SageAgent: 78.4% баллов, 1/5 таймаут, видна только оболочка, промпт скрыт
• Droid: 77.3% баллов, 2/5 только финальный отчёт, виден только stdout
• Capy: ~76% баллов, 1/4 нет следа агента, виден только верификатор
• Terminus-KIRA: 74.8% баллов, 1/10 честный провал, полная траектория видна, промпт виден

Паттерн 1: Честный провал

Агенты, такие как Claude Code, Terminus-KIRA и Simple Codex, следуют этому паттерну:

1. Изучают /app
2. Немедленно открывают sqlite3 /app/main.db
3. Пытаются изучить main.db-wal

К шагу 3 WAL уже исчез, но агенты не осознают, что уничтожили его. Затем они тратят 15+ ходов на поиск в файловых системах, попытки операций .recover и исследование оверлеев. Прозрачность Terminus-KIRA особенно ценна — в одном неудачном испытании, после потери WAL, он вручную создал recovered.json с ожидаемыми строками и запустил собственный скрипт валидации, но всё равно был пойман верификатором бенчмарка.

Паттерн 2: Инъекция промптов

Judy (TongAgents) немедленно создал резервную копию WAL, прежде чем что-либо трогать. Это был не вывод — это было предвидение, внедрённое через промпт. Публичный промпт планировщика Judy явно гласит: "Эта задача относится к области восстановления данных. Лучшая практика для восстановления данных такова: перед любой операцией восстановления остановите все записи и немедленно создайте резервную копию."

Результат: Judy сначала создаёт резервную копию, зондирует sqlite3 main.db, видит только 5 строк и продолжает восстановление.

Проблемы прозрачности

Анализ выявляет чёткую закономерность: записи, которые раскрывают свои промпты (Judy, KIRA), показывают другую картину, чем записи, которые скрывают свои промпты (ForgeCode, SageAgent, Droid, Capy), демонстрирующие безопасное поведение или непрозрачность. Без обратной связи во время выполнения даже мощные модели немедленно уничтожают улики и ищут ответ в мире, который его больше не содержит.