ИИ-агенты пока часто выглядят убедительно в контролируемых тестах: модель получает чёткую задачу, вызывает один инструмент и выдаёт ожидаемый результат. В рабочей системе сценарий сложнее. Агенту приходится учитывать состояние сервисов, права пользователей, неполные сведения, зависимые действия и ошибки API.
Именно этот разрыв между демонстрацией и эксплуатацией изучают Meta и Hugging Face в проекте OpenEnv. В публикации Hugging Face Blog от 12 февраля 2026 года описан практический эксперимент с календарным окружением, созданным компанией Turing. Авторы проверяли не только способность модели выбрать правильный инструмент, но и её устойчивость в длинной последовательности операций.
OpenEnv переносит оценку из симуляции в рабочие сценарии
OpenEnv задуман как открытая инфраструктура для проверки агентов в средах, которые сохраняют состояние и могут подключаться к реальным инструментам и API. Вместо изолированного вопроса «смогла ли модель вызвать нужную функцию» разработчики получают более прикладной тест: сможет ли агент последовательно выполнить задачу, не потерять контекст и корректно восстановиться после ошибки.
Среда использует интерфейс, ориентированный на Gymnasium: агент может сбросить окружение, выполнить действие и получить наблюдение. Для подключения инструментов применяется стандартный интерфейс MCP. Такой подход должен упростить сравнение разных агентов и сценариев — от браузеров и репозиториев кода до календарей.
Исходный материал с описанием архитектуры и эксперимента опубликован в Hugging Face Blog. Код и материалы самого проекта доступны через репозиторий OpenEnv на GitHub. Эти ссылки описывают инфраструктуру с разных сторон: первая — результаты и постановку эксперимента, вторая — программную основу.
Почему календарь оказался сложнее обычного вызова API
Календарь кажется простым примером для автоматизации: создать встречу, изменить время или найти свободный слот. Однако в реальном сервисе агент должен учитывать, к какому календарю относится событие, какие записи видит текущий пользователь, разрешено ли ему вносить изменения и какие действия необходимо выполнить до публикации результата.
Для проверки Turing создала Calendar Gym — изолированное окружение с операциями над календарями, событиями и разрешениями. Агент может сначала запросить доступные инструменты, затем получить список видимых календарей, создать событие или изменить права доступа. Ошибка на раннем шаге влияет на следующие операции: неверный идентификатор календаря или отсутствие разрешения делают последующие вызовы бессмысленными.
Материалы окружения опубликованы в репозитории Calendar Gym на Hugging Face. В качестве примера авторы показывают последовательность, в которой клиент OpenEnv сбрасывает среду, получает список инструментов, запрашивает календари и создаёт встречу. Для разработчика это важное отличие от статического теста: результат зависит от текущего состояния среды и истории предыдущих действий.
Длинные цепочки стали главным источником ошибок
По данным эксперимента, агенты сравнительно уверенно справлялись с отдельными действиями, когда задача была сформулирована явно. Надёжность снижалась по мере роста числа зависимых шагов. Модели могли выбрать правильную операцию, но неправильно передать аргументы, перепутать порядок вызовов или продолжить работу после неудачного ответа, не проверив состояние системы.
Авторы выделяют несколько повторяющихся ограничений.
Во-первых, агенту трудно удерживать план на протяжении длинной последовательности. Успешный одиночный вызов не означает, что модель сможет завершить весь рабочий процесс. В календарном сценарии необходимо сначала определить доступный ресурс, затем выбрать нужный календарь, сформировать корректные параметры события и проверить результат.
Во-вторых, неоднозначные формулировки заметно ухудшали результат. Когда в запросе прямо указывался идентификатор календаря, доля успешных задач, по данным публикации, была близка к 90%. При описании того же объекта естественным языком она снижалась примерно до 40%. Это не означает, что любой агент будет показывать такие же значения в другом окружении: цифры относятся к описанному авторами тесту и его набору задач.
В-третьих, правильный выбор инструмента не гарантирует корректное выполнение. Более половины зафиксированных ошибок, согласно материалу, были связаны с неверными аргументами или неправильным порядком действий. Следовательно, оценивать нужно не только маршрутизацию запроса к нужной функции, но и проверку схемы, обработку ответа и восстановление после сбоя.
Что этот тест меняет для разработчиков агентов
OpenEnv предлагает проверять агента в условиях, которые ближе к реальной эксплуатации: с частичной видимостью данных, контролем доступа и изменяемым состоянием. Это особенно важно для систем, которым разрешают действовать от имени пользователя. В такой конфигурации ошибка может заключаться не в «неправильном ответе» модели, а в лишнем изменении, обращении к недоступному объекту или пропуске обязательной проверки.
Практический вывод для разработчиков — добавить в контур агента явные проверки. Перед вызовом инструмента следует валидировать обязательные поля и идентификаторы, после действия — проверять наблюдение среды, а при отказе в доступе не подменять результат догадкой. Для неоднозначных запросов полезнее сначала выполнить поиск и уточнение объекта, чем поручать языковой модели угадывать ссылку на него.
Calendar Gym также показывает, почему тесты только на финальный ответ недостаточны. Агент может сформулировать правдоподобное сообщение о созданной встрече, хотя API отклонил запрос или событие попало не в тот календарь. В рабочих системах нужно фиксировать последовательность действий, результаты промежуточных вызовов и фактическое состояние среды после завершения задачи.
Что пока нельзя считать доказанным
Публикация описывает один класс окружений и результаты, приведённые авторами проекта. Из них нельзя напрямую вывести, что OpenEnv решает проблему надёжности ИИ-агентов или что конкретная модель будет одинаково работать с почтой, браузером и корпоративными базами данных.
Неясно и то, насколько результаты зависят от состава задач, настроек агентов и конкретных моделей. Поэтому приведённые показатели стоит воспринимать как сигнал о характере ошибок, а не как универсальный рейтинг технологий. Для сравнения систем разработчикам потребуется запускать одинаковые сценарии в изолированных средах, повторять их после изменений и отдельно учитывать стоимость неудачных действий.
Для читателя, который оценивает агентную платформу, полезно проверить три вещи: сохраняет ли тест состояние между вызовами, моделирует ли он реальные права доступа и показывает ли ошибки промежуточных операций. Если проверяется только один вызов инструмента или заранее подготовленная симуляция, такой результат ещё не говорит о готовности агента к работе в production-системе.
