Мультиагентная система (Multi-Agent System, MAS) — это схема, в которой несколько ИИ-агентов делят между собой роли и работают параллельно, чтобы выполнить одну задачу. Агент-координатор делит работу, агенты-исполнители (субагенты) ищут информацию или пишут каждый в своём отдельном контексте, а координатор собирает результаты.
Но сама по себе добавка агентов не делает систему умнее. В эксперименте Google Research и других исследователей на шести типах задач мультиагентные схемы оказались до 81% лучше одного агента там, где работу можно разделить, и до 70% хуже там, где её нужно делать шаг за шагом. В статье разобраны определение и пять шаблонов, а затем — на основе этого эксперимента и открытых материалов Anthropic, Cognition и других — показано, как понять, в каких задачах подход помогает, а в каких вредит.
Мультиагентность = команда, которая делит роли и работает параллельно
— вместо того чтобы поручать всё одному ИИ, работу делит небольшая команда специалистов
У каждого своё контекстное окно, и все работают параллельно.
Координатор проверяет результаты, прежде чем их объединить: в экспериментах наличие такого проверяющего координатора сильно влияло на то, насколько распространялись ошибки.
Содержание
- 1. Что такое мультиагентная система
- 2. Зачем заставлять несколько ИИ работать вместе
- 3. Пять шаблонов
- 4. Что показали эксперименты: где помогает, а где вредит
- 5. Как это используют реальные продукты
- 6. Стоимость: около 15 раз больше токенов, чем в чате
- 7. Таблица решения: стоит ли применять
- 8. Главное в проектировании и типичные виды сбоев
- 9. Как каждый шаблон записывается в основных SDK
- Резюме
- FAQ
1. Что такое мультиагентная система
Мультиагентная система (Multi-Agent System, MAS) — это схема, в которой несколько ИИ-агентов сообща решают одну задачу. У каждого агента свои инструкции (промпт), свои инструменты и свой контекст, и цель достигается за счёт обмена результатами.
Базовый элемент — один агент — сам прокручивает цикл «подумать → применить инструмент → посмотреть на результат», как описано в статье Что такое ИИ-агент. Точнее всего мультиагентную систему можно представить как этот цикл плюс разделение ролей и параллельность.
Чем она отличается от одного агента
| Аспект | Один агент | Мультиагентная система |
|---|---|---|
| Устройство | Один ИИ прокручивает цикл | Несколько ИИ работают вместе |
| Контекст | Всё помещается в одно окно | Разделён по ролям (посторонняя информация не смешивается) |
| Параллельность | В основном шаг за шагом | Исполнители могут работать одновременно |
| Распространение ошибок | Собственные ошибки накапливаются | Без проверяющего ошибка исполнителя попадает прямо в итог |
| Стоимость | Ниже (около 4 раз больше, чем чат) | Выше (около 15 раз больше, чем чат) |
| Сильная сторона | Пошаговая работа, где каждый шаг зависит от предыдущего | Исследование, сравнение и проверка, которые делятся на независимые части |
Множители токенов — это цифры, которые Anthropic опубликовала о собственной функции исследования (How we built our multi-agent research system, 13 июня 2025 года). Подробнее в разделе 6.
2. Зачем заставлять несколько ИИ работать вместе
Исходная точка такая: «если один агент справляется со всем, используйте одного». Мультиагентная система нужна, когда вы упираетесь в три стены, которые одному агенту по самому его устройству преодолеть трудно.
Три стены, которые трудно пройти одному агенту
Пример эффекта: Anthropic сообщила, что в функции Research у Claude схема с Claude Opus 4 в роли координатора и Claude Sonnet 4 в роли исполнителей показала на внутренней оценке исследовательских задач результат на 90,2% лучше, чем один Opus 4 (тот же источник). Там же сказано, что объём израсходованных токенов сам по себе объяснял 80% разброса результатов (на исследовательской оценке BrowseComp). Иначе говоря, главная сила мультиагентной системы — в том, что отдельные контексты работают бок о бок и прочитывают больше, чем помещается в одного агента.
3. Пять шаблонов
У мультиагентных систем есть несколько типовых форм. В разных продуктах они называются по-разному, но в основном сводятся к пяти. Где это уместно, указана и соответствующая категория из эксперимента в разделе 4 (независимая, централизованная, децентрализованная, гибридная).
3-1. Оркестратор и исполнители (самый распространённый)
Один координатор (оркестратор) делит работу и раздаёт её нескольким исполнителям (субагентам). Каждый исполнитель работает в отдельном контексте и возвращает результат координатору. В терминах эксперимента это централизованная схема. По этому шаблону устроены функция исследования Anthropic, субагенты Claude Code и способ «вызвать агента как инструмент» в OpenAI Agents SDK (Agent.as_tool()).
3-2. Передача (handoff: эстафета ответственных)
Агенты передают управление разговором, фактически говоря «дальше ведёшь ты». В документации OpenAI Agents SDK специалист, получивший передачу, становится активным агентом до конца хода. Подходит для работы «окна приёма», например чтобы направить обращение из приёмной в бухгалтерию или техподдержку. Swarm, экспериментальный предшественник этого SDK, теперь сообщает в своём репозитории, что его заменил Agents SDK, поэтому новые проекты стоит строить на Agents SDK.
3-3. Иерархия (команда команд)
Дерево, где под главным координатором стоят промежуточные координаторы, а под ними — исполнители. В Claude Code субагенты могут запускать своих субагентов по умолчанию на глубину до трёх уровней (официальная документация), а Cursor в версии 2.5 (февраль 2026 года) тоже разрешил исполнителям запускать исполнителей. Каждый лишний уровень добавляет токены и ожидание, поэтому задайте предел глубины.
3-4. Равноправные агенты (дебаты и согласие)
Координатора нет: несколько агентов высказываются на равных и повторяют обмен, пока не придут к согласию. В терминах эксперимента это децентрализованная схема. Исследования Multi-Agent Debate сообщают о росте фактической точности и качества рассуждений. Обычно хорошо работает там, где нужно сопоставлять несколько точек зрения, например при поиске в интернете (раздел 4).
3-5. Конвейер (фиксированный порядок)
Агенты запускаются в фиксированном порядке, например «исследование → структурирование → проверка → выдача». Поскольку следующего агента выбирает программа, а не ИИ, результаты стабильны и легко понять, где произошёл сбой. OpenAI Agents SDK описывает «цепочку» (вывод одного агента — вход следующего) и «цикл оценки» (по очереди работают агент-исполнитель и агент-оценщик) как шаблоны, которые собираются в коде.
Пять шаблонов в одной таблице
4. Что показали эксперименты: где помогает, а где вредит
Какой шаблон выигрывает, зависит от характера работы. В цифрах это показала статья Towards a Science of Scaling Agent Systems исследователей из Google Research, Google DeepMind и других организаций (последняя версия — апрель 2026 года). На трёх семействах моделей — GPT, Gemini и Claude — в ней сравниваются пять схем (один агент и четыре мультиагентные) на шести типах задач и 260 комбинациях (представлена в блоге Google Research в январе 2026 года; указанные в блоге 180 конфигураций относятся к первой версии).
Источник: раздел 4.2 статьи. В исправлении кода и планировании все проверенные мультиагентные схемы уступили одному агенту; показана та, что проиграла меньше всех (исправление кода — от −2,1% до −14,9%, планирование — от −39,1% до −70,0%).
Отсюда следуют три вывода.
- Сильный выигрыш — только там, где работу можно разделить: в финансовом анализе выручку, расходы и рынки можно изучать отдельно и свести в конце, поэтому централизованная схема обошла одного агента примерно на 81%.
- Там, где важен порядок, подход вредит: в задаче планирования, где каждый ход определяет следующий, все схемы оказались хуже одного агента. При разделении работы допущения исполнителей расходятся, а силы уходят на согласование.
- Исправление кода тоже не улучшилось: Anthropic также пишет, что в большинстве задач программирования по-настоящему параллельных частей меньше, чем в исследовательских (её статья), и это согласуется с результатом.
Проверяющий координатор сдерживает распространение ошибок
В той же статье измерено, насколько ошибки исполнителей переходят в итоговый результат при каждой схеме (кратность, где один агент = 1).
Независимая (без обсуждения и проверки)
17,2×
Результаты просто ставятся рядом, и ошибки остаются
Децентрализованная (дебаты на равных)
7,8×
Обсуждение исправляет часть ошибок, но проверять некому
Гибридная
5,1×
Координатор плюс частичное обсуждение между исполнителями
Централизованная (координатор проверяет)
4,4×
Координатор проверяет результаты исполнителей, прежде чем объединить
Источник: таблица 5 статьи (Error Amp). По той же таблице число ходов на задачу в среднем составляло 7,2 у одного агента против 27,7 у централизованной и 44,3 у гибридной схемы.
«Если один агент уже решает 45% и больше, добавление агентов обычно вредит». Авторы сообщают, что в задачах, где точность одного агента уже превышает примерно 45%, добавление агентов, как правило, снижает результат. Эксперимент подтверждает порядок действий: сначала измерить одного агента и только по этой цифре решать, добавлять ли ещё.
5. Как это используют реальные продукты
Функция исследования Anthropic: число исполнителей зависит от сложности вопроса
Research у Claude — классический пример схемы «оркестратор и исполнители»: координатор делит вопрос, исполнители параллельно ищут, координатор собирает результаты. Самое полезное в опубликованном устройстве — то, что в промпте прописано, сколько исполнителей брать в зависимости от сложности вопроса (её статья).
| Тип вопроса | Число исполнителей | Вызовы инструментов |
|---|---|---|
| Проверка простого факта | 1 (только координатор) | 3–10 |
| Прямое сравнение | 2–4 | По 10–15 у каждого |
| Сложное исследование | Иногда больше 10 | У каждого исполнителя чётко отделённая зона ответственности |
По словам Anthropic, до появления этих правил ранние версии допускали ошибки вроде запуска 50 исполнителей ради простого вопроса. Если вы строите свою систему, быстрее всего вставить эту таблицу в промпт как правило выбора масштаба. Кроме того, переход на параллельный вызов поиска и других инструментов сократил время исследования сложных вопросов до 90%.
Субагенты в Claude Code и Codex
В Claude Code можно поручать поиск, ревью и подобную работу субагентам. Каждый субагент работает в своём контексте и возвращает главному агенту только сводку, поэтому основной контекст не забивается. По умолчанию одновременно может работать до 20 субагентов с вложенностью до трёх уровней. Чем это отличается от «команд агентов», где исполнители общаются друг с другом по ходу работы, разобрано в статье Субагенты и команды агентов в Claude Code, а как просить параллельную работу в сравнении с Codex — в статье Параллельные субагенты в Codex и Claude Code.
Devin (Cognition): от «не стройте» к «координируйте»
В июне 2025 года Cognition опубликовала статью «Don't Build Multi-Agents», где утверждала, что параллельные исполнители, не знающие решений друг друга, выдают противоречащие результаты. Два её принципа: «делиться контекстом, причём полным ходом работы агента, а не отдельными сообщениями» и «действия несут неявные решения, а противоречащие решения дают плохой результат».
В марте 2026 года та же компания выпустила функцию, в которой Devin делит крупную задачу и поручает её нескольким Devin, работающим параллельно, каждый — в своей виртуальной машине. Главный Devin следит за ходом работы, разрешает конфликты и собирает результаты. От параллельности не отказались — пришли к схеме, где главный агент берёт на себя расхождения между исполнителями. Это совпадает с выводом раздела 4 о проверяющем координаторе.
Cursor: не ждать исполнителей
В версии 2.5 (17 февраля 2026 года) Cursor сделал субагентов асинхронными, чтобы главный агент продолжал работу, не дожидаясь их. Исполнители также могут запускать своих исполнителей. Anthropic тоже пишет, что синхронное выполнение, при котором координатор ждёт окончания работы исполнителей, создаёт узкие места, так что «не заставлять главного агента ждать» стало общей задачей для всех разработчиков.
6. Стоимость: около 15 раз больше токенов, чем в чате
Anthropic пишет, что агенты тратят примерно в 4 раза больше токенов, чем чат, а мультиагентные системы — примерно в 15 раз (её статья). Применительно к вашей задаче расчёт выглядит так.
Пример расчёта (множители — по функции исследования Anthropic; в других задачах они другие)
Вопрос, который в чате стоит 10 000 токенов → около 40 000 с одним агентом и около 150 000 токенов с мультиагентной системой.
При 100 запросах в день: чат — 1 млн, один агент — 4 млн, мультиагентная система — 15 млн токенов. Умножьте на цену за токен из официального прайса используемой модели.
Растут не только токены
Разделяйте жёсткие пределы и ориентиры
Когда исполнители запускают исполнителей и что-то уходит в цикл, расходы резко растут. При работе с Claude есть два вида пределов, которые действуют по-разному.
| Предел | Где задаётся | Останавливает ли выполнение |
|---|---|---|
| Предел расходов | max_budget_usd в Claude Agent SDK (maxBudgetUsd в TypeScript) | Да (новые исполнители не запускаются, запрос завершается) |
| Глубина вложенности | Переменная окружения CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH (по умолчанию 3; при 1 вложенности нет) | Да (исполнители нижнего уровня делают работу сами) |
| Одновременные исполнители | Переменная окружения CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS (по умолчанию 20) | Да (сверх предела исполнители не запускаются) |
| Бюджет задачи | task_budget в Claude API (бета, минимум 20 000 токенов) | Нет (ориентир, по которому модель распределяет усилия) |
Источники: Subagents in the Agent SDK и Task budgets (проверено 12 ноября 2026 года). Три жёстких предела выше действуют в TypeScript SDK v0.3.219 и Python SDK v0.2.127 и новее; в более ранних версиях части из них нет или значения по умолчанию другие. В документации бюджет задачи назван рекомендательным, а не принудительным, поэтому, если выполнение нужно гарантированно остановить, сочетайте его с пределом расходов или max_tokens.
7. Таблица решения: стоит ли применять
Если свести всё сказанное, решение почти всегда определяется пятью вопросами. Отвечайте сверху вниз; если хотя бы один ответ попадает в колонку «один агент», начните с одного агента.
| Вопрос | В пользу мультиагентной системы | В пользу одного агента | Основание |
|---|---|---|---|
| Можно ли разделить работу на независимые части? | Да (по компаниям, документам, аспектам) | Каждый шаг зависит от предыдущего результата | Финансовый анализ +80,8%, планирование от −39,1% до −70,0% |
| Насколько хорошо уже справляется один агент? | Точность одного агента низкая | Один агент уже решает около 45% и больше | Статья Google Research и других |
| Нужен ли исполнителям общий контекст? | Каждому хватает своей информации | Без общего контекста результаты противоречат друг другу (большая часть программирования) | Anthropic, Cognition |
| Помещается ли всё в один контекст? | Материалов слишком много, контекст одного агента переполняется | Помещается в контекст одного агента | Объём токенов объяснял 80% разброса результатов |
| Стоит ли результат 15-кратного расхода токенов? | Высокая ценность каждого запроса (отчёты об исследовании, аудите, сравнении) | Массовая типовая обработка, приём обращений с мгновенным ответом | ~15 раз по данным Anthropic |
Anthropic и в своём руководстве по созданию агентов советует искать максимально простое решение и усложнять его только при необходимости. Порядок первых шагов и минимальные примеры кода — в статье Как построить мультиагентную систему, а как сделать первого одиночного агента — в статье Как создать ИИ-агента.
8. Главное в проектировании и типичные виды сбоев
① Дайте каждому исполнителю цель, формат результата, инструменты и границы
Anthropic пишет, что при расплывчатых инструкциях исполнители неверно понимают задачу, повторяют те же поиски, что и другие, или не находят нужной информации. Укажите каждому исполнителю (1) цель, (2) формат, в котором вернуть результат, (3) инструменты и источники, которыми можно пользоваться, и (4) границы задачи. Субагент в Claude Agent SDK не получает разговор главного агента: ему передаётся только промпт, с которым его вызывают (официальная документация), поэтому пути к файлам и уже принятые решения пишите прямо в этот промпт.
② Укажите, насколько глубоко копать
Исполнители плохо решают сами, насколько глубоко исследовать. Пропишите правила масштаба вроде таблицы из раздела 5 и задайте глубину рассуждений. Параметр effort у Claude можно задать для каждого исполнителя, а в определении агента в Agent SDK доступны значения от low до max. Простых исполнителей держите «лёгкими», проверяющих — «глубокими», и расходы будут ниже.
③ Сделайте проверку частью работы координатора
Как показал раздел 4, централизованная схема, где координатор проверяет результаты перед объединением, распространяла ошибки гораздо меньше, чем независимая без проверки (4,4× против 17,2×). Включите в инструкции координатора шаг поиска противоречий между результатами исполнителей и проверки доказательств перед тем, как их принять.
④ Знайте типы сбоев
Исследователи из Калифорнийского университета в Беркли и других организаций разделили сбои на 3 категории и 14 типов, изучив более 1600 журналов выполнения семи мультиагентных систем (Why Do Multi-Agent LLM Systems Fail?). Это удобный контрольный список при пересмотре архитектуры.
| Категория | Что происходит | Что делать |
|---|---|---|
| Проблемы устройства | Агенты не следуют инструкциям о роли или задаче, повторяют одни и те же шаги, не знают, когда остановиться | Прописать в промптах роли, рамки и условия завершения |
| Рассогласование агентов | Допущения расходятся, нужная информация не передаётся, мнения других агентов игнорируются | Делиться полным ходом работы; координатор разрешает расхождения |
| Недостаточная проверка | Преждевременное завершение, отсутствие проверки или поверхностная проверка | Назначить проверяющего (координатора или отдельного исполнителя) |
⑤ С самого начала стройте журналирование
Если не видно, что делает мультиагентная система, её невозможно исправить. С первого дня записывайте входы и выходы каждого исполнителя, время, токены и вызванные инструменты. Об оценке Anthropic пишет, что начинала с примерно 20 запросов, отражающих реальное использование, и поручала ИИ оценивать их по рубрике. Практичнее следить за изменениями на небольшом наборе запросов, чем ждать большой системы оценки.
9. Как каждый шаблон записывается в основных SDK
Один и тот же шаблон в разных SDK называется по-разному. Как выбирать между ними (скорость прототипирования, зрелость для продакшена, расход токенов), разобрано в статье Сравнение фреймворков ИИ-агентов; здесь показано только, какой элемент соответствует каждому шаблону из раздела 3.
| SDK | Оркестратор и исполнители | Передача / конвейер |
|---|---|---|
| Claude Agent SDK | Исполнители задаются в agents и вызываются инструментом Agent (прежнее название Task) | Отдельного элемента нет; конвейер — это последовательный вызов агентов из вашего кода |
| OpenAI Agents SDK | Исполнители вызываются как инструменты через Agent.as_tool() | Управление передаётся через handoffs; цепочки и параллельный запуск собираются в коде |
| LangGraph | Ветвление от узла-координатора к узлам-исполнителям | Порядок, ветвления и циклы записываются как граф из узлов и рёбер |
| Strands Agents (AWS) | Исполнители вызываются как инструменты через Agents as Tools | В Swarm исполнители передают работу друг другу; в Graph или Workflow задаётся порядок |
| Microsoft Agent Framework | Содержит шаблоны мультиагентной оркестрации как готовые элементы | Порядок задаётся как рабочий процесс (workflow) |
Microsoft перевела репозиторий AutoGen в архив и больше не выпускает для него исправлений ошибок и уязвимостей (проверено 12 ноября 2026 года). Для новых проектов рекомендован преемник — Microsoft Agent Framework. Минимальные примеры кода для каждого SDK — в статье Как построить мультиагентную систему.
Резюме
- Мультиагентная система распределяет роли между несколькими ИИ, которые параллельно выполняют одну задачу. Она преодолевает стены одного агента: переполнение контекста, отсутствие параллельности и совмещение ролей «делает» и «проверяет».
- Пять шаблонов: оркестратор и исполнители, передача, иерархия, равноправные агенты и конвейер. Самый распространённый — оркестратор и исполнители.
- Помогает ли подход, зависит от работы. В делимом финансовом анализе он обошёл одного агента на +80,8%, в планировании, где важен порядок, проиграл от 39,1% до 70,0%, в исправлении кода улучшения тоже не было.
- С проверяющим координатором распространение ошибок снизилось с 17,2× (независимая схема) до 4,4×.
- Токенов уходит примерно в 15 раз больше, чем в чате (у одного агента — примерно в 4 раза). Расходы, глубину и число одновременных исполнителей задавайте жёсткими пределами, которые действительно останавливают выполнение.
- Порядок решений: сначала постройте и измерьте одного агента. Выделяйте исполнителей только для делимых частей, где одного агента оказалось недостаточно.
FAQ
Q1. Мультиагентная система всегда лучше «умного» одиночного агента?
Нет. Функция исследования Anthropic оказалась на 90,2% лучше одного агента, но речь о задачах, которые делятся на независимые части. В эксперименте Google Research и других все мультиагентные схемы уступили одному агенту в задаче планирования, где важен порядок. Всё решает то, можно ли разделить работу.
Q2. Помогает ли мультиагентный подход в программировании?
Если несколько исполнителей пишут части одного исправления, это обычно не помогает. В эксперименте все мультиагентные схемы уступили одному агенту в исправлении кода (SWE-bench Verified) — от −2,1% до −14,9%. А вот поручать исполнителям независимую работу — поиск, ревью, запуск тестов, — чтобы основной контекст оставался свободным, — типичный сценарий для субагентов Claude Code.
Q3. Можно ли перейти от одного агента к мультиагентной системе постепенно?
Да. Сначала постройте одного агента и измерьте точность, токены и время; когда станет видно, где переполняется контекст или что можно выполнять параллельно, выделите в исполнителей только эти части. Если с самого начала проектировать всё как мультиагентную систему, вы не сможете измерить, что на самом деле помогает.
Q4. Есть ли стандартный протокол коммуникации между агентами?
Для связи агентов с инструментами и данными де-факто стандартом стал MCP (Model Context Protocol). Он возник в Anthropic, в декабре 2025 года передан в Agentic AI Foundation при Linux Foundation и принят OpenAI, Microsoft, AWS и другими. Для общения агентов между собой есть созданный Google A2A (Agent2Agent), который тоже перешёл в Linux Foundation. ACP (Agent Communication Protocol) от IBM в августе 2025 года влился в A2A.
Q5. Защитит ли бюджет задачи от неконтролируемого роста расходов?
Сам по себе — нет. Бюджет задачи в Claude API — это ориентир, по которому модель распределяет усилия, и документация прямо говорит, что он не принудительный. Чтобы гарантированно остановить выполнение, задайте предел расходов в Agent SDK (max_budget_usd) и пределы глубины вложенности и числа одновременных исполнителей (таблица в разделе 6).
Q6. «Субагенты» и «мультиагентность» — это разные вещи?
Субагенты — это исполнители в шаблоне «оркестратор и исполнители» внутри мультиагентной системы. В Claude Agent SDK главный агент остаётся один и вызывает исполнителей инструментом Agent только при необходимости. Схемы, в которых исполнители напрямую общаются друг с другом по ходу работы (например, команды агентов в Claude Code), ближе к шаблону равноправных агентов или к гибридному.
