Мультиагентные системы: оркестрация нескольких AI-агентов

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

Это не «четыре чата вместо одного». Это архитектурный паттерн, при котором несколько AI-агентов работают под управлением оркестратора. Каждый — со своей ролью, своими инструментами и зоной ответственности. А оркестратор следит, чтобы они не мешали друг другу и не дублировали работу. Если вы уже собрали своего первого агента и он упёрся в потолок — время подниматься на уровень выше.

Почему одного агента недостаточно

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

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

Вторая проблема — специализация. Агент, который умеет искать задачи в Jira и писать SQL-запросы, уже раздут по системному промпту. Добавьте ему «анализ трендов», «форматирование документа» и «проверку на противоречия» — и он начнёт путаться. Не потому что модель глупая. А потому что контекст перегружен инструкциями. Это как дать одному сотруднику пять должностных — он будет переключаться и ошибаться, даже если компетентен в каждой роли по отдельности.

Мультиагентная система решает обе проблемы:

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

Результат: пять последовательных шагов одиночного агента превращаются в три агента, работающих параллельно. Не «в пять раз быстрее» — но ощутимо. А главное — качественнее.

Три паттерна оркестрации

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

Последовательная (Pipeline)

Агенты выстраиваются в цепочку. Выход первого — вход второго. Выход второго — вход третьего.

Классический пример: Researcher собирает сырые данные → Analyst сравнивает с историей и ищет аномалии → Writer оформляет в документ. Каждый ждёт предыдущего. Плюс: предсказуемо, легко отлаживать — видно, на каком шаге всё пошло не так. Минус: медленно. Общее время = сумма времён всех агентов. Плюс задержки на передачу контекста между ними.

Pipeline хорош для задач, где результат шага N критичен для шага N+1. Например, нельзя анализировать данные, которые ещё не собраны.

Параллельная (Fan-out / Fan-in)

Оркестратор (Supervisor) раздаёт подзадачи агентам одновременно. Они работают независимо. Результаты собираются, объединяются и отдаются пользователю.

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

Fan-out / Fan-in — рабочий паттерн для большинства аналитических задач. Параллельный сбор из Jira, Confluence и БД плюс параллельный анализ собранного — и результат готов за время самого медленного агента, а не суммы всех.

Децентрализованная (Swarm)

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

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

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

Архитектура оркестратора: что внутри

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

Компоненты оркестратора:

• Декомпозитор — разбирает задачу пользователя на подзадачи. «Подготовь комплексный отчёт по релизу» превращается в: «собрать задачи спринта», «сравнить с прошлым спринтом», «найти архитектурные решения», «написать черновик отчёта и ADR».
• Диспетчер — определяет, какому агенту какую подзадачу отдать. Учитывает роли агентов и их текущую загрузку (в продвинутых реализациях).
• Агрегатор — собирает результаты агентов, проверяет полноту и собирает в единый документ. Если какого-то результата не хватает — перезапускает соответствующего агента.
• Монитор — следит за таймаутами и зацикливаниями. Если агент не ответил за N секунд или трижды вернул противоречивый результат — Supervisor эскалирует: либо перезапускает, либо сообщает пользователю, что подзадача не решена.

graph TB
  USER["Аналитик<br/>ставит задачу"]
  SUPERVISOR["Supervisor Agent<br/>оркестратор"]
  MEMORY["Общая память<br/>векторная БД<br/>+ рабочая"]
  R_AGENT["Researcher Agent<br/>сбор данных"]
  A_AGENT["Analyst Agent<br/>анализ и сравнение"]
  W_AGENT["Writer Agent<br/>документирование"]
  V_AGENT["Validator Agent<br/>проверка результатов"]
  JIRA["Jira API"]
  CONF["Confluence API"]
  DB["База данных"]
  RESULT["Результат<br/>комплексный отчёт<br/>+ ADR + аналитика"]

  USER -->|"задача"| SUPERVISOR
  SUPERVISOR -->|"читает контекст"| MEMORY
  SUPERVISOR -->|"делегирует сбор"| R_AGENT
  SUPERVISOR -->|"делегирует анализ"| A_AGENT
  SUPERVISOR -->|"делегирует текст"| W_AGENT
  R_AGENT --> JIRA
  R_AGENT --> CONF
  R_AGENT --> DB
  R_AGENT -->|"собранные данные"| MEMORY
  A_AGENT -->|"читает данные"| MEMORY
  A_AGENT -->|"результат анализа"| MEMORY
  W_AGENT -->|"читает анализ"| MEMORY
  W_AGENT -->|"черновик"| V_AGENT
  V_AGENT -->|"замечания"| W_AGENT
  V_AGENT -->|"утверждён"| RESULT
  SUPERVISOR -.->|"мониторит"| R_AGENT
  SUPERVISOR -.->|"мониторит"| A_AGENT
  SUPERVISOR -.->|"мониторит"| W_AGENT

  style USER fill:#e0e0e0,stroke:#999,color:#333
  style SUPERVISOR fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style MEMORY fill:#7b68ee,stroke:#5a4db2,color:#fff
  style R_AGENT fill:#50c878,stroke:#3a9a5c,color:#fff
  style A_AGENT fill:#f0a500,stroke:#c88400,color:#fff
  style W_AGENT fill:#50c878,stroke:#3a9a5c,color:#fff
  style V_AGENT fill:#e0e0e0,stroke:#999,color:#333
  style JIRA fill:#50c878,stroke:#3a9a5c,color:#fff
  style CONF fill:#50c878,stroke:#3a9a5c,color:#fff
  style DB fill:#50c878,stroke:#3a9a5c,color:#fff
  style RESULT fill:#4a90d9,stroke:#2c5f8a,color:#fff

На схеме — полная архитектура мультиагентной системы с Supervisor. Аналитик (серый) ставит задачу. Supervisor (синий) — центральный узел: читает общую память (фиолетовый), делегирует подзадачи трём агентам-исполнителям. Researcher (зелёный) ходит в Jira, Confluence и БД, складывает сырые данные в память. Analyst (жёлтый) читает эти данные, сравнивает с историей и пишет результаты анализа обратно в память. Writer (зелёный) забирает анализ из памяти, генерирует черновик и отправляет Validator (серый) на проверку. Если есть замечания — Writer дорабатывает, если нет — результат уходит пользователю.

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

Практический кейс: отчёт по релизу силами трёх агентов

Разберу конкретный сценарий. Задача аналитика: «Подготовь комплексный отчёт по релизу — что сделано, какие риски, какие архитектурные решения приняты, черновик ADR».

Одиночный агент решал бы это последовательно: Jira → Confluence → анализ → текст. Минут пять-десять на всё. Мультиагентная система делает это иначе:

sequenceDiagram
  participant A as Аналитик
  participant S as Supervisor
  participant R as Researcher
  participant AN as Analyst
  participant W as Writer
  participant M as Память
  participant J as Jira
  participant C as Confluence

  A->>S: "Подготовь комплексный отчёт по релизу"
  S->>S: Декомпозиция задачи на подзадачи
  S->>M: Сохранить цель и контекст

  par Параллельный запуск агентов
      S->>R: "Собери все задачи спринта"
      R->>J: JQL-запрос
      J-->>R: Список задач
      R->>C: Поиск ADR за период
      C-->>R: Архитектурные решения
      R->>M: Сохранить сырые данные
  and
      S->>AN: "Сравни с прошлым спринтом"
      AN->>M: Читает историю спринтов
      M-->>AN: Данные Sprint 23
      AN->>AN: Анализ: тренды, аномалии, риски
      AN->>M: Сохранить результаты анализа
  end

  S->>M: Проверка: все подзадачи выполнены?
  M-->>S: Статус: сбор и анализ готовы

  S->>W: "Напиши черновик отчёта и ADR"
  W->>M: Читает данные и анализ
  M-->>W: Полный контекст
  W->>W: Генерация документа
  W->>S: Черновик готов

  S->>S: Финальная сборка и форматирование
  S-->>A: Комплексный отчёт + ADR + аналитика

  Note over S,A: Оркестратор координирует<br/>трёх агентов параллельно<br/>и выдаёт единый результат

На диаграмме три фазы. Первая — Supervisor декомпозирует задачу и сохраняет контекст в память. Вторая — параллельный запуск: Researcher идёт в Jira и Confluence, Analyst в это же время читает историю из памяти и готовит сравнение. Они не ждут друг друга. Третья фаза — последовательная: Supervisor проверяет, что сбор и анализ завершены, и запускает Writer. Тот читает из памяти всё, что собрали Researcher и Analyst, генерирует документ и возвращает Supervisor. Финальная сборка и форматирование — и комплексный отчёт у аналитика.

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

Что внутри каждого агента

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

Общая память — критический компонент. Без неё агенты не могли бы обмениваться результатами. С ней — Researcher кладёт данные, Analyst их читает, Writer собирает итог. Это реализуется через векторную БД или структурированное хранилище, доступное всем агентам через один контекст.

Подключение инструментов

Инструменты агентов подключаются так же, как и у одиночного агента — через MCP-сервер. Researcher получает доступ к Jira и Confluence. Analyst — к историческим данным и SQL-запросам. Writer — к шаблонам документов. Разграничение инструментов по ролям — не просто архитектурная чистота. Это защита: Writer не может случайно вызвать SQL-запрос, потому что в его промпте нет такого инструмента.

Если вы ещё не работали с MCP, рекомендую заглянуть в разбор протокола и его применение для подключения LLM к Jira и Confluence — там детально о том, как инструменты описываются и вызываются.

Когда мультиагентная система оправдана, а когда — overengineering

Мультиагентная система требует инфраструктуры: оркестратор, общая память, мониторинг, логирование. Прежде чем разворачивать этот зоопарк, проверьте по таблице:

Простой тест: откройте системный промпт вашего агента. Если он начинается со слов «ты можешь: искать задачи, анализировать тренды, писать документы, проверять противоречия, форматировать отчёты, сравнивать спринты, искать ADR…» — вы переросли одного агента. Разделяйте.

С другой стороны, если задача — «собери задачи спринта из Jira» — не надо разворачивать трёх агентов с оркестратором. Один вызов API справится быстрее. Оговорюсь: мультиагентная архитектура — не серебряная пуля. Это инструмент для сложных задач.

Заключение

Мультиагентная система — это не «давайте запустим пять чатов параллельно». Это архитектура с Supervisor, общей памятью и специализированными агентами под управлением оркестратора. Три паттерна — pipeline, fan-out/fan-in, swarm — закрывают почти все сценарии аналитика, от простой цепочки до параллельного сбора из трёх источников.

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

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