Лучший ИИ-агент решил лишь 60% облачных задач DevOps, 80% провалов — из-за логики

Представьте, что вы просите ИИ-агента закрыть доступ уволившемуся сотруднику в AWS. Опытный инженер проверит пользователей, роли, ключи и сервисные аккаунты. Агент может отключить одну учётную запись, отчитаться «готово» и оставить открытыми другие пути входа. Именно такие провалы показал CloudOpsBench — новый открытый бенчмарк, то есть набор стандартных задач для сравнения моделей. Лучшая из протестированных моделей, Claude Fable 5.1, решила только 60% задач, а GPT-6 Astra — 53%. Около 80% неудач связаны не с тем, что модель не знает облако, а с тем, что она плохо рассуждает: неверно оценивает масштаб работы, не проверяет все нужные сервисы или останавливается слишком рано. Если вы думаете отдать агенту операции с облачной инфраструктурой, эти цифры подсказывают, где ставить защиту.

Что проверяет CloudOpsBench

Бенчмарк создала команда под руководством Анга Чена из Мичиганского университета. Версия 1.0 включает 45 задач на AWS, которые написали опытные DevOps-инженеры. Набор охватывает типичную работу: починить сервис, удалить ресурсы, ограничить права доступа, выкатить обновление и вывести проект из эксплуатации.

Каждая задача выполняется одинаково в реальном облаке AWS и в эмуляторе. Эмулятор удобен для повторяемых прогонов без риска для настоящей инфраструктуры. Проект опубликован на GitHub под лицензией Apache 2.0, к нему приложен подробный разбор ошибок. Расширения для GCP, Azure и OCI (Oracle Cloud Infrastructure) запланированы.

Где ломаются агенты

Даже лидер проваливает заметную часть заданий: у Claude Fable 5.1 это 60% успеха, у GPT-6 Astra — 53%. Ни одна модель не справилась со всеми задачами. По словам авторов, в большинстве случаев узкое место — именно рассуждение.

Примерно 80% неудач укладываются в три сценария:

• агент неверно оценивает объём задачи;
• не проверяет все связанные сервисы;
• останавливается раньше, чем работа закончена.

Это ровно история с доступом уволенного сотрудника: команды агент знает, но не убеждается, что картина закрыта целиком.

Оставшиеся примерно 20% ошибок — неправильные действия. Часть из них имеет необратимые последствия для инфраструктуры. Например, удалённый ресурс уже не вернуть, и здесь цена ошибки выше, чем при незавершённой работе.

Что делать на практике

Выводы ниже — наши рекомендации, а не результаты авторов бенчмарка.

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

Второе — не принимайте слово «готово» на веру. Раз частая причина неудач — ранняя остановка, нужна независимая проверка итога: скрипт или ревью, которое перечисляет затронутые сервисы и сверяет их с ожидаемым состоянием.

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

Ограничения

Набор из 45 задач невелик и пока покрывает только AWS, поэтому цифры относятся к конкретной версии бенчмарка и конкретным моделям. В вашей инфраструктуре с собственными соглашениями результаты могут отличаться. Но общий вывод ясен: главное, что мешает агентам в облачных операциях, — планирование и самопроверка, а не знание команд. Пока эти навыки не улучшатся, человек остаётся последней линией защиты перед необратимыми действиями.