Когда одного агента уже не хватает

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

Четыре обязательных блока

Диспетчер
Решает, какой агент берётся за задачу. Может быть простым (жёсткий порядок шагов) или условным (в зависимости от результата предыдущего шага выбирается следующий).
Очередь задач
Хранит, что уже сделано, что в процессе, что ждёт своей очереди. Без неё при сбое одного шага непонятно, с какого места продолжать.
Общая память
Место, откуда каждый следующий агент берёт результат предыдущего. Без общей памяти агенты работают вслепую и дублируют чужую работу.
Наблюдаемость
Лог того, какой агент что сделал и почему принял именно такое решение. Без него отладка сводится к угадыванию, где сломалась цепочка.

Оркестратор или просто цепочка промптов

Таблица прокручивается вбок на телефоне →

ПараметрЦепочка промптов вручнуюОркестратор
Число шаговКомфортно до 2-3Держит десятки без потери контроля
Обработка сбоя на полпутиНачинать заново вручнуюПродолжает с места сбоя
Условная логика («если результат такой - иди сюда»)Приходится делать рукамиВстроена в диспетчер
Порог входаНизкий - просто пишете промпты по очередиВыше - нужно продумать архитектуру заранее

Если задач у вас 2-3 и они выполняются редко - цепочка промптов вручную быстрее и проще. Оркестратор окупается, когда шагов много, они выполняются регулярно и цена ошибки на полпути высокая.

Где чаще всего ломается на старте

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

С чего начать свой оркестратор

Сохраните себе
  1. Начните с линейной цепочки без условной логики - усложняйте только когда реальная задача этого потребует.
  2. Заложите общую память с первого дня, даже для двух агентов - переделывать архитектуру позже дороже.
  3. Логируйте каждое решение диспетчера - какой агент выбран и почему, а не только финальный результат.
  4. Продумайте, что произойдёт при сбое на середине цепочки - продолжение с места сбоя должно быть заложено сразу, а не добавлено потом.
  5. Не оркеструйте задачу, которую проще решить одним агентом - сложность архитектуры должна быть оправдана реальной зависимостью шагов друг от друга.
Когда нужен оркестратор ИИ-агентов, а не один агент?
Когда задач несколько, они зависят друг от друга по результату и выполняются регулярно - для разовой изолированной задачи одного агента достаточно.
Нужна ли сложная условная логика оркестратору с самого начала?
Нет, начните с линейной цепочки шагов и добавляйте ветвление только когда реальная задача этого потребует.
Что чаще всего забывают при проектировании оркестратора?
Наблюдаемость - лог решений каждого агента. Без него отладка сбоя превращается в угадывание, где сломалась цепочка.
← Все статьи блога