Цепочка агентов или оркестратор: чем платить за автономность

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

Что скрывается за двумя словами

Термины в индустрии плавают, поэтому договоримся о значениях в рамках этого текста.

Цепочка (chain, pipeline) — фиксированная последовательность шагов. Выход шага N — вход шага N+1. Порядок задан кодом заранее: извлечь данные → суммаризировать → перевести → отформатировать. Ветвлений либо нет, либо они простые и предсказуемые.

Оркестратор (orchestrator, supervisor) — отдельный агент-диспетчер^*, который получает задачу, сам решает, каких исполнителей позвать, читает их ответы и на основании этого выбирает следующий шаг. Порядок и число вызовов определяются в рантайме моделью, а не автором кода.

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

Почему это не спор о вкусах

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

Стоимость: где утекают токены

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

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

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

Детерминизм: сможете ли вы повторить результат

Цепочка при одинаковом входе (и температуре 0) стремится к одинаковому выходу. Шаги те же, порядок тот же. Это удобно для тестов и для регресса: сломалось — знаете, на каком из пяти шагов.

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

Что это значит на практике

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

Наблюдаемость: где искать причину сбоя

Когда линейный пайплайн выдаёт мусор, вы смотрите логи по шагам и находите виновника. Причинно-следственная связь прямая.

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

Сравнение по ключевым осям

Когда что выбирать

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

1. Фиксированный процесс с известными шагами — цепочка. Например, конвейер обработки документа: распознать → извлечь поля → проверить → сохранить.
2. Задача с ветвлением, но конечным набором путей — цепочка с условными переходами (роутер на входе). Всё ещё предсказуемо и дёшево.
3. Открытая задача, где нужен выбор инструментов на лету — оркестратор. Пользователь спрашивает что угодно, а система сама решает: искать в вебе, лезть в базу или считать.
4. Много независимых подзадач разом — оркестратор с параллельным вызовом исполнителей, где диспетчер собирает результаты.

Гибридный путь

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

^* Агент-диспетчер (supervisor) — это тоже вызов языковой модели, только его задача не выполнить работу, а решить, кому её поручить и что делать с результатом. Он не считает и не пишет код сам, он маршрутизирует.