Dynamic Workflow 是什么 в Claude Code: Token Accounting и Gateway Governance

Главное в dynamic workflows для Claude Code — не только масштаб, а то, куда переезжают оркестрация, видимость токенов и границы approval. Dynamic workflow — это JavaScript-скрипт, который пишет Claude и который runtime выполняет в фоне для координации множества subagent-ов. В /workflows оператор видит phases, число агентов, token totals, elapsed time, prompts, recent tool calls и результаты. Один пользовательский запрос становится измеримым workflow run, а не просто очередным ходом чата. Для команд, которые маршрутизируют трафик Claude Code через gateway или proxy, это новая операционная поверхность, требующая явной обработки.

Что произошло

Anthropic описывает dynamic workflows как режим оркестрации Claude Code для codebase audits, крупных миграций и cross-checked research. Функция требует Claude Code v2.1.154 или новее и доступна на платных планах — Pro, Max, Team, Enterprise — с Anthropic API access, а также на Amazon Bedrock, Google Cloud Vertex AI и Microsoft Foundry. Пользователям Pro нужно включить её в /config в строке Dynamic workflows.

Архитектура принципиально отличается от существующих примитивов subagent и skill. Dynamic workflow — это JavaScript-скрипт, который Claude пишет под описанную задачу; runtime выполняет его в фоне, пока сессия остаётся отзывчивой. Скрипт хранит цикл оркестрации, ветвление и промежуточные результаты в переменных — не в context window Claude. В context попадает только финальный синтезированный ответ. Проще говоря, если вопрос звучит «что такое dynamic workflow?», ответ такой: скрипт определяет workflow, а Claude Code предоставляет и координирует агентов, которые его выполняют.

Официальная документация даёт чёткую матрицу выбора:

Встроенная команда /deep-research — первый выпущенный workflow: она разворачивает веб-поиск по нескольким направлениям, перекрёстно проверяет источники, голосует по каждому утверждению и возвращает цитируемый отчёт с отфильтрованными непроверенными данными.

Почему это важно для AI-инженерных команд

Учёт токенов больше не ограничивается сессией. При работе с subagents и skills объём работы в Claude Code примерно связан с видимыми ходами. С dynamic workflows один пользовательский prompt может запустить скрипт, который за один run разворачивает десятки или сотни subagent-ов. /workflows показывает token usage по phase и agent, поэтому операторам нужно считать стоимость не только по user/session, но и по workflow run. Иначе легитимный /deep-research или migration workflow будет выглядеть как необъяснимый usage spike.

Rate limits и plan usage по-прежнему применяются. Документация Anthropic говорит, что workflow runs учитываются в usage и rate limits как любая другая session. Runtime ограничивает локальное выполнение — до 16 concurrent agents, меньше на машинах с ограниченным CPU, и до 1,000 agents total per run — но эти caps не заменяют тестирование headroom на shared keys.

Governance-поверхность расширилась. С subagents Claude решает пошагово, что запускать, и каждое решение видно в транскрипте разговора. С workflows логика оркестрации живёт в JavaScript-скрипте, который пишет Claude. Этот скрипт — план выполнения, и после approval он работает автономно. CLI approval flow может показать planned phases, raw script review и per-workflow consent; Desktop app даёт Once, Always и Deny. Операторам стоит считать workflow script проверяемым артефактом, а не невидимым состоянием чата.

Пользователи Bedrock, Vertex и Foundry получают новый routing-вопрос. Dynamic workflows доступны через эти provider paths, но каждый agent в workflow использует model текущей session, если script явно не направляет stage на другой model. Команды, которые закрепляют более дешёвые модели для routine work, должны проверить текущий model перед большим workflow и явно попросить Claude использовать меньшие модели для stages, где не нужен strongest model.

Router/operator-угол

Dynamic workflows вводят новый класс API-трафика, который выглядит иначе, чем интерактивное использование Claude Code:

• Burst-паттерн: workflow-запуск генерирует всплеск параллельных запросов, а не равномерный поток последовательных ходов. Если gateway применяет per-second rate limiting, burst от workflow может вызвать throttling, которого обычная сессия не вызывает.
• Распределение токенов: каждый subagent в workflow решает узкую подзадачу, поэтому отдельные запросы короче, чем полноконтекстная интерактивная сессия. Но суммарный token count за один workflow-запуск может быть существенно выше, чем за одну длинную сессию.
• Атрибуция запросов: в стандартной сессии Claude Code каждый API-вызов атрибутируется пользовательской сессии. В workflow-запуске сотни API-вызовов атрибутируются одному workflow run ID. Если billing или audit-система атрибутирует стоимость по API-вызовам, а не по workflow-запускам, вы увидите всплеск, похожий на аномалию.

Чеклист оператора для dynamic workflows:

1. Обновите модель бюджетирования токенов. Если вы устанавливаете per-user или per-team token budget на основе паттернов интерактивных сессий, добавьте отдельную категорию для workflow-запусков. Один запуск /deep-research может потребить больше токенов, чем весь день интерактивной работы.

2. Проверьте запас rate limit. Перед включением workflows для команды убедитесь, что лимит запросов в минуту вашего Anthropic API key достаточен для workflow-burst. Используйте документированные caps как planning bounds: до 16 concurrent agents и до 1,000 agents total per run — но не заменяйте ими реальный тест headroom.

3. Логируйте workflow run ID. Если gateway или proxy логирует отдельные API-вызовы, добавьте workflow run ID, phase name, agent index, token totals и elapsed time в схему логов, если эти поля доступны. Это позволит атрибутировать всплеск активности одному workflow-запуску, а не считать его аномальным трафиком.

4. Проверьте flow подтверждения скрипта. Dynamic workflows требуют подтверждения пользователя перед запуском. Для Enterprise-деплоев с managed settings убедитесь, что ваша политика managed settings разрешает или ограничивает выполнение workflows. Поле claude agents в settings.json теперь управляет поведением диспетчеризации агентов, что влияет на subagent-ы workflow.

5. Тестируйте на Bedrock/Vertex/Foundry перед широким включением. Функция доступна на всех трёх платформах, но поведение может отличаться в зависимости от того, как каждая платформа обрабатывает burst-трафик и rate limit.

Что стоит проверить пользователям TheRouter

Для команд, маршрутизирующих трафик Claude Code через TheRouter или любой OpenAI-compatible gateway, первоочередной вопрос — корректно ли gateway обрабатывает burst-паттерн workflow-запусков. Workflow, разворачивающий много agents, может создать короткий плотный burst model traffic — каждый request всё равно несёт свой authorization, model selection и request body.

Если routing-конфигурация применяет per-request трансформации (например, инжектирует system prompt или переписывает имя модели), убедитесь, что эти трансформации stateless и могут обрабатывать конкурентные запросы без состояния гонки. Stateful-трансформации, зависящие от контекста сессии, могут вести себя непредсказуемо, когда много agent-запросов из одного workflow-запуска приходят близко друг к другу.

Для команд, использующих ledger TheRouter для billing-сверки, следите за всплесками в метриках объёма запросов — они будут выглядеть как короткие пики, а не как плавный рост интерактивного использования. Если вы используете алерты по аномальному объёму запросов, скорректируйте пороги с учётом того, что один workflow-запуск может генерировать трафик, эквивалентный нескольким часам интерактивной работы.

Dynamic workflows находятся в research preview, поэтому API и модель billing могут измениться до general availability. Текущее поведение — каждый subagent как независимый API-вызов — правильное допущение для планирования, но по мере развития функции сверяйтесь с billing-документацией Anthropic.

Важно понимать, что dynamic workflows меняют не только технический профиль нагрузки, но и организационную модель ответственности. В традиционной сессии Claude Code один разработчик генерирует предсказуемый объём запросов. С workflows один запрос может инициировать работу, эквивалентную нескольким часам интерактивной сессии. Это требует пересмотра политик использования, лимитов на уровне команды и процедур согласования для крупных workflow-запусков — особенно в Enterprise-деплоях, где стоимость одного запуска может существенно варьироваться в зависимости от масштаба задачи.