Содержание
- 1. Что такое мультиагентная система?
- 2. Зачем вообще оркестрировать несколько ИИ?
- 3. Пять ключевых архитектурных паттернов
- 4. Сравнение основных фреймворков
- 5. Что реально работает в продакшене
- 6. Стоимость и компромиссы — реальность 15-кратного расхода токенов
- 7. Когда использовать, а когда нет
- 8. Лучшие практики проектирования
- Резюме
- FAQ
В 2026 году разговор об ИИ-агентах сместился с «один супер-агент, который делает всё» на «команда агентов с разными ролями». Anthropic Research, субагенты Claude Code, инженерная команда Devin, параллельные воркеры Cursor — все они построены на архитектуре, которая координирует несколько ИИ.
Эта статья начинается с определения, что такое мультиагентная система на самом деле, затем проходит по основным архитектурным паттернам, сравнению продакшен-фреймворков, реальным примерам, структуре стоимости и в итоге — когда её стоит использовать, а когда нет — всё подкреплено свежими источниками. Откажитесь от фантазии «просто перейдём на мульти, и всё станет умнее» и получите реальную основу для проектных решений.
Мультиагент = команда специалистов, работающих параллельно
— вместо того чтобы поручать всё одному ИИ, маленькая команда экспертов делит работу
Каждый работает в собственном контекстном окне, параллельно.
Оркестратор агрегирует результаты и возвращает ответ — это самая распространённая на сегодня схема.
1. Что такое мультиагентная система?
Мультиагентная система (MAS) — это архитектура, в которой несколько ИИ-агентов кооперируются для решения одной задачи. У каждого агента собственный промпт, инструменты и контекст; они обмениваются сообщениями и результатами для достижения общей цели.
Базовый «одиночный агент» — описанный в нашей статье об ИИ-агенте — это одна сущность, самостоятельно прогоняющая цикл «восприятие → рассуждение → действие → наблюдение». Самый понятный способ представить мультиагентную систему: возьмите это и добавьте специализацию ролей и параллелизм.
Чем отличается от одиночного агента
| Аспект | Одиночный агент | Мультиагент |
|---|---|---|
| Структура | Один ИИ выполняет цикл | Несколько ИИ работают совместно |
| Контекст | Всё запихнуто в одно окно | Разделён по ролям (предотвращает загрязнение) |
| Параллелизм | По сути последовательный | Субагенты могут работать параллельно |
| Специализация | Один универсал делает всё | Оптимизация по ролям (команда специалистов) |
| Отладка | Простая, легко прослеживается | Сложная; нужно отслеживать ещё и трафик между агентами |
| Стоимость | Низкая (одна сессия) | Высокая (обычно в 2–15 раз больше токенов) |
| Задержка | Быстро | Медленнее (накладные расходы на координацию) |
| Где идеально | Чёткие, последовательные задачи | Задачи, требующие исследования, параллельного поиска или специализации |
2. Зачем вообще оркестрировать несколько ИИ?
Стартовая позиция — «если один агент справляется со всем, оставьте его в покое». Мультиагент становится необходим из-за трёх структурных стен, которые одиночному агенту тяжело преодолеть.
Три стены, которые одиночный агент не может пробить
Мультиагент преодолевает эти стены тройным набором: «изоляция контекста × параллелизация × специализация ролей». Anthropic Research — канонический пример: ведущий исследователь планирует работу, несколько субагентов исследуют разные аспекты параллельно, а результаты агрегируются. Anthropic сообщает, что это дало примерно 90% прироста качества по сравнению с одноагентной версией.
3. Пять ключевых архитектурных паттернов
Мультиагентные дизайны бывают нескольких «форм». Названия отличаются от фреймворка к фреймворку, но по сути всё сводится к этим пяти паттернам.
3-1. Оркестратор-воркер (самый распространённый)
Один «дирижёр (оркестратор / ведущий агент)» декомпозирует задачу и параллельно отправляет части нескольким «воркерам (субагентам)». Каждый воркер работает в собственном контексте и возвращает результат оркестратору, который агрегирует их в финальный вывод.
Используется в: Anthropic Research, субагентах Claude Code, канонической схеме OpenAI Agents SDK.
3-2. Handoff (линия OpenAI Swarm)
Агенты явно передают управление друг другу по принципу «твоя очередь». История диалога и контекст переходят из рук в руки. Структурно похоже на тикет, передаваемый между исполнителями; подходит для сценариев вроде эскалации в службе поддержки.
Используется в: OpenAI Agents SDK (преемник старого Swarm).
3-3. Иерархический (команды команд)
Древовидная структура: под оркестратором находится дополнительный слой агентов «среднего звена», а под ними — группа воркеров. Встречается в крупных системах — Devin от Cognition, по сообщениям, использует этот паттерн. Стоимость и задержка растут с глубиной, поэтому два-три уровня — реалистичный потолок.
3-4. Peer-to-peer (дебаты и консенсус)
Никакого оркестратора — несколько агентов спорят на равных и итерируются, пока не достигнут консенсуса. Изучается под названием Multi-Agent Debate; по сообщениям, повышает фактическую точность и устойчивость рассуждений. Реализация нетривиальна, поэтому практическое применение пока узкое.
3-5. Конвейер (форма workflow)
Каждый агент работает в фиксированной последовательности вроде «исследование → структурирование → проверка → вывод». Это домашняя территория LangGraph с его графовой моделью. Жертвует динамическим принятием решений ради воспроизводимости и более простой отладки — и часто оказывается самой стабильной формой в продакшене.
Пять паттернов с первого взгляда
4. Сравнение основных фреймворков
К 2026 году разработка мультиагентов консолидировалась вокруг четырёх фреймворков (длинный хвост мелких фреймворков поредел).
| Фреймворк | Вендор | Подходящий паттерн | Особенности |
|---|---|---|---|
| Claude Agent SDK | Anthropic | Оркестратор/воркер | Субагенты + Hooks + интеграция с MCP. Claude Code построен на нём. |
| OpenAI Agents SDK | OpenAI | Handoff | Выпущен в марте 2025 года как преемник Swarm. Построен вокруг передачи управления между агентами. |
| LangGraph | LangChain | Конвейер / конечный автомат | Графовая модель; выражает сложные ветвления и циклы. Силён в отладке. |
| Strands Agents | AWS | Оркестратор/воркер | Продакшен-уровень с интеграцией Bedrock. Богатые корпоративные возможности (аудит-логи и т. д.). |
| CrewAI | Независимый OSS | Команды на основе ролей | Состоит из агентов с «должностями». Хорош для обучения и PoC; продакшен-внедрений мало. |
| AutoGen | Microsoft Research | Peer-to-peer / дебаты | Возник как исследовательский проект. Уклон в академию; продакшен-использование в меньшинстве. |
В продакшене большая четвёрка — это Claude Agent SDK, OpenAI Agents SDK, LangGraph и Strands. CrewAI и AutoGen хороши для обучения и PoC, но корпоративные продакшен-внедрения сосредоточены в первых четырёх.
5. Что реально работает в продакшене
Anthropic Research (внутри Claude.ai)
Функция исследования в Claude.ai — учебник по схеме оркестратор-воркер. Ведущий исследователь разбивает вопрос пользователя на части, несколько субагентов параллельно изучают разные аспекты (информация о компании, хронология, технические детали и т. д.), а результаты агрегируются в отчёт. Anthropic опубликовал детали в инженерном блоге и сообщает примерно о 90% приросте точности по сравнению с одноагентной версией.
Субагенты Claude Code
В Claude Code можно передавать долгие задачи субагентам с разными ролями. Пример: основной Claude составляет план, исследовательский субагент параллельно читает несколько файлов, а имплементирующий субагент пишет патч. У каждого субагента собственное контекстное окно, поэтому он не загромождает основной контекст.
Devin (Cognition)
Автономный инженер Devin от Cognition, по сообщениям, использует иерархическую мультиагентную структуру. Под родительским агентом в стиле проджект-менеджера параллельно работают команды специалистов по доменам. Именно такая глубина нужна, чтобы доводить сложные PR и миграционные работы от и до.
Параллельные воркеры Cursor
Недавнее обновление Cursor усилило способность дробить изменения, охватывающие несколько файлов, между параллельными субагентами. Вместо одного агента, последовательно обрабатывающего файлы, отдельные агенты работают бок о бок на разных участках.
6. Стоимость и компромиссы — реальность 15-кратного расхода токенов
Прежде чем покупать тезис «мульти = умнее», нужно понять структуру стоимости. Собственный отчёт Anthropic говорит, что мультиагентная система сжигает примерно в 15 раз больше токенов, чем стандартная чат-сессия.
Готовьтесь к удорожанию мультиагента в 2–15 раз
— подтверждается как официальными, так и сторонними замерами
Типичные замеры MAS: 2–5x
→ варьируется от уровня параллелизма и числа субагентов
Из-за координации и обмена сообщениями
Общее время на стене всё равно может снизиться благодаря параллелизму
Очереди, дублирующие инстансы, логи
Усилия на отладку фактически тоже растут
По отраслевым опросам, ~70% ИИ-нагрузок могут достичь 90–95% качества мультиагента при 30–40% стоимости с одиночным агентом. «Просто перейдём на мульти» экономически неверно.
Мультиагент оправдывает себя только для «задач, где ценность вывода соизмерима со стоимостью». Цитируя формулировку Anthropic: целевой сценарий — «сложные исследовательские задачи, где ценность вывода высока относительно стоимости».
7. Когда использовать, а когда нет
Случаи, требующие мультиагента
- Параллельные исследования: «изучить десять сайтов одновременно и отчитаться», «обратиться к нескольким API параллельно и слить результаты» — всё, где параллелизм создаёт прямую ценность
- Длительные автономные задачи: нагрузки, превышающие контекстное окно одной сессии. Без разделения ролей загрязнение контекста убивает точность
- Гетерогенная специализация: когда один агент и «пишет код», и «ревьюит код», его критический взгляд притупляется. Разделение ролей напрямую повышает качество
- Однократные задачи с высокой бизнес-ценностью: аудит-отчёты, стратегический анализ, сложные технические исследования — выводы, оправдывающие стоимость
Случаи, когда не стоит
- Чёткие, последовательные задачи: «исправь этот код», «суммируй этот документ» — работа, которую одиночный агент завершает в штатном режиме
- Сервисы, чувствительные к задержкам: первые ответы чат-ботов, клиентская поддержка — везде, где требуется быстрая реакция
- Чувствительные к стоимости пакетные задания: высокообъёмная повторяющаяся работа. Переход на мульти умножает себестоимость единицы на множитель, и математика рушится
- Команды с дефицитом отладки и эксплуатации: сложность мультиагента растёт экспоненциально. Если команда не может это поддерживать, начинайте с одиночного
Отраслевая мантра — «Начинайте с одного агента, добавляйте новых только при чёткой причине». Это консенсус среди продакшен-инженеров в 2026 году.
8. Лучшие практики проектирования
Если вы решили, что мультиагент — правильный выбор, вот те места, где спотыкаются проектировщики, — в основном по материалам, опубликованным Anthropic.
1. Передавайте субагентам явные «цель, формат вывода, инструменты и границы»
Большинство сбоев субагентов имеют форму «расплывчатые инструкции привели к перетеканию в другую задачу» или «выводы не имели общего формата и не агрегировались». Рекомендация Anthropic: давайте каждому субагенту (1) чёткую цель, (2) ожидаемый формат вывода, (3) инструменты и источники информации, которыми он может пользоваться, и (4) границы его задачи.
2. Делайте «уровень усилий» явным
Субагенты плохо решают сами, «как глубоко копать». Заложите уровень усилий в промпт — «разведка в один шаг», «исчерпывающая верификация», «вывод только из известной информации». xhigh и task budgets (beta) в Claude Opus 4.7 — это и есть официальный ответ на эту проблему.
3. Поручите оркестратору работу по «агрегации и разрешению конфликтов»
Результаты субагентов могут противоречить друг другу (например, сообщать один и тот же факт под разными углами). Половина работы оркестратора — «разрешать противоречия и сводить их в один связный ответ». Сэкономите на логике агрегации — и выгоды от перехода на мульти исчезнут.
4. Стройте наблюдаемость с самого начала
Мультиагентные системы рушатся в момент, когда невозможно понять, что происходит. Логируйте вход/выход каждого субагента, время выполнения, расход токенов и вызовы инструментов с первого дня. LangGraph и Strands спроектированы с расчётом на наблюдаемость, и это одна из причин их успеха в продакшене.
5. Начинайте с одиночного, делите только в узких местах
Не проектируйте мульти с самого начала. Сначала запустите как одиночный агент, и только потом выделяйте субагента в точках, которые вы чётко идентифицировали как стены. Тот же подход, что и при рефакторинге, — этого достаточно.
Резюме
- Мультиагент — архитектура, в которой «несколько ИИ работают параллельно с разделёнными ролями». Она преодолевает три стены одиночного агента: загрязнение контекста, отсутствие параллелизма и смешение ролей
- Ключевые паттерны — пять: оркестратор-воркер, handoff, иерархический, peer-to-peer и конвейер. Оркестратор-воркер — безусловный лидер
- Основные фреймворки сконцентрировались в большой четвёрке: Claude Agent SDK, OpenAI Agents SDK, LangGraph и Strands
- Стоимость в 2–15 раз выше. Задержка +30–50%. Браться за это легкомысленно — экономически неверно
- Правило выбора: если параллелизм, специализация или долгая работа — жёсткое требование, идите в мульти. Иначе одиночного достаточно
- Правило проектирования: начинайте с одиночного, делите только в узких местах, когда они станут видны
FAQ
Q1. Мультиагент всегда лучше «более умного одиночного агента»?
Нет. Anthropic Research показал ~90% прирост точности, но это произошло в его профильной зоне «сложного параллельного исследования». Для чётких последовательных задач одиночный агент быстрее, дешевле и как минимум не хуже. Всё зависит от характера задачи.
Q2. Если я сам хочу построить мультиагентную систему, с какого фреймворка начать?
Зависит от сценария. Используете Claude? Начинайте с Claude Agent SDK (официальный, с субагентами + Hooks). OpenAI-центричный стек? Agents SDK. Нужно выразить сложную логику ветвлений? LangGraph. Продакшен в AWS? Strands. Для обучения CrewAI хорош для понимания концепций.
Q3. Можно ли постепенно мигрировать с одиночного на мульти?
Да, и большинство продакшен-систем именно так и делают. Соберите MVP как одиночный агент, потом выделяйте субагентов только там, где реально упёрлись в пределы контекстного окна, проблемы с задержкой или потребность в специализации. Проектировать всё как мульти с нуля не рекомендуется.
Q4. Есть ли стандартный протокол коммуникации между агентами?
На 2026 год де-факто стандартом становится MCP (Model Context Protocol). Возник в Anthropic и теперь принят OpenAI, Microsoft, AWS и другими. Широко используется как общий интерфейс между агентами и между агентами и инструментами. Существует также предложение по стандартизации ACP (Agent Communication Protocol), но реализаций пока мало.
Q5. Какой самый частый сценарий отказа мультиагента?
(1) Отсутствие наблюдаемости (непонятно, что происходит), (2) Слишком расплывчатые инструкции субагентов, не позволяющие агрегировать результаты, и (3) Взрыв стоимости. Особенно (3): субагент попадает в цикл, всю ночь долбит API, и облачный счёт за ночь подскакивает на порядок — такие происшествия удивительно часты. Всегда задавайте task budgets (потолки по стоимости и времени).
Q6. Является ли мультиагент путём к AGI (общему ИИ)?
Исследователи разделились. Один лагерь утверждает: «специализация ролей и координация — суть интеллекта»; другой считает: «масштабирование одной модели — суть, мультиагент лишь инженерный обходной приём». Оба тезиса имеют основания. Практически безопаснее всего рассматривать мультиагент как «способ расширить диапазон ИИ-задач, достижимых сегодня».
Q7. Есть ли промежуточный вариант между одиночным и мультиагентом?
Да. «Одиночный агент + субагенты-как-инструменты». Инструмент Task в Claude Agent SDK — именно это: основной остаётся одиночным агентом, но может по требованию запускать одноразовых субагентов. Без полной сложности мультиагента это раздвигает некоторые границы одиночного. Популярен как разумный компромисс.