Что такое мультиагентная система
Мультиагентная система (МАС) - это архитектура, где несколько ИИ-агентов работают вместе для решения задачи. Каждый агент автономен, у каждого своя роль, свои инструменты, свой контекст.
Простая аналогия: один агент - это разработчик-одиночка. Мультиагентная система - это команда, где есть аналитик, разработчик, тестировщик и тимлид.
Зачем нужно несколько агентов, если можно дать одному все инструменты? Потому что LLM деградируют при росте контекста. Мы измеряли: агент с 50 инструментами и промптом на 8000 токенов выбирает правильный инструмент в 73% случаев. Тот же агент с 10 инструментами и промптом на 2000 токенов - в 94%. Разница 20% точности - это разница между рабочей системой и источником багов.
Три компонента
Агенты. Каждый агент - это LLM + промпт + набор инструментов. Исследователь с доступом к поиску и веб-скрапингу. Кодер с доступом к файловой системе и git. Ревьюер который только читает код и даёт обратную связь. Узкая специализация = высокая точность.
Оркестратор. Координатор, который решает кому какую задачу отдать. Может быть жёстким пайплайном (A, потом B, потом C), динамическим (LLM-менеджер сам решает) или гибридом.
Протокол общения. Как агенты передают результаты. В простом случае - текст. В продакшне - структурированные данные с типизацией. Google выпустил протокол A2A для стандартизации этого.
Три паттерна оркестрации
Pipeline (конвейер). Агенты работают последовательно: выход одного - вход другого. Исследователь собрал данные, аналитик обработал, писатель оформил. Предсказуемо, легко отлаживать. Мы используем этот подход и описали его как Pipeline Triad Pattern. По нашей оценке, конвейер покрывает 80% задач в продакшне.
Supervisor (супервайзер). Центральный агент-менеджер раздаёт задачи и собирает результаты. Гибче конвейера: менеджер может динамически решить кому что отдать. Но он же становится бутылочным горлышком. Если менеджер ошибся в распределении - вся система буксует. Каждое решение менеджера - это дополнительный вызов LLM, который стоит денег и добавляет задержку.
Swarm (рой). Агенты общаются напрямую друг с другом, без центрального координатора. Каждый сам решает когда подключиться. Максимальная гибкость, минимальный контроль. На практике - самый сложный паттерн для отладки. OpenAI экспериментирует с этим подходом в Swarm framework.
Когда мультиагентность оправдана
Не всегда. Один хороший агент часто лучше трёх средних. Мы пришли к этому выводу после нескольких неудачных экспериментов. Подробно писали об этом: больше агентов - не всегда лучше.
Нужна мультиагентность:
- Задача чётко делится на этапы с разными инструментами (исследование, код, тесты)
- Контекст одного агента не вмещает всю задачу (>100K токенов)
- Нужна параллельная обработка (проверить 10 серверов одновременно)
- Требуется "второе мнение" (один пишет, другой проверяет)
Не нужна мультиагентность:
- Задача решается одним агентом за 5-15 шагов
- Этапы сильно зависят друг от друга
- Бюджет ограничен (каждый агент = отдельные вызовы LLM)
Эмпирическое правило: если задача требует менее 20 tool calls, один агент справится лучше. Если больше 50 - стоит думать о разделении.
Экономика: один агент vs команда
| Метрика | 1 агент (30 tools) | 3 агента (10 tools) |
|---|---|---|
| Точность tool selection | Заметно ниже | Выше (меньше выбор - меньше ошибок) |
| Среднее кол-во шагов | Больше | Меньше суммарно |
| Стоимость задачи | Выше | Ниже за счёт точности |
| Время выполнения | Последовательно | Быстрее (с параллелизмом) |
| Сложность отладки | Низкая | Средняя |
Общий паттерн: команда агентов часто обходится дешевле одного универсального, потому что каждый работает точнее и тратит меньше циклов на ошибки. Но это работает только когда задача правильно разделена. Плохое разделение убивает все преимущества.
Фреймворки для мультиагентных систем
CrewAI. Самый популярный. Определяете роли, задачи, зависимости на Python. Хорошо для прототипов, но абстракции протекают на сложных сценариях. ~15K звёзд на GitHub.
AutoGen (Microsoft). Фокус на разговорных паттернах - агенты общаются в чате. Хорош для brainstorm-сценариев, слаб для строгих пайплайнов. Тяжёлый: минимальный проект тянет 200MB зависимостей.
LangGraph. Граф-ориентированный подход от LangChain. Состояния и переходы. Мощный, но кривая входа крутая - нужно думать графами.
Свой runtime. Написать оркестратор самому - не так сложно как кажется. Очередь задач, вызовы LLM, роутинг результатов. Для прода часто единственный вариант, потому что фреймворки навязывают абстракции, которые не подходят вашему кейсу. Мы пришли к собственному паттерну после экспериментов со всеми перечисленными.
Проблемы мультиагентных систем и антипаттерны
Каскадные ошибки. Если первый агент ошибся, все следующие работают с мусором. Представьте: исследователь нашёл неправильные данные, аналитик на их основе сделал выводы, писатель оформил статью. Три агента работали, результат - мусор. Решение: валидация на каждом переходе + fallback-стратегии.
"Шёпот по цепочке". Каждый агент интерпретирует входные данные по-своему. К третьему агенту исходный смысл может измениться до неузнаваемости. Решение: передавать не текст, а структурированные данные (JSON с чёткой схемой).
Стоимость координации. Три агента по $0.30 - это не $0.90, а $1.20-1.50 с учётом обмена данными и координации. Оркестратор тоже вызывает LLM. Метрики обязательны.
Безопасность. Агент с правами на чтение может передать данные агенту с правами на запись. Без изоляции один скомпрометированный агент ломает всю систему. Принцип минимальных привилегий: каждый агент получает только те инструменты, которые нужны для его задачи.
Реальный пример: как устроен контент на этом сайте
Этот сайт управляется мультиагентной системой. Вот конвейер:
-
Агент-аналитик. Проверяет Яндекс.Вордстат (поисковый спрос), метрики сайта (что читают), конкурентов. Выбирает тему с максимальным потенциалом трафика. Выход: тема + ключевые слова + целевая аудитория.
-
Агент-писатель. Получает задание, пишет черновик. Учитывает SEO-ключи, перелинковку на существующие статьи, формат (POSTS_FORMAT.md). Выход: markdown-файл с готовой статьёй.
-
Человеческое ревью. Это принципиально. Черновик отправляется на проверку. Человек решает: публиковать, доработать или удалить.
-
Агент-публикатор. После одобрения вставляет в базу, обновляет sitemap, отправляет анонс в Telegram.
Четыре шага, одна человеческая проверка. Стоимость: $1-2 на статью. Время: 15-20 минут агентской работы, 5-10 минут ревью.
Стандарты мультиагентных систем: A2A и MCP
Мультиагентные системы созрели до момента, когда появились стандарты:
A2A (Agent-to-Agent). Протокол от Google для общения между агентами. Определяет как агенты обмениваются задачами, результатами и метаданными. Не привязан к конкретному фреймворку или LLM.
MCP (Model Context Protocol). Стандарт Anthropic для подключения инструментов к агентам. Не про общение агентов, а про то, как агент получает доступ к внешним системам.
Если A2A - это язык общения между агентами, то MCP - это интерфейс между агентом и инструментами.
Когда внедрять мультиагентную систему
Честный ответ: большинству проектов мультиагентная ��истема не нужна. Один хороший агент с правильным промптом и набором инструментов закроет 80% задач. Мы сами пришли к мультиагентности не потому что это модно, а потому что упёрлись в потолок контекста и точности на сложных задачах.
Если вы только начинаете - не начинайте с мультиагентности. Постройте одного ИИ-агента с нуля, доведите его до прода, измерьте метрики ИИ-агента. Когда увидите что один агент стабильно ошибается на определённом типе задач, тогда думайте о втором. Минимальный рабочий вариант: основной агент + агент-ревьюер. Два агента, ноль фреймворков.
Если хотите сразу глубже: Pipeline Triad - паттерн конвейера из трёх агентов, A2A протокол межагентного взаимодействия - как индустрия стандартизирует общение между агентами. А статья почему больше агентов не значит лучше стоит прочитать первой - она про то, почему добавление агентов часто ухудшает результат.