Dynamic Workflow 是什么？Claude Code Token Accounting 与 Gateway 治理

Claude Code 动态工作流最值得关注的地方不只是规模，而是编排逻辑、token 可见性和审批边界被移动到了哪里。如果你在问「dynamic workflow 是什么」，最短答案是：它是 Claude 编写、由 runtime 在后台执行的 JavaScript 编排脚本，用来协调大量子 agent。/workflows 视图会展示 phase、agent 数量、token 总量、耗时、prompt、最近工具调用和结果。这意味着一次用户请求不再只是一个聊天轮次，而是一个可度量的 workflow run。对于通过 gateway 或 proxy 路由 Claude Code 流量的团队来说，这是一个需要明确处理的新运营面。

发生了什么

Anthropic 将 dynamic workflows 定位为面向代码库审计、大规模迁移和交叉核验研究的 Claude Code 编排模式。该功能需要 Claude Code v2.1.154 或更高版本，适用于付费计划（Pro、Max、Team、Enterprise）、Anthropic API access，以及 Amazon Bedrock、Google Cloud Vertex AI 和 Microsoft Foundry。Pro 用户需在 /config 的 Dynamic workflows 行中手动开启。

动态工作流的架构与 Claude Code 现有的 subagent 和 skill 原语有本质区别。动态工作流是一段 JavaScript 脚本，由 Claude 根据你描述的任务编写，由 runtime 在后台执行，同时保持当前会话的响应性。脚本本身持有编排循环、分支逻辑和中间结果——而非存储在 Claude 的 context window 中。Claude 的 context 只接收最终的综合答案。换句话说，如果问题是「dynamic workflow 是什么」，答案是：由脚本决定工作流，由 Claude Code 提供并协调执行它的 agent。

官方文档给出了清晰的决策矩阵：

内置的 /deep-research 命令是第一个正式发布的工作流：它从多个角度并行展开网络搜索，交叉核验来源，对每条声明进行投票，并返回一份过滤掉未经核实内容的带引用报告。

为什么 AI 工程团队需要关注

Token accounting 不再只看会话。 使用 subagent 和 skill 时，一个 Claude Code 会话的工作量大致与可见轮次数相关。而使用动态工作流时，单个用户 prompt 可能触发一个脚本，在一次 run 中扇出数十到数百个子 agent。/workflows 视图按 phase 和 agent 展示 token usage，因此 operator 应同时按 workflow run、用户和会话追踪成本。否则，一次正常的 /deep-research 或迁移 workflow 可能看起来像无法解释的用量峰值。

Rate limit 和 plan usage 仍然生效。 Anthropic 文档说明，workflow run 会像其他 session 一样计入计划用量和 rate limit。Runtime 会限制本地执行规模——最多 16 个并发 agent，在 CPU 受限机器上更少；单次 run 最多 1,000 个 agent——但这些上限并不意味着可以跳过共享 key 的容量测试。

治理面扩大了。 使用 subagent 时，Claude 逐轮决定下一步启动什么，每个决策都可在对话记录中看到。使用 workflow 时，编排逻辑存在于 Claude 编写的 JavaScript 脚本中。这个脚本就是执行计划，一旦批准就会自主运行。CLI approval flow 可展示 planned phases、raw script review 和按 workflow 记住同意的选项；Desktop app 则提供 Once、Always、Deny。Operator 应把 workflow script 当成需要审查的制品，而不是不可见的聊天状态。

Bedrock、Vertex 和 Foundry 用户面临新的路由考量。 Dynamic workflows 可通过这些 provider path 使用，但 workflow 中每个 agent 默认使用当前 session 的模型，除非脚本把某个 stage 路由到其他模型。把低成本模型固定给日常工作的团队，应在大型 workflow 前确认当前 model，并明确要求 Claude 在不需要最强模型的 stage 使用更小模型。

Router/Operator 视角分析

动态工作流引入了一类与交互式 Claude Code 用量截然不同的 API 流量：

• 突发模式：工作流运行产生的是并行请求突发，而非顺序轮次的稳定流。如果你的 gateway 应用了每秒 rate limiting，工作流突发可能触发普通会话不会触发的限流。
• Token 分布：工作流中每个子 agent 处理一个窄范围的子任务，单个请求往往比完整上下文的交互会话短。但一次工作流运行的 token 总量可能远高于单个长会话。
• 请求归因：在标准 Claude Code 会话中，每个 API 调用可归因到一个用户会话。在工作流运行中，数百个 API 调用归因于单个工作流运行 ID。如果你的计费或审计系统按 API 调用而非按工作流运行归因成本，你会看到一个看起来像用量异常的峰值。

动态工作流 Operator 检查清单：

1. 更新 token 预算模型。 如果你基于交互会话模式设置了每用户或每团队的 token 预算，为工作流运行单独设置预算类别。单次 /deep-research 运行消耗的 token 可能超过一整天的交互会话。

2. 检查 rate limit 余量。 在为团队启用工作流之前，验证你的 Anthropic API key 的每分钟请求数限制是否有足够余量应对工作流突发。以 Anthropic 文档中的上限作为规划边界：最多 16 个并发 agent，单次 run 最多 1,000 个 agent；但不要用上限替代真实压测。

3. 记录工作流运行 ID。 如果你的 gateway 或 proxy 记录单个 API 调用，在日志 schema 中加入 workflow run ID、phase name、agent index、token totals 和 elapsed time（如可用）。这样可以将一批活动归因到单次 workflow run，而不是将其视为异常流量。

4. 审查脚本审批流程。 动态工作流在运行前需要用户批准。对于使用 managed settings 的 Enterprise 部署，验证你的 managed settings 策略是否允许或限制工作流执行。settings.json 中的 claude agents 字段现在控制 agent 调度行为，这会影响工作流子 agent。

5. 在 Bedrock/Vertex/Foundry 上广泛启用前先测试。 该功能在三个云平台上均可用，但行为可能因各平台处理突发流量和 rate limit 的方式不同而有所差异。

TheRouter 用户应关注什么

对于通过 TheRouter 或任何 OpenAI-compatible gateway 路由 Claude Code 流量的团队，当务之急是验证你的 gateway 是否能正确处理工作流运行产生的突发流量模式。一个扇出大量 agent 的 workflow 会形成短时间、高密度的模型流量——每个请求仍然带有独立的 authorization、model selection 和 request body。

如果你的路由配置应用了每请求转换（例如注入 system prompt 或重写 model 名称），请验证这些转换是无状态的，能够在无竞争的情况下处理并发请求。依赖会话上下文的有状态转换，当同一 workflow 的多个 agent 请求密集到达时可能表现异常。

对于使用 TheRouter 用量账本进行计费对账的团队，关注请求量指标中的工作流运行突发——它们会以短暂峰值的形式出现，而非交互式用量的平缓增长。

动态工作流目前处于 research preview 阶段，API 接口和计费模型在正式发布前可能发生变化。当前行为——每个子 agent 作为独立 API 调用——是规划的正确假设，但随着功能成熟，请以 Anthropic 的计费文档为准。