Прямой ответ: успешная демонстрация ничего не доказывает о надёжности ИИ-агента, потому что правильный вопрос не в том, выполнил ли он задачу один раз, а в том, выполняет ли он её правильно каждый раз. В исследовании, которое Microsoft опубликовала 20 августа 2026 года, самая сильная модель набрала 65,36% при однократном запуске каждой задачи, но прошла все двадцать попыток лишь в 25,25% задач. Этот разрыв и есть расстояние между агентом, который впечатляет вас на встрече, и агентом, которому можно доверить данные клиентов.

Что на самом деле создала Microsoft

Инструмент называется Thinkingbox — это тестовая среда с открытым исходным кодом, выпущенная под лицензией MIT на GitHub. Идея проста и остроумна: вместо того чтобы подключать инструменты напрямую к агенту, вы описываете их как MCP-совместимые серверы, запускаете агента в изолированной сессии с собственной базой данных и записываете полную трассу выполнения.

Главное — в том, как выставляется оценка. Фреймворк не читает, что агент, по его словам, сделал; он проверяет, что на самом деле изменилось в базе данных после завершения задачи. Это различие — не техническая мелочь. Агенты отлично умеют писать убедительное резюме работы, которой никогда не было, и любая оценка по стенограмме диалога измеряет качество текста, а не качество выполнения.

На основе этой среды команда создала бенчмарк Thinkingbox-bench, включающий 507 рабочих процессов, подчинённых политикам, в пяти областях: розничная торговля и электронная коммерция, путешествия и гостеприимство, автострахование, внутренняя ИТ-поддержка в необанке, а также ИТ- и HR-поддержка в консалтинговой фирме. Каждая задача запускалась двадцать раз на двенадцати моделях, как проприетарных, так и с открытыми весами.

Почему эта цифра важна для владельца бизнеса

Представьте, что вы поручили агенту обработку заявок на возврат в вашем магазине. Доля успеха 65% на бумаге выглядит приемлемо. На практике это означает, что треть заявок завершается неверным результатом: возврат денег, выплаченный дважды, заказ, закрытый без возврата товара на склад, или исключение, сделанное для клиента, которому ваша политика его не разрешает.

Хуже того, сбои в этом исследовании не были очевидными аварийными остановками. В статье прямо говорится, что многие сбои завершались чисто и включали шаги, выглядевшие корректными, тогда как итоговое состояние системы всё равно было неверным. Ни сообщения об ошибке, ни остановки, ничего, что загорелось бы на панели мониторинга. Лишь журнал, который читается как обычно, и данные, которые незаметно стали неверными.

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

Это объясняет и распространённый источник разочарования. Пилот проходит успешно, потому что он выполнил задачу один раз на чистых данных. Реальная работа — это та же задача тысячи раз на запутанном накопленном состоянии, и именно там проявляется разница между 65% и 25%.

Что сделать перед внедрением любого агента

  • Требуйте повторных запусков, а не одной демонстрации. Сделайте критерием приёмки двадцать последовательных запусков одной и той же задачи на одних и тех же данных. Поставщик, который отказывается, тем самым кое-что вам сообщает.
  • Измеряйте состояние данных, а не текст ответа. Заранее определите, как должна выглядеть запись в вашей базе данных после выполнения задачи, и сравнивайте с этим реальность. Не довольствуйтесь чтением собственного резюме агента.
  • Тестируйте политики, а не только простые задачи. Большая часть вашей работы не свободна; она ограничена правилами: сроками возврата, кредитными лимитами, исключениями для приоритетных клиентов. Агент, который успешен без ограничений, может провалиться при первом же реальном условии.
  • Составьте тестовый набор из собственных случаев. Возьмите двадцать реальных случаев за последние месяцы, включая странные, которые сбивали с толку ваших сотрудников, и превратите их в фиксированный набор тестов, который вы прогоняете на любой модели перед внедрением и после каждого обновления.
  • Предоставляйте полномочия поэтапно. Начните с агента, который предлагает, но не выполняет, затем позвольте ему выполнять операции с низким уровнем влияния, а потом расширяйте его полномочия по мере накопления реальной истории измерений. Полномочия нужно зарабатывать данными, а не впечатлениями.

Как мы подходим к этому в Origami

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

Главный вывод из этого исследования не в том, что агенты непригодны. А в том, что мерило, которым мы их оценивали, было неверным. Сегодняшние агенты — мощные инструменты в пределах чётко определённой и постоянно измеряемой области и очень слабые, когда им передают чувствительный процесс на основании убедительной демонстрации. Разница не в модели, а в инженерной дисциплине вокруг неё.

Источники