Оркестратор-агент: зачем один ИИ дирижирует другими

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

Что такое оркестратор-агент

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

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

Оркестратор не умнее исполнителей. Он просто не пытается держать в голове всё сразу — и в этом весь фокус.

Чем это отличается от обычного пайплайна

Жёсткий пайплайн — это заранее прописанная последовательность: сначала A, потом B, потом C. Разработчик решает порядок шагов на этапе кода. Оркестратор решает его во время выполнения: сам определяет, сколько исполнителей запустить, какие, и нужно ли повторить шаг, если результат вышел слабым. Это гибче, но и непредсказуемее по стоимости и времени.

Где оркестрация реально нужна

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

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

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

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

Главный подводный камень — стоимость. Anthropic прямо отметил, что мультиагентная система расходует в разы больше токенов, чем один чат: считается и работа оркестратора, и каждого исполнителя, и повторная передача промежуточных результатов. Точных множителей универсальных нет — они зависят от числа исполнителей и длины их контекстов, — но порядок «в несколько раз дороже одиночного вызова» держите в голове при проектировании.

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

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

Как это устроено внутри

Минимальный цикл оркестратора выглядит так:

1. Разбор запроса. Оркестратор получает задачу и формулирует план: какие подзадачи нужны и в каком порядке.
2. Делегирование. Каждой подзадаче он назначает исполнителя с чётким описанием — что вернуть, в каком формате, каким инструментом воспользоваться. Расплывчатое задание исполнителю — частая причина мусора на выходе.
3. Сбор результатов. Исполнители возвращают сжатые ответы. Оркестратор оценивает: хватает данных или нужен ещё один заход.
4. Синтез. Финальный вызов сводит всё в цельный ответ пользователю.

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

Готовые каркасы

Собирать оркестрацию с нуля не обязательно. Есть фреймворки, где паттерн уже заложен: LangGraph описывает агентов как граф с узлами и переходами, OpenAI выпустил Agents SDK с явной передачей задачи между агентами (handoff), CrewAI строит «команды» ролей. Выбор между ними — это выбор между контролем и скоростью старта: низкоуровневый граф даёт больше власти над логикой, высокоуровневая «команда» быстрее запускается, но хуже отлаживается, когда что-то идёт не так.

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

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

* Термин пришёл из музыки и из мира контейнеров: оркестратор дирижирует исполнителями, как дирижёр оркестром или Kubernetes контейнерами.