Агентов не пишут разработчики: как Cloud.ru перестроил архитектуру ИИ-автоматизации
Переход от создания универсальных агентов командой ИИ к модели, где каждый инженер создает своих специализированных помощников, стал ключом к масштабированию поддержки в Cloud.ru. Ограничения классической автоматизации и стратегия «раздачи удочек» вместо «вылова рыбы».
# Агентов не пишут разработчики: как Cloud.ru перестроил архитектуру ИИ-автоматизации
В начале пути команды ИИ-автоматизации казалось, что всё очевидно: нужно наблюдать за работой инженеров, описывать их действия в промптах и запускать агентов, которые будут решать задачи клиентов. В Cloud.ru такая стратегия работала отлично на начальных этапах. Была автоматизирована классификация обращений, суммаризация переписки и маршрутизация тикетов. Однако, когда были собраны все очевидные сценарии, прогресс резко остановился.
Стало ясно, что проблема не в качестве языковых моделей (LLM) или сложности архитектуры. Проблема заключалась в самом подходе к автоматизации сложной инженерной деятельности. Когда речь заходит о поддержке облачных платформ, где задействовано более 200 сервисов — от Kubernetes и GPU-инфраструктуры до Kafka и объектных хранилищ, — классический агент быстро исчерпывает свой потенциал.
Почему классическая автоматизация достигает потолка
Инженерная поддержка в облачных сервисах фундаментально отличается от работы колл-центра. Здесь решения принимаются не по шаблонным инструкциям, а на основе глубокого анализа логов, мониторинга и понимания специфики архитектуры системы. Диагностический процесс зависит от опыта специалиста: какие гипотезы он проверяет первым и в каком порядке изучает компоненты.
Попробовать передать эти знания ИИ-команде означало заставить её погружаться в каждый из сотен сервисов заново. Чтобы создать сценарий для одного сервиса, специалистам приходилось тратить недели на изучение внутренней архитектуры, API и инструментов диагностики. При таком темпе масштабирование невозможно, так как количество сервисов постоянно растет.
Исследования от Microsoft и Boston Consulting Group подтверждают этот вывод: переход к эффективной автоматизации происходит не тогда, когда ИИ берет на себя задачи, а когда человек управляет несколькими специализированными агентами, отвечая за итоговый результат. Главный ограничитель становится не технологический, а организационный — способность компании изменить процессы и дать сотрудникам инструменты для работы с ИИ.
Вместо удочек — рыбы
Команда ИИ-автоматизации поняла, что её задача сместилась с написания тысяч агентов на создание условий для их независимого создания инженерами. Вместо вопроса «Что вы хотите автоматизировать?», начались разговоры о том, «Что мешает вам сделать это самостоятельно?».
Основные барьеры, которые озвучили команды: * Отсутствие удобного доступа к моделям. * Нехватка готовых инструментов. * Отсутствие безопасной среды с понятными правилами. * Необходимость самостоятельно настраивать инфраструктуру.
Вместо того чтобы создавать монолитную платформу, решили убрать эти препятствия. Были развернуты локальные модели, настроены guardrails (системы безопасности) и подготовлены MCP-серверы. Инженерам предоставили готовый инструмент, который объединял всё необходимое, позволяя сосредоточиться на предметной области, а не на настройке серверов.
Сообщество и евангелисты
Первым шагом стало выявление «евангелистов» — сотрудников, которые уже проявляли интерес к технологиям. Вокруг них сформировалось внутреннее сообщество. Результатом стала волна уникальных сценариев, которые команда ИИ вряд ли создала бы сама: агенты для автоматического прохождения диагностических чек-листов, разбора алертов и проверки конфигураций Kubernetes.
Важную роль сыграла система нематериальной мотивации и проект «ИИ Авангард». Были введены лидерборды, внутренняя валюта и ачивки за создание полезных инструментов. Это позволило не только поощрить энтузиазм, но и сделать практики работы с ИИ заметными, поощрив обмен опытом между командами.
Сейчас фокус смещается на масштабирование этой практики среди всех сотрудников компании, чтобы каждый инженер мог за считанные дни создать своего личного помощника, использующего его уникальную экспертизу.