Мультиагентная система (Multi-agent system)

Мультиагентная система (multi-agent system) — это вычислительная система, в которой несколько автономных агентов взаимодействуют в общей среде и решают индивидуальные или коллективные задачи. В контексте LLM это обычно означает не одного универсального агента, а набор специализированных ролей и правил координации: кто маршрутизирует задачу, кто выполняет подзадачу, кто проверяет ответ и как между участниками передаётся состояние.

Английский термин: multi-agent system. Рядом в документации часто встречаются выражения multi-agent orchestration и multi-agent workflow; это не полные синонимы, а скорее описание того, как именно координируются агенты.

Практический вердикт: мультиагентность полезна, когда задачу действительно нужно делить между ролями, ветвить или проверять через отдельные шаги. Если же всё надёжно решается одним AI Agent (ИИ-агентом) и простым workflow, лишние агенты часто добавляют больше координации, чем пользы. Редакционное ограничение: в этой статье нет универсального сравнения цен, задержек и качества ответов, потому что исходники пакета подтверждают архитектуры, статусы проектов и версии, но не дают сопоставимых кросс-вендорных бенчмарков и прайсинга.

Простыми словами

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

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

Как это работает

Базовое определение даёт IEEE: multi-agent systems — это вычислительные frameworks, где несколько автономных сущностей взаимодействуют в общей среде ради индивидуальных или общих целей. В современных LLM-инструментах различия между реализациями обычно сводятся к трём вещам: стилю оркестрации, управлению состоянием и режиму выполнения.

Пользователь
    |
    v
[Координатор / Router]
   /      |       
  v       v        v
[Agent A][Agent B][Agent C]
         |       /
    v     v      v
 [Общее состояние / среда]
            |
            v
 [Guardrail / проверка человеком]
            |
            v
      Финальный ответ

1. Поступает задача. Система получает запрос и решает, нужен ли один агент или несколько ветвей обработки.
2. Выбирается паттерн координации. В Microsoft Agent Framework задокументированы встроенные оркестрации Sequential, Concurrent, Handoff, Group Chat и Magentic. В OpenAI Agents SDK многoагентные паттерны выражаются через небольшой набор примитивов: agents, handoffs и guardrails.
3. Агенты обмениваются управлением или работают параллельно. Если вам нужен явный граф, LangGraph описывает workflow через State, Nodes и Edges, а в multi-agent-паттернах отдельно выделяет subagents, handoffs, skills, router и custom workflow.
4. Сохраняется контекст. На практике это может быть общее состояние, память, знания о ходе выполнения или журнал шагов. В документации CrewAI упор сделан на crews и flows, а также на guardrails, memory, knowledge и observability.
5. Результат проходит контроль. Для чувствительных сценариев важны guardrails и human-in-the-loop. Microsoft прямо документирует поддержку human-in-the-loop, а OpenAI выделяет guardrails как один из базовых примитивов SDK.

Из этого следует важная мысль: мультиагентная система — это не один конкретный паттерн, а класс архитектур. Один проект может строиться на handoff между двумя агентами, другой — как явный граф с состоянием и проверками, третий — как role-based crew.

Где применяется

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

• Передача задачи между специализациями. В OpenAI Agents SDK это выражается через handoffs: один агент может передать выполнение другому, если следующая подзадача требует других инструкций или инструментов.
• Явные workflow с ветвлениями и контролем. Microsoft Agent Framework делает акцент на agents, harness, workflows и integrations, а также на графовой оркестрации, когда вам важно явно описать путь выполнения и точки вмешательства человека.
• Кастомные execution flows. LangGraph подходит там, где нужна тонкая настройка маршрутизации, состояния и переходов между узлами, а не только «разговор нескольких агентов».
• Role-based команды. CrewAI позиционирует себя вокруг collaborative AI agents, crews и flows, что удобно, когда система строится как набор ролей с памятью, знаниями и наблюдаемостью.
• Исследовательские и legacy-паттерны multi-agent conversation. Paper по AutoGen описывает framework, где LLM-приложения строятся из нескольких агентов, способных разговаривать друг с другом для выполнения задач. Но для новых проектов важно учитывать текущий статус репозитория: AutoGen отмечен как maintenance mode и community-managed.

Короткая карта актуальных фреймворков

Ниже — только проверяемый срез по состоянию на 2026-08-18 из официальных docs и release-страниц.

Практический пример

Ниже не код конкретного SDK, а рабочий сценарий проектирования multi-agent system, который опирается на общие паттерны из OpenAI Agents SDK, Microsoft Agent Framework и LangGraph.

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

1. Начните с координатора. Один агент принимает запрос и решает: достаточно ли одного шага или нужен handoff.
2. Добавьте только действительно нужные роли. Например, отдельный агент нужен, если подзадача требует иного системного контекста, других инструментов или других ограничений. Для этого полезно заранее продумать system prompt для каждой роли, а не пытаться описать всё одной инструкцией.
3. Выберите способ оркестрации. Если шаги линейные — подойдёт sequential. Если ветви независимы — concurrent. Если нужен явный переход между ролями — handoff. Если важны развилки, состояние и контроль — лучше проектировать graph/workflow.
4. Явно храните состояние. Даже если у вас всего два агента, фиксируйте, кто получил задачу, что уже сделано и какой результат передаётся дальше. Без этого multi-agent быстро превращается в трудноотлаживаемую цепочку сообщений.
5. Поставьте проверку перед финалом. Guardrail или human-in-the-loop особенно важны там, где ответ нельзя публиковать или исполнять без дополнительной проверки. Это уже не только вопрос архитектуры, но и вопрос AI Safety.

Если после такой схемы выясняется, что все шаги легко объединяются в одну инструкцию и один набор инструментов, это хороший сигнал вернуться к одноагентной архитектуре. Для большинства команд это полезнее, чем «делать multi-agent на всякий случай».

Чем отличается от…

Ограничения и заблуждения

Этот термин часто переоценивают. По исходникам пакета видно, что даже у зрелых фреймворков различаются не только API, но и текущие эксплуатационные ограничения.

• Заблуждение: «несколько агентов всегда лучше одного». На практике дополнительные агенты добавляют маршрутизацию, состояние и контроль. Если задача проста, multi-agent может только усложнить систему.
• Заблуждение: «multi-agent = свободный диалог агентов между собой». По документации Microsoft и LangGraph это может быть и строгий граф, и последовательный workflow, и handoff, и group chat.
• Ограничение OpenAI hosted multi-agent. В документации OpenAI Agents SDK hosted multi-agent помечен как experimental; handoffs в этом режиме отклоняются, есть текущие ограничения по поддерживаемым настройкам, и на экземпляр допускается только один активный hosted response.
• Ограничение статуса AutoGen. Репозиторий AutoGen прямо указывает maintenance mode и community-managed status, а новых пользователей направляет к Microsoft Agent Framework. Для оценки нового проекта это важнее, чем популярность старых примеров.
• Слабое место — состояние. Если не продумать, где хранится контекст и кто отвечает за его обновление, multi-agent система становится трудной для воспроизведения и отладки.
• Нет универсальной цены. Источники пакета отдельно отмечают неопределённость по прайсингу и региональной доступности: стоимость зависит от underlying model, provider или managed cloud path, поэтому её нужно проверять на официальных страницах конкретного вендора.

Связанные материалы

• AI Agent (ИИ-агент) — базовый термин, от которого удобно отталкиваться перед проектированием multi-agent system.
• AI Safety (безопасность ИИ) — зачем multi-agent workflow почти всегда требует guardrails и проверок.
• Как составить system prompt — практическая основа для разделения ролей между агентами.
• Cursor — AI-редактор кода и coding agent и Replit Agent — смежный контекст, если вы сравниваете агентные подходы в разработке.

Источники

• Multi-agent systems | IEEE Technology Navigator
• OpenAI Agents SDK
• Models – OpenAI Agents SDK
• Releases · openai/openai-agents-python · GitHub
• Microsoft Agent Framework Overview | Microsoft Learn
• Workflow orchestrations in Agent Framework | Microsoft Learn
• agent-framework/python/CHANGELOG.md at main · microsoft/agent-framework · GitHub
• GitHub – microsoft/autogen: A programming framework for agentic AI · GitHub
• AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Framework
• Releases · microsoft/autogen · GitHub
• Multi-agent – Docs by LangChain
• Graph API overview – Docs by LangChain
• Releases · langchain-ai/langgraph · GitHub
• CrewAI Documentation – CrewAI
• Releases · crewAIInc/crewAI · GitHub

Вопросы и ответы

Мультиагентная система и AI-агент — это одно и то же?

Нет. AI-агент — это один исполнитель с инструкциями и инструментами. Мультиагентная система — это архитектура, где несколько агентов координируются через handoff, workflow, group chat или граф.

Когда достаточно handoff, а когда нужен граф?

Если задача просто передаётся от одной роли к другой, handoff часто достаточно. Если нужны ветвления, параллельные шаги, явное состояние, точки проверки и вмешательство человека, полезнее graph/workflow-подход, как в Microsoft Agent Framework или LangGraph.

Можно ли уже сейчас строить hosted multi-agent на OpenAI?

Можно экспериментировать, но документация OpenAI помечает hosted multi-agent как experimental. Там есть текущие ограничения: handoffs в этом режиме отклоняются, не все настройки поддерживаются, и на экземпляр допускается только один активный hosted response.

Стоит ли начинать новый проект с AutoGen?

Если вы поддерживаете существующую систему или делаете исследовательский прототип, AutoGen всё ещё важен как multi-agent conversation framework и академическая точка отсчёта. Но репозиторий одновременно указывает maintenance mode и community-managed status, а новым пользователям рекомендует смотреть на Microsoft Agent Framework.