Почему агентов ИИ не должны писать разработчики: опыт Cloud.ru

Создание агентов искусственного интеллекта для клиентской поддержки — это не задача для разработчиков. Такой вывод сделала команда ИИ-автоматизации облачного провайдера Cloud.ru, когда столкнулась с остановкой прогресса в развитии своей внутренней платформы. Сначала казалось, что проблема кроется в недостаточно умных моделях, неточных промптах или неудачной архитектуре, но корень оказался глубже — в самом подходе к автоматизации. Передача создания агентов в руки инженеров, которые мыслят категориями кода, а не бизнес-процессов, приводит к хрупким и негибким решениям. В этой статье мы разберем, почему так происходит, какие ошибки совершила команда Cloud.ru и как правильный подход может ускорить внедрение ИИ в поддержку.

Почему разработчики неэффективны при создании ИИ-агентов

Разработчики, как правило, подходят к созданию агентов с инженерным мышлением: они стремятся описать все возможные сценарии в коде, сделать поведение предсказуемым и полностью контролируемым. Однако агенты ИИ — это не классический софт, а скорее цифровые сотрудники, которые должны адаптироваться к нестандартным ситуациям, понимать контекст и взаимодействовать с людьми. Когда разработчик пишет агента, он невольно переносит в него свои привычки: жесткую логику, стремление к полному контролю, ориентацию на технические метрики. В результате агент отлично работает на тестовых данных, но ломается при первом реальном обращении клиента.

Ключевая ошибка — попытка закодировать все возможные сценарии. Агент должен учиться на примерах, а не следовать жестко заданным правилам. Когда разработчик закладывает в промпты конкретные инструкции, он ограничивает способность модели к адаптации. Такие инструкции быстро устаревают, и агент не справляется с новыми ситуациями, что вынуждает команду возвращаться к ручной поддержке. В Cloud.ru это проявилось в полной мере: несмотря на все усилия, прогресс остановился, и только смена подхода позволила сдвинуться с мертвой точки.

Как команда Cloud.ru пришла к этому выводу

История началась с энтузиазма: команда ИИ-автоматизации Cloud.ru верила, что большие языковые модели решат большинство проблем клиентской поддержки. Первые пилоты действительно показали хорошие результаты — агенты успешно отвечали на типовые вопросы, снижая нагрузку на операторов. Однако по мере усложнения сценариев прогресс замедлился. Каждое новое улучшение требовало все больше усилий, а результаты становились менее предсказуемыми. Инженеры перепробовали разные модели, улучшали промпты, меняли архитектуру — ничего не помогало.

Автор статьи, инженер Cloud.ru, признается, что сначала винил во всем модели, затем промпты, но даже самые изощренные инструкции не решали проблему. Тогда команда проанализировала, кто именно создает агентов, и обнаружила, что процесс полностью контролируют разработчики. Они пишут код, определяют логику, задают параметры. По сути, они создают традиционное ПО, а не гибких ИИ-помощников. Это открытие перекликается с более широким трендом: успешные внедрения ИИ требуют участия предметных экспертов, а не только программистов. Например, в системах рекомендаций лучшие результаты достигаются, когда алгоритмы настраивают маркетологи, а не инженеры.

Почему агенты должны учиться, а не программироваться

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

Один из подходов, который предлагает автор, — использовать платформы low-code или no-code, где бизнес-пользователи могут настраивать агентов без написания кода. Это позволяет специалистам по поддержке самим определять сценарии, добавлять примеры, корректировать поведение агента. Разработчики же сосредотачиваются на инфраструктуре: интеграциях, безопасности, масштабировании. Такой подход ускоряет итерации и делает агентов более гибкими.

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

Технические детали: что именно пошло не так в Cloud.ru

В Cloud.ru агенты изначально строились на основе больших языковых моделей с использованием RAG-подхода. Разработчики писали промпты, которые должны были направлять модель на правильные ответы, и создавали векторные базы знаний для поиска релевантной информации. На тестовых сценариях все работало, но в продакшене агенты часто давали неверные ответы или зависали на сложных запросах.

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

Решение, к которому пришла команда, — упростить агентов и передать их настройку бизнес-пользователям. Они начали использовать платформу, где операторы поддержки могли создавать агентов через визуальный интерфейс, добавляя примеры диалогов и правила без кода. Разработчики оставили за собой только техническую часть: подключение к API, настройку моделей, обеспечение безопасности. Это позволило агентам быстрее адаптироваться к реальным запросам клиентов, а команда разработчиков сосредоточилась на улучшении инфраструктуры.

Кого затронет и как: разработчики, бизнес и клиенты

Этот вывод касается не только Cloud.ru, но и любой компании, которая пытается внедрить ИИ-агентов. Разработчикам придется пересмотреть свою роль: вместо написания каждого агента вручную они будут создавать платформы и инструменты, которые позволяют другим создавать агентов. Это требует новых навыков: проектирование API, работа с low-code платформами, понимание бизнес-процессов.

Для бизнес-пользователей, таких как операторы поддержки, это открывает новые возможности. Они смогут сами настраивать агентов под свои нужды, быстро реагировать на изменения в продукте или политике компании. Это сокращает время на внедрение изменений и повышает качество обслуживания клиентов.

Клиенты также выигрывают: агенты, созданные с участием предметных экспертов, лучше понимают их потребности, дают более точные ответы и быстрее решают проблемы. В конечном счете это снижает нагрузку на живых операторов и повышает удовлетворенность.

В России и СНГ этот тренд особенно актуален, так как многие компании только начинают внедрять ИИ в поддержку. Опыт Cloud.ru может стать ориентиром для тех, кто хочет избежать типичных ошибок и построить эффективную систему автоматизации.

Что будет дальше: эволюция роли разработчика в ИИ-агентах

Ожидается, что в ближайшие годы роль разработчика в создании агентов будет смещаться от прямого написания кода к созданию платформ и инструментов. Уже сейчас появляются low-code платформы, которые позволяют бизнес-пользователям создавать сложных агентов без программирования. Разработчики будут отвечать за интеграцию этих платформ с корпоративными системами, обеспечивать безопасность и масштабируемость.

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

Опыт Cloud.ru показывает, что успех в создании ИИ-агентов зависит не от технической сложности, а от правильного распределения ролей. Передача контроля над агентами бизнес-пользователям — это не потеря для разработчиков, а возможность сосредоточиться на более интересных и важных задачах. В конечном счете это приводит к созданию более эффективных и человекоцентричных систем поддержки.