Шеф формирует бригаду под заказ: Orchestrator-Workers
🤔 Зачем это читать
В прошлой теме ты разобрал распараллеливание (parallelization — когда задачу заранее режут на независимые куски и считают одновременно). Удобно, быстро. Но вот сцена с работы, которую этим способом не закрыть. К тебе приходят жалобы клиентов. Одна — на качество товара, и всё. Другая — на качество, на доставку и ещё на грубость менеджера, три разных отдела. Третья вообще про возврат денег, четвёртая — одна строчка «всё плохо». Каждая жалоба по структуре своя. Сколько частей в ней — заранее не знает никто.
И тут фиксированный конвейер пасует. Ты не можешь прописать «всегда дели жалобу на три части и раздавай трём исполнителям» — потому что в одной жалобе одна тема, а в другой пять. Жёсткая нарезка либо разрежет простое на лишние куски, либо не успеет разрезать сложное. Задачи каждый раз разные по форме — а конвейер один и тот же.
Знакомо? Это типичная ловушка: пытаешься загнать живой поток разнокалиберных задач в одну жёсткую схему — и она трещит на каждой второй. Нужен не фиксированный конвейер, а кто-то, кто посмотрит на конкретную задачу и решит на месте, на сколько частей её бить и кого звать.
После этой темы ты сможешь отличать задачи, где хватит заранее нарезанного конвейера, от задач, где нужен экспедитор, формирующий бригаду на лету (orchestrator-workers — экспедитор-исполнители). А заодно увидишь, почему этот мощный приём не стоит включать везде подряд: за гибкость платят и деньгами, и риском, что разбивку напутает уже сам экспедитор.
Задержись на 10 секунд. Вспомни на своей работе поток заявок, обращений или заказов, где каждая штука — своей формы: одна простая, другая разветвлённая на пять подзадач, и заранее ты не знаешь, какая придёт. Подержи эту картину в голове. Именно для неё придуман сегодняшний приём — и к ней мы вернёмся в конце.
🍽 Банкет, под который шеф каждый раз собирает разную бригаду
Помнишь бригаду из прошлых тем — кухню, где не один повар-универсал, а несколько ролей: гриль, соусы, холодный цех, десерты (мультиагент — бригада агентов, где у каждого своя задача)? И помнишь экспедитора у раздачи — того, кто принимает заказ, раздаёт по станциям и собирает блюда одного стола вместе? Сегодня этот экспедитор выходит на первый план.
Представь шефа-экспедитора, к которому пришёл заказ на банкет. Он смотрит на конкретный заказ — и под него решает, кого сегодня поставить к плите. Заказ на 20 человек, всё горячее, без сладкого? Зовёт гриль и соусника, кондитера сегодня не трогает. Завтра заказ на свадьбу: тут и горячее, и три вида десерта, и отдельно — диетическое блюдо для гостя с аллергией. Шеф формирует бригаду уже другую: добавляет кондитера, выделяет отдельного повара под аллергика. Бригада не фиксирована — она собирается под каждый заказ заново.
Вот это и есть orchestrator-workers (по-русски — «экспедитор-исполнители»): один агент-оркестратор (orchestrator — дирижирующий агент, тот, кто оркеструет; оркестрация / orchestration — это и есть дирижирование агентами) смотрит на пришедшую задачу, сам решает, на какие подзадачи её разбить и сколько исполнителей (workers — рабочие-исполнители) под это нужно, раздаёт им подзадачи, дожидается и собирает результат в один ответ. Ключевое слово — «сам решает». Не по заранее прописанной схеме, а глядя на то, что именно пришло.
⚖️ Чем это отличается от распараллеливания (и почему путают)
Тут легко споткнуться, потому что снаружи похоже: и там, и там задачу делят на куски и считают их несколькими исполнителями. Но разница принципиальная, и она в одном слове — кто решает, на сколько частей бить.
При распараллеливании части нарезаны заранее, тобой, и всегда одинаково. Ты сел до запуска и прописал: «у договора всегда проверяем три вещи — сроки, штрафы, условия оплаты». Три раздела — три исполнителя, каждый раз одни и те же. Это как бригада на банкет, где меню известно и всегда одно: гриль, салаты, десерт — три станции, неизменно. Деление зашито в схему.
При orchestrator-workers части определяет оркестратор на лету, глядя на конкретную задачу. Сколько подзадач — заранее неизвестно, потому что зависит от того, что пришло. Одной жалобе хватит одного исполнителя, другой нужно пять. Это шеф, который смотрит на сегодняшний заказ и только тогда решает, кого ставить к плите.
🔁 Как это работает по шагам (на пальцах)
Если совсем коротко: оркестратор посмотрел на задачу → нарезал подзадачи под неё → раздал исполнителям → собрал их ответы в один результат. А ниже то же самое чуть подробнее, на псевдокоде — это просто логика на человеческом языке, не настоящий код (можешь пролистать, если суть уже ясна).
задача = пришедшая жалоба клиента # форма заранее неизвестна
# ШАГ 1 — экспедитор смотрит на КОНКРЕТНУЮ задачу и сам решает разбивку
подзадачи = оркестратор читает жалобу → выделяет, сколько в ней тем
# в одной жалобе вышло 1 тема, в другой — 5; число НЕ задано заранее
# ШАГ 2 — раздать каждую подзадачу своему исполнителю
для каждой подзадачи из подзадачи:
ответ = исполнитель разбирает свою подзадачу
# ШАГ 3 — экспедитор собирает все ответы в один результат у «раздачи»
итог = оркестратор сводит ответы исполнителей в единый ответ клиенту
# → на следующую жалобу бригада соберётся заново, под её форму
Заметь две вещи. Первое: всю работу по разбивке делает шаг 1 — это и есть мозг паттерна, момент, где оркестратор «думает», на что бить. Второе: оркестратор не просто раздаёт, он ещё и собирает разрозненные куски обратно в осмысленное целое. Раздать-собрать (map-reduce — здесь в смысле «раздать подзадачи и собрать их ответы воедино») — две половины одной работы, и обе на нём.
💸 Что это даёт владельцу — и чем за это платят
Польза прямая: один и тот же агент-оркестратор закрывает поток разнокалиберных задач, который фиксированным конвейером не закроешь. Не надо городить десять разных схем под десять форм жалоб — одна гибкая, которая подстраивается. Там, где задачи и правда каждый раз разные, это экономит и нервы, и переделки.
Но за гибкость есть цена, и владельцу её надо видеть. Во-первых, дороже: шаг «оркестратор думает над разбивкой» — это лишний вызов модели на каждую задачу, поверх работы самих исполнителей. Во-вторых, и это важнее, оркестратор сам может ошибиться в разбивке: разрезать жалобу не по тем швам, потерять тему, раздробить то, что надо было оставить целым. Появляется новая точка, где всё может пойти не так — и эта точка не в исполнителях, а в том, кто ими дирижирует.
Отсюда мышление владельца: не «давайте сделаем умный динамический оркестратор» по умолчанию, а сначала честно спросить — а структура задачи правда каждый раз разная? Если по факту она почти всегда одинаковая, фиксированное деление дешевле, проще и надёжнее — и одной точкой отказа меньше. Динамический экспедитор берут не для красоты, а когда разнообразие задач реально не лезет в жёсткую схему.
🎮 Фиксированный конвейер — или экспедитор на лету?
Шесть задач с работы. Для каждой реши: хватит ли заранее нарезанного конвейера (распараллеливание, деление всегда одинаковое) — или нужен экспедитор, который формирует бригаду на лету (orchestrator-workers)? Сначала сформулируй ответ про себя, потом жми и сверяйся. Разбор появится сразу.
Прежде чем жать на кнопку, проговори про себя один признак: «структура этой задачи КАЖДЫЙ РАЗ одинаковая — или меняется от случая к случаю?» Одинаковая → хватит конвейера. Каждый раз разная → нужен экспедитор.
📖 Ключевые понятия
- Orchestrator-Workers (экспедитор-исполнители)
- Приём, где один агент-оркестратор смотрит на конкретную задачу, сам решает на лету, на сколько подзадач её разбить и сколько исполнителей нужно, раздаёт их и собирает ответы воедино. Шеф-экспедитор, который под каждый заказ-банкет формирует свою бригаду заново.
- Оркестратор (orchestrator)
- Дирижирующий агент: тот, кто оркеструет. Не делает работу сам, а решает, как разбить задачу, кому что поручить и как собрать результат. Его «мозг» — это шаг разбивки: посмотреть на задачу и понять, на что её бить.
- Исполнители (workers)
- Агенты, которым оркестратор раздаёт подзадачи. Каждый делает свой кусок и возвращает результат. Сколько их и кто именно — зависит от задачи, потому что бригада собирается под неё.
- Раздать-собрать (map-reduce)
- Две половины работы оркестратора: «раздать» подзадачи исполнителям и «собрать» их ответы обратно в единое целое. Экспедитор не только распределяет по станциям, но и сводит блюда одного стола вместе у раздачи. (Здесь — в смысле «раздать и собрать»; как этим закрывают массовый поток однотипных задач, отдельно разберём позже.)
- Динамическое дробление
- Разбивка задачи решается в момент исполнения, глядя на конкретный вход, а не задана заранее. Это и есть главное отличие от распараллеливания, где части нарезаны до старта и всегда одинаковые.
🛡️ Частые заблуждения
«Orchestrator-workers — это просто распараллеливание, только модно названное»
Нет, разница в одном принципиальном месте: кто и когда решает разбивку. При распараллеливании части нарезаны заранее тобой и всегда одинаковые. При orchestrator-workers их определяет сам оркестратор на лету, глядя на конкретную задачу, — число подзадач заранее неизвестно. Снаружи похоже (и там, и там несколько исполнителей), но это разные инструменты под разные задачи: одинаковая структура → конвейер, разная каждый раз → экспедитор.
«Динамический экспедитор умнее, значит его и надо ставить везде»
Перебор, и дорогой. За гибкость платят: лишний вызов модели на разбивку каждой задачи плюс риск, что оркестратор сам напутает с нарезкой. Если структура задачи на практике почти всегда одинаковая, фиксированное деление дешевле, проще и надёжнее — и в нём одной точкой отказа меньше. Динамику берут не потому, что «умнее», а потому, что разнообразие задач реально не лезет в жёсткую схему.
«Оркестратор просто раздаёт работу — собрать всё обратно несложно, это мелочь»
Как раз сборка — половина дела и частый источник провала. Раздать подзадачи мало: ответы исполнителей надо свести в один связный результат без дублей, противоречий и потерянных кусков. Экспедитор, который раздал по станциям, но не собрал блюда одного стола вместе, оставит гостя с разрозненными тарелками. «Собрать» нагружает оркестратор не меньше, чем «раздать».
🧠 AI-чутьё (AI Judgment)
Динамическое дробление мощно, но не бесплатно — и не всегда нужно
Главный навык владельца здесь не «уметь собрать оркестратор», а уметь спросить: а структура моих задач правда каждый раз разная — или мне это только кажется? Динамическое дробление выглядит умно и универсально, и именно поэтому его легко поставить туда, где хватило бы простого фиксированного деления. А каждый «умный» оркестратор — это лишние деньги на каждую задачу и новая точка, где можно ошибиться: теперь напутать с разбивкой может не только исполнитель, но и тот, кто ими дирижирует.
Прикладывай к любому предложению про «умную автоматизацию, которая сама всё разрулит» простой фильтр: «что именно решается на лету — и точно ли это нельзя зашить заранее?». Если вендор предлагает динамический оркестратор там, где задачи на самом деле однотипные, — он продаёт тебе сложность и счёт за неё, а не пользу. Гибкость окупается только там, где есть настоящее разнообразие.
И держи нить вперёд. Сам вопрос «на сколько частей вообще стоит дробить и стоит ли» — это отдельная большая тема, к которой мы скоро подойдём: дробление мощно, но избыточная бригада на простой задаче — это бардак и палёж бюджета, ровно как пять поваров на одну яичницу. А ещё рядом встанет вопрос «кто здесь главный и что будет, если он отвалится»: оркестратор — это удобный хаб, но и единая точка отказа (single point of failure — узел, поломка которого роняет всю систему): заболел шеф-экспедитор — и кухня встала, даже если повара на местах.
🎯 Практика
Одно задание на пять минут — оно превращает «фиксированный конвейер против экспедитора» из абзаца в твой рабочий фильтр.
- Вернись к тому потоку задач, который ты держал в голове в начале — заявки, обращения, заказы. Запиши его в одну строку.
- Честно реши главный вопрос: структура этих задач каждый раз одинаковая или разная? Возьми пять реальных штук из этого потока и посмотри — у всех ли пяти один и тот же набор частей, или у каждой свой. Это и есть твой диагноз.
- По диагнозу выбери: одинаковая структура → фиксированный конвейер (дешевле и надёжнее, не усложняй). Разная каждый раз → экспедитор на лету — и тогда сразу прикинь цену: лишний вызов на разбивку каждой задачи плюс риск, что оркестратор её напутает. Стоит ли гибкость этих денег именно в твоём случае?
Помнишь поток жалоб из начала — где одна про одно, а другая сразу про пять отделов? Теперь видно, почему фиксированная нарезка на нём трещала: структура каждый раз разная. Экспедитор, который читает жалобу и собирает бригаду под неё, — ровно для такого потока. А вот типовой договор с тремя вечными разделами в таком экспедиторе не нуждается — там хватит конвейера.