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

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

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

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

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

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

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

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

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

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

Как создать AI-агента: пошаговое руководство

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

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

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

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

Мультиагентность — дорогое удовольствие. Инженерная команда 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 — механизм, который останавливает выполнение на критических шагах и требует подтверждения от человека. Без него мультиагентная система в проде опасна. Агент может принять решение, которое приведёт к необратимым последствиям: удалить данные, отправить письмо не тому адресату, списать деньги.

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

• перед выполнением деструктивных операций;
• перед отправкой финального ответа пользователю;
• когда субагент вернул результат с низкой уверенностью.

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

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

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

• Динамическая оркестрация — оркестратор сам решает, что делать дальше, на каждом шаге. Гибко, но непредсказуемо.
• Детерминированная логика — жёсткий процесс, описанный в коде или BPMN. Предсказуемо, но негибко.
• Гибрид — жёсткий процесс описан в BPMN, а LLM принимает решения внутри шагов. 

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

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

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

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

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

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

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

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

LangChain: что это такое и как построить на нём AI-агента

Начинать стоит с прямых вызовов 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 — за «как попросить другого агента что-то сделать». Вместе они покрывают весь стек взаимодействия.

Как стать AI-инженером: роадмап для бэкендера

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

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

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

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

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

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

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

• code_writer — пишет код
• security_checker — проверяет код на уязвимости
• explainer — объясняет результат простым языком

Шаг 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 показали, что сбои мультиагентных систем чаще всего происходят от оркестратора, а не от отдельных агентов.

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

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

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

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

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

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

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

10 AI-навыков, которые должен освоить каждый разработчик

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

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

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

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

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

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

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

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

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

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

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

15 курсов по нейросетям в Яндекс Практикуме: какой же выбрать

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

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

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

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

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

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

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

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