Один агент или несколько: как выбрать мультиагентную архитектуру

Коротко (TL;DR)

Главный вопрос при проектировании — не «мультиагент лучше или хуже», а «для этой задачи какая архитектура правильная». И лучшая иллюстрация, что ответ не очевиден: 12 июня 2025 года команда Devin (Cognition) публично написала «не стройте мультиагентов», а буквально на следующий день, 13 июня, Anthropic показала обратное — их многоагентная система обошла одиночного агента на 90%+. Обе позиции оказались правы — просто каждая для своего типа задач, и понять, для какого именно, и есть навык архитектора.

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

Мультиагентная система стоит в 10–15 раз дороже в токенах, чем одиночный агент, поэтому усложнять нужно только под доказанную необходимость, а не «на вырост» или потому что так делают крупные компании. Ниже — где именно проходит граница, два типа координации, дерево решений из четырёх вопросов Anthropic, реальные датированные кейсы и честный разбор провалов.

Данные волатильны; версии моделей, цены и кейсы быстро устаревают — у каждой цифры ниже указана своя дата.

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

Один агент или несколько: где проходит граница

Начинать всегда стоит с одного агента — это дешевле, предсказуемее и проще в отладке. Уходить в мультиагент есть смысл при одном из четырёх сигналов:

AMD покупает себе место у Anthropic: 2 гигаватта MI450 в обмен на инвестицию до $5 млрд

Пять паттернов агентных систем: механика, примеры и цена каждого

Воркфлоу против ИИ-агента: как выбрать и не переплатить за автономность

Как не терять контекст в Claude Code: компакт, resume и handoff

Оркестрация агентов Claude Code: как заставить их работать командой

• Насыщение контекста (context saturation). Задача не влезает в окно одного агента — слишком много файлов, источников, шагов. Тогда работу делят между агентами, у каждого своё окно.
• Специализация задач (task specialization). Нужны разные экспертизы, которые плохо уживаются в одном промпте (например, юридический анализ и финансовое моделирование).
• Параллелизм ради скорости (latency). Независимые подзадачи можно гнать одновременно, а не последовательно.
• Изоляция сбоев (fault isolation). Ошибка одного агента не должна ронять всю систему — отдельные контексты локализуют проблему. Это особенно ценно там, где часть подзадач работает с ненадёжными внешними данными: пусть «падает» один агент, а не весь конвейер.

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

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

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

Два типа мультиагентных систем

Если решение дробить принято, есть два принципиальных способа организовать агентов:

Иерархия проще в контроле: супервайзер держит план и раздаёт задачи. Её узкое место — переполнение контекста самого супервайзера; типовые решения — редактирование контекста, инструменты памяти и потолок порядка 25 тысяч токенов на подзадачу.

Коллаборация гибче, но опаснее: равные агенты могут прийти к эмерджентному (незапланированному) поведению, а отладить переписку многих агентов сложно. Важный нюанс из независимого исследования: топология влияет на скорость распространения ошибок отдельно от их частоты. Независимые агенты усиливают ошибку примерно в 17,2 раза, а централизованная координация — только в 4,4 раза. То есть даже неполная иерархия устойчивее полного роя — сильный аргумент в пользу супервайзера по умолчанию.

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

Отдельно про управление контекстом супервайзера — это не абстрактный «вызов», а конкретная инженерная работа. Координатор, который держит в голове весь план и результаты всех специалистов, быстро упирается в предел окна. Решают это тремя способами: редактированием контекста (выкидывать отработавшее), инструментами памяти (выносить состояние наружу) и жёстким потолком на объём, который каждый субагент возвращает наверх (порядка 25 тысяч токенов). Без этих мер супервайзер деградирует ровно так же, как одиночный агент в переполненном окне, — и вся иерархия теряет смысл. Модель координатора при этом обычно берут посильнее: например, флагман уровня Claude Sonnet 5 как lead, а на воркеров ставят модель подешевле — так устроена и сама research-система Anthropic.

Агентные воркфлоу: паттерны и что за ними

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

Отдельно стоит emerging-направление: динамическая генерация агентов на лету и сетевые (peer-to-peer) топологии. Динамическая генерация — это когда система сама решает, каких агентов создать под конкретную задачу, а не работает с заранее прописанным набором ролей. Сетевые топологии — когда агенты связаны не через центр, а между собой напрямую, как узлы графа. Обе идеи звучат мощно, но это пока экспериментальная зона — устойчивых продакшн-систем на них почти нет, а сложность отладки и непредсказуемость поведения растут быстрее, чем выигрыш.

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

Дерево решений: четыре вопроса

Самое ценное в подходе Anthropic — не абстрактные советы, а конкретное дерево из четырёх вопросов, которое ведёт к архитектуре:

1. Сколько нужно контроля? Если на кону регуляторика, деньги или безопасность — берите один агент или строго последовательный воркфлоу с явными точками контроля. Автономность тут — риск.
2. Насколько сложен домен? Узкий домен закрывает один агент; много разнородных поддоменов — сигнал к мультиагенту со специализацией.
3. Каков бюджет токенов? Мультиагент стоит в 10–15 раз дороже одиночного агента. Мало ресурсов — один агент или аккуратный параллельный, не полноценная многоагентная система.
4. Нужна ли глубокая экспертиза? Если задача требует нескольких разных специализаций, которые не уживаются в одном промпте, — это довод за отдельных агентов (или навыки-специализации).

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

Разберём на примере. Задача — автоматизировать разбор входящих обращений в банк. Вопрос 1 (контроль): на кону деньги и регуляторика — значит, автономию ограничиваем, нужны явные точки контроля. Вопрос 2 (домен): обращения разнородны (карты, кредиты, мошенничество) — есть специализация. Вопрос 3 (бюджет): важно не раздуть стоимость на потоке — полноценный рой отпадает. Вопрос 4 (экспертиза): да, ветки требуют разных знаний. Ответы складываются в конкретную архитектуру: последовательный воркфлоу с маршрутизатором на входе и специализированными обработчиками — то есть гибрид «последовательный + динамическая маршрутизация», а не свободный мультиагент. Дерево не выдаёт «мультиагент да/нет», оно выдаёт форму системы.

Гид по выбору архитектуры

Сведём ответы в практический навигатор — от простого к сложному:

Практический сигнал, который часто упускают: считайте инструменты, а не только домены. По исследованиям, задачи с 16+ инструментами — сильнейший предиктор провала координации, сильнее самой сложности домена. Если у вас разрастается набор инструментов на агента — это повод упростить, а не добавить ещё агентов. И контринтуитивный факт из той же области (находка DyLAN): три оптимизированных агента нередко обгоняют семь, а обрезка команды с семи до четырёх одновременно улучшает результат и снижает расход токенов на 52,9–67,8%. Больше агентов ≠ мощнее.

Гибридные стратегии

На практике архитектуры комбинируют. Три рабочих гибрида из фреймворка Anthropic:

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

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

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

Реальные кейсы

Показать стоит и успехи, и то, что за ними стоит.

Как устроен кейс Anthropic Research архитектурно: ведущий агент (lead) получает запрос, декомпозирует его и раздаёт подзадачи субагентам, каждый из которых исследует свою часть в отдельном контексте, а затем lead синтезирует ответ. Это классический оркестратор-воркеры на read-heavy задаче — там, где параллельное чтение множества источников складывается в лучший результат. Именно форма задачи (много независимого чтения) объясняет, почему здесь мультиагент выиграл, а в других сценариях проигрывает.

Важные оговорки. Прирост +90,2% — внутренний замер Anthropic по одной методике на исследовательских задачах, не универсальный закон. Кейс Coinbase и Gradient Labs идут из архитектурного PDF Anthropic; там же упоминается ускорение «в 100 раз» у Tines, но его второй источник принадлежит тому же вендору — поэтому этот показатель мы не выносим как независимо подтверждённый. Общий принцип при чтении любых таких кейсов: успех конкретной компании — не доказательство, что архитектура подойдёт вам; смотрите на сходство формы задачи, а не на громкость цифры.

Отдельный тип кейса — специализация ролей без классического супервайзера: связка агента-инициализатора (готовит окружение) и агента-кодера (автономный цикл) из разбора Anthropic для многодневных задач. Это мультиагентность через разделение ролей, а не через иерархию координации. Для контраста, одиночный персональный ИИ-агент — это другой полюс: одна роль, один контекст, своя экономика.

Где ломается: риски и провалы

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

Индустрия расколота, и это важно. Cognition в посте «Don’t Build Multi-Agents» (12 июня 2025) прямо предупреждает: параллельные субагенты с изолированным контекстом принимают конфликтующие решения, и собрать из них согласованный результат тяжело — особенно в задачах с записью (код). Примерно через десять месяцев они смягчили позицию: читать данные многоагентно можно, а вот записывать лучше однопоточно. Anthropic на своём research-продукте (read-heavy задачи) получила противоположный результат. Вывод не «кто прав», а «разные формы задач требуют разных архитектур»: write-heavy код тяготеет к одному агенту, read-heavy ресёрч выигрывает от многих.

Деньги и статистика провалов. Gartner прогнозирует (25 июня 2025, опрос 3400+ организаций), что более 40% проектов agentic AI будут закрыты к 2027 году — из-за растущих затрат, неясной ценности и слабого контроля рисков. Академический разбор MAST (1600+ трасс, 14 типов провалов) фиксирует частоту сбоев мультиагентных систем в диапазоне 41–86,7% (по вторичному пересказу первичного исследования).

Когда мультиагент прямо ХУЖЕ. Самое ценное — количественные пороги из независимого исследования Google DeepMind (декабрь 2025). Если одиночный агент уже решает задачу с успехом выше ~45%, добавление агентов ухудшает результат (эффект насыщения способности). На параллельных задачах мультиагент даёт прирост до +80,9%, а на последовательных рассуждениях — деградацию от −39% до −70%. Это операционализирует интуицию «усложняй только когда доказано» в конкретные числа: посмотрите на тип задачи (параллельная или последовательная) и на текущий успех одиночного агента, прежде чем дробить.

Почему так происходит, легко понять на пальцах. Параллельная задача (собрать данные из десяти источников) хорошо режется на независимые куски — агенты не мешают друг другу, и их работа складывается. Последовательное рассуждение (доказать теорему, где шаг 5 опирается на шаг 4) резать нельзя: передача промежуточного вывода между агентами теряет нюансы, и цепочка рвётся. Отсюда практическое правило: параллельное дробится, последовательное — нет. Если ваша задача — длинная цепочка зависимых шагов, один агент с непрерывным контекстом почти всегда лучше команды.

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

Живой риск на практике — утечка контекста между агентами: в реальном PR (июль 2026) чинили именно передачу лишнего контекста между агентами, приводившую к сбою. Изолированные контексты защищают, но стыки между агентами — точка, где всё ломается.

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

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

FAQ

Когда достаточно одного агента, а когда нужны несколько? Один агент — когда задача влезает в его контекст, экспертиза одна, важны предсказуемость и контроль. Несколько — при насыщении контекста, потребности в разных специализациях, параллелизме ради скорости или изоляции сбоев. Если ни один из этих сигналов не сработал, оставайтесь на одном агенте: мультиагент в 10–15 раз дороже в токенах.

Чем иерархическая архитектура отличается от коллаборативной? В иерархии центральный супервайзер координирует специалистов (субагенты как инструменты) — проще контролировать, но узкое место в контексте супервайзера. В коллаборативной равные агенты общаются напрямую — гибче, но труднее в отладке и рискует эмерджентным поведением. По устойчивости к ошибкам иерархия обычно выигрывает: централизованная координация усиливает ошибки примерно в 4,4 раза против 17,2 у независимых агентов.

Правда ли, что больше агентов — всегда мощнее? Нет. Если одиночный агент уже даёт выше ~45% успеха, добавление агентов часто ухудшает результат. На последовательных рассуждениях мультиагент деградирует на 39–70%. Есть находки, что три оптимизированных агента обгоняют семь, а обрезка команды улучшает и качество, и стоимость. Число инструментов (16+) — более сильный предиктор провала, чем число агентов.

Как выбрать архитектуру по дереву решений Anthropic? Ответьте на четыре вопроса: сколько нужно контроля (регуляторика/деньги/безопасность → один агент или последовательный воркфлоу), насколько сложен домен, каков бюджет токенов (мультиагент 10–15×), нужна ли глубокая разноплановая экспертиза. Каждый шаг к сложности повышает цену и риск — не идите дальше, чем требует задача.

Почему одни говорят «не стройте мультиагентов», а другие показывают +90%? Потому что они говорят про разные задачи. Cognition предупреждает про write-heavy задачи (код), где параллельные агенты конфликтуют при записи. Anthropic показала выигрыш на read-heavy ресёрче, где параллельное чтение складывается хорошо. Правильный вывод — смотреть на форму своей задачи, а не выбирать «лагерь».