«Агент сказал, что всё сделано. База данных не согласилась»: Microsoft и Hugging Face выпустили ThinkingBox

Что выпустили Microsoft и Hugging Face

3 октября 2026 года на Hugging Face вышел совместный блог Microsoft и Hugging Face о ThinkingBox. Это не чат-модель и не набор промптов, а среда и бенчмарк: агент работает с инструментами, а оценка идёт по терминальному состоянию бэкенда и побочным эффектам, которые он после себя оставил. Сама публикация описывает ThinkingBox как «песочницу» для агентов, а ThinkingBox-Bench — как датасет-бенчмарк для их оценки. Полные детали, включая ablation-таблицы и приложение с разбором трассировок, вынесены в статью arXiv:2608.19741.

Авторы приводят пример из розничного сценария: клиентке пятнадцать дней не доставляют кухонную технику за $745, груз застрял в статусе «исключение» на складе в Нэшвилле. Агент делает девять вызовов инструментов — вытаскивает заказ, проверяет трекинг, смотрит профиль, дважды ищет правила возврата, заводит тикет и разбирает хронологию — и по правилам компенсация ей действительно не положена. После этого он закрывает тикет со статусом resolved и пишет, что запрос решён. Ошибок две: перевозчик всё ещё в статусе «исключение», то есть требуемое конечное состояние — on hold, а клиентка так и не получила ответа на свой реальный вопрос. Именно этот разрыв ThinkingBox и измеряет.

По описанию авторов, каждая задача задаёт стартовое состояние бэкенда, цель пользователя, доступные MCP-инструменты, политику домена и исполняемые проверки над итоговым состоянием; смоделированный пользователь держит приватный контекст и выдаёт его только по запросу. Каждая попытка получает изолированную MCP-сессию со свежим состоянием, поэтому двадцать прогонов одной задачи сопоставимы между собой. 477 из 507 задач оцениваются только по состоянию, ещё 30 добавляют рубрику по ответу. Описание окружения ThinkingBox опубликовано в документации OpenEnv.

Вызов инструмента — это не результат

Главный вывод блога: финальные ответы и корректные вызовы инструментов — лишь прокси. Агент может звучать правильно и при этом оставить неверное значение, изменить не ту запись или создать лишний побочный эффект. В ablation-эксперименте на общем наборе из 121 680 валидных попыток и 12 моделей 79 853 попытки провалили исполняемые проверки. Из этих провалов 67,24% всё равно завершились чисто: вызвали изменяющий состояние инструмент и не сообщили об итоговой ошибке инструмента.

Исполняемые проверки нашли конкретику: неверные значения полей — в 77,61% случаев, непреднамеренные дополнительные эффекты — в 43,30%, отсутствующие обязательные эффекты — в 25,36%. Эти находки пересекаются между собой. Формулировка авторов звучит так: траектория — это утверждение, состояние базы данных — доказательство, а повторение — проверка на доверие.

Одного успеха мало: зачем двадцать прогонов

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

Охват и надёжность расходятся

По pass@1 лидирует Claude Opus 5.5 — 67,16% в целом по 507 задачам, на две трети процентного пункта выше Claude Opus 5. Сильнейшая открытая модель — Kimi-K3, отстающая от GPT-6 Astra меньше чем на пункт. Домен при этом решает почти всё: Claude Opus 4.6 берёт 68,62% в ретейле и только 8,30% в автостраховании.

Настоящая картина проявляется на повторах. Kimi-K3 решает хотя бы раз 93,89% бенчмарка — 476 задач из 507, это лучший охват в поле, а в ретейле он первый с 82,24%. Но все двадцать попыток он проходит лишь на 68 задачах из 507, то есть на 13,41%. Claude Opus 5 устроен наоборот: хотя бы раз он решает 79,09% задач, зато 47,53% бенчмарка проходит на каждой попытке. Более новая модель эту проблему не лечит: Claude Opus 5.5 выше по средней за все попытки, но проходит все двадцать попыток ровно на том же числе задач, что и Opus 5 — 241.

Если смотреть, насколько модель удерживает свой результат за двадцать повторов, картина такая: GPT-6 Astra сохраняет 78% от своего pass@1, Claude Opus 5.5 и Claude Opus 5 — по 71%, а GLM-5.1, Kimi-K2.6 и DeepSeek-V4-Pro — примерно по 8%.

Сколько стоит надёжность

Авторы посчитали стоимость успешной попытки: цену полного набора из 507 попыток они разделили на число успешных. Дешевле всех по стоимости одного успеха оказался GPT-5.6 Sol — $0,127; GPT-5.4 добавляет 3,45 процентного пункта к pass@1 за $0,004 и стоит $0,131 за успех; Claude Opus 5.5 — $0,276. При этом GPT-5.4 обходится в $43,49 за 507 попыток при pass@1 65,36%, что и даёт $0,131 на успешную попытку.

Отдельно считается стоимость надёжной задачи — цена полной кампании из двадцати прогонов, делённая на число задач, пройденных 20/20. Здесь дешевле всех GPT-5.4 — $6,80, хотя планку держат лишь 128 задач; GPT-6 Astra доходит до 231 задачи за $7,45; Claude Opus 5.5 делит первое место по числу задач (241) за $7,80. Claude Opus 5 тоже проходит 241 задачу, но уже за $13,30, поэтому Opus 5.5 доминирует над ним напрямую. Вывод авторов прост: самый дешёвый правильный ответ — не самый дешёвый надёжный.

Подписи отказов

Каждой провальной траектории авторы присвоили одну детерминированную подпись. Приблизительно четыре из пяти отказов — это работа с инструментами, а не рассуждение. Доли такие: использование инструментов — 79,9%, неверные обновления состояния — 10,3%, неполное решение пользовательской задачи — 7,0%, отсутствие изменяющего состояние действия — 2,9%.

Практический вывод: агенты обычно успевают начать рабочий процесс, но не восстанавливаются после ошибок инструментов, невыполненных предпосылок или пустых выборок. То есть это в первую очередь проблема повторов и восстановления после сбоев, а не проблема модели. Сложность зависит и от домена: в среднем по приведённым моделям ретейл даёт 59,52% pass@1, а автострахование — 33,83%.

Как это запустить

ThinkingBox-Bench стоит за интерфейсом OpenEnv, и каждый завершённый эпизод возвращает бинарную награду pass/fail. Для запуска нужны Linux или WSL, Python 3.11+, uv и Docker, а также checkout thinkingbox-data на закреплённом релизе и эндпоинты моделей для агента, смоделированного пользователя и судьи — один эндпоинт может обслуживать все три роли. Сервер OpenEnv поднимает только API, остальное запускается вручную; готовность отдаёт 503, пока не пройдут проверки данных, конфигурации и Session Proxy.

Код ThinkingBox распространяется по лицензии MIT, данные бенчмарка — по CDLA-Permissive-2.0, а окружение OpenEnv — по BSD-3-Clause. Отдельно авторы оговаривают, что каждая задача публичного бенчмарка — синтетическая реконструкция: рабочие процессы и политики смоделированы по реальным корпоративным паттернам, но клиенты ненастоящие.