один агент или пятнадцать? реальное руководство по архитектуре мульти-агентных систем

Дроби на несколько агентов только тогда, когда один агент доказуемо не вытягивает задачу — когда работа распадается на независимые подзадачи, каждой из которых нужен свой контекст, свои инструменты, и они могут идти параллельно, не мешая друг другу. Канонический паттерн — orchestrator-worker (агент-«супервайзер», который планирует и делегирует, плюс субагенты, каждый из которых раскапывает одну ветку). Всё остальное — агенты, которые перекидывают задачу друг другу по одному сообщению, «команды» в общем чате — это обычно театр. В июне 2026 Anthropic отчиталась, что её мульти-агентная research-система обогнала одиночного агента на 90,2% на внутреннем тесте — но ценой примерно 15× по токенам. Cognition (команда Devin) дала противоположный совет — «Don't Build Multi-Agents» — потому что параллельные агенты принимают противоречащие решения, когда не делят контекст. Правы обе. Реальный навык — не собрать пятнадцать агентов, а понять, какие задачи заслуживают больше одного, и спроектировать контекст, который они делят. Это руководство — про архитектуру, паттерны общения, слой памяти и честный раздел «когда побеждает один агент».

почему «мульти-агент» стал маркетинговым словом

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

У сообщества есть точное название этому разрыву: «deployed, not demoed» — задеплоено, а не показано в записи экрана. Мульти-агентная система, которая выигрывает скринкаст, и система, которая переживает неделю в продакшене, — это разные артефакты. Демка оптимизируется под «выглядит автономно». Продакшен оптимизируется под корректно, дёшево и отлаживаемо — и эти три вещи с каждым новым агентом даются сложнее, а не легче.

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

единственное решение, которое действительно важно: дробить или оставить одного

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

Ресёрч — «найди всё про X по 30 источникам» — учебниковый кейс для мульти-агентов: можно развернуться веером, параллельно копать независимые зацепки и слить результат. Кодинг — учебниковый анти-кейс: каждая правка зависит от предыдущей, поэтому параллельные кодинг-агенты мешают друг другу. Именно поэтому Anthropic выбрала мульти-агентов для ресёрча, а Cognition аргументирует против них для кодинг-агентов вроде Devin. Один год, противоположные советы — и оба правы, просто описывают разные формы задач.

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

паттерн supervisor — тот, что доживает до продакшена

Паттерн, который реально едет в прод, — orchestrator-worker, он же supervisor. Один ведущий агент держит план; он порождает субагентов, у каждого своё окно контекста и свои инструменты, чтобы параллельно копать независимые ветки; субагенты возвращают сжатые выводы; ведущий сводит их в один ответ.

                  ┌────────────────────────┐
   запрос юзера → │  LEAD / ОРКЕСТРАТОР    │  планирует, дробит, делегирует
                  └───────────┬────────────┘
            ┌─────────────────┼─────────────────┐
            ▼                 ▼                  ▼
      ┌──────────┐     ┌──────────┐       ┌──────────┐
      │ субагент │     │ субагент │       │ субагент │   своё окно контекста,
      │  (веб)   │     │  (доки)  │       │  (код)   │   свои инструменты, параллельно
      └────┬─────┘     └────┬─────┘       └────┬─────┘
           └────── сжатые выводы ───────────────┘
                            ▼
                  ┌────────────────────────┐
                  │  LEAD сводит воедино →  │  финальный ответ + ссылки
                  └────────────────────────┘

Почему так, а не общий чат-беспредел? Три причины:

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

В минимальной форме ведущий — это просто агент, чьи «инструменты» — другие агенты:

# Псевдокод — цикл supervisor, без привязки к фреймворку
def lead_agent(query):
    plan = llm_plan(query)                  # разбить на независимые подзадачи
    results = run_parallel([                 # развернуть веером — у каждого свой контекст
        subagent(task=t, tools=tools_for(t))
        for t in plan.subtasks
    ])
    return llm_synthesize(query, results)    # один писатель сводит всё воедино

Цифры и подвох. Anthropic отчиталась, что её orchestrator-worker research-система (ведущий Claude Opus 4 управляет субагентами Claude Sonnet 4) обогнала одиночного Opus 4 на 90,2% на внутреннем research-тесте. Там же они выяснили: сам объём использованных токенов объясняет около 80% разброса результатов — большая часть выигрыша в том, что больше агентов позволяют потратить больше токенов, параллельно, по большему контексту. Подвох: это стоило примерно 15× токенов от обычного чата. Такая экономика оправдана только для дорогих задач, где тщательность стоит реальных денег. Не вешай множитель 15× на «суммируй это письмо».

как агенты на самом деле общаются друг с другом

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

Жёсткие правила Cognition, выстраданные на Devin, бьют ровно в эту точку:

• Дели контекст и дели полные трейсы агентов — не только финальное сообщение. Субагент должен видеть рассуждение, которое привело к его задаче, а не голую однострочную выжимку. Потерянный контекст — причина №1 противоречащих решений.
• Держи запись (writes) однопоточной. Когда несколько агентов читают — нормально; когда несколько пишут в одно состояние параллельно — получаешь несвязный вывод. Пусть дополнительные агенты добавляют интеллект (анализ, варианты), но сами действия проводи через одного писателя. Это принцип «single writer», и именно поэтому supervisor — а не равноправный групповой чат — это устойчивый паттерн.

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

общая память как файловая система, а не как лог чата

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

OpenViking (выложила в open source команда Volcano Engine от ByteDance, ~15K★) — самый наглядный пример. Он выставляет контекст — память, ресурсы, навыки — под схемой URI viking://{scope}/{path}, по которой агенты ходят привычными командами вроде ls и find. Ключевая идея — многоуровневая загрузка: каждый кусок контекста хранится на трёх уровнях детализации.

Агент просматривает аннотации L0, чтобы найти релевантное, читает L1 там, где важно, и тянет полный L2 только когда деталь реально нужна — адресуясь по URI, как открывая файл. Так ты даёшь команде агентов общую большую базу знаний, не заставляя каждого таскать её целиком в контексте. Это чисто ложится на supervisor: субагенты пишут сжатые выводы в хранилище, ведущий читает аннотации и углубляется только там, где обязан.

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

недооценённый ключ: куратор, который рулит соотношением сигнал/шум

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

Лекарство — субагент-куратор: маленькая дешёвая модель, чья единственная работа — отсекать шум и оставлять опорные факты до того, как контекст увидит дорогая модель. Статья 2026 года «Escaping the Context Bottleneck: Active Context Curation for LLM Agents via Reinforcement Learning» (подход ContextCurator) ставит в пару замороженный мощный TaskExecutor и лёгкую policy-модель, обученную через RL агрессивно вычищать шум окружения, сохраняя редкие факты, которые понадобятся дальше. Результаты:

Куратор на 7B (на базе Qwen-2.5-7B) не уступил варианту с gpt-4o в роли куратора — фронтирная модель для вычистки не нужна. Это и есть архитектурный ход, который всё ещё недооценён: в мульти-агентной системе один из самых ценных «агентов» — вовсе не эксперт по предметке, а дешёвый вахтёр, который решает, что вообще позволено увидеть дорогим агентам. Лучшее соотношение сигнал/шум почти всегда бьёт «больше агентов».

когда один агент с хорошими инструментами просто побеждает

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

• Задача последовательная. Каждый шаг зависит от предыдущего (кодинг, многошаговые транзакции, что угодно с состоянием). Параллельные агенты только мешали бы друг другу.
• Всё влезает в один контекст. Если вся работа спокойно помещается в одно окно, дробление добавляет накладные расходы на координацию без выигрыша.
• Задержка или цена на пределе. Один агент — один счёт за токены и ноль межагентных round-trip'ов.
• Это нужно отлаживать. Один цикл, один трейс. Отказ роя — это «где-то в маршрутизации сообщений», а это паршивое место, чтобы сидеть там в 3 часа ночи.

Честный ход, который в 2026-м в тренде, а не наоборот: есть реальный откат от переусложнённых агентных систем — команды тихо выдирают рой обратно и катят одного крепкого агента. Мульти-агенты — это возможность, а не статусный символ. Если один агент с тремя хорошими инструментами справляется, это и есть сеньорское решение. (Если ты ещё выбираешь сам слой агента — смотри мой разбор фреймворков; если ни разу не собирал базовый цикл — начни с первого агента на чистом Python.)

пять способов сломать мульти-агентную систему (и как чинить)

• Грабли: равноправный групповой чат вместо supervisor. Агенты болтают на равных и принимают противоречащие решения. Фикс: orchestrator-worker. Один ведущий планирует и сводит; субагенты только отчитываются наверх.
• Грабли: худые хэндоффы. Передаёшь однострочники — теряешь контекст, и следующий агент действует наугад. Фикс: дели полные трейсы и самодостаточные брифы, а не выжимки (правило Cognition).
• Грабли: параллельные писатели. Два агента меняют одно состояние — получаешь несвязный вывод. Фикс: однопоточная запись — лишние агенты добавляют интеллект, действия коммитит один писатель.
• Грабли: контекст как один гигантский транскрипт. Каждый агент перечитывает всё, и сигнал тонет. Фикс: адресуемая многоуровневая память (L0/L1/L2 в духе OpenViking) и субагент-куратор.
• Грабли: мульти-агенты на задачу для одного. Платишь ~15× токенов, чтобы сделать связанную задачу хуже. Фикс: честно прогони тест на дробление; по умолчанию — один агент, пока он доказуемо не перестанет вытягивать.

как я на самом деле гоняю агентов в продакшене

По умолчанию у меня не рой. Большинство задач, которые я катаю, — это один агент, плотный набор инструментов и хорошая наблюдаемость вокруг. К мульти-агентам тянусь только когда задача реально разворачивается веером — ресёрч, широкий сбор данных, всё, где независимые ветки копают параллельно — и даже тогда это строгий orchestrator-worker: один ведущий, который планирует и синтезирует, и stateless-субагенты, каждый получает запечатанный бриф и отчитывается обратно. Общее состояние живёт в адресуемом хранилище, а не в промпте на 200K токенов, который каждый агент перечитывает. Дешёвая модель курирует вывод инструментов до того, как его увидит дорогая. И каждый агент — одиночный или суб — крутится в песочнице, потому что каждый инструмент, который агент может вызвать, — это поверхность атаки (чек-лист безопасности тут), с полным трейсингом, чтобы у отказа в 3 ночи было где искаться (мониторинг тут). Архитектура скучная — намеренно. Скучное и доживает до продакшена.

что дальше — и когда стоит уйти

Если собираешься строить мульти-агентную систему — сначала прогони тест на дробление. Последовательная, связанная, влезает в одно окно? Собери одного отличного агента и уйди от роя — это сеньорское решение. По-настоящему параллельная и жадная до контекста? Бери orchestrator-worker, дели полный контекст вниз, держи запись однопоточной, делай память адресуемой и ставь дешёвого куратора перед дорогой моделью. И заложи бюджет на токены до старта, потому что тщательность стоит 15× только когда задача того стоит.

Источники

1. Anthropic — «How we built our multi-agent research system» — архитектура orchestrator-worker, прирост 90,2% над одиночным агентом, цена ~15× по токенам и объём токенов как ~80% разброса результатов. https://www.anthropic.com/engineering/built-multi-agent-research-system Получено 16 июня 2026.

2. Cognition — «Don't Build Multi-Agents» (Walden Yan) — принципы «дели полные трейсы» и однопоточной записи («single writer»), а также аргументы против параллельных агентов на связанных задачах. https://cognition.ai/blog/dont-build-multi-agents Получено 16 июня 2026.

3. OpenViking (ByteDance / Volcano Engine), GitHub — схема URI viking:// и модель многоуровневой загрузки контекста L0/L1/L2 для общей памяти агентов. https://github.com/volcengine/OpenViking Получено 16 июня 2026.

4. «Escaping the Context Bottleneck: Active Context Curation for LLM Agents via Reinforcement Learning» (arXiv 2604.11462) — разделение ContextCurator/TaskExecutor, цифры по WebArena и DeepSearch и результат куратора 7B против gpt-4o. https://arxiv.org/abs/2604.11462 Получено 16 июня 2026.

Проектируешь мульти-агентную систему — или пытаешься понять, нужна ли она вообще? Запусти проект — я проектирую и собираю AI-агентов, MCP-серверы и агентные системы, которые работают на твоём сервере, с правильным числом агентов: не демку, а версию, которая доживает до продакшена.