Claude Code Dynamic Workflows — это не просто «запустить больше агентов». Это режим, в котором Claude Code пишет JavaScript workflow script, а фоновый runtime координирует несколько subagents. Используйте его только тогда, когда сам план оркестрации должен стать кодом, который можно прочитать, сохранить и улучшить. Если обычная сессия Claude Code, один subagent, skill, hook или routine уже владеют задачей, начинайте с меньшей поверхности.
На 3 июня 2026 года официальные документы Anthropic описывают Dynamic Workflows как research preview для Claude Code v2.1.154 или новее. Те же документы говорят, что workflow runs учитываются в plan usage и rate limits, а текущие пределы составляют до 16 concurrent agents и до 1,000 total agents per run. Поэтому первый вопрос не «будет ли быстрее», а «можно ли безопасно передать план скрипту».
| Задача | Dynamic Workflows подходят, когда... | Меньшая поверхность лучше, когда... | Первый безопасный шаг |
|---|---|---|---|
| Большой audit или migration | части можно выполнять независимо и сравнивать | один файл, пакет или reviewer закрывает результат | попросить один узкий slice и явный verification bar |
| Повторяемая research или validation петля | branching plan стоит сохранить как script | нужен только reusable method | оставить как skill, пока код оркестрации не нужен |
| Tool-heavy implementation | subagents нужны отдельные read/write/command contexts | достаточно deterministic lifecycle rule | выбрать hooks |
| Scheduled или unattended work | workflow только часть более широкого runtime | cadence, retries и external state являются реальным owner | оставить в routine или external job system |
| ultracode exploration | вы хотите, чтобы Claude оценил необходимость workflow | простая session уже решает задачу | начать с малого и смотреть /workflows |
Стоп-правило: не начинайте с whole-repo migration, широкого research sweep или workflow с большими правами. Попросите малый slice, разрешите только нужные tools, смотрите run в /workflows и принимайте решение stop, save или resume только по evidence.
Что меняется, когда план становится скриптом
Главное изменение — место, где живет план. В обычной беседе Claude Code держит план, tool results и исправления в одном контексте. В Dynamic Workflow Claude сначала пишет JavaScript orchestration script, затем runtime выполняет его в фоне. Script может запускать subagents, раздавать ветки, собирать intermediate results и возвращать один синтезированный ответ.
Это полезно для задач, где ценность возникает из независимых проверок. Security audit, multi-package migration, architecture review, claim verification и performance investigation часто выигрывают от нескольких чистых контекстов. Но количество агентов само по себе не является доказательством качества. Доказательство — это разделение работы, независимая проверка и понятный synthesis.
Цена такой структуры — меньше conversational control. Workflow не будет останавливаться после каждого шага, чтобы уточнить намерение пользователя. Permission prompts могут появляться, но обычного диалога внутри run нет. Subagents могут читать, писать и выполнять команды в рамках разрешенных tools. Поэтому первый workflow должен быть достаточно узким, чтобы вы могли понять, помогла ли оркестрация, прежде чем расширять scope.
| Компонент | За что отвечает | Что проверять |
|---|---|---|
| Claude Code session | request, approvals, final review | нужна ли оркестрация вообще |
| Workflow script | branching, subagent calls, synthesis path | план читаем, повторяем и сохраняем |
| Subagents | независимые slices работы | writes, commands, дублирование, missed checks |
| /workflows | run management и usage visibility | stop, save, resume, token pressure |
Если script делает только «попроси одного агента поправить один файл», это не workflow-задача. Если script фиксирует reusable harness для audit, migration или cross-checking, поверхность начинает окупаться.
Отличие от subagents, skills, hooks и routines
Dynamic Workflows не заменяют другие поверхности Claude Code. Выбор должен начинаться с owner модели. Кто владеет планом? Кто владеет runtime? Кто владеет методом? Кто владеет trigger?
| Поверхность | Лучший owner | Используйте, когда | Почему не workflow |
|---|---|---|---|
| Обычная сессия | живой conversation | один контекст может решить и проверить | сложность в описании не равна необходимости script |
| Subagent | один specialized worker | нужен отдельный reviewer или investigator | один worker дешевле и понятнее |
| Skill | reusable method | метод важнее branching runtime | нужно помнить процесс, не запускать harness |
| Hook | deterministic event rule | действие должно сработать до или после события | правило не нуждается в agent fan-out |
| Routine | unattended или scheduled runtime | время, retry или external trigger владеет задачей | workflow не является scheduler |
| Dynamic Workflow | JavaScript orchestration script | plan должен стать reviewable code | много агентов не гарантируют качество |
Эти выходы защищают от лишней сложности. Если вам нужен метод — пишите skill. Если нужен lifecycle guardrail — используйте hook. Если задача должна просыпаться завтра утром, ближе routines. Если вы выбираете между продуктами и агентами, это уже не вопрос Dynamic Workflows.
Где место ultracode, deep research и /workflows
Входов несколько. Самый прозрачный путь — прямо попросить Claude создать workflow и сначала показать план, slices, allowed tools и verification bar. /deep-research лучше подходит для research synthesis, когда нужно собрать независимые paths и сравнить выводы. /workflows — это поверхность наблюдения и управления run, а не магическая кнопка.
ultracode — session setting. Текущие model configuration docs отделяют его от обычного effort level: он использует очень высокий effort и позволяет Claude orchestrate Dynamic Workflows для substantive tasks. Это не saved workflow, не фиксированная цена и не указание включать workflow для каждой сложной фразы.
| Нужда | Начните с | Почему |
|---|---|---|
| Один явный orchestrated run | прямой request на workflow | решение видно и можно review |
| Research synthesis | /deep-research | соответствует форме исследования |
| Проверить, нужна ли оркестрация | ultracode | Claude может оценить сложность |
| Управлять run | /workflows | видно состояние и usage |
| Повторить доказанный harness | saved workflow file | план становится artifact |
Если поведение отличается на старой версии Claude Code, сначала обновитесь. Затем проверьте local /config и /workflows в той же environment, где будет запускаться task.
Первый безопасный workflow
Перед запуском проверьте три условия. Work можно разбить на независимые slices. Сравнение или verification этих slices реально повышает качество. Script оркестрации может быть полезен снова. Если хотя бы один пункт не выполняется, используйте обычную session, subagent или skill.
Хороший первый prompt узкий. Не «перепиши весь repo», а «возьми auth package и связанные tests; найди три migration risks; предложи patches; проверяй existing test command; не редактируй файлы вне package; спрашивай разрешение перед writes; перед масштабированием покажи usage и unresolved risks».
Такой prompt задает boundary, tools, verification и scaling condition. Цель первого run — не доказать, что Claude может запустить много агентов. Цель — понять, дает ли script-owned orchestration больше evidence, чем нормальная сессия.
Во время run держите /workflows открытым. Смотрите, тратятся ли tokens на независимую работу или на повторение. Смотрите, не просит ли workflow слишком широкие permissions. Смотрите, объясняет ли synthesis, что проверял каждый subagent. Если эти сигналы слабы, остановите run и сузьте задачу.
Cost, limits, permissions и disable controls
Dynamic Workflows не являются бесплатным параллелизмом. Текущие документы говорят, что workflow runs учитываются в plan usage и rate limits, а та же задача может потратить заметно больше tokens, чем single conversation. /workflows показывает usage для runs, а /usage помогает проверить более широкий профиль Claude Code.
На 3 июня 2026 года действующие пределы — до 16 concurrent agents и до 1,000 total agents per run. Эти числа достаточно велики, чтобы строить мощный harness, и достаточно велики, чтобы loose prompt быстро потратил budget.
Permission control начинается до запуска. Subagents могут читать, писать и выполнять commands согласно tools и approval path. Для первого use case ограничьте target path, allowed commands и review checkpoint. Для team rollout заранее решите, кто владеет stop control. Документы описывают /config, disableWorkflows, CLAUDE_CODE_DISABLE_WORKFLOWS=1, managed settings и admin settings как уровни контроля.
| Preflight | Зачем | Evidence |
|---|---|---|
| Какая версия | old behavior может отличаться | local version check |
| Feature включен | availability меняется | /config и official docs same day |
| Минимальный slice | предотвращает broad run | target path и verification bar |
| Какие tools разрешены | agents могут писать и запускать commands | approval mode и allowlist |
| Как смотреть usage | workflow тратит больше tokens | /workflows, /usage, rate-limit signals |
| Кто отключает | нужен kill switch | settings, env, managed или admin layer |
Если эти вопросы не закрыты, широкий workflow запускать рано.
Хорошие и плохие примеры
Хорошие кандидаты получают выгоду от нескольких чистых контекстов. Large migration подходит, если packages можно менять и проверять отдельно. Security audit подходит, если dependency risk, auth boundary, data exposure и tests нужно изучать независимыми ветками. Claim verification подходит, если docs, code и runtime evidence должны проверяться разными agents.
Плохие кандидаты обычно проще. Single-file refactor не становится workflow только потому, что важен. Deterministic pre-commit behavior должен быть hook. Reusable prompt method должен быть skill. Daily repo sweep ближе к routine. Simple debugging session остается conversation, пока не появились реальные branches.
Есть и team risk: workflow может скрывать неопределенность. Если команда не может назвать, что должен доказать каждый subagent, параллельность только усложнит audit. Сначала пишите verification bar, затем решайте, нужны ли agents.
Что сохранять после успешного run
Saved workflow должен быть похож на automation artifact, а не на transcript. Укажите owner, inputs, allowed tools, stop rule, verification и reuse rule.
| Что сохранить | Что должно быть ясно |
|---|---|
| Owner | repo area, team или release job |
| Intent | manual audit, migration slice, research harness |
| Inputs | paths, branch assumptions, test commands |
| Tool boundary | expected reads, writes, commands |
| Stop rule | когда остановиться, а не расширять |
| Verification | tests, comparisons, review evidence |
| Reuse rule | когда run стоит повторить |
Не сохраняйте workflow только потому, что run сработал. Сохраняйте, когда script легче читать, reuse и улучшать, чем обычный prompt.
Командный rollout без лишнего риска
Перед командным использованием решите не сколько agents можно запустить, а кто владеет boundary. У workflow должны быть owner, allowed tools, stop rule, verification evidence и rollback path. Без этого saved workflow становится личным экспериментом, который другой инженер не сможет безопасно повторить.
Записывайте evidence первого run: исходный prompt, target paths, approved tools, workflow slices, usage seen in /workflows, outputs from subagents, failed branches, test commands и unresolved risks. Если synthesis не показывает, что именно проверил каждый subagent, не расширяйте scope.
| Rollout item | Pass signal | If weak |
|---|---|---|
| Owner | repo area или team названы | keep local, do not share |
| Permission boundary | writes и commands ограничены | shrink scope |
| Usage evidence | /workflows и /usage reviewed | reduce fan-out |
| Verification | tests и comparison explicit | rewrite prompt |
| Disable path | /config, settings, env или admin owner known | do not standardize |
Не используйте Dynamic Workflows вместо review process. Это orchestration surface, not governance. Хороший rollout выбирает один repeatable job, например migration slice, claim verification или audit harness, доказывает value, затем сохраняет script вместе с explanation и reuse rule.
Для regulated или production-facing work добавьте negative boundaries заранее: не менять deploy config, не добавлять dependencies, не выходить за target package и не запускать destructive commands без human approval. Эти ограничения лучше включать в первый prompt, а не пытаться объяснять после broad run. Если workflow создал patch, review должен смотреть не только diff. Проверьте evidence from subagents, failed branches, duplicated exploration и tests. Если final synthesis не возвращает независимую проверку, задача была слишком широкой или verification bar недостаточно конкретен.
Часто задаваемые вопросы
Dynamic Workflows то же самое, что subagents?
Нет. Subagents — workers с отдельным контекстом. Dynamic Workflow — orchestration layer, который может координировать много workers через script.
Что делает ultracode?
ultracode — session setting. Он включает очень высокий effort и позволяет Claude использовать Dynamic Workflows для substantive tasks. Это не saved workflow и не универсальный режим для всего.
/deep-research является workflow?
Это documented entry point для research-heavy workflow behavior. Для coding migration или audit лучше явно описать scope, tools и verification.
Где лежат saved workflows?
Текущие docs указывают .claude/workflows/ и ~/.claude/workflows/. Относитесь к ним как к reviewable automation artifacts.
Можно resume позже?
Текущие docs связывают resume с той же Claude Code session. Если уйти во время run, следующая session стартует fresh. Проверьте /workflows перед уходом.
Сколько это стоит?
Безопасной фиксированной цены нет. Workflow учитывается в usage и rate limits и может тратить больше tokens. Начинайте с малого, смотрите /workflows и /usage.
Как отключить workflows?
Проверьте /config, disableWorkflows, CLAUDE_CODE_DISABLE_WORKFLOWS=1, managed settings и admin settings. В team rollout заранее назначьте owner этого control.
Они заменяют routines, hooks или skills?
Нет. Workflows владеют script-owned orchestration. Routines владеют unattended runtime. Hooks владеют deterministic event rules. Skills владеют reusable method.