Иерархия агентов: как менеджер раздаёт задачи подчинённым

Один агент на GPT-4-класса модели неплохо справляется, пока задача помещается в один диалог. Как только вы просите его «изучить рынок, сравнить пять конкурентов, написать отчёт и подготовить презентацию», контекст переполняется, инструкции теряются, а модель начинает путать шаги. Ответ, к которому пришли команды OpenAI, Anthropic, LangChain и CrewAI, — не один большой агент, а несколько маленьких с разделением ролей. Самая ходовая архитектура называется orchestrator-worker: агент-менеджер декомпозирует задачу и раздаёт куски агентам-исполнителям.

Зачем вообще делить агента на роли

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

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

Менеджер не должен уметь всё. Он должен уметь раскладывать задачу на части, которые кто-то другой выполнит независимо, и собирать ответы обратно.

Как устроена связка менеджер — подчинённые

В базовом варианте поток выглядит так:

1. Декомпозиция. Менеджер получает цель пользователя и разбивает её на подзадачи. Часто это отдельный вызов модели, который возвращает структурированный список (JSON с шагами).
2. Делегирование. Каждая подзадача уходит агенту-исполнителю. Исполнители могут работать параллельно, если между ними нет зависимостей, или последовательно, если результат одного нужен другому.
3. Сбор и синтез. Менеджер получает результаты, отбраковывает мусор, при необходимости отправляет задачу на переделку и формирует финальный ответ.

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

Плоская иерархия против глубокой

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

Сколько это стоит и как медленно работает

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

Где деньги и время утекают:

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

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

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

Где всё ломается

Иерархия агентов добавляет свои классы ошибок, которых нет у одиночного агента.

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

^* Галлюцинация — уверенный ответ модели, не опирающийся на реальные данные: выдуманный факт, ссылка или цифра, поданные как достоверные.

Практические принципы

Что снижает боль при построении такой схемы:

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

Готовые каркасы для этого уже есть: CrewAI построен вокруг ролей и делегирования, LangGraph позволяет описать граф с supervisor-узлом, OpenAI Agents SDK и Anthropic-документация показывают паттерны orchestrator-worker. Ни один из них не избавляет от главного вопроса — стоит ли вообще дробить задачу. На него отвечаете вы, а не фреймворк.