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

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

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

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

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

Дневник курса, урок 8. Здесь пригодится разобранное в соседних постах: агент как машина состояний (урок 6) — на этих узлах, рёбрах и объекте Command собираются топологии ниже; поиск по своим данным (урок 3) — та самая связка «один агент плюс RAG», с которой команду и сравнивают. Пост читается отдельно: все термины вводятся заново.

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

Задача, с которой всё обычно начинается, звучит буднично. Собрать досье по десяти конкурентам, свести в таблицу, написать выводы. Один агент берётся за неё честно, открывает первый сайт, второй, третий, и к шестому его контекст превращается в свалку, где выводы по первому конкуренту утонули между цитатами с четвёртого. Напрашивается очевидное. Раздать сайты десяти исполнителям, а сведение и выводы поручить одиннадцатому.

Переход от одного монолитного агента к команде специализированных агентов, которые координируются ради общей задачи, и называется мультиагентной системой (multi-agent system, MAS). Один агент — это один контекст и один набор инструментов. У команды контекстов несколько, между ними приходится гонять состояние, и появляется участник, который следит за общей целью. Сдвиг тут от «как написать умный промпт» к «как организовать отдел». В типовой виртуальной команде PM/Planner декомпозирует и назначает, Developer исполняет, QA/Critic ищет дефекты, а над ними оркестратор раздаёт подзадачи и собирает результат. Финальное слово остаётся за оркестратором, а не за тем исполнителем, кто ответил последним.

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

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

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

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

Разбор типовых провалов одиночного агента (урок 1) — слишком широко очерченная задача, доступы шире необходимых, цикл без верхней границы расхода — здесь стоит перечитать с другим вопросом. Что из этого списка чинит второй агент, а что он размножает? Чинит он ровно один пункт. «Модель не проверила себя» закрывается внешним критиком, которому дали другую инструкцию. Остальные три от разделения ролей не лечатся вовсе. Широкая задача остаётся широкой, только теперь её неверно понимают четверо, а незакрытый цикл превращается из одного бесконечного диалога в четыре одновременных.

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

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

Второй и последний пункты в проде обычно и решают, причём работают в паре. Возьмём проверку договора перед подписанием. Цена пропущенного пункта несопоставима с ценой лишнего прогона, поэтому отдельный проверяющий окупается на первом же случае. А когда у системы спросят, почему она не заметила автопролонгацию, лог по ролям даст конкретный ответ: агент-экстрактор пункт вытащил, агент-проверяющий не сопоставил его с чек-листом. У монолитного агента на том же месте одна длинная простыня рассуждения, по которой видно, что решение неверное, но не видно, где именно оно свернуло не туда.

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

Посадите трёх агентов в общий чат без правил передачи хода, и они будут обсуждать, кто что должен делать, вежливо соглашаться друг с другом и уточнять формулировки. Задачу при этом не доведут. Кто имеет право передать управление, кому и вместе с чем? Ответ на это и есть топология. Три базовых рисунка покрывают почти все продакшен-кейсы, их и разберём.

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

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

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

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

Handoff — явная передача через объект Command, который сразу несёт и переход (goto), и обновление состояния (update):

from langgraph.types import Command

@tool
def transfer_to_support(runtime) -> Command:
    """Передать поток выполнения агенту поддержки."""
    return Command(
        goto="support_agent",
        update={"active_agent": "support_agent"},
        graph=Command.PARENT,   # нужно при переходе через границу подграфа
    )

Смысл склейки перехода и состояния в одном объекте практический. Разъехаться они не могут. Иначе выходит знакомая по распределённым системам картина: управление уже уехало к принимающему, а данные, с которыми он должен работать, ещё нет. Есть и отдельная деталь, на которой ломаются первые сборки. В историю родительского графа надо положить и сообщение с вызовом инструмента, и ответ на этот вызов. Пропустите одно из двух, и у принимающего агента история диалога порвётся, а достраивать её он начнёт сам.

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

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

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

Выбирают по природе работы. Подзадачи разные — fan-out, одинаковые — map-reduce, поток входящих — pipeline. Ошибка на этом выборе стоит дорого именно потому, что выглядит безобидной. Map-reduce, натянутый на разнородные подзадачи, даёт десять исполнителей с одинаковой инструкцией и десять одинаково поверхностных ответов.

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

Посмотрим, как это выглядит на письме лиду. Writer собрал follow-up по истории взаимодействий и вставил фразу про скидку, которой в CRM нет. Не со зла, а потому что в истории мелькало обсуждение цены. Критику дают другую инструкцию: сверить каждое фактическое утверждение письма с карточкой сделки и вернуть список несоответствий. Он возвращает одно, Writer переписывает абзац. Канонично это паттерн evaluator-optimizer. Генератор выдаёт кандидата, оценщик критикует по структурным критериям, цикл крутится до приёмки или до лимита итераций. Вариантов сборки три: критик после исполнителя (линейная проверка), ансамбль критиков-специалистов и самопроверка. Последняя слабее по причине, разобранной выше.

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

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

Возьмём десять шагов, на каждом точность 90%. Интуиция подсказывает, что система надёжная, ведь девяносто процентов — приличная оценка почти для чего угодно. Арифметика отвечает иначе. Такая цепочка доходит до конца в 35% случаев.

Причина не в том, что ошибки «накапливаются». Это метафора, и она скорее мешает. Чтобы цепочка выдала верный результат, верным должен быть каждый шаг: первый агент не переврал сумму, второй правильно её классифицировал, третий подставил в нужное поле. Вероятность того, что все независимые события произойдут разом, равна произведению их вероятностей, поэтому надёжность цепочки не усредняется по шагам, а перемножается. Для линейной цепочки из 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 шагов
             └─────────────────────────────────────┘
              ошибки перемножаются — цепочка хрупкая

Степень бьёт в обе стороны, и это самое полезное свойство формулы. Пять процентных пунктов точности, потерянные на каждом шаге, обходятся дороже, чем кажется на слух. Разница между 0.90^10 и 0.85^10 — это 35% против 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

Фреймворк для MAS обычно выбирают по тому, что попалось в первом туториале. А по чему выбирать осмысленно? По одной оси, от гибкости диалога к жёсткому контролю. Чем нужнее предсказуемый поток, тем ближе к графу. Чем быстрее надо собрать команду под понятный бизнес-процесс, тем ближе к ролям.

Сперва стоит убрать из этого списка то, что туда попало по недоразумению. В сравнения фреймворков регулярно затягивают n8n, Dify и Kestra, а это другой класс инструментов. Оркестратор процессов — менеджер проектов: он знает порядок шагов, расписание, ретраи, подключения к почте, CRM и базе, и всё это описано заранее и детерминированно. Команда агентов — исполнители, которых менеджер нанимает под кусок работы, где заранее не расписать. Выбирать между ними не приходится, они не конкуренты. В рабочей сборке n8n дёргает crew по событию или расписанию, забирает результат и везёт его дальше по своему конвейеру, а crew отвечает только за ту часть, которую нельзя выразить условием в узле.

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

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,
)

backstory тут не украшение. Так специализация фиксируется в системном промпте и держится все ходы диалога. За удобство приходится платить токенами, потому что role-playing промпты многословны по устройству. Архитектура при этом двухслойная, Crews и Flows. Crews ведут stateful нелинейную коллаборацию, а Flows дают детерминированный Python-native control plane, где статические шаги остаются обычными функциями и не требуют моделировать каждый переход как узел графа.

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

AutoGen смотрит на координацию как на разговор. Агенты у него не функции, которые кто-то вызывает, а участники общего чата: каждый видит накопленную историю, отвечает в неё и влияет на ход обсуждения. Собирается это через GroupChat — несколько агентов в одном треде, где отдельный selector решает, кто пишет следующим. Схема даёт то, чего нет у ролевого конвейера: агенты спорят и приходят к консенсусу, генератор и критик крутят несколько кругов правок, кто-то запускает код и приносит результат обратно в разговор.

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

При этом сам AutoGen раскололся на две несовместимые линии, и раскол этот содержательный. Microsoft переписал AutoGen на асинхронную event-driven actor-модель (v0.4+), где взаимодействия агентов разложены на изолированные события, ради наблюдаемости и вменяемого дебага. Часть сообщества с таким переездом не согласилась, и community-форк AG2 (ag2ai/ag2) сохранил conversation-centric дизайн v0.2 вместе с обратной совместимостью.

Чтобы убрать фрагментацию, 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, swarm (InMemorySaver для состояния внутри треда, InMemoryStore для памяти между тредами и add_active_agent_router, чтобы вернуть управление последнему активному агенту) и handoff через Command. В supervisor есть характерная деталь — create_forward_message_tool, который прокидывает ответ воркера пользователю напрямую. Без него координатор пересказывает своими словами то, что исполнитель уже написал, и вы платите за одни и те же данные дважды. Сначала на генерации, потом на пересказе.

Сведём ось «скорость сборки ↔ детерминизм» в три строки.

Поверх фреймворков идёт ещё один слой — протокол A2A (Agent2Agent). MCP стандартизировал «агент ↔ инструмент», однако связь «агент ↔ агент» между разными командами, фреймворками и вендорами осталась незакрытой, примерно как платёжные интеграции до появления общих SDK. 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 — агентов между собой. Как этот слой устроен изнутри и где договорённость перестаёт что-либо гарантировать, разобрано в посте про протокол A2A.

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

Пользователь возвращается через неделю, и агент спрашивает то, что выяснял в прошлый раз. Внутри команды та же беда в другой форме. По умолчанию между задачами передаётся только output предыдущей, поэтому Writer знает ровно то, что успел записать Researcher, и ничего из позавчерашнего разговора. Прежде чем чинить, стоит разделить, что здесь называют памятью. Слово одно, а вещей за ним четыре, и живут они по разным правилам.

РАБОЧАЯ        текущий контекст запроса       живёт до конца прогона
               быстро, но упирается в окно

ЭПИЗОДИЧЕСКАЯ  история прошлых сессий          «было ли уже такое»
               и диалогов

СЕМАНТИЧЕСКАЯ  факты о пользователе и мире     «что я про него знаю»
               извлечённые из разговоров

ПРОЦЕДУРНАЯ    правила и навыки работы         «как мы это делаем»
               системные промпты, скиллы

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

Самая заметная реализация семантического слоя — 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.

Второй пункт объясняет, почему одного вектора мало. Косинусная близость хорошо находит «что-то про еду», но плохо отвечает на вопрос про конкретную сущность. Имя компании или артикул совпадает точно или не совпадает вовсе, и здесь BM25 с прямым совпадением по сущности работает надёжнее эмбеддинга. Четвёртый пункт отвечает на вопрос, чья это память. Без явного scope факты одного пользователя утекают в ответы другому, а это уже не качество, а инцидент.

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

И здесь нам понадобится отдельный навык — читать memory-бенчмарки. LoCoMo и LongMemEval устроены одинаково. Длинные многосессионные диалоги плюс вопросы по их содержимому: что пользователь говорил месяц назад, что из этого потом изменилось. Оценка идёт в проценте правильных ответов, так что «92,5» читается как «система ответила верно на 92,5% вопросов».

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

Насколько шатки лидерборды памяти, видно по спору 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) превращает команду в систему, которая помнит историю.

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

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

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

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) и собирается быстро, строк за двадцать, поэтому хорош для линейных пайплайнов 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 получены вендорами и кратно расходятся между методологиями. На своих данных, корпусе и профиле нагрузки соотношения будут другими, так что проверяйте перед решением.