Команда узких агентов против одного универсала: что дешевле

Идея одного всемогущего агента, которому кидаешь любую задачу, красиво выглядит в демо и разваливается на реальном рабочем процессе. Контекст переполняется, модель путает роли, а на длинной цепочке рассуждений накапливаются ошибки. Ответ индустрии — мультиагентные системы, где вместо универсала работает связка узких исполнителей: один планирует, второй пишет код, третий проверяет, четвёртый лезет в базу данных. Anthropic в своём инженерном блоге за 2025 год описывала, как их система для глубокого поиска раскладывается на ведущего агента и субагентов, которые ищут параллельно. Google продвигает похожую логику через фреймворк Agent Development Kit. Но у разделения труда есть цена, и она измеряется в токенах и задержке.

Почему универсал упирается в потолок

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

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

Специализация бьёт по всем трём точкам. Узкий агент получает короткий, заточенный под задачу промпт и чистый контекст. Роли разведены. А отдельный агент-критик способен поймать ошибку до того, как она уйдёт дальше.

Как устроена команда агентов

Самая распространённая схема — оркестратор и исполнители¹. Ведущий агент разбирает запрос, решает, какие подзадачи нужны, и раздаёт их специализированным субагентам. Каждый субагент работает в своём контексте и возвращает наверх только результат, а не весь ход размышлений. Это экономит контекст оркестратора: он видит итоги, а не мусор промежуточных шагов.

Типовые роли

• Планировщик — раскладывает задачу на шаги, не выполняя их.
• Исполнитель — делает конкретную работу: пишет код, дёргает API, формирует текст.
• Критик или ревьюер — проверяет результат исполнителя против требований.
• Инструментальный агент — узкий доступ к одному ресурсу: поиск, база данных, файловая система.

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

Где проходит граница специализации

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

Цена вопроса: токены и задержка

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

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

Когда команда оправдана, а когда нет

Ориентируйтесь на характер задачи, а не на моду.

1. Задача распадается на независимые куски. Если подзадачи можно делать параллельно — поиск по разным источникам, проверка нескольких гипотез, — команда даёт выигрыш по времени.
2. Нужен внешний контроль качества. Отдельный критик ловит то, что исполнитель не видит в своём же выводе.
3. Разные подзадачи требуют разных моделей. Дешёвая быстрая модель для рутины, дорогая — для сложного рассуждения. Тут разделение экономит, а не тратит.
4. Задача линейна и коротка. Тогда универсал справится дешевле и быстрее, а лишние агенты только добавят задержку.

Что ломается на практике

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

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

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

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