AI-агент может корректно вызвать API, написать убедительный итоговый ответ и при этом не выполнить задачу в системе, ради которой был запущен. Эту проблему разбирает ThinkingBox — бенчмарк Microsoft и Hugging Face для оценки агентов в сценариях с изменяемым состоянием. Вместо качества финального текста он проверяет записи в бэкенде и побочные эффекты: изменились ли нужные поля, создан ли необходимый объект, не появились ли лишние действия. В совместной публикации Microsoft и Hugging Face этот принцип сформулирован прямо: валидный вызов инструмента не равен достигнутому результату.

Показательный сценарий связан с обращением клиента по поводу задержанной доставки кухонного прибора стоимостью 745 долларов. Агент последовательно получил сведения о заказе, проверил отслеживание, профиль и правила компенсации, не нашёл существующего обращения и создал новое. Он верно определил, что клиенту не положена компенсация за задержку. Но затем система закрыла тикет как решённый, хотя исключение у перевозчика оставалось открытым. Правильным конечным состоянием был статус ожидания. Как следует из описания тестового случая, ошибка свелась к значению в записи, а не к качеству рассуждения или форме девяти вызовов инструментов.

Почему успешный запуск не означает надёжность.

ThinkingBox разделяет несколько часто смешиваемых метрик. Pass@1 показывает вероятность выполнения задачи в одной попытке. Охват задач хотя бы одним успехом отвечает на другой вопрос: способен ли агент иногда найти рабочий путь. Наконец, серия из 20 одинаковых запусков с чистого состояния измеряет воспроизводимость. В сводке результатов, опубликованной daily.dev, говорится о 507 бизнес-процессах из ритейла, автострахования, путешествий, необанкинга и консалтинга, протестированных на 18 LLM. Набор данных и harness, по этим сведениям, доступны для воспроизведения.

Разница между единичным успехом и стабильной работой особенно существенна для операций, где ошибка меняет данные клиента, статус заявки или финансовую запись. Авторы приводят пример Kimi-K3: модель решала хотя бы раз 93,89% задач, но выполняла все 20 запусков без ошибки только в 13,41% случаев. Claude Opus 5 и Claude Opus 5.5, по приведённым результатам, завершали без ошибок все 20 попыток в 241 из 507 задач. Это не означает универсального превосходства моделей вне данного набора сценариев, но показывает ограниченность одной метрики pass@1 при выборе модели для автономного процесса.

Проверка конечного состояния обнаруживает и менее заметную проблему — «чистые» сбои. В абляции на 121 680 валидных испытаниях 12 моделей 67,24% неуспешных запусков завершились без финальной ошибки инструмента и включали хотя бы одно изменяющее состояние действие. При этом исполняемые проверки находили неправильные значения полей в 77,61% таких случаев, непредусмотренные эффекты — в 43,30%, а отсутствующие обязательные эффекты — в 25,36%; категории могут пересекаться. Разбор FourWeekMBA отдельно уточняет, что опубликованные оценки стоимости основаны на тарифах, использованных авторами бенчмарка, а не на универсальной цене внедрения.

Основной риск лежит в работе с инструментами.

Согласно данным ThinkingBox, на обработку инструментов приходится 79,9% диагностированных неудач, на некорректные обновления состояния — 10,3%, на неполное разрешение запроса пользователя — 7%, на отсутствие изменяющего действия — 2,9%. Это смещает инженерный фокус. Проблема не всегда в том, что модель не поняла задачу: она может дойти до верной последовательности шагов, неверно обработать ответ API, не восстановиться после частичной ошибки или подтвердить выполнение до контрольного чтения из системы.

Техническая конструкция бенчмарка рассчитана на то, чтобы агент не влиял на оценку собственного результата. Как описывает обзор HyperAI, сессии изолированы друг от друга, извлечение состояния детерминировано, а учётные данные для проверки отделены от контура агента. Это не независимый аудит заявленных результатов, а описание той же методики, но оно проясняет ключевое требование: проверяющий компонент не должен доверять логам и декларации агента о завершении работы.

Такой подход применим не только к базам данных. В отдельном проекте VASB агенту предлагается создать файл с точно заданным содержимым и не затронуть другие файлы; проверка сравнивает итоговую файловую систему с условиями задания. В описании VASB статус DONE прямо отделён от факта выполнения. Общий принцип для CRM, биллинга, файловых хранилищ и внутренних API один: текстовый отчёт агента — это свидетельство намерения, а не доказательство результата.

Как применять выводы в продукте.

Командам, внедряющим AI-агентов, полезно строить завершение процесса как проверяемое утверждение. После действия агент должен передавать идентификаторы созданных или изменённых сущностей, а отдельный контур — читать систему учёта и сопоставлять фактическое состояние с инвариантами задачи. В обсуждении практики на форуме r/AI_Agents участники предлагают именно такую двухэтапную схему для операций возврата: подтверждать результат независимым запросом к биллинговому провайдеру. Это пользовательский опыт, а не результат исследования, однако он совпадает с логикой ThinkingBox.

  • Определяйте для каждой операции наблюдаемые условия успеха: статус, сумму, идентификатор, список допустимых побочных эффектов.
  • Разделяйте выполнение и верификацию: агент не должен быть единственным источником сведений о собственном результате.
  • Тестируйте не только единичный успех, но и повторяемость сценария из одинакового начального состояния.
  • Считайте стоимость с учётом повторных запусков, проверки и передачи спорных случаев человеку.

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