Агент сказал: «Готово». База данных не согласилась.

Агент сообщает, что задача выполнена. База данных показывает другое. Microsoft описала в блоге Hugging Face систему ThinkingBox: она оценивает агентов не по ответам, а по тому, что они на самом деле изменили в бэкенд-системах.

graph TD
    A[Агент запускает действие] --> B{Вызов инструмента};
    B -- Успешно --> C[Агент сообщает: "Готово"];
    C -- Не проверяет --> D[База данных: Состояние не изменилось / Ошибка];
    D -- Обнаружено ThinkingBox --> F{Расхождение: "Готово" vs "Не готово"};

Расхождение между ожиданием и реальностью: агент сообщил об успехе, но база данных показала ошибку.

Как измерять надежность агентов: Microsoft ThinkingBox

ThinkingBox смотрит, как на самом деле изменилось состояние системы, а не на правильность ответов или вызовов инструментов. Инструмент запускает задачи многократно и проверяет их фактическое выполнение.

Почему инструмент - это не результат

Агент правильно вызвал инструмент - задача выполнена? ThinkingBox показывает обратное. Финальные ответы и валидные вызовы инструментов - это лишь прокси. Агент может звучать правильно, но при этом оставить неверное значение, изменить не ту запись или создать непредусмотренный побочный эффект. Только записи в системе отвечают на вопрос о выполнении задачи.

Microsoft провела 121 680 попыток с 12 LLM, 79 853 попытки провалили исполнительные проверки. Из этих сбоев 67.24% завершились чисто, вызвали инструмент, изменяющий состояние, и не сообщили об ошибках. Большинство проблем кроются не в логике агента, а в его взаимодействии с внешними системами.

graph LR
    A[Общая производительность (Pass@1)] -- Не всегда = --> B[Надежность (Observed 20/20)];
    subgraph Метрики ThinkingBox
        A1[Pass@1: Доля успешных попыток] --> A;
        A2[Pass@20: Хотя бы один успех из 20] --> A;
        A3[Observed 20/20: Все 20 попыток успешны] --> B;
    end
    style A fill:#fff,stroke:#333,stroke-width:2px;
    style B fill:#f9f,stroke:#333,stroke-width:2px;

Разница между однократным успехом (Pass@1) и полной консистентностью (Observed 20/20).

Один успех не значит надежность: метрики Pass@1, Pass@20, Observed 20/20

Надежность агента нельзя измерить одним успешным запуском. ThinkingBox запускает каждую задачу 20 раз из идентичного чистого бэкенда. Важные метрики:

`pass@1`: Доля всех попыток, которые были успешными (насколько хорошо он работает обычно?).
`pass@20`: Доля задач, решенных хотя бы один раз за 20 попыток (может ли он *вообще* это сделать?).
`Observed 20/20`: Задачи, которые фактически прошли все 20 записанных попыток (может ли он *всегда* быть правильным?).

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

Сколько стоит надежность: скрытые затраты на консистентность

Надежность стоит дороже разового успеха. Авторы посчитали (это оценка, а не реальные счета за облако) разницу в стоимости успешной задачи и стоимости *надежной* задачи (той, которая проходит все 20/20 попыток).

Самая дешевая надежная задача у GPT-5.4: $6.80, но таких задач у него всего 128.
Claude Opus 5.5 достигает наибольшего количества надежных задач (241) по цене $7.80.

Самый дешевый способ получить правильный ответ - не самый дешевый способ получить надежный ответ. В 79.9% случаев сбои агентов связаны с обработкой инструментов, а не с логикой.

pie title Причины сбоев AI-агентов
    "Обработка инструментов" : 79.9
    "Некорректное обновление состояния" : 10.3
    "Незавершенные действия пользователя" : 7.0
    "Отсутствие действия, изменяющего состояние" : 2.9

Основные причины сбоев AI-агентов: проблема инструментов, а не логики.

Причины сбоев: чаще инструмент, чем логика

Примерно четыре из пяти сбоев связаны с обработкой инструментов, а не с логикой рассуждений. Агенты обычно доходят до этапа выполнения рабочего процесса, а затем не могут восстановиться после ошибок инструментов, невыполненных предусловий или пустых поисковых запросов. Это проблема повторных попыток и восстановления после ошибок, прежде чем это станет проблемой самой модели. Сложности значительно различаются в зависимости от домена: розничная торговля в среднем показывает 59.52% `pass@1`, в то время как автострахование - всего 33.83%.

Применить у себя

Что проверить на практике

Внедрить проверку конечного состояния: Проверяйте конечное состояние системы перед фиксацией изменений, а не полагайтесь на успешный вызов инструмента. Это может быть сверка с базой данных, проверка файлов или состояния API.
Использовать метрики надежности: Кроме однократного успеха (`pass@1`) смотрите на консистентность (`Observed 20/20`), особенно в критически важных задачах. Это позволит понять, насколько агент предсказуем.
Анализировать доменные особенности: Учитывайте, что производительность агента может сильно варьироваться в зависимости от предметной области. Тестируйте агентов на реальных данных и сценариях вашего домена.
Фокусироваться на обработке ошибок: Разрабатывайте механизмы повторных попыток и восстановления после ошибок инструментов. Большинство сбоев агентов происходит именно на этом этапе.

Как понять, что получилось

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

Источники

Microsoft ThinkingBox: The Agent Said It Was Done. The Database Disagreed.