Термин «многоагентные системы» (Multi-Agent Systems, MAS) прочно вошёл в лексикон разработчиков AI-продуктов. Идея кажется привлекательной: вместо одного «универсального» агента запустить несколько специализированных, которые договариваются, уточняют и дополняют друг друга. На практике же переход от одного агента к нескольким — это не просто масштабирование, а смена парадигмы с новыми проблемами координации, стоимости и отладки.
Разберём, как устроены современные MAS, какие архитектуры реально работают, а какие остаются экспериментальными.
Зачем вообще нужны несколько агентов
Одиночный LLM-агент — это программа, которая с помощью модели может рассуждать, вызывать инструменты и хранить контекст. Его возможности ограничены окном внимания, глубиной одного «потока мыслей» и склонностью к зацикливанию на одной стратегии.
Многоагентные системы решают три задачи:
- Разделение компетенций. Один агент пишет код, другой тестирует, третий анализирует уязвимости. Каждый использует свою систему промптов и, возможно, свою модель.
- Параллельная обработка. Агенты могут работать одновременно над разными частями задачи — например, собирать данные из нескольких источников.
- Критическая проверка. Один агент генерирует вариант, другой его рецензирует. Это снижает галлюцинации и улучшает качество финального ответа.
Основные архитектурные топологии
Современные реализации MAS можно свести к нескольким схемам.
Оркестратор (Supervisor). Центральный агент управляет подчинёнными: ставит задачи, собирает результаты, решает, что делать дальше. Это самая распространённая схема в продуктах вроде LangGraph и CrewAI. Плюс — простота управления. Минус — единая точка отказа: если оркестратор ошибается в маршрутизации, вся цепочка ломается.
Децентрализованная (Peer-to-Peer). Агенты общаются напрямую, без центрального координатора. Каждый решает, кому передать задачу или запросить уточнение. Пример — AutoGen от Microsoft. Такая схема сложнее в отладке, но устойчивее к сбоям.
Иерархическая. Многоуровневая структура, где агенты нижнего уровня отчитываются перед агентами среднего, а те — перед верхним. Используется в задачах с чёткой декомпозицией: например, планирование маршрута логистики, где каждый уровень отвечает за свой масштаб.
Рыночная (Auction-based). Агенты «торгуются» за выполнение подзадач, предлагая свою оценку стоимости или времени. Применяется в исследовательских проектах и симуляциях экономических процессов. В коммерческих AI-продуктах встречается редко.
Сравнение популярных фреймворков
| Фреймворк | Тип координации | Сильные стороны | Ограничения |
|---|---|---|---|
| LangGraph | Оркестратор + граф | Гибкая маршрутизация, поддержка циклов и условных переходов | Требует явного описания графа, сложен для новичков |
| CrewAI | Оркестратор (менеджер) | Простой старт, встроенные роли и задачи | Ограниченная кастомизация, проблемы с длинными цепочками |
| AutoGen | Децентрализованная (чат) | Гибкое взаимодействие, поддержка человека в цикле | Сложная отладка, нет встроенного графа выполнения |
| Microsoft Semantic Kernel | Оркестратор + плагины | Интеграция с Azure и .NET, планировщик | Меньше сообщества, чем у LangChain |
| MetaGPT | Иерархическая (имитация компании) | Хорош для генерации кода и документации в стиле Scrum | Жёсткая структура ролей, избыточен для простых задач |
Когда многоагентный подход оправдан
На основе анализа публичных кейсов и бенчмарков можно выделить сценарии, где MAS действительно дают прирост.
Генерация и ревью кода. Агент-разработчик пишет код, агент-тестировщик запускает юнит-тесты, агент-архитектор проверяет соответствие стандартам. В бенчмарке SWE-bench мультиагентные подходы (например, AgentCoder) показали прирост в pass@1 на 15–20% по сравнению с одиночными агентами.
Исследование документов и написание отчётов. Несколько агентов параллельно анализируют разные источники, затем агент-редактор собирает единый отчёт. Это быстрее последовательной обработки, но требует тщательной настройки дедупликации.
Симуляции и ролевые игры. В исследовательских проектах (Generative Agents от Стэнфорда) MAS используются для моделирования поведения групп. Коммерческое применение пока ограничено, но интересно для UX-тестирования.
Когда MAS — избыточная сложность
Многие проекты, где пытаются внедрить многоагентную архитектуру, на самом деле решаются одним агентом с хорошим набором инструментов. Признаки того, что MAS не нужен:
- Задача линейна: получить данные → обработать → выдать результат.
- Агенты не обмениваются промежуточными результатами, а просто вызываются последовательно.
- Вы не готовы тратить время на отладку недетерминированного поведения (агенты могут «заболтаться» или уйти в бесконечный цикл).
- Бюджет на токены ограничен: MAS потребляет в 2–5 раз больше токенов, чем одноагентное решение, из-за служебных сообщений и повторной обработки контекста.
Известные проблемы и ограничения
Рост затрат. Каждое сообщение между агентами — это токены. В реальных проектах счёт за API может вырасти на порядок по сравнению с одиночным агентом.
Недетерминизм. Одна и та же задача может быть решена по-разному в зависимости от порядка сообщений, температуры моделей и случайных факторов. Это затрудняет тестирование и регрессию.
Галлюцинации в цепочке. Если один агент выдал неверный факт, последующие агенты могут его подхватить и развить. Без внешней верификации ошибка накапливается.
Сложность отладки. Понять, почему система приняла то или иное решение, можно только просматривая полный лог диалогов между агентами. Инструментов визуализации пока мало.
Что дальше
Развитие MAS идёт в сторону более жёстких протоколов (например, спецификация A2A от Google) и встроенной верификации. Появляются бенчмарки для оценки именно координации, а не отдельных агентов. Но пока многоагентные системы остаются нишевым инструментом: они мощны, но требуют опыта и готовности платить за сложность.
Что можно проверить уже сейчас: если вы работаете с LangGraph или CrewAI, попробуйте замерить стоимость и время выполнения одной и той же задачи в одноагентном и многоагентном режиме. Разница часто оказывается неожиданной.