Мультиагентные системы: почему рой агентов бьёт по счёту

Идея звучит соблазнительно: вместо одной модели, которая пытается всё держать в голове, вы запускаете несколько специализированных агентов. Один планирует, второй пишет код, третий проверяет, четвёртый ищет в интернете. Фреймворки вроде LangGraph, CrewAI, AutoGen и OpenAI Swarm сделали такую сборку вопросом сотни строк кода. Но у архитектуры есть скрытая цена, о которой в туториалах пишут редко: каждый агент — это отдельная цепочка вызовов LLM, и счёт растёт не линейно, а с ускорением.

Откуда берётся перерасход

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

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

Три источника лишних токенов

• Повторное чтение контекста. Каждый вызов внутри цепочки перечитывает всю предыдущую переписку. В длинных сессиях доля входных токенов доминирует над выходными.
• Служебные промпты. У каждого агента своя системная инструкция — роль, инструменты, правила. Эти сотни токенов уходят в каждый запрос агента.
• Циклы и переспросы. Агент-критик отклоняет ответ, агент-исполнитель переделывает, и круг повторяется. Каждая итерация — новый полный проход.

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

Энергия и счёт — это одно и то же

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

Важная деталь ценообразования: у крупных провайдеров выходные токены стоят заметно дороже входных, а длинный контекст оплачивается на каждом шаге. Актуальные тарифы всегда сверяйте на страницах цен OpenAI, Anthropic и Google — они меняются несколько раз в год, и подставлять сюда конкретное число в долларах за миллион токенов было бы дезинформацией уже через квартал.

Одна модель против роя: что выбрать

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

Практический вывод: прежде чем поднимать рой из пяти агентов, проверьте, не решается ли задача одной моделью с доступом к инструментам. Часто оркестрация нужна не самой задаче, а красоте диаграммы.

Как урезать счёт, не ломая архитектуру

1. Ставьте разные модели на разные роли. Планировщику нужна сильная модель, а агенту-форматтеру хватит дешёвой и быстрой. Гонять всё через флагман — самый частый способ переплатить.
2. Ограничивайте историю. Не тащите в каждый вызов всю переписку. Суммируйте старые ходы или обрезайте контекст до релевантного окна.
3. Кешируйте промпты. Провайдеры предлагают кеширование входного контекста — повторяющиеся системные инструкции тарифицируются со скидкой. Проверьте, поддерживает ли ваш API prompt caching.
4. Ставьте лимит на циклы. Жёсткий потолок итераций между исполнителем и критиком спасает от бесконечных переделок, которые тихо съедают бюджет.
5. Логируйте токены по агентам. Без разбивки расхода по узлам вы не поймёте, кто именно жжёт бюджет. Большинство фреймворков отдают эту телеметрию из коробки.

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

Мультиагентная схема оправдана, если:

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

Рой агентов вам не нужен, если:

• задача решается одним промптом с чёткой инструкцией — чат-бот поддержки, классификация обращений, короткая генерация;
• вы работаете на высоком объёме запросов, где каждая лишняя тысяча токенов множится на миллионы вызовов;
• важна предсказуемая задержка: цепочка из десятка вызовов почти всегда медленнее одного.

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

* RAG (Retrieval-Augmented Generation) — подход, при котором модель перед ответом подтягивает релевантные фрагменты из внешней базы знаний и отвечает с опорой на них, а не только на обучающие данные.