Как собрать мультиагентную систему из оркестратора и субагентов

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

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

Что такое мультиагентная система

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

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

Кто такие оркестратор и субагенты

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

Субагент получает узкую задачу и свой набор инструментов. Он не знает, что происходит за пределами его задачи. Ему дали контекст, инструменты и сказали: «сделай вот это». Он делает и возвращает результат.

По классификации Microsoft субагенты бывают внутренними — частью одного решения, и внешними — отдельными системами, которые живут под управлением других команд. Внешние субагенты — это когда вы не владеете кодом агента, но можете вызвать его по API и получить результат. Например, отдел аналитики поддерживает свой агент для расчёта метрик, а вы дёргаете его через A2A.

Чем это отличается от одного агента с набором инструментов

Ключевое различие — изоляция контекста. У субагента чистое окно, он не тащит на себе историю всего диалога. Он получает ровно то, что нужно для его задачи, и не видит лишнего.

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

Когда мультиагентная система окупается

Мультиагентность — дорогое удовольствие. Инженерная команда Anthropic измерила расходы: одиночный агент сжигает примерно вчетверо больше токенов, чем обычный чат-запрос. Мультиагентная схема с раздачей задач субагентам — примерно в 15 раз больше.

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

Компания Microsoft сформулировала чёткие критерии, когда применять такую архитектуру, а когда нет.

Применять:

Не применять:

Из чего состоит архитектура

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

Зона ответственности оркестратора

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

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

Специализация субагентов

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

Как выглядит описание субагента в конфиге:

{
  "name": "code_reviewer",
  "role": "проверяет код на соответствие стандартам и находит уязвимости",
  "tools": ["read_file", "search_pattern", "check_security"],
  "context_window": 32000,
  "model": "claude-3.5-sonnet"
}

Субагент получает задачу, свои инструменты и контекст. Всё, что выходит за его зону ответственности, он не видит и не обрабатывает.

Память и передача контекста

Оркестратор передаёт субагенту только то, что нужно для выполнения конкретной подзадачи. 

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

{
  "task_id": "subtask-001",
  "agent": "code_reviewer",
  "instruction": "проверь файл src/main.py на уязвимости",
  "context": {
    "file_path": "src/main.py",
    "rules": ["security_standard_v2"]
  }
}

Субагент возвращает результат в том же формате:

{
  "task_id": "subtask-001",
  "status": "completed",
  "result": {
    "issues": 3,
    "severity": ["high", "medium", "low"]
  }
}

Точки, которые контролирует человек

Human-in-the-loop — механизм, который останавливает выполнение на критических шагах и требует подтверждения от человека. Без него мультиагентная система в проде опасна. Агент может принять решение, которое приведёт к необратимым последствиям: удалить данные, отправить письмо не тому адресату, списать деньги.

Где ставить паузу:

По каким схемам работает оркестрация

Оркестрация агентов — это способы координации работы между оркестратором и субагентами. Основные схемы.

Схема	Как работает	Когда брать	Где ломается
Prompt chaining	Агенты выполняются последовательно, результат каждого передаётся следующему	Чёткая последовательность шагов, где каждый зависит от предыдущего	Ошибка на раннем шаге убивает всю цепочку
Orchestrator-workers	Оркестратор раздаёт задачи субагентам и собирает результаты	Задача естественно распадается на независимые подзадачи	Оркестратор может взять работу на себя вместо делегирования
Evaluator-optimizer	Один агент генерирует решение, другой оценивает и отправляет на доработку	Задачи, где качество результата критично и требует итераций	Зацикливание — агенты могут бесконечно править друг друга
Handoff	Управление передаётся от одного агента к другому в зависимости от контекста	Динамические сценарии, где следующий шаг зависит от текущего	Потеря контекста при передаче
Long-running processes	Длительные процессы с сохранением состояния и возможностью восстановления	Задачи, которые выполняются часы или дни	Сложность отладки и восстановления после сбоев

Отдельно стоит сказать про развилку между динамической оркестрацией через LLM, детерминированной логикой и гибридом:

Чем собирать мультиагентную систему

Мультиагентную систему можно собрать на одном из нескольких фреймворков. Основные варианты на 2026 год — в таблице.

Фреймворк	Языки	Модель оркестрации	Порог входа
LangGraph	Python, JS/TS	Граф и явное состояние	Средний — нужен опыт работы с графами
CrewAI	Python	Ролевые команды	Низкий — самый простой старт
OpenAI Agents SDK	Python, JS/TS	Handoff	Низкий — минимальная абстракция
Google ADK	Python, TS, Java, Go	A2A и RemoteA2aAgent	Средний — привязан к экосистеме Google
Microsoft Agent Framework	Python, .NET	Графовые workflow	Средний — для экосистемы Microsoft

Есть коротко:

LangGraph — для тех, кому нужна аудируемость и явное управление состоянием. 

CrewAI — для быстрого прототипирования с ролевыми агентами. OpenAI Agents 

SDK — для чистого делегирования с минимальной абстракцией. 

Google ADK — мультимодальность и интеграция с Vertex AI. 

Microsoft Agent Framework вышел в GA в апреле 2026 как преемник AutoGen и Semantic Kernel.

Начинать стоит с прямых вызовов API. Фреймворк нужен, когда появились память между сессиями, восстановление после ошибок, несколько специализированных агентов и человеческие апрувы (подтверждения). Если вы пишете пять субагентов, которые общаются через JSON — фреймворк только добавит сложности.

Как агенты договариваются между собой

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

MCP для инструментов

Model Context Protocol (MCP) — вертикальный слой: агент подключается к инструментам, базам и API. В декабре 2025 Anthropic передала спецификацию в Agentic AI Foundation при Linux Foundation. Текущая версия спецификации — 2025-11-25, транспорт — Streamable HTTP.

К моменту передачи проекта открытая экосистема насчитывала свыше 10 тысяч общедоступных серверов. В реестрах сообщества индексируется больше 18 000 MCP-серверов. В июле 2026 вышла версия MCP 728 — stateless, без необходимости рукопожатия сессии.

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

A2A для агентов

Agent-to-Agent (A2A) — горизонтальный слой: агенты находят друг друга, договариваются, обмениваются результатами. Google запустила A2A в апреле 2025, v1.0 вышла в марте 2026. В августе 2026 Google передала протокол в Agentic AI Foundation при Linux Foundation.

Обнаружение агентов работает через Agent Card — JSON-манифест, который публикуется по адресу /.well-known/agent.json. В нём описано, кто такой агент, что умеет, где его найти и как аутентифицироваться.

Жизненный цикл задачи: submitted → working → completed/failed. Пять официальных SDK: Python, TypeScript, Java, Go, .NET.

В 2026 году идёт работа над совместной спецификацией стыковки MCP и A2A. MCP отвечает за «как подключиться к инструменту», A2A — за «как попросить другого агента что-то сделать». Вместе они покрывают весь стек взаимодействия.

Собираем первую систему по шагам

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

Шаг 1. Выбрать задачу, которая честно распадается на подзадачи разных типов

Наша задача — «напиши функцию для валидации email, проверь код на уязвимости, объясни, что получилось». Она распадается на три подзадачи: написание кода, проверка безопасности, генерация объяснения.

Шаг 2. Описать роли

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

Три субагента:

Шаг 3. Написать системный промт оркестратора с правилом делегирования

Ты — оркестратор. Твоя задача — разбить запрос пользователя на подзадачи и делегировать их субагентам.
У тебя есть три субагента: code_writer, security_checker, explainer.
Правила делегирования:
1. Сначала вызови code_writer для генерации кода.
2. Результат code_writer передай security_checker.
3. Результаты обоих передай explainer для финального объяснения.
4. Никогда не выполняй работу субагентов сам.

Шаг 4. Описать субагентов с ограниченным набором инструментов

{
  "name": "code_writer",
  "role": "пишет код на Python по описанию задачи",
  "tools": ["write_python_code", "run_tests"],
  "context": "получает описание задачи, возвращает код"
}

{
  "name": "security_checker",
  "role": "проверяет код на уязвимости",
  "tools": ["scan_code", "check_owasp"],
  "context": "получает код, возвращает список уязвимостей"
}

{
  "name": "explainer",
  "role": "объясняет код и результаты проверки простым языком",
  "tools": ["generate_explanation"],
  "context": "получает код и список уязвимостей, возвращает объяснение"
}

Шаг 5. Задать формат сообщения между агентами

{
  "task_id": "uuid",
  "from": "orchestrator",
  "to": "code_writer",
  "instruction": "напиши функцию для валидации email",
  "context": {}
}

Субагент возвращает:

{
  "task_id": "uuid",
  "from": "code_writer",
  "to": "orchestrator",
  "status": "completed",
  "result": {
    "code": "def validate_email(email): ..."
  }
}

Шаг 6. Прогнать на десяти реальных запросах и сравнить с одним агентом по стоимости и качеству

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

Что ломается в мультиагентных системах

Ошибки в мультиагентных системах — это не баги в коде, а баги в архитектуре. Исследователи из Нанкинского университета на ICML 2026 показали, что сбои мультиагентных систем чаще всего происходят от оркестратора, а не от отдельных агентов.

Наиболее распространенные ошибки:

Как понять, что система работает

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

Метрики, которые стоит считать:

Логирование каждого вызова субагента — обязательное условие отладки. Без логов вы не поймёте, почему система выдала странный ответ.

Частые вопросы

Чем субагент отличается от инструмента?

Инструмент — это функция, которую агент вызывает для получения данных или выполнения действия. Субагент — это автономный ИИ-агент со своим контекстным окном и набором инструментов. Субагент принимает решения, инструмент — нет.

Сколько субагентов оптимально в одной системе?

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

Можно ли собрать мультиагентную систему без фреймворка?

Да. Прямые вызовы API и JSON-сообщения между агентами — это и есть мультиагентная система. Фреймворк добавляет удобство, но не является обязательным. Начинайте без фреймворка, добавляйте его, когда почувствуете боль.

Нужен ли MCP, если агенты уже общаются через A2A?

Да. MCP — для подключения к инструментам и данным. A2A — для общения между агентами. Это разные слои, они не заменяют друг друга. MCP решает, как агент получает доступ к базе данных. A2A решает, как один агент просит другого что-то сделать.

Как посчитать, окупается ли мультиагентная схема?

Сравните стоимость выполнения одной задачи на мультиагентной системе и на одиночном агенте. Умножьте разницу на количество задач в месяц. Если мультиагентная система даёт выгоду (качество, скорость, надёжность), которая превышает разницу в стоимости — окупается.

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

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

Советуем дополнительно почитать

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

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

Что такое MLOps — операции машинного обучения для задач ML-разработки — дисциплина мониторинга и автоматизации релизов моделей, которая стоит за курсом из галереи и за метриками из последнего раздела статьи.

Как защитить API-ключи от утечки: чек-лист разработчика — актуально для системы, где несколько субагентов дёргают внешние инструменты и API одновременно, у каждого — свои ключи доступа.

12 AI GitHub-репозиториев 2026 года: локальные модели, автоматизация и агенты — где посмотреть на CrewAI, LangChain и другие фреймворки из статьи в виде реального опенсорсного кода со звёздами и историей коммитов.