Мультиагентные системы: когда команда агентов окупается

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

1. Что такое MAS и когда они оправданы

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

Один агент — это один контекст и один набор инструментов. Команду собирают, когда задача требует разных специализаций, параллелизма или внешнего контроля качества. Типовая виртуальная команда: PM/Planner декомпозирует и назначает, Developer исполняет, QA/Critic ищет дефекты. Над ними — оркестратор, который раздаёт подзадачи и собирает результат. Сдвиг тут от «как написать умный промпт» к «как организовать отдел».

И честно о цене. MAS дороже, медленнее на координации и легко скатывается в «обсуждение вместо результата». У Anthropic это измерено напрямую. Их система orchestrator-worker (Claude Opus 4 ведущим + Claude Sonnet 4 субагентами) обошла одиночный Claude Opus 4 на +90,2% во внутреннем research-эвале (бенчмарк BrowseComp). Но платят за это токенами: агенты расходуют примерно в 4 раза больше токенов, чем чат, а мультиагентные системы — примерно в 15 раз больше. Причём один только расход токенов объясняет 80% дисперсии результата; на число параллельных tool-call приходится ~10%, на выбор модели ~5%.

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

MAS оправдана, когда есть хотя бы одно из:

Разные специализации — Researcher / Writer / Reviewer / Actor.
Высокая цена ошибки — нужен второй контроль (критик/ревьюер).
Параллелизм — latency важна, задачу можно разбить, время падает в 2–3 раза.
Автокоррекция через разделение ролей — исполнитель не оценивает себя сам.
Логи по ролям — легче дебажить и объяснять решение бизнесу.

2. Топологии и паттерны координации

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

SUPERVISOR (звезда)            SWARM (рой)                 HANDOFF (передача)

       ┌─────────┐            ┌───────┐   ┌───────┐        ┌───────┐
       │  super  │            │ agent ├──>│ agent │        │ sales │
       └────┬────┘            │   A   │<──┤   B   │        └───┬───┘
     ┌──────┼──────┐          └───┬───┘   └───┬───┘            │ goto
     v      v      v              │           │                v
  ┌────┐ ┌────┐ ┌────┐            └─────┬─────┘           ┌─────────┐
  │ w1 │ │ w2 │ │ w3 │                  v                 │ support │
  └────┘ └────┘ └────┘            ┌─────────┐             └─────────┘
   контроль у одного           любой передаёт            явная передача
   координатора                управление любому         control + state

Рисунок — три топологии MAS: supervisor (один координатор раздаёт работу N исполнителям и собирает ответ), swarm (агенты децентрализованно передают управление друг другу, состояние хранит активного агента), handoff (агент явно передаёт и поток управления, и состояние целевому узлу).

В supervisor (звезда) центральный координатор декомпозирует задачу, делегирует исполнителям и собирает финал. Та же топология у Anthropic зовётся orchestrator-worker, у CrewAI — hierarchical. Swarm децентрализован: автономные агенты сами передают управление, а состояние отслеживает, кто сейчас активен. Handoff — явная передача через объект Command, который сразу несёт и переход (goto), и обновление состояния (update).

Поверх топологий работают два обязательных класса паттернов.

Параллелизм даёт выигрыш от разбиения работы:

Fan-out / fan-in — планировщик режет задачу на N разных подзадач, исполнители берут их одновременно, агрегатор склеивает. «Проанализируй 10 конкурентов» → 10 агентов → одна таблица. Время ≈ 1× самого медленного, не N×.
Sectioning (в терминах Anthropic) — то же, что fan-out: разные непересекающиеся куски одной большой задачи.
Voting / ensembling — один и тот же запрос уходит N агентам, ответы сводят консенсусом для надёжности.
Pipeline — конвейер про throughput, а не latency: одна задача быстрее не станет, но за час прогонишь больше.

Критик / ревьюер — это must-have, а не опция. LLM иногда галлюцинирует и проходит мимо собственных ошибок, поэтому самооценке исполнителя доверять нельзя. Работает асимметрия: проверить решение легче и дешевле, чем создать. Отдельный агент-критик с другим промптом ловит то, что генератор пропустил, и возвращает на исправление. Канонично это паттерн evaluator-optimizer: генератор выдаёт кандидата, оценщик критикует по структурным критериям, цикл крутится до приёмки или до лимита итераций.

Живой продакшен-пример — Google DeepMind Co-Scientist (опубликован в Nature, 2026). Коалиция агентов на Gemini под управлением supervisor-планировщика: Generation выдвигает гипотезы, Reflection работает виртуальным peer-reviewer (это и есть критик), Ranking проводит попарные турниры, Proximity кластеризует для разнообразия, Meta-review синтезирует дебаты. Цикл «generate, debate, and refine» — генератор↔критик в чистом виде, на уровне научных гипотез. Контроль качества вынесен в отдельного ревьюера, а не в самооценку генератора.

3. Математика каскадных ошибок

Главный контраргумент против «давайте добавим ещё агентов»: успех системы падает экспоненциально. Для линейной цепочки из n независимых шагов с точностью каждого p вероятность успеха равна:

P(успех) = p ^ n   —   точность одного шага p в степени числа шагов n

  p = 0.90:   4 шага → 0.90^4 ≈ 0.66     10 шагов → 0.90^10 ≈ 0.35
  p = 0.85:                               10 шагов → 0.85^10 ≈ 0.20

  точность      шаги
  каждого    ┌─────────────────────────────────────┐
  шага 90%   │ ████████████████████████░░░░░░░░░░░ │  66%   4 шага
             │ ████████████░░░░░░░░░░░░░░░░░░░░░░░ │  35%  10 шагов
             └─────────────────────────────────────┘
              ошибки перемножаются — цепочка хрупкая

Рисунок — обрыв надёжности: при точности шага 90% четырёхзвенная цепочка успешна только в 66% случаев, а десятизвенная — в 35%; при 85% десять шагов дают всего 20%. Без промежуточного контроля ошибки перемножаются.

Критик «разрывает цепь»: ошибку ловят до того, как она уйдёт дальше и будет принята следующими агентами за ground truth. Защита от зацикливания — жёсткий лимит итераций критика (1–3); не принято после третьей правки — эскалация на человека.

Больше агентов — не значит лучше. Исследование Google DeepMind под руководством Yubin Kim (декабрь 2025) прогнало 180 конфигураций по пяти архитектурам и трём семействам моделей. Выводы жёсткие. Выигрыш от координации выходит на плато примерно на 4 агентах; дальше латентность связи и оркестрационные издержки перевешивают пользу специализации. А неструктурированные сети «мешок агентов» (densely connected mesh) усиливают ошибки до 17,2 раза против одиночного агента: галлюцинация расходится по связям, и сеть быстро сходится к ложному консенсусу — «conformity cascade».

То же подтверждает таксономия отказов MAST (март 2025): анализ 1 642 трейсов по семи фреймворкам показал общий разброс отказов 41–86,7%, а крупнейшая категория — сбои координации (36,9%). Что отсюда забрать: ограничивайте число активных агентов, гоняйте состояние через централизованный control plane вместо плотной сетки и ставьте программные проверки (компилятор, линтер, тесты) на границах шагов — они ловят ошибки, не тратя лишних токенов.

4. Фреймворки: чем собирать MAS

Выбор сводится к оси «гибкость диалога ↔ жёсткий контроль». Чем нужнее предсказуемый поток — тем ближе к графу; чем быстрее надо собрать команду под бизнес-процесс — тем ближе к ролям.

CrewAI смотрит на MAS как на команду, а не граф. Агент описывается как должностная инструкция: role + goal + backstory + tools + llm. Задача — description + expected_output + agent + context. Команда (Crew) — агенты, задачи, Process (sequential / hierarchical) и manager_llm. Рабочий crew собирается строк за двадцать. Архитектура двухслойная — Crews и Flows: Crews ведут stateful нелинейную коллаборацию, Flows дают детерминированный Python-native control plane (статические шаги как обычные функции, без моделирования каждого перехода как узла графа).

from crewai import Agent, Task, Crew, Process

writer = Agent(
    role="B2B Sales Follow-up Writer",
    goal="Написать персонализированное follow-up письмо лиду по истории взаимодействий.",
    backstory="Опытный B2B sales-копирайтер EdTech-платформы…",
    llm=llm_strong, allow_delegation=False,
)

crew = Crew(
    agents=[researcher, planner, writer, critic],
    tasks=build_tasks(lead_id),
    process=Process.sequential,
    manager_llm=supervisor_llm,
)

CrewAI часто цитируют по числу «5,76× быстрее LangGraph» на QA-нагрузках. Читать его стоит как заявление вендора (self-reported), а не как факт: ускорение даёт снятие тяжёлых транзитивных зависимостей legacy-LangChain (инициализация, setup), а не когнитивное превосходство схемы role/goal/backstory. Независимых peer-reviewed замеров точности этой схемы нет. В проде CrewAI к тому же нередко дороже по токенам — verbose role-playing промпты и ReAct-циклы; команды прототипируют на CrewAI, а потом переписывают на LangGraph, когда токены становятся узким местом.

AutoGen раскололся на две несовместимые линии. Community-форк AG2 (ag2ai/ag2) сохраняет conversation-centric дизайн v0.2 и обратную совместимость. Microsoft переписал AutoGen на асинхронную event-driven actor-модель (v0.4+). Чтобы убрать фрагментацию, Microsoft свёл всё в единый Microsoft Agent Framework (статус Release Candidate в 2026), а оба предка — AutoGen и Semantic Kernel — переведены в maintenance mode. Если кратко об API-сдвиге: @tool-декоратор вместо обёрток FunctionTool; multi-turn по умолчанию вместо single-turn; stateless-агенты с явными сессиями agent.create_session(); native human-in-the-loop через ctx.request_info() / @response_handler; оркестрация через SequentialBuilder / GroupChatBuilder / HandoffBuilder / MagenticBuilder.

LangGraph моделирует MAS как направленный граф с явными узлами, рёбрами и схемой состояния — это про детерминизм и контроль. Реализует те же три топологии: supervisor (с create_forward_message_tool, чтобы прокидывать ответ воркера напрямую и не платить за пересказ супервайзером), swarm (InMemorySaver + InMemoryStore + add_active_agent_router) и handoff через Command.

И отдельный слой идёт поверх фреймворков: протокол A2A (Agent2Agent). MCP стандартизировал «агент ↔ инструмент», но связь «агент ↔ агент» между разными командами, фреймворками и вендорами осталась незакрытой. A2A под Linux Foundation за первый год собрал 150+ организаций, попал в крупные cloud-платформы и enterprise-прод. Механика: агент публикует возможности в Agent Card по /.well-known/agent-card.json (RFC 8615); работа идёт через Task с жизненным циклом submitted → working → completed / failed / canceled / rejected / input-required / auth-required; транспорт на выбор: JSON-RPC 2.0, REST или gRPC. Для регулируемых сред есть Signed Agent Cards (подпись JWS поверх канонизированной карты), чтобы клиент проверял личность агента до запуска. Позиционирование — дополнение к MCP, а не конкурент: MCP связывает агента с инструментами, A2A — агентов между собой.

5. Память между сессиями

По умолчанию между задачами в команде передаётся только output предыдущей. Чтобы агенты помнили пользователя и историю между сессиями, нужен отдельный слой памяти. Mem0 — это SDK, который сам извлекает факты из диалога и хранит их в векторной БД. Принципиальное отличие от RAG: RAG хранит тексты (нарезает диалог на чанки вместе с «Got it» и «Also»), а Mem0 хранит факты, извлечённые LLM, — с дедупликацией и разрешением конфликтов. «User is vegetarian» ≈ «user doesn't eat meat» сольются в одну запись; январский факт «vegetarian» против майского «started eating chicken» пометится устаревшим, свежий — актуальным.

Четыре технических столпа Mem0:

Single-pass ADD-only extraction — асинхронно извлекает предпочтения пользователя и подтверждения агента с равным весом.
Multi-signal retrieval — три параллельных прохода (semantic + BM25 + entity matching), результаты сливаются в один скор.
Entity linking — сущности извлекаются при add() и кладутся в параллельную БД, чтобы не тащить внешний graph-DB.
Multi-scope память — user_id / agent_id / run_id / org_id.

В single-agent Mem0 — это «помни пользователя между сессиями». В MAS он становится слоем координации команды: общий слой памяти меняет архитектуру связей. В CrewAI подключается через memory=True + memory_config с провайдером mem0 и scope по user_id. Запись в проде держат асинхронной (async_mode=True), чтобы не блокировать ответ.

И здесь нужен отдельный навык: как читать memory-бенчмарки. По данным самого Mem0 (релиз апрель 2026), его алгоритм даёт LoCoMo 92,5 (против 72,9 у full-context), LongMemEval 94,4, при ~6 956 токенах на запрос против ~26 000 у full-context — то есть −70%+ токенов (в материалах курса попадается и цифра −90%). Все эти числа получены и опубликованы вендором — это не нейтральный замер.

Насколько шатки лидерборды памяти, видно по спору Zep против Mem0. Zep на temporal knowledge graph Graphiti заявил 84% на LoCoMo; Mem0 опубликовал «исправленный» скор Zep 58,44% (якобы неверно учтены adversarial-категории); Zep ответил 75,14%. Расхождение не на проценты, а кратно. Вывод простой: любые LoCoMo-числа подавайте с оговоркой, что объективные сравнения остаются спорными и вендор-зависимыми — это не индустриальный консенсус.

Итог

MAS — не апгрейд по умолчанию, а осознанный выбор: в ~80% задач хватает одного LLM плюс RAG, а команда платит токенами (×15 к чату) и латентностью.
Берите команду, когда есть реальная причина: разные специализации, высокая цена ошибки, параллелизм или нужда в логах по ролям.
Критик/ревьюер обязателен — он разрывает цепь каскадных ошибок, которая иначе роняет десятизвенный пайплайн до 35% успеха.
Держите топологию узкой: плато выигрыша ~4 агента, плотная сетка усиливает ошибки до 17×, координация — крупнейшая категория отказов.
Фреймворк — вопрос оси «скорость сборки (CrewAI) ↔ детерминизм (LangGraph)»; бенчмарки вендоров читайте как заявления, а не факты. Память между сессиями (Mem0) превращает команду в систему, которая помнит историю.

FAQ

Когда мультиагентная система реально нужна, а когда хватит одного агента?

Команда оправдана, если есть хотя бы одно: разные специализации, высокая цена ошибки (нужен внешний критик), параллелизм с важной latency или потребность в логах по ролям. В остальных случаях — а это около 80% задач — хватает одного LLM с RAG. MAS повышает расход токенов примерно в 15 раз против чата и добавляет оркестрационные издержки, поэтому идти в неё стоит только под конкретную причину.

Почему добавление агентов снижает надёжность системы?

Успех линейной цепочки падает экспоненциально: P = pⁿ. При точности каждого шага 90% четыре звена дают ~66%, а десять — всего 35%. Ошибки перемножаются, и каждый следующий агент принимает чужую ошибку за истину. Исследование DeepMind показало, что выигрыш от координации выходит на плато примерно на 4 агентах, а неструктурированные сети усиливают ошибки до 17 раз.

Зачем нужен агент-критик в команде?

LLM иногда галлюцинирует и проходит мимо собственных ошибок, поэтому самооценке исполнителя доверять нельзя. Отдельный критик с другим промптом ловит брак до того, как он пойдёт дальше по цепочке. Это опирается на асимметрию: проверить решение дешевле, чем создать. Чтобы критик не зациклился, ставят лимит итераций (1–3) и эскалацию на человека.

Чем CrewAI отличается от LangGraph?

CrewAI описывает MAS как команду ролей (role/goal/backstory) и собирается быстро — около 20 строк; хорош для линейных пайплайнов research→write→review. LangGraph моделирует систему как граф состояний с явными узлами и рёбрами — это детерминизм и контроль логики/ошибок. Заявление CrewAI о «5,76× быстрее» — self-reported и объясняется снятием legacy-зависимостей LangChain, а не превосходством схемы ролей; в проде CrewAI часто дороже по токенам.

Чем A2A отличается от MCP?

MCP связывает один агент с инструментами, данными и ресурсами — «агент ↔ инструмент». A2A связывает независимых агентов между фреймворками и организациями — «агент ↔ агент». Это дополняющие стандарты, а не конкуренты. A2A работает через Agent Card по /.well-known/agent-card.json и task-based state machine, поддерживающую асинхронное возобновление через сетевые границы.

Чем Mem0 отличается от RAG для памяти агента?

RAG хранит тексты: нарезает диалог на чанки и эмбедит вместе с шумом вроде «Got it». Mem0 хранит факты, извлечённые LLM, с дедупликацией и разрешением конфликтов во времени — устаревший факт помечается, свежий отдаётся при запросе. Mem0 ищет по личной истории конкретного пользователя (scope по user_id), а не по всей корпоративной базе.

Источники

Anthropic — How we built our multi-agent research system — независимые цифры цены и эффекта MAS: +90,2%, ×15 токенов, 80% дисперсии.
Anthropic — Building Effective Agents — каноническая таксономия паттернов: orchestrator-workers, parallelization, evaluator-optimizer.
Google DeepMind — AI Co-Scientist — продакшен-пример паттерна критик/ревьюер на коалиции агентов.
CrewAI — документация — объекты Agent/Task/Crew/Process, Crews+Flows, memory_config.
AutoGen → Microsoft Agent Framework — migration guide — статус AutoGen/AG2 и сдвиг API.
Mem0 — препринт arXiv:2504.19413 — четыре столпа памяти и бенчмарки LoCoMo/LongMemEval/BEAM.
Zep vs Mem0 — спор о бенчмарках памяти — почему LoCoMo-числам нельзя верить как нейтральным.
A2A Protocol — Linux Foundation — статус протокола и механика спецификации v1.0.

Числовые ориентиры из текста — это профильные замеры на конкретных бенчмарках и нагрузках: цифры Anthropic (×4 / ×15 токенов, 80% дисперсии) зависят от типа задачи, а бенчмарки памяти и «5,76×» CrewAI получены вендорами и кратно расходятся между методологиями. На своих данных, корпусе и профиле нагрузки соотношения будут другими — проверяйте перед решением.