Проверяйте стабильность работы AI-агентов: ThinkingBox

Лид: зачем это полезно и как быстро запустить

ThinkingBox — среда и бенчмарк для проверки AI‑агентов в задачах, где важен конечный статус записей в базе данных. Ключевая идея: проверяйте не текст ответа агента, а реальные изменения в системе — именно они решают задачу клиента. Для воспроизводимых сравнений каждый сценарий прогоняют 20 раз с чистой тестовой базой, чтобы отличить единичный успех от стабильной работы.

Практическая польза понятна: если агент закрывает тикет, но не меняет статус в базе, внешний вид диалога может вводить в заблуждение. ThinkingBox показывает такие расхождения и помогает принимать архитектурные решения: требовать подтверждения состояния, внедрять обработку ошибок инструментов и отдавать критичные изменения на ручную проверку. Для запуска окружения в примерах используется CLI tb; например, старт сессий MCP выполняется командой tb mcp-start — она важна, если хотите воспроизвести кейсы локально через OpenEnv.

Что именно измеряет ThinkingBox

Среда оперирует набором задач с заранее заданным начальным состоянием бэкенда, доступными «инструментами» (tool calls) и формальными проверками требуемого конечного состояния. «Tool call» здесь — вызов внешнего инструмента или API; «MCP» — прокси для таких инструментов, через который тесты получают изолированные сессии.

Каждую задачу запускают 20 раз на той же модели агента, но с новой базой. Итоговые изменения в базе и побочные эффекты извлекаются детерминированно и сверяются с требуемым результатом. Метрики: pass@1 (доля успешных попыток среди всех запусков), pass@20 (решаемость задачи хотя бы в одном из 20 запусков) и observed 20/20 — число задач, которые модель прошла во всех 20 повторных запусках.

Таким образом ThinkingBox отвечает на три вопроса: умеет ли модель вообще выполнить задачу; может ли она сделать это иногда; и делает ли она это всегда. Это помогает отделить «может» от «можно доверять в продакшене».

Главные выводы и практические последствия

Первый вывод: наличие корректных вызовов инструментов и «правильного» финального текста не гарантирует, что состояние бэкенда изменилось верно. В экспериментах многие запуски выглядели успешными в логах инструментов и в ответах агента, но не прошли исполнимые (executable) проверки по базе.

Вторая вещь — повторяемость. Один удачный прогон не значит стабильность. Авторы запускают каждый сценарий 20 раз и показывают, что у одних моделей большие показатели «сделает хотя бы раз», у других — выше доля задач, где все 20 попыток завершаются верно. При выборе модели для работы с реальными записями имеет смысл смотреть не на pass@20, а на observed 20/20 или на другие метрики повторяемости.

Третье: большинство сбоев связано не с «мыслящей» частью модели, а с обработкой инструментов: ошибки инструментов, неправильные предусловия или пустые результаты поиска. Авторы классифицируют сигнатуры ошибок и отмечают, что примерно четыре из пяти провалов относятся к взаимодействию с инструментами — это задача ретраев и обработки ошибок, а не исключительно улучшения LLM.

Экономика надежности: стоимость успеха и стоимость надёжности

Чтобы учесть затраты, ThinkingBox оценивает «стоимость за успешную попытку» и «стоимость за надёжную задачу». Первая метрика — отношение предполагаемой цены токенов за набор прогонов к числу успешных попыток; вторая — цена за кампанию из 20 прогонов, делённая на число задач, которые модель прошла во всех 20 прогонках.

Вывод практический: модель с низкой стоимости за единичный успех может оказаться дороже на единицу стабильного результата, потому что добиваться 20/20 надёжности приходится многократно. Для инжиниринга это означает: при планировании бюджета и SLA учитывайте цену не только за «средний» ответ, но и за проверенную и повторяемую смену состояния.

Как запускать и воспроизводить тесты

ThinkingBox и данные ThinkingBox‑Bench доступны через Hugging Face и OpenEnv. Окружение собирается из нескольких компонентов: OpenEnv, тестовый набор microsoft/thinkingbox-data, сервис Typesense и MCP-серверы. Авторы дают примерные команды установки и запуска, включая установку CLI tb и последовательный старт Typesense и MCP.

Одна из команд, которую используют в инструкции для оценки эпизода: uv run --project envs/thinkingbox_env thinkingbox-eval one_task.yaml --config thinkingbox.yaml --repeat 1 — она выполняет проверку одного задания и сохраняет результаты. OpenEnv‑адаптер возвращает бинарный результат (pass/fail) и отдельный файл с операционными ошибками, чтобы можно было повторно прогонять только инфраструктурные сбои.

Рекомендации по внедрению в продакшен

Используйте сигнал terminal state: проверяйте конечное состояние перед фиксацией транзакции, а не полагайтесь на текстовую самопроверку агента. Классифицируйте ошибки инструментов и делайте таргетированные ретраи и компенсации только для восстановимых случаев.

Уменьшайте поверхность инструментов — ограничьте список внешних вызовов до необходимых для конкретного рабочего потока. Для критичных изменений вводите человеческий контроль там, где откат дорог или невозможен.

Наконец, валидация: воспроизведите один проблемный сценарий у себя через OpenEnv и посмотрите реальные изменения в базе — это даёт диагностический материал для улучшения обработчиков ошибок.

Ограничения и что важно учитывать

Все публичные задачи в бенчмарке — синтетические реконструкции рабочих процессов и политик. Они смоделированы по реальным паттернам, но не отражают конкретных живых пользователей. Следовательно, показатели показывают относительную картину, полезную для сравнения моделей и практик, но не подменяют стресс‑тесты на ваших собственных данных.

Результаты зависят от выбранных моделей, тарифов и конфигураций endpoints; авторам использовались конкретные цены и наборы точек доступа для сравнения, что даёт сравнительный индекс, а не счёт в реальном биллинге. Кроме того, метрика стабильности (k/20) — полезный дизайн‑ввод, но нужно выбирать k, который соответствует вашим SLA.

Куда смотреть дальше

Полезная часть проекта — не только лидерборд, а сама среда тестирования. Если вы строите систему, которая меняет реальные записи, повторяемые и исчерпывающие проверки в тестах помогут выявить слабые места интеграции и обработчиков ошибок до инцидента.

Репозитории и документация доступны через Hugging Face и GitHub: ThinkingBox как среда, ThinkingBox‑Bench как набор заданий и OpenEnv‑адаптер для запуска. Авторы предлагают воспроизводить отдельные сценарии и отчётно фиксировать, как часто система должна быть «правильной» — определите свой k и укажите, считается ли это best‑of‑k или every‑of‑k.