Мультиагентные системы: как несколько ИИ-агентов могут решать сложные задачи вместе

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

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

Разберемся, как устроены такие решения, где они пригодятся дизайнеру, маркетологу или контент-менеджеру и как собрать первую MAS самостоятельно.

Мультиагентная система, или MAS (Multi-Agent System), объединяет несколько автономных агентов, которые взаимодействуют друг с другом ради общей цели. У каждого участника может быть своя роль, инструкция, набор инструментов и доступ к определенным данным.

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

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

Для описания MAS используют несколько основных понятий:

Разница будет хорошо заметна при сравнении с одиночным агентом.

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

В простой MAS может быть два агента. Например, первый готовит материал, второй проверяет его по заданным критериям и возвращает замечания. В более сложных проектах появляются планировщик, аналитик, несколько исполнителей и отдельный контроллер.

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

Допустим, маркетинговой команде нужно каждую неделю готовить обзор активности конкурентов. Аналитик собирает исходные данные и выделяет изменения. Второй агент проверяет источники. Третий превращает результаты исследования в структурированный отчет. Контроллер сравнивает финальную версию с требованиями и либо принимает ее, либо отправляет конкретный блок на доработку.

Память и контекст

Чтобы участники могли взаимодействовать, им нужен способ передавать промежуточные результаты. Это может быть общая память, база данных, файл, объект состояния или сообщение следующему агенту.

Хранить абсолютно всю историю обычно нет необходимости. Исследователь может передать редактору таблицу с фактами и ссылками, а не полный журнал своих рассуждений. Так контекст остается компактнее, а управление им — проще.

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

Кто управляет агентами

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

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

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

Как выглядит один рабочий цикл

Внутри отдельного этапа тоже может быть свой цикл:

Инструментами могут быть API, поиск, файлы, базы знаний, таблицы, CMS и другие внешние сервисы. Поэтому возможности MAS зависят не только от выбранной языковой модели. Большую роль играет инфраструктура вокруг нее — память, интеграции, правила передачи данных и механизм контроля.

До финального макета дизайнеру обычно приходится изучить задачу, посмотреть референсы, выбрать направление, подготовить материалы и проверить соответствие брендбуку. Часть такой работы можно распределить между AI-агентами.

Например, цепочка может начаться с исследования. Первый агент собирает референсы по заданной теме и группирует их по визуальным приемам. Следующий получает результаты и предлагает несколько концепций. Еще один готовит подробные задания для генеративной модели. После получения изображений отдельный участник проверяет их по заранее заданным критериям: композиции, стилю, ограничениям бренда. Финальный компонент приводит материалы к нужной структуре для передачи дизайнеру.

Человек при этом может подключаться в контрольных точках. Например, сначала выбрать одну из концепций, а уже после этого разрешить MAS переходить к генерации. Это сэкономит ресурсы и оставит творческое решение за специалистом.

Похожая архитектура подходит для маркетинга. Один агент собирает поисковые запросы, другой группирует их по смыслу, следующий готовит структуру материала, а редакторский агент проверяет черновик на соответствие заданной тональности и требованиям. После одобрения результат можно передать компоненту, который загрузит его в CMS.

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

Но автоматизировать весь процесс ради самой автоматизации не стоит. Иногда обычный скрипт, последовательный workflow или один агент справятся быстрее и дешевле. Разделение на роли оправдано, когда у этапов действительно разные инструкции, инструменты или критерии оценки.

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

No-code

Визуальная платформа позволяет собрать workflow из готовых блоков — принять запрос, обратиться к модели, передать результат другому компоненту и выполнить действие во внешнем сервисе.

Так проще увидеть маршрут информации и проверить саму идею до полноценной разработки. Роли можно описать отдельными системными инструкциями, а передачу результатов настроить между узлами сценария.

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

Low-code

Для более гибких проектов можно использовать Python, API языковых моделей и специализированные фреймворки. Среди инструментов для работы с несколькими агентами встречаются LangGraph, AutoGen и CrewAI.

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

Упрощенная MAS может работать так:

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

Full-code

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

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

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

Для первого проекта лучше взять повторяющуюся задачу, результат которой легко проверить. Например, собрать мудборд из десяти референсов, подготовить три концепции и проверить их на соответствие заданному стилю.

Шаг 1. Определите конкретную цель

Формулировка «помогай мне делать дизайн» не подойдет — система не знает, какой результат считать готовым.

Рабочий вариант: «По описанию проекта собери 10 релевантных референсов, раздели их по визуальным направлениям и на их основе подготовь три концепции. Для каждой укажи идею, композицию и ключевые визуальные приемы».

Сразу задайте и формат результата. Например, таблица референсов плюс три карточки концепций.

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

Шаг 2. Разделите работу на роли

Теперь определите, какие части действительно требуют разных исполнителей. В нашем примере достаточно исследователя, автора концепций и рецензента.

Промпт исследователю может выглядеть так: «Изучи переданные источники и выбери 10 референсов, подходящих теме проекта. Для каждого укажи, какой визуальный прием стоит рассмотреть».

Рецензент получает другую инструкцию: «Проверь три концепции по ТЗ. Для каждой перечисли конкретные расхождения. Не предлагай новую концепцию, если текущую можно исправить».

Так роли не конкурируют друг с другом. Давать всем участникам почти одинаковые инструкции и надеяться, что они сами распределят обязанности, не рекомендуем.

Шаг 3. Выберите стек

Для эксперимента подойдет no-code платформа. Если нужны собственные функции и гибкое управление, можно выбрать Python и один из агентных фреймворков.

На этом этапе стоит определить языковую модель, необходимые API, место хранения промежуточных данных и способ запуска сценария.

Шаг 4. Опишите правила передачи результата

Каждый агент должен знать, что он получает на входе и что обязан передать дальше.

Например: «Верни JSON с полями title, description, source и visual_features». Тогда следующему компоненту не придется угадывать структуру ответа.

Для рецензента можно отдельно прописать критерий завершения: «Если все обязательные требования выполнены, верни статус approved. Если нет — status revision и список замечаний».

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

Шаг 5. Тестируйте агентов по отдельности

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

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

Так вам будет проще найти источник ошибки. Если сразу запустить пять компонентов, придется разбираться, какой именно этап испортил результат.

Шаг 6. Запустите сценарий на реальных задачах

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

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

Шаг 7. Добавляйте улучшения по результатам тестов

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

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

Так станет видно, действительно ли новая архитектура ускоряет работу.

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

Другая проблема возникает из-за конфликтующих ролей. Допустим, исполнитель должен строго следовать ТЗ, а рецензенту дали слишком широкую инструкцию «сделай результат лучше». Он может начать менять требования по своему усмотрению. Поэтому зона ответственности каждого участника должна быть ограничена.

Есть и технические риски:

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

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

Новичку проще начать с визуального конструктора, чтобы разобраться в самой логике передачи информации. Когда сценарий станет сложнее, переходите к Python и специализированным библиотекам.

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

Разобраться с ошибками вам помогут GitHub Discussions, Stack Overflow и другие сообщества конкретных фреймворков. При поиске примеров обращайте внимание на дату публикации: инструменты вокруг AI быстро меняются, поэтому код годичной давности иногда использует уже устаревшие интерфейсы.

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

В Московском институте технологий и управления эти направления можно изучать на программах факультета информационных технологий.

На бакалавриате «Технологии искусственного интеллекта» мы знакомим студентов с машинным и глубоким обучением, нейронными сетями, анализом больших объемов данных, NLP и Python. Программа подойдет тем, кто хочет получить системную подготовку в области искусственного интеллекта и научиться применять AI для разработки интеллектуальных решений.

Еще одна программа бакалавриата — «Инженер искусственного интеллекта». В ней акцент сделан на разработке и внедрении AI-моделей — здесь вы изучите Python, машинное обучение, нейросети, компьютерное зрение, NLP, анализ больших данных и интеграцию интеллектуальных технологий в программные продукты.

Для выпускников бакалавриата и специалитета есть магистратура «Интеллектуальные встраиваемые системы». Она подойдет тем, кому интересно применение машинного обучения и AI во встраиваемых устройствах и инженерных проектах.

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

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

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