Один агент со всеми инструментами сразу рано или поздно начинает путаться в маршрутизации и планировании. Он тратит контекстное окно на то, что можно было бы отдать отдельному специалисту. Multi-agent архитектура решает эту проблему разделением задач между несколькими агентами с узкой ролью каждого. Ниже три конкретных сценария, где это дает измеримую выгоду, и честный разбор, почему несколько агентов не всегда дешевле одного.
В статье: три бизнес-сценария с multi-agent архитектурой (саппорт, контент, разработка), таблица распределения ролей, честная оценка расходов на API и разбор, когда несколько агентов вообще не нужны.
Зачем продукту несколько AI-агентов, если один справляется?
Один агент справляется, пока у него мало инструментов и задача линейна. Как только маршрутизация, память и инструменты растут, агент начинает путаться и терять контекст. Multi-agent архитектура выделяет отдельного агента там, где ему нужна собственная область принятия решений.
Проблема с одним универсальным агентом не в его "уме", а в перегрузке. Ему приходится одновременно решать, к какому инструменту обратиться, как спланировать шаги и что сохранить в памяти. Каждая новая функция добавляет ему еще один повод запутаться в маршрутизации.
Разделение на специализированных агентов снимает эту нагрузку. Правило простое: выделяй агента не потому, что можно формально выделить шаг процесса, а потому, что этому компоненту действительно нужна отдельная область принятия решений. Если задача строго последовательная и один агент напрямую зависит от результата другого, отдельный агент чаще всего не нужен, там хватит обычного пайплайна.
Как несколько агентов снижают расходы на саппорте?
Супервайзер разбирает входящий запрос и отправляет простые вопросы дешевой модели, а сложные, требующие эскалации, дорогой. Разделение по стоимости модели, а не по случайному распределению нагрузки, дает реальную экономию на API.
В типичной multi-agent системе поддержки супервайзер маршрутизирует запрос к одному из специализированных агентов: технический, биллинг, отслеживание заказов, FAQ, жалобы, эскалация. Каждый агент решает узкую задачу и использует RAG для поиска ответа в базе знаний компании, вместо того чтобы держать все правила и процессы в одном гигантском системном промпте.
Экономика здесь простая. Вопрос "как сбросить пароль" не требует топовой модели с длинным контекстом. А вот жалоба с признаками фрустрации клиента, где нужна деэскалация и потом передача живому оператору, оправдывает более дорогую модель и развернутый промпт. Дорогая модель включается только там, где она реально нужна, а не на каждый входящий диалог подряд. Отдельный агент эскалации, который структурированно передает диалог человеку, когда AI не справляется, часто и есть разница между системой, которой доверяют, и обычным чат-ботом.
Как ускорить контент-конвейер несколькими агентами вместо одного?
Один агент генерирует черновик, второй проверяет факты и стиль, третий адаптирует текст под конкретный канал. Роли выполняются параллельно, а не по очереди, что дает выигрыш по времени на объеме контента.
При последовательной работе одного агента над большим объемом текста время растет линейно: сначала черновик, потом проверка, потом адаптация под каждый канал по очереди. При параллельных ролях разные части конвейера обрабатываются одновременно, и именно на объеме разница становится заметной.
Похожий принцип работает и в командах живых людей, только с агентами роль. Лиза, например, раньше вручную разбирала по 15-20 видео на одну контентную единицу для VibeCoderz. После того как процесс расписали на отдельные шаги, скрипт стал вставлять ссылки, забирать транскрибацию и раскладывать разбор по 15 критериям. Задача, которая занимала 4 часа, стала занимать 5,5 минут. Формально это не классическая multi-agent система, но принцип тот же: выделить каждому шагу свою узкую зону ответственности вместо одного универсального прохода.
Почему код-ревью отдельным агентом снижает риск пропущенных ошибок?
Один агент пишет код, второй независимо ищет в нем баги и уязвимости, третий пишет тесты. Независимость ролей снижает риск, что модель "не замечает" собственную ошибку, потому что смотрит на код, который сама же написала.
Модель, которая пишет код и сама же его проверяет в одном проходе, реже находит собственные ошибки. Она уже приняла решения по архитектуре и склонна их подтверждать, а не оспаривать. Отдельный агент-ревьюер, у которого нет истории написания этого кода, смотрит на него свежим взглядом и охотнее находит то, что автор кода пропустил.
На практике это близко к иерархической архитектуре: оркестратор решает, к каким агентам обращаться, а специализированные агенты параллельно закрывают свои узкие задачи, включая независимую верификацию. В инструментах вроде Claude Code и Cursor такая логика уже встроена через под-агентов: можно поручить один поток кодогенерации, а ревью и тесты выделить в отдельную роль с собственным контекстом.
Multi-agent архитектура всегда дешевле одного агента?
Нет. Несколько агентов означают несколько отдельных вызовов API вместо одного, и при наивной реализации это увеличивает расход токенов, а не снижает его. Экономия появляется только при осмысленном распределении ролей по стоимости модели, а не при автоматическом умножении числа вызовов.
Здесь важна честная оговорка. По данным инженерного отчета Anthropic о системе для Claude Research, обычный агентский диалог тратит примерно в 4 раза больше токенов, чем стандартный чат, а multi-agent система с несколькими под-агентами использует уже около 15 раз больше токенов, чем обычный чат. При этом на исследовательских задачах такая архитектура показала прирост качества примерно на 90% относительно одиночного агента — но это цена за широкий параллельный поиск по большому объему источников, а не бесплатный бонус.
Разработчики платформы Vercel в своем гайде по multi-agent системам называют три законных повода добавлять агентов: каталог инструментов у одного агента разросся за 10-15 штук, подзадачи реально независимы и могут идти параллельно, или контекст переполняется даже после сжатия истории. Если ни одного из этих трех условий нет, дешевле и надежнее оставить одного агента с хорошо описанными инструментами.
Максим: «У Нейроскрайба ждали от разработчика неделю-две-три на фичу. У Нейроштата целая команда работала месяцами над тем же классом задач, и результат все равно разочаровывал, потому что скорость реализации оказалась критичнее самого функционала. С тех пор я сначала считаю, окупит ли лишний агент задержку и токены, а потом уже добавляю его в систему.»
Кому и когда действительно нужна multi-agent архитектура
| Сценарий | Роли агентов | Где экономия | Риск при наивной реализации |
|---|---|---|---|
| Саппорт с эскалацией | Супервайзер, технический, биллинг, эскалация | Дешевая модель на простые вопросы, дорогая только на сложные | Все агенты на одной дорогой модели без разделения по стоимости |
| Контент-конвейер | Черновик, факт-чек и стиль, адаптация под канал | Параллельная работа вместо последовательной, экономия времени на объеме | Дублирование контекста между агентами, повторная передача одних и тех же данных |
| Разработка с ревью | Кодогенерация, независимый ревьюер, тесты | Меньше пропущенных ошибок за счет независимого взгляда | Оркестратор без четких routing hints, агенты путают, кому передавать управление |
Три сценария объединяет одно: агента выделяют не ради архитектурной моды, а потому что у него появляется собственная зона решений, которую нет смысла держать в одном универсальном промпте.
Частые вопросы про multi-agent архитектуру
Сколько агентов нужно продукту для старта?
Для большинства продуктов на старте достаточно одного агента с хорошо описанными инструментами. Добавлять второго и третьего стоит только когда у одного агента реально разрослись каталог инструментов или маршрутизация.
Multi-agent система дороже одного агента в API?
Да, обычно дороже, если считать в токенах на задачу. Экономия появляется не за счет меньшего числа вызовов, а за счет того, что дорогая модель используется только на сложных подзадачах, а не на каждом запросе подряд.
Чем отличается multi-agent от простого пайплайна с несколькими шагами?
В пайплайне шаги жестко зависят друг от друга и выполняются по порядку. В multi-agent системе у каждого агента есть собственная область принятия решений, и он может работать параллельно с другими или даже отказаться от шага, если он не нужен.
Нужен ли multi-agent саппорт-бот небольшому продукту?
Обычно нет. Разделение на агентов оправдано, когда объем и разнообразие обращений уже требуют разных процессов эскалации и разного уровня модели под них. На малом объеме один хорошо настроенный агент справляется дешевле.
Как передать контекст между агентами без потери информации?
Через сжатую сводку (summary) вместо полной истории диалога, плюс сохранение AI- и tool-сообщений при передаче управления, чтобы у принимающего агента была целостная картина без раздувания контекста.
Можно ли совмещать multi-agent архитектуру с обычным Claude Code или Cursor?
Да, оба инструмента поддерживают под-агентов с собственным контекстом внутри одной сессии разработки. Это позволяет выделить, например, отдельного агента для ревью кода без переезда на отдельный фреймворк оркестрации.
Каталог инструментов и обзоры IDE с поддержкой агентов смотрите в каталоге AI-инструментов VibeCoderz. Если решаете, нужна ли multi-agent архитектура именно вашему продукту, обсудите это на консультации с Максимом.