Workflow Orchestration

Workflow Orchestration

Claude Code dynamic workflows - JS-скрипт, который оркестрирует недетерминированных субагентов. Скрипт = «рельсы» (loop, branching, промежуточные результаты в переменных); агенты = «поезда». Надёжность даёт код вокруг агентов, а не агенты сами. Доступность зависит от плана, текущей конфигурации и runtime: на Pro включи Dynamic workflows в /config; перед запуском проверь доступность в текущей сессии.

Этот skill - наш свод поверх официального API: что платформа уже даёт, и что мы добавляем сами для задач, где нужна доказуемая полнота batch-результата.

Текущая опора (проверено 2026-09-06): официальная документация, официальный разбор и официальный cookbook. Дата обновления docs/cookbook на странице не указана; blog датирован 2026-06-02.

Когда workflow, а когда нет

Бери workflow когда: задаче нужно больше агентов, чем удержит один контекст; нужна повторяемая оркестрация как читаемый скрипт; нужен repeatable quality-паттерн (агенты adversarially проверяют находки друг друга перед тем как их вернуть).

Практический тест: бери workflow, когда работа больше контекста одного агента или один и тот же шаг надо повторить по множеству независимых элементов, а orchestration полезно сохранить и повторить. Для 1--3 одноразовых делегаций бери subagent. Это не правило «все три условия», а выбор масштаба и повторяемости.

НЕ бери workflow когда: хватает 1-3 субагентов на ход (бери subagent); задача - следование инструкции (skill); нужен интерактивный sign-off в середине (кроме permission prompts, run не принимает mid-run input; каждый этап с sign-off = свой workflow).

Opt-in обязателен. Workflow tool вызывается, когда user прямо просит workflow своими словами, использует keyword ultracode, или в сессии включён Ultracode. После v2.1.160 literal workflow больше не является trigger keyword (до этой версии он был им); обычная явная просьба работает в обеих версиях. Иначе — обычные субагенты. Это и наше правило, и поведение платформы.

Анатомия (точный API)

export const meta = {                       // ПЕРВЫМ. Pure literal — без переменных,
  name: 'my-flow',                          // вызовов функций, спредов, интерполяции.
  description: 'one-liner для диалога approve',
  phases: [{ title: 'Scan', detail: '...' }, { title: 'Fix' }],  // = phase() вызовам
  whenToUse: '...',                         // опц., в списке /workflows
}
// тело — обычный async JS + примитивы:
phase('Scan')                               // группа прогресса; agent() ниже в неё
const r = await agent('prompt', {schema: S, label, phase, model, isolation, agentType})
const all = await parallel(items.map(x => () => agent(...)))   // БАРЬЕР, ждёт всех
const out = await pipeline(items, stageA, stageB)              // fan-out, БЕЗ барьера
const sub = await workflow('deep-research', {question})        // суб-воркфлоу, вложен. 1
log('сообщение пользователю')

• agent(prompt, opts?) → без schema возвращает финальный текст (string); со schema (JSON Schema) форсит StructuredOutput tool и возвращает валидированный объект (модель ретраит при mismatch); null, если агент остановлен в ходе run или случилась невосстановимая API-ошибка. opts: label, phase (явная группа - юзать внутри parallel/pipeline, не глобальный phase()), model (опускать - наследует модель сессии; ставить только когда уверен), isolation:'worktree' (дорого - только когда агенты параллельно мутируют файлы), agentType ('Explore', 'code-reviewer'...).
• parallel(thunks) - массив функций ()=>Promise, барьер. Результат агента может быть null. .filter(Boolean) допустим только для представления уже учтённых результатов; для явного batch сначала свяжи каждый null с исходным item и верни его как pending.
• pipeline(items, ...stages) - каждый item независимо через все стадии, БЕЗ барьера между ними (item 2 на стадии 3, item 4 ещё на стадии 1). Если стадия даёт null, следующие могут быть пропущены; после pipeline восстанавливай состояние по исходному item. Дефолт для многостадийной работы.
• budget {total: number|null, spent(), remaining()} - токен-таргет хода. total null если не задан. Хард-потолок: при достижении agent() бросает.
• args - значение, переданное в Workflow, дословно (для параметризованных команд).

Золотые правила (L1 корректности)

1. pipeline по умолчанию. parallel-барьер - ТОЛЬКО когда стадия N реально нужна ВСЕ результаты N-1 разом (dedup по всему множеству, early-exit по总count, «сравни с остальными находками»). «Надо сначала flatten/filter» - делай это ВНУТРИ стадии pipeline.
2. Никогда Date.now() / Math.random() / argless new Date() - бросают (ломают journaling/resume). Таймстемпы - через args; «случайность» - варьируй prompt/label по idx.
3. Скрипт НЕ имеет fs/shell. Читают/пишут/запускают команды только агенты (у них Bash, Read, Write). Скрипт лишь координирует и передаёт данные через переменные.
4. schema для всего, что обрабатываешь кодом. Текст парсить нельзя надёжно - schema даёт валидированный объект + авто-ретрай.
5. Явный batch не теряет identity. Не фильтруй null до ledger: finder:<input> / verify:<finding> / card:<finding> / sample:<input> / judge:<input> / card-audit остаётся pending. Card audit доказывает one-to-one set equality (count, distinct IDs, membership), не только count. COMPLETE только когда полный set доказан; иначе верни INCOMPLETE и named pending.
6. meta - pure literal. Любая вычисляемая часть = parse error.
7. Permission mode не фиксирован skill-ом. Subagents применяют permission rules сессии; agent permission prompts могут приостановить run. До long run подготовь нужный allowlist, но не заявляй acceptEdits или автоодобрение без проверки текущего режима.

Подтверждённые текущие limits

До 16 concurrent agents (меньше на CPU-limited host) · до 4,096 items в одном parallel() или pipeline() · 1,000 agents total на run. Не используй фиксированный minimum version как замену current availability: проверь план, /config, runtime и актуальную документацию. bundled /workflow-authoring для редактирования saved script требует v2.1.248+. Остальные числа из старого community research не используй как current contract: см. references/research-findings-2026-05-30.md только как исторические заметки.

Quality-паттерны (повышают доверие к результату)

• Adversarial verify - на каждую находку N независимых скептиков, промпт «опровергни, по умолчанию refuted=true». Убить если большинство опровергло. Ловит правдоподобно-неверное.
• Perspective-diverse verify - когда находка может сломаться по-разному, дай каждому верификатору свою линзу (correctness/security/perf/repro), не N одинаковых.
• Judge panel - N независимых попыток под разными углами → параллельные судьи оценивают → синтез из победителя + лучшие идеи из остальных. Бьёт «одна попытка, итерируем».
• Loop-until-dry - для discovery неизвестного размера: спавнить finders пока K раундов подряд не дадут ничего нового. Dedup против seen (всё виденное), НЕ против confirmed - иначе отклонённые находки возвращаются каждый раунд и не сходится.
• Multi-modal sweep - параллельные агенты, каждый ищет своим способом (по контейнеру / по контенту / по сущности / по времени). Каждый слеп к находкам других.
• Completeness critic - финальный агент «что упущено - не пройденная модальность, непроверенный claim, непрочитанный источник?». Найденное = следующий раунд.

Масштабируй под запрос: «найди баги» - пара finders, single-vote. «Тщательно проверь» - больше finders, 3-5-голосный adversarial, стадия синтеза.