Когда мультиагентность превращается в оверинжиниринг

За последний год мультиагентные фреймворки стали витриной ИИ-инженерии: CrewAI, AutoGen от Microsoft, LangGraph, OpenAI Swarm (экспериментальный проект, который в 2025 году был заменён на Agents SDK). Идея одна — разбить задачу между несколькими автономными агентами, которые общаются друг с другом, и получить систему, превосходящую одну модель. На демо это выглядит впечатляюще. В продакшене команды всё чаще откатываются к одному-двум вызовам модели, потому что рой агентов оказывается медленнее, дороже и непредсказуемее.

Anthropic в инженерном блоге про свою исследовательскую систему Claude Research прямо предупредила: мультиагентные архитектуры сжигают в разы больше токенов, чем однопоточные, и оправданы только там, где задача реально параллелизуется и стоит этих денег. Это и есть главная развилка, о которой почти не говорят на конференциях.

Что вообще называют мультиагентностью

Под мультиагентной системой обычно понимают несколько экземпляров LLM с разными ролями и инструментами, которые обмениваются сообщениями и координируются — либо через оркестратора¹, либо напрямую между собой. Классический пример из демо: агент-планировщик разбивает задачу, агенты-исполнители делают части, агент-критик проверяет результат.

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

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

Три скрытые цены рвущегося на агентов проекта

• Токены. Каждый агент несёт свой системный промпт, историю диалога и описания инструментов. При передаче задачи между агентами контекст часто дублируется. Anthropic оценивала расход токенов мультиагентной системы примерно в 15 раз выше, чем у обычного чата, — цифра из их публикации, не универсальная константа.
• Латентность. Последовательные агенты складывают задержки. Там, где один вызов отвечает за 3–5 секунд, цепочка из четырёх ролей легко разгоняется до 20–40 секунд.
• Отладка. Когда результат неверный, надо понять, на каком из агентов сломалась логика. Трассировка межагентных сообщений — отдельная инженерная работа, которой в однопоточной системе просто нет.

Когда мультиагентность действительно оправдана

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

• Широкий research. Один агент-координатор ставит подзадачи, несколько субагентов параллельно ищут по разным источникам, координатор сводит. Ветки независимы — параллелизм реально экономит время.
• Разные модальности или инструменты. Когда одной части задачи нужен доступ к базе, другой — к вебу, третьей — к коду, и эти домены плохо совмещаются в одном промпте.
• Долгие автономные процессы. Мониторинг, где агент-наблюдатель следит за событиями и делегирует реакцию, а не выполняет всё в одном потоке.

Во всех остальных случаях стоит начинать с самого простого: один вызов модели, потом — один вызов с инструментами (function calling), потом — линейная цепочка. К мультиагентности переходить, только когда упёрлись в конкретное ограничение, а не заранее.

Сравнение подходов

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

Кому это пригодится, а кому нет

Стоит присмотреться к мультиагентности

• Команде, которая строит research-ассистента, обходящего десятки источников: параллельные субагенты сокращают время ответа реально, а не на бумаге.
• Продукту с чёткими независимыми доменами — например, когда один агент работает с CRM, другой с аналитикой, и их выводы сводятся в конце.
• Тем, у кого уже есть наблюдаемость: трассировка вызовов, логи, метрики токенов на каждого агента. Без этого мультиагентная система превращается в чёрный ящик.

Не стоит городить агентов

• Для чат-бота поддержки, который отвечает на вопросы по базе знаний. Здесь достаточно одного вызова с RAG³ — рой агентов только замедлит ответ.
• Для последовательных задач вроде «прочитать документ → извлечь поля → заполнить форму». Это линейный pipeline, а не переговоры автономных агентов.
• Стартапу на ранней стадии, где важнее скорость итераций и предсказуемая стоимость запроса, чем архитектурная эстетика.

Как не свалиться в оверинжиниринг

1. Сформулируйте задачу как один промпт и проверьте, где именно он ломается: не хватает данных, контекста, инструментов.
2. Добавьте недостающее минимальным способом — сначала инструменты к одному агенту, а не второго агента.
3. Замерьте латентность и расход токенов до и после каждого усложнения. Если цифры растут быстрее качества — откатывайтесь.
4. Переходите к параллельным агентам, только когда доказали, что ветки независимы и последовательное выполнение — узкое место.
5. Заложите трассировку с первого дня: без логов межагентного обмена вы не отладите систему в проде.

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

² Контекстное окно — максимальный объём текста (в токенах), который модель удерживает за один вызов; при переполнении старые части теряются.

³ RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные фрагменты из внешней базы и опирается на них.