Orchestration patterns и соседние понятия

1. Паттерн оркестрации — это схема, не три агента

После разговоров про agent team легко зацепиться именно за оболочку: team lead, несколько subagent-ов, стрелочки, всё блестит. Но жить потом приходится не с оболочкой, а со схемой. Паттерн оркестрации — это схема разделения работы по ролям, артефактам и проверяемым границам: кто что делает, что отдаёт на выходе, как следующий понимает, что ему передали рабочий результат, а не фантазию.

Хороший паттерн живёт дольше конкретной версии Claude Code: сегодня роль исполняется через plan mode, завтра — через built-in subagent, послезавтра — через свежую сессию. Схема прежняя. Это и делает workflow устойчивым, а не привязанным к кнопке.

Удобно держать в голове такую карту:

planner / executor / verifier

PLAN.md

researcher / implementer / reviewer

CODEBASE_NOTE.md

architect / coder / tester

ARCHITECTURE_NOTE.md

hypothesis A / hypothesis B / neutral verifier

HYPOTHESES.md

Обратите внимание на одну тонкую, но важную вещь. Security reviewer, performance reviewer, test reviewer, architecture reviewer — это не новые паттерны, а разные фокусы роли reviewer. Один и тот же человек в разных очках, а не новый оркестр.

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

2. Базовая тройка planner / executor / verifier

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

Представим знакомый контекст Commerce OS. Есть issue: в очереди возвратов запросы на refund идут в неверном порядке. Проблема уже более-менее понятна: место боли найдено, область известна — задача не про исследование всего проекта, а про аккуратное изменение и верификацию.

Тогда planner делает не код, а план: его задача — зафиксировать цель, границы, риски и команды проверки. Например, так:

# PLAN.md
Цель: исправить сортировку refund-запросов в inbox.
Файлы: support/RefundInboxService.java, support/RefundInboxServiceTest.java
Риски: не менять API контроллера и SLA-логику.
Проверка: ./gradlew test --tests "*RefundInbox*"

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

Дальше приходит executor. Его работа — не думать обо всём мире, а реализовать согласованный шаг. В простом случае это основная сессия Claude, в формальном — subagent с узкими правами записи. На выходе — не «готово», а конкретный diff и список изменённых файлов.

После этого вступает verifier. И вот здесь многие ломают схему: им кажется, что это просто ещё один синоним слова review. Нет. Verifier превращает «я что-то изменил» в «это изменение либо прошло agreed checks, либо нет» — по плану, границам и проверкам, а не только по коду.

Схему удобно видеть как поток артефактов:

flowchart TD
    A["Planner
plan mode"] -->|PLAN.md| B["Executor
main session / subagent"]
    B -->|diff + changed files| C["Verifier
fresh session / reviewer"]
    C -->|VERIFY.md| D["Human decision"]

Если хотите, это почти конвейер. Не завод, конечно, а скорее маленькая мастерская. Но принцип тот же: следующий шаг начинается не после вдохновения, а после понятного артефакта.

Результат verifier-а тоже должен быть конкретным:

# VERIFY.md
Статус: REWORK
Причина: сортировка исправлена, но падает тест на archived refunds.
Команда: ./gradlew test --tests "*RefundInbox*"
Diff: только support/*

Видите, как резко падает градус магии? И это хорошо. Вместо «мне кажется, стало лучше» появляется инженерный язык: статус, причина, команда, область diff. Именно в этот момент картинка становится рабочим механизмом.

3. Researcher / implementer / reviewer

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

Допустим, в Commerce OS пришёл сигнал: странно ведут себя high-value refunds. Домен вы знаете, но не знаете точно, где смешались сортировка, SLA и ручное подтверждение. В такой задаче planner / executor / verifier запускать на полном ходу рановато — сам план строился бы на слишком слабом понимании системы. Здесь выгоднее сначала выделить researcher. Его выход — не diff, а короткая карта фактов.

# CODEBASE_NOTE.md
Маршрут: POST /api/orders/{id}/refund
Ключевой сервис: RefundApplicationService
Очередь inbox строит: RefundInboxQueryService
Риск: SLA-логика смешана с приоритетом очереди

Implementer в этой схеме уже работает намного спокойнее: у него входной артефакт с кодовыми опорами, а не только текст issue. Он может взять основную сессию Claude, plan mode перед редактированием или узкий subagent. Но поведение всё равно остаётся локальным: не переисследовать половину проекта, если researcher уже это сделал — и не менять симптомы, не поняв причину.

А вот reviewer здесь особенно полезен в виде fresh session. Почему не та же самая сессия? Потому что implementer уже заражён своим контекстом: гипотезы, тупики, старые версии решения, логика «ну я же тут чуть-чуть поправил, это нормально». У fresh reviewer этого багажа нет. И в этом вся его сила.

Просить reviewer-а можно коротко и строго:

Посмотрите только diff и CODEBASE_NOTE.md.
Проверьте, не вышли ли изменения за согласованную область.
Верните findings с привязкой к файлам и рискам.

Такой reviewer не должен превращаться во второго researcher — иначе вы просто удвоите стоимость этапа исследования. Его задача — свежо проверить изменение, а не перепрожить весь путь implementer-а.

Если сформулировать разницу между первым и вторым паттерном совсем коротко, получится так. Planner / executor / verifier нужен, когда задача уже в целом понятна. Researcher / implementer / reviewer — когда понятность ещё надо заработать.

4. Architect / coder / tester: про границы ответственности

Теперь возьмём другой тип работы. Не баг и не локальный fix, а структурную задачу: в Commerce OS вы хотите вынести экспорт заказов в отдельный модуль, чтобы контроллер перестал быть «швейцарским ножом на стероидах» и делегировал CSV-логику нормальному сервису. Здесь проблема уже не в одном if, а в том, где проходит граница ответственности.

Именно для таких задач хорошо работает architect / coder / tester. Здесь architect не обязан быть седым человеком из отдела «я запрещаю вам коммитить». Это роль, которая фиксирует: что разделяем, что остаётся нетронутым, какой контракт нельзя сломать.

Например, его артефакт может выглядеть так:

# ARCHITECTURE_NOTE.md
Новый модуль: orders/export
Граница: controller принимает запрос, CSV собирает ExportService
Не трогаем: payments/, support/, публичный URL /api/orders/export
Проверка: ручной экспорт и существующая команда сборки

Этот кусок может показаться скромным, но именно он защищает coder-а от очень распространённой болезни: «раз уж я здесь, давайте заодно улучшу соседний пакет». Нет, не давайте: в больших структурных задачах scope creep растёт со скоростью грибов после дождя.

Coder здесь уже работает в более жёстком коридоре: он не проектирует границы заново, а реализует зафиксированное решение. В этом паттерне особенно хорошо видно, что роль не равна уровню seniority: одни и те же вы, с тем же Claude, в одной задаче architect, в другой — coder.

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

Особенно полезен этот паттерн там, где задача звучит как «добавим новый модуль», «выделим adapter», «вынесем service», «разрежем ответственность». Если же вы лечите баг на шесть строк — звать architect-а не нужно: это уже не orchestration, а заседание комитета по перестановке стула.

5. Одна и та же роль не обязана быть агентом

Иерархию понятий мы уже разложили в лекции про agent teams: orchestration pattern — это сама схема ролей и артефактов, а конкретную роль исполняет main session, fresh session, subagent или человек. Отсюда вывод, важный именно здесь: симметрия «одна роль = один агент» почти никогда не обязательна.

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

Хорошее правило звучит так: реализация роли выбирается по риску и сложности, а не по любви к архитектурной красоте.

planner

researcher

executor

reviewer / verifier

tester

Это значит, например, что делать planner отдельным агентом просто «для единообразия» — плохая экономическая идея: вы платите coordination cost ради эстетики. А эстетика, конечно, прекрасна, но merge conflict ей не остановишь.

Здесь же полезно помнить про подход курса, устойчивый к смене версий. В вашей версии Claude Code какие-то поверхности называются иначе, часть возможностей agent team недоступна, интерфейс agent view отличается от скриншота соседа. Это нормально: важна не кнопка, а логика — роль → артефакт → проверка.

Полезный вопрос для самопроверки звучит так: «Если убрать слово agent, останется ли роль осмысленной?» Да — вы правильно проектируете workflow. Нет — вы, скорее всего, проектируете интерфейс, а не инженерный процесс.

6. Verifier держит всю схему на земле

Самая недооценённая часть сегодняшней темы — termination model, то есть условие остановки роли. Пока его нет, паттерн выглядит серьёзно, но работает как бесконечный мессенджер: один что-то сделал, другой прокомментировал, третий что-то почувствовал, а когда закончить — неизвестно. Особенно критично это для verifier.

Именно verifier чаще всего превращает расплывчатое «ну вроде готово» в машинно проверяемое условие. Эта идея уже знакома по long-running tasks: если условие завершения проверяемо машиной, Claude идёт к нему несколько ходов подряд без ручного babysitting. Здесь та же логика, только на уровне роли.

Сравните плохие и хорошие stop conditions:

То есть хороший verifier не говорит «я посмотрел» — он говорит: вот команда, вот область diff, вот вердикт. Например, так:

verifier_condition:
  tests: ./gradlew test --tests "*RefundInbox*"
  diff_scope: support/RefundInboxService.java, support/RefundInboxServiceTest.java
  api_contract: unchanged
  result: VERIFIED | REWORK

Видите, почему verifier — центр всей схемы? Потому что именно вокруг него формализуется finish line: executor меняет код, пока condition не выполнена, а как только выполнена — задача переходит в человеческое решение. Без описанной condition вы возвращаетесь в ручную диспетчеризацию: «ну что, теперь лучше?», «а теперь?», «а ещё раз посмотри». Утомляет человека, Claude и бюджет токенов. И выглядит, честно говоря, как ремонт крана методом разговоров.

Отдельно полезно помнить про situational pattern hypothesis A / hypothesis B / neutral verifier. Он особенно хорош там, где две гипотезы причины бага спорят между собой: один доказывает версию A, второй — версию B, а neutral verifier смотрит на воспроизводимые признаки и решает, какая гипотеза выдерживает проверку. Без neutral verifier это философский кружок по интересам.

7. Agent pipeline diagram — паттерн как артефакт

После verdict о самой параллельности нужен второй артефакт: схема ролей, handoff-ов и точек проверки. Пока паттерн живёт в вашей голове или в договорённости «ну ты сначала исследуй, потом я поправлю», он хрупок: один понял так, другой иначе, третий решил, что reviewer и verifier — разные вселенные. Поэтому его фиксируют как agent pipeline diagram: он переводит схему из разговоров в поддерживаемый артефакт Workflow Kit.

Хороший pipeline diagram не обязан быть шедевром дизайнерской мысли. Он отвечает на три вопроса: какая роль идёт первой, какой артефакт отдаёт и кто на него опирается дальше. Например, в Workflow Kit это может жить так:

# docs/pipelines/refund-inbox.md
Pattern: planner / executor / verifier
Planner: main session / plan mode -> PLAN.md
Executor: subagent refund-fixer -> diff + changed files
Verifier: fresh reviewer -> VERIFY.md
Human: решение о merge

Если нужно, диаграмма может быть и визуальной:

flowchart TD
    A["Planner"] -->|PLAN.md| B["Executor"]
    B -->|diff + tests| C["Verifier"]
    C -->|VERIFY.md| D["Human decision"]

Смысл здесь не в красоте стрелочек, а в том, что workflow становится командным артефактом, а не личной привычкой одного разработчика. Более того, такую диаграмму удобно класть рядом с AGENT_HANDOFF_CONTRACT.md, чтобы каждый переход между ролями был подкреплён формальным handoff: вход, выход, проверка.

В этот момент оркестрация перестаёт быть «набором умных чатов» и становится частью инженерной системы. И проверяется это просто: возьмите любой паттерн из сегодняшней таблицы и мысленно вычеркните слово «агент». Остались роль, артефакт и проверка — planner отдаёт PLAN.md, verifier возвращает вердикт по diff — значит, схема переживёт и смену версии Claude Code, и переезд роли из plan mode в subagent. Стрелочки на диаграмме вторичны. Первично то, что каждый переход подкреплён понятным входом, выходом и способом проверить, что дальше передали рабочий результат, а не надежду.

1

Задача

Claude code, 15 уровень, 3 лекция

Недоступна

Терминальный выбор orchestration pattern

Терминальный выбор orchestration pattern

Открыть

1

Задача

Claude code, 15 уровень, 3 лекция

Недоступна

Создание agent pipeline diagram

Создание agent pipeline diagram

Открыть