← Университет

Оркестрация и субагенты: как устроен «консилиум» ИИ-агентов и что из этого применимо к заводу Лучиана

Зачем вообще нужна оркестрация

Оркестрация — это не «запустить несколько ИИ одновременно», это управление координацией: кто что делает, кто кому передаёт результат, кто проверяет качество, что происходит при сбое. Anthropic формулирует это жёстко: «многоагентные системы нужно проектировать как архитектуры прежде всего, промпты — во вторую очередь» (orchestration-patterns.md). Это первая и главная ошибка новичков — они думают, что мультиагентность решается хорошим промптом для «главного» агента. На деле она решается тем, кто кому что показывает и в какой момент.

Важно с самого начала развести три роли, которые часто путают под общим словом «агент». Планировщик (planner) решает, ЧТО делать и в каком порядке — на выходе план и критерии готовности, а не готовый результат. Исполнитель (executor) делает конкретную работу инструментами — пишет код, генерирует картинку, отправляет запрос в API. Критик (critic/judge) оценивает результат исполнителя против критериев планировщика и имеет право вернуть на доработку или дать вето. Смешение этих трёх ролей в одном агенте — самая частая причина, почему «умный ИИ» выдаёт правдоподобный, но неверный результат: один и тот же агент, который писал код, не может объективно найти в нём ошибку — у него, по выражению доклада Factory (ow1we5PzK-o), «cost bias»: он заинтересован, чтобы его же работа оказалась правильной. Именно поэтому разделение planner/executor/critic — не организационная прихоть, а способ убрать этот системный перекос, аналогично тому, как в человеческой команде автор кода не проверяет сам себя.

У Лучиана уже есть живой пример оркестрации — конвейер завода ⓪→⑨ (channel-forge → memory-bank → channel-hq → генератор → thumbnail-studio → channel-hq → YouTube → memory-bank). Это классический иерархический pipeline с гейтами: центральный «диспетчер» (channel-hq/core/orchestrator.mjs, сейчас выключен) ведёт проект по строго определённым стадиям, у каждой стадии свой владелец-сервис, узкая специализация, и есть два человеческих контрольных пункта (EDIT_PENDING, APPROVAL_PENDING). По сути это уже «оркестратор + рабочие», просто ещё не автономный ночью и с ручными гейтами вместо агента-критика.

Пять базовых паттернов оркестрации — и где они уже живут на заводе

Материал orchestration-patterns.md выделяет пять архитектур координации агентов, и полезно сразу примерить их на завод, а не изучать абстрактно.

1. Sequential / Pipeline (конвейер). Линейная цепочка этапов, каждый зависит от предыдущего. Это ровно то, что уже есть: ⓪→⑨. Хорош, когда порядок операций фиксирован и известен заранее (генерация видео действительно не может обойтись без сценария до озвучки).

2. Hierarchical (оркестратор + воркеры). Центральный агент решает, каких специализированных «работников» вызвать, и параллелит независимые части. Anthropic сообщает конкретную цифру: параллельные вызовы инструментов ускоряют результат на 90% против последовательных, а мультиагентная система на Opus-лидере с Sonnet-подагентами обошла одноагентный Opus на 90.2% в исследовательских задачах (за счёт того, что «главный агент координирует, делегируя специализированным подагентам, работающим параллельно»). У Лучиана это уже есть частично — POST /api/projects/batch запускает N видео параллельно, «пейсит губернатор» (resource-governor). Это и есть иерархическая оркестрация с брокером ресурсов вместо неограниченного fan-out.

3. Handoff (передача управления). Децентрализованная маршрутизация: агент сам решает, кому передать задачу дальше, получатель становится полноправным «владельцем», а не просто вызванным инструментом. Хорошо ложится на будущего «универсального строителя» Лучиана: triage-агент читает запрос клиента → передаёт архитектору → тот передаёт кодеру → кодер передаёт тестировщику. Риск — «бесконечные циклы передачи» (агент А отправляет к Б, Б отправляет обратно к А), поэтому нужен предел числа хопов и «естественное завершение» — рабочий процесс кончается, когда активный агент не инициирует новый handoff. Этот же паттерн напрямую применим к будущему агенту-«разведчику возможностей» (opportunity scout) из требований Лучиана: сканирование рынка/трендов — это по природе задача с неизвестным заранее маршрутом (сегодня зацепка в нише X, завтра в тренде Y), поэтому её правильно строить как handoff-цепочку (сканер → углублённый анализ конкретной находки → расчёт экономики → передача в очередь на решение), а не как жёсткий pipeline с фиксированным числом этапов, потому что для одной находки может понадобиться два шага, а для другой — пять.

Отдельно стоит подчеркнуть разницу между agent и workflow, которую материал LP5OCa20Zpg формулирует чётко: агент сам решает, сколько шагов ему нужно для решения задачи и в каком порядке действовать, тогда как workflow следует фиксированному пути с заранее определённым числом этапов. Это не вопрос «что лучше», а вопрос соответствия задаче: конвейер видео Лучиана внутри одной стадии (например, stage_script → stage_script_qc → stage_voice → ...) — это workflow, потому что порядок операций известен и не меняется от прогона к прогону; а вот выбор темы для канала или диагностика боли клиента в консультант-фабрике — это агентная задача, потому что число нужных шагов и их порядок заранее не известны. Ошибка в обе стороны: жёсткий workflow там, где нужна гибкая разведка (например, «5 шагов на выбор ниши», хотя иногда нужно 2, а иногда 12), или свободный агент там, где путь и так известен и его достаточно закодировать один раз (тогда агент просто дороже и менее предсказуем, чем скрипт).

4. Blackboard (общая доска). Агенты не общаются друг с другом напрямую, а читают/пишут в общее хранилище знаний; управляющий компонент решает, кто активируется дальше по содержимому доски. У Лучиана это буквально memory-bank — три банка (global / per-channel / per-generator), к которым обращаются разные сервисы конвейера. Это уже blackboard-архитектура на практике, просто её роль пока ограничена хранением профилей и логов, а не активным динамическим управлением «кто следующий».

5. Concurrent / Fan-out-Fan-in. Множество агентов обрабатывают один и тот же вход параллельно, дальше агрегатор сводит результаты. Именно этот паттерн лежит в основе консультант-фабрики MVP, о которой мечтает Лучиан.

Best-of-N + Judge Panel — паттерн для консультант-фабрики MVP

Это самый релевантный паттерн лично для второго приоритета Лучиана («веер MVP за ночь»). Архитектура из orchestration-patterns.md:

Задача
  ├→ Generator Agent #1 → Решение A
  ├→ Generator Agent #2 → Решение B
  └→ Generator Agent #N → Решение N
  → Judge Panel (Scorer + Critic + Commander)
  → выбрано лучшее (Pareto-optimal)

Ключевая методологическая деталь, которую легко упустить: судейство бывает pointwise (оценка одного решения по шкале), pairwise (сравнение двух, турнир на выбывание) и checklist (разложение критериев с весами). Исследование "When AIs Judge AIs" показывает, что PairJudge с knockout-турниром эффективнее для best-of-N, чем попарное сравнение всех со всеми — сложность O(N log N) вместо O(N²), и что гомогенные судьи снижают качество оценки — то есть нельзя просто запустить одну и ту же модель трижды в роли критика, разнообразие ролей критично.

Это прямая инструкция для его MVP-конвейера: если он хочет получить 3–10 параллельных решений для боли клиента, ему нужен не один судья-агент, а панель с разными «углами зрения» (например: судья по UX, судья по техническому риску, судья по скорости продажи), и сравнение лучше строить турниром на выбывание, а не полным перебором пар — иначе стоимость судейства растёт квадратично при росте N.

Материал mvp-factory.md уточняет конкретную реализацию этого паттерна в Claude Code Ultra: три explorer-агента в отдельных контекстных окнах, каждый оптимизирует свой trade-off (производительность, developer experience, скорость), плюс один critic-агент, который оценивает полноту, failure-модусы и синтезирует лучшее из всех трёх. Важная деталь про экономику: «параллельное выполнение занимает примерно столько же wall-clock времени, как один агент последовательно, но вы получаете три независимые перспективы» — то есть веер MVP не удлиняет ночь, он просто стоит дороже по токенам (там же указано: мультиверс-разработка стоит 2-3× дороже линейной, но даёт O(n×m) вместо O(n) охват вариантов). Это прямой ответ на страх Лучиана «монстр, кушающий $1000 в минуту»: веер дорог не по времени, а по деньгам, и это управляемая переменная — можно ограничить N и модель на explorer'ах (Sonnet вместо Opus).

Planner-Executor-Critic — почему критик не опция, а обязательный узел

Цифры из финансового исследования (522 сессии), которые процитированы в orchestration-patterns.md, стоит запомнить дословно: первый проход одного агента без критика — 24.9% безошибочных результатов; после внутреннего цикла с критиком — 87.8% отловленных ошибок; финальная точность системы — 92.1%, против 60% у чисто одноагентного подхода. Разница в 32 процентных пункта — это не мелкая оптимизация, это провал против успеха.

Для завода Лучиана это прямо переводится в его собственное правило №5 законов: «критика до и после» — план критикуется до кода, диф критикуется после. Он уже интуитивно открыл этот паттерн вручную (сам как критик). Задача эволюции системы — не изобретать критика заново, а вынести эту роль в отдельного агента с правом вето, а не полагаться на то, что один и тот же генератор сам себя перепроверит. В autonomous-coding.md это называется verifier pattern: «independent agent получает только артефакт и требования без контекста генератора. Это предотвращает систематические ошибки, которые generator и reviewer делают одинаково» — иначе говоря, если критик видит всю цепочку рассуждений генератора, он унаследует его слепые пятна. У его thumbnail-studio уже есть похожая проблема и решение — «эхо-камера обучения устранена, судья QC смягчён» (шов из 07-07) — это конкретный пример того, как критик, слишком близкий к генератору, начинает подтверждать его же ошибки (echo chamber). Правило: критик должен получать минимум контекста от генератора, максимум — от требований.

Токеномика оркестрации — цена мультиагентности

Anthropic даёт прямое сравнение потребления: обычный чат = 1×, агент с инструментами ≈ 4×, полноценная многоагентная система ≈ 15×. При этом «80% вариативности производительности объясняется использованием токенов; модель и число вызовов инструментов — остальные 20%» — то есть просто «больше агентов» не значит «умнее», часто это просто «дороже за то же самое». Для Лучиана с его травмой раздувания контекста до 1M токенов на 12-шаговой задаче это ключевой урок: оркестрация без управления контекстным окном — это не архитектура, а способ сжечь бюджет.

Практический рецепт из того же материала (совпадает с его собственными правилами): компактификация между агентами — передавать выжимку, не сырьё; суммаризация результата перед хендоффом; внешнее хранилище для долгих процессов вместо раздувания контекста; явный prioritization — агент должен знать, что критично, а что нет. Anthropic приводит пример из своей же исследовательской системы: LeadResearcher «активно фильтрует, какой контекст передаёт Critique Agent, чтобы окно не взорвалось» — то есть даже у Anthropic оркестратор не передаёт критику полную историю, а курирует её.

Из практики Claude Code: видео iJHJaTOwggs (Dynamic Workflows) показывает конкретную деталь архитектуры, важную для его будущего «строителя»: при обычных субагентах промежуточные результаты живут в контекстном окне Claude, и сессия блокируется, пока субагенты работают; в dynamic workflow (скрипт, который Claude сам пишет и который выполняется рантаймом в фоне) промежуточные результаты живут в переменных скрипта, а не в контексте модели, и сессия остаётся отзывчивой, пока в фоне крутятся до 1000 агентов (16 одновременно). Это ответ на вопрос «как строить систему, которая не взрывает контекст оркестратора при масштабе» — не пытаться удержать всё в разговоре с моделью, а кодифицировать оркестрацию как программу с явным состоянием. Именно так уже устроен channel-hq/orchestrator.mjs — это не «агент, который помнит», а код с состояниями (QUEUED → GENERATING → ... → DONE), и это правильно, а не временное решение, которое нужно заменить на «более умного агента».

Типичные ошибки — по антипаттернам и по кейсам провалов

Из orchestration-patterns.md, список антипаттернов, прямо касающихся Лучиана: - добавление агентов без явной специализации («на всякий случай ещё один агент»); - игнорирование управления контекстным окном; - использование детерминированных паттернов (жёсткий pipeline) для недетерминированных по сути задач (например, диагностика неизвестной проблемы у клиента — тут нужен handoff/blackboard, а не жёсткая последовательность); - отсутствие fallback при сбое агента; - избыточная сложность для простых задач — не каждой подзадаче нужен отдельный агент.

Из case-studies-failures.md — жёсткая математика вероятности: при точности 95% на каждом шаге 10-шаговая задача имеет только 60% шанс дойти до конца без ошибки (0.95^10). Отсюда Loop of Death — агент чинит ошибку, чинение создаёт новую ошибку, цикл повторяется, «сжигая самые дорогие токены». Решение практиков (получили 70% экономии и 99.9% надёжности): smart routing (маленькая модель классифицирует сложность задачи и направляет на дешёвую или дорогую модель), semantic caching (40% подзадач обслуживается из кэша без единого токена), sandboxed execution с лимитом попыток (максимум 3 попытки, потом эскалация, а не бесконечный цикл). Это прямая рекомендация для его ночного «строителя»: жёсткий лимит попыток на самоисправление и явный порог, после которого агент не пытается снова, а откладывает задачу и идёт дальше (его правило №5 — «не терять задачи», персистентная очередь — это ровно тот механизм, который спасает от Loop of Death: упавшая задача не удаляется и не зацикливается, а уходит в очередь на следующий цикл).

95% пилотов AI-агентов падают при масштабировании не из-за качества моделей — по данным Composio, а из-за интеграционных проблем: «Dumb RAG» (свалить все документы в вектор-базу и надеяться, что модель разберётся), брошенные (brittle) API-коннекторы, «polling tax» (агент дёргает API каждые 5 секунд, 95% запросов впустую). Для завода это подтверждает уже принятое архитектурное решение — webhook/event-driven вместо polling там, где возможно, и жёсткие контракты между сервисами (у него уже есть 08-contracts.md — швы имеют явный протокол, это правильно против brittle connectors).

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

Материалы про провалы в production (case-studies-failures.md) дают жёсткую статистику: 95% пилотов агентных систем падают при масштабировании, и это критически важно понимать до того, как Лучиан начнёт строить свою полную ночную автономию. Причина падений — почти никогда не «модель недостаточно умная», а архитектурные и интеграционные ошибки. Michael Hannecke называет 14 типовых паттернов отказа, из которых для Лучиана особенно важны четыре:

Отдельная линия критики современной индустрии (wqH1hTkA6qg, «Stop Building AI Agents») бьёт по соблазну плодить узкоспециализированных агентов «под каждый случай»: авторы указывают, что типичная ошибка компаний — «строить отдельного агента под каждый use case» (tax agent, legal agent, marketing agent), тогда как «агент под капотом на самом деле универсален» и разница должна быть не в модели-агенте, а в навыках/инструментах и контексте, которые ему выдаются. Это прямо перекликается с материалом CEvIs9y1uog («Don't Build Agents, Build Skills Instead») и с его же 5-м законом «повторил дважды → оформи скиллом»: правильная единица масштабирования для Лучиана — не «ещё один субагент», а переиспользуемый скилл, который любой из его агентов может подключить. Отдельная линия (uCKhOmth2ms, «The best AI agents are simpler than you think») подтверждает то же с другой стороны: эффективные production-агенты почти всегда проще, чем воображает новичок — меньше «умной» оркестрации, больше явного, детерминированного кода вокруг узкого решающего ядра.

Практическое правило для завода: не каждая новая задача требует нового агента-специалиста. Прежде чем добавлять субагента, спросить: (1) это механическая операция → скрипт; (2) это уже существующий скилл, применённый к новому контексту → не новый агент, а новый вызов существующего с другим промптом/инструментами; (3) это принципиально новый тип суждения (новая роль в консилиуме) → тогда агент.

Human-in-the-loop, который масштабируется, а не блокирует

Крайности из case-studies-failures.md — «либо каждое действие требует одобрения (узкое место — 10-20 задач/день), либо полная автономия (McDonald's AI, дававший сарказм жалующимся клиентам, — систему пришлось отключить)». Работающий средний путь — tiered autonomy, риск-таблица:

Уровень риска Автономия Требование
Read-only (чтение данных, анализ) 100% нет
Create/Update (генерация, публикация контента) высокая опциональная проверка
Delete / необратимое низкая человек обязателен
Payment / деньги 0% человек + явное подтверждение

Это буквально формализует уже принятую Лучианом красную линию («тратить деньги без подтверждения нельзя», при этом «публиковать, писать, менять — можно» ночью). Важно, что это не два состояния (доверяем/не доверяем), а спектр по типу действия — и его нынешние гейты EDIT_PENDING/APPROVAL_PENDING можно со временем не убирать полностью, а дифференцировать по каналу/риску: для устоявшегося канала с хорошей историей — автономная публикация; для нового эксперимента — сохранить approval-гейт, пока не накоплена статистика доверия. Это то, что материал называет «selective autonomy»: чекпоинт перед дорогостоящим/необратимым решением математически «перезагружает» вероятность накопленной ошибки (0.95^5 вместо 0.95^10 для всей цепочки).

Трёхэтапный workflow для строителя приложений

Отдельно стоит опыт Vincent Quigley (Sanity, case-studies-failures.md), напрямую применимый к первому приоритету Лучиана — «строителю приложений по одной команде»: «AI doesn't learn from mistakes. You fix the same misunderstandings repeatedly» — модель не накапливает опыт внутри одной генерации, поэтому нужен явный трёхэтапный процесс: первая попытка (по опыту автора ~95% брака — но она стоит того, потому что строит контекст и выявляет реальные требования), вторая попытка (уточнённые нюансы, ~50% брака), третья попытка — уже итерируемый рабочий результат. Практическая деталь: явные аннотации ошибок в промпте следующего прогона («вы допустили ошибку в файле X, строка Y: неправильно — …, правильно — …») работают лучше общих указаний «почини баги». Для ночного автономного строителя это означает: первый ночной прогон по новой задаче клиента не должен считаться финальным по умолчанию — архитектура должна закладывать минимум 2-3 цикла план→код→критика→фикс за ночь, а не один проход с последующей сдачей.

Фреймворки оркестрации: чем управлять «нервной системой» завода

Отдельный практический вопрос — на чём кодифицировать оркестрацию. Три модели координации из материалов задают разный контракт между агентами:

Вывод не «выбрать один фреймворк», а взять из каждого нужное: типизированное состояние и checkpointing (LangGraph) — потому что его конвейер уже граф с гейтами; жёсткие пределы на глубину/ширину дерева субагентов (OpenClaw) — потому что «запусти N» может незаметно превратиться в неконтролируемый веер; предупреждение про накладные расходы менеджера на простых задачах (CrewAI) — не оборачивать оркестратором то, что можно вызвать напрямую.

Наблюдаемость: без трассировки оркестрация — чёрный ящик

Отдельная категория ошибок из case-studies-failures.md, которая обычно всплывает уже после того, как первая версия системы «вроде работает»: production падает не потому, что демо было нечестным, а потому что демо тестирует только happy path — без таймаутов, без edge cases, без реального объёма данных, и, главное, без трассировки. Конкретный кейс: компания потеряла €50k, потому что агент молча вернул неверный результат — после того как добавили полную трассировку (какой инструмент выбран и почему, входные параметры, latency, вывод, обоснование решения на каждом шаге), проблему нашли за 30 минут вместо недель слепого дебага.

Для завода Лучиана это прямое дополнение к его 4-му закону «проверяй живое, не код»: помимо docker ps и просмотра UI глазами, оркестратору нужен структурированный лог каждого шага пайплайна (какой агент/сервис, какое решение, на основе чего, сколько стоило) — фактически расширение того, что уже частично делает _factory_patchlog.md и memory-bank/log.jsonl, но применительно к решениям агентов-критиков, а не только к деплоям людей. Без этого любой веер MVP или ночной автономный строитель — чёрный ящик: система выдаёт результат, но непонятно, почему critic отверг вариант B в пользу A, и это невозможно улучшать со временем (а самообучение — второй этап его дорожной карты).

«Missions» (Factory): архитектура многодневного автономного билда — ближайший прообраз ночного строителя Лучиана

Отдельно стоит разобрать доклад «The Multi-Agent Architecture That Actually Ships» (ow1we5PzK-o.txt) — Luke из Factory описывает систему Missions, которая уже в production запускает автономные разработческие сессии на 16 дней подряд (архитектурно рассчитана на 30). Это почти буквально то, что нужно Лучиану для первого приоритета — «строитель приложений по одной команде, ночью, без него», только растянутое на недели, а не на одну ночь. Стоит разобрать её устройство подробно, потому что доклад формулирует таксономию мультиагентных стратегий яснее большинства академических источников: пять примитивов коммуникации агентов — delegation (родитель поручает и получает ответ, самый частый паттерн — субагенты в кодинг-инструментах), creator-verifier (разделение ролей: у создателя есть «cost bias» — заинтересованность, чтобы его же код оказался рабочим, поэтому проверяющий должен быть отдельным агентом со свежим контекстом — «this is why we do code review as humans as well»), direct communication (агенты общаются напрямую, без координатора — хрупко, состояние расползается), negotiation (агенты делят общий ресурс — тот же API, тот же участок кода — потенциально не антагонистично, а win-win), broadcast (один агент рассылает статус/контекст/ограничения всем — незаметный, но критичный для когерентности долгих прогонов).

Missions комбинирует четыре из пяти (delegation, creator-verifier, broadcast, negotiation) в трёхролевую архитектуру: Orchestrator (планирует, задаёт уточняющие вопросы, производит план + «validation contract» — что значит «готово» ДО того, как написана хоть строка кода), Workers (реализуют фичу с чистым контекстом, без накопленного «мусора» разговора, коммитят в git и передают следующему воркеру чистое состояние), Validators (проверяют — причём два типа: scrutiny validator — тесты/линт/типы + code review субагенты на каждую фичу, и user testing validator — буквально запускает приложение и кликает по нему через computer use, как QA-инженер). Ключевая деталь: ни один валидатор не видел код при его написании — «validation is adversarial by design», что дословно повторяет verifier pattern из autonomous-coding.md.

Самое ценное практическое наблюдение — про параллелизм, который не работает: «если у вас 10 агентов работают одновременно, у вас 10-кратная пропускная способность» — но команда Factory это попробовала, и не сработало для софтверных задач: агенты конфликтуют, наступают на изменения друг друга, дублируют работу, принимают несовместимые архитектурные решения, и «overhead координации съедает выигрыш в скорости, при этом сжигая токены». Решение Missions — фичи выполняются серийно (один воркер/валидатор активен в любой момент времени), а параллелится только то, что безопасно параллелить в принципе — read-only операции (поиск по коду, исследование API, code review). Это прямое предостережение против интуиции «чем больше субагентов работает одновременно, тем быстрее» — для его будущего строителя приложений правильная модель, вероятно, «серийно по фиче/модулю, параллельно по независимым модулям и по read-only разведке», а не «просто больше параллельных копий».

Другой прямой урок — контекст не теряется благодаря структурированному хендоффу, а не благодаря памяти модели: воркер, закончив фичу, не просто говорит «готово» — он заполняет структурированную сводку (что сделано, что осталось, какие команды выполнялись и с каким кодом выхода, какие проблемы обнаружены, соблюдены ли процедуры оркестратора). Именно фиксация этого на бумаге, а не надежда, что агент «помнит», позволяет системе самоисправляться на границах milestone. Это прямая методологическая рекомендация для memory-bank Лучиана: не «журнал действий», а структурированный хендофф-контракт с обязательными полями.

Наконец — «droid whispering» (авторский термин Factory): нужно осознанно подбирать модель под роль (планирование выигрывает от медленного вдумчивого рассуждения — старшая модель; имплементация — от скорости и креативности — средняя модель; валидация — от точного следования инструкциям, причём иногда полезно валидировать другим провайдером модели, чтобы не унаследовать те же слепые пятна обучающих данных). Это прямое продолжение уже принятой Лучианом «лестницы моделей» (Fable-оркестратор / Opus-синтез / Sonnet-анализ / Haiku-механика) — с уточнением, что критик, возможно, стоит держать вообще на другом семействе модели, а не только на другом уровне той же линейки.

Практические выводы для Лучиана

  1. Не строить оркестратора заново — включить и доработать существующий. У него уже есть иерархический pipeline-оркестратор (channel-hq/orchestrator.mjs). Задача не «выбрать фреймворк», а (а) включить его, (б) заменить ручные гейты EDIT_PENDING/APPROVAL_PENDING на агента-критика с правом условного вето (кроме денег — это по-прежнему жёсткая граница), (в) запитать LEARNING-стадию, чтобы метрики реально возвращались в memory-bank (сейчас холостая).

  2. Для консультант-фабрики MVP — best-of-N + judge panel, турнир, а не полный перебор. N explorer-агентов (3–10, как он и хочет), каждый с явно разным приоритетом (скорость / надёжность / дешевизна), панель из 2-3 разнородных критиков (не клонов одной роли), knockout-турнир для сравнения, а не оценка каждого каждым.

  3. Критик должен получать минимум контекста от генератора. Иначе echo chamber — свежий урок из его же thumbnail-studio. Отдельная сессия/субагент для критика, видит только артефакт + критерии, не историю рассуждений.

  4. Оркестрация как код (dynamic workflow / скрипт), а не как «умный менеджер-агент», для больших ночных прогонов. Промежуточное состояние — в переменных/файлах/memory-bank, не в контексте модели. Это прямое продолжение его 5-го закона и требования к токеномике.

  5. Лестница моделей и жёсткие лимиты попыток на каждом узле оркестрации — не только на уровне отдельной задачи, но встроено в саму архитектуру: smart router перед дорогими агентами, sandbox с max 3 попытками перед эскалацией в очередь, а не в бесконечный цикл.

  6. Мультиагентность — не всегда нужна. Для механических, детерминированных операций (аудит, подсчёт, поиск) — скрипт/grep, не агент (его же 3-й закон подтверждён исследованиями: multi-agent = 15× дороже чата, и 80% этой цены — не качество, а объём). Оркестрация оправдана там, где нужна параллельная разведка неопределённости (ниши, MVP-варианты, диагностика непонятной проблемы) — а не там, где путь уже известен.

Стоит также вернуться к цифрам себестоимости, потому что для Лучиана деньги — главный угол всего проекта. Anthropic оценивает мультиагентную систему примерно в 15× дороже простого чата; отдельные замеры по коду (Hannecke) дают порядок $0.01-0.05 за одну задачу в зависимости от модели, и это до умножения на количество агентов в оркестрации. Если веер MVP — это 3-10 explorer-агентов плюс панель из 2-3 критиков, то одна ночь консультант-фабрики — это условно 10-15 полноценных агентных сессий на одну боль клиента, что при текущих ставках Sonnet/Opus легко выливается в единицы-десятки долларов за ночь на клиента — совершенно приемлемо относительно суммы сделки, но требует явного бюджетного потолка на прогон (его же правило: >250k cache-read или >$0.50 — стоп и пересборка), иначе один неудачно зациклившийся explorer может съесть бюджет всей ночи.

  1. Параллелить модули, не строки одного файла. Урок Missions (Factory) прямо предостерегает от «просто больше субагентов одновременно» на кодовой базе — конфликты и дублирование съедают выигрыш. Для строителя приложений: параллельный веер вариантов — да (разные MVP, разные каналы, разные ниши), но одна и та же кодовая база одним прогоном пишется серийно, с параллельной разведкой (поиск, research) внутри.

  2. Структурированный хендофф вместо надежды на память агента. Каждый субагент, закончив шаг, должен писать явную сводку (что сделано/не доделано, какие команды и с каким результатом, что обнаружено) в файл/memory-bank — а не полагаться на то, что следующий агент «поймёт по контексту». Это одновременно снижает токены (следующий агент читает сводку, а не всю историю) и защищает от Loop of Death и дрейфа между сессиями.

  3. Наблюдаемость закладывать сразу, не когда «вроде работает». Структурированный лог решений каждого критика/оркестратора (что выбрано, на основе чего, сколько стоило) — без этого невозможно ни отлаживать веер MVP, ни выполнить обещанное самообучение системы (нечем будет учиться, если решения не зафиксированы).

  4. Явно выбрать модель под роль, а не одну модель на всю оркестрацию. Планировщик — на медленном вдумчивом рассуждении (Opus/Fable), исполнитель — на скорости (Sonnet), критик — по возможности на другом семействе модели, чтобы не унаследовать те же слепые пятна, что и генератор; механика — на Haiku. Это расширение уже принятой им лестницы моделей, с добавлением идеи «разный провайдер для критика».

Итог: от чего к чему

Разрыв между заводом сегодня и целевой системой сводится не к «добавить больше агентов», а к трём конкретным сдвигам оркестрации: (1) включить и достроить уже существующий иерархический pipeline-оркестратор до цикла с настоящим агентом-критиком вместо ручных гейтов там, где это безопасно по деньгам; (2) добавить веерные (best-of-N + judge panel, concurrent fan-out) паттерны поверх этого pipeline — именно они, а не переписывание конвейера, дают консультант-фабрику MVP и ускорение контент-фабрики; (3) зафиксировать дисциплину, которую завод уже частично соблюдает интуитивно (5 законов Лучиана), как формальную архитектуру оркестрации — структурированные хендоффы, лимиты глубины/параллелизма дерева субагентов, разделение ролей planner/executor/critic по разным моделям, трассировка решений. Мультиагентность у Лучиана уже не гипотеза — она работает в его конвейере каждый день; следующий шаг — сделать её осознанной, ограниченной по бюджету и наблюдаемой, а не просто «включить оркестратор и надеяться».

Источники (материалы, использованные в анализе)