Claude Code Dynamic Workflows 深度解析：如何通过动态编排与多 Agent 验证突破传统 Workflow 和 Agent 框架限制

💡 核心摘要 (TL;DR)

Claude Code 推出的 Dynamic Workflows 通过动态生成 JavaScript 编排脚本，将任务规划与执行从上下文窗口中剥离出来，实现大规模 Agent 协作。

与 Subagent 和 Skill 不同，Dynamic Workflows 的计划和执行均由代码驱动，具备更强的可扩展性、可重复性和中断恢复能力。

其核心创新在于对抗性验证（Adversarial Validation）机制，通过多个独立 Agent 交叉审查结果，提高复杂任务的可靠性与准确性。

什么是 Claude Code Dynamic Workflows

Claude Code 最新推出的 Dynamic Workflows 是一种全新的 AI 编排机制。Claude 会根据用户任务动态生成一段 JavaScript Workflow 脚本，由运行时引擎在后台执行，并协调数十到数百个并行 Agent 完成复杂工作。

在实际案例中，Bun 团队利用该能力完成了 Zig 到 Rust 的大规模代码迁移项目，共涉及约 75 万行代码，并在 11 天内完成迁移，测试通过率达到 99.8%。

其设计思路既不同于传统 Agent 框架，也不同于经典 Workflow 引擎。

Subagent、Skill 与 Dynamic Workflows 的本质区别

Subagent 是 Claude 在对话过程中按需生成的工作者。每轮对话中，Claude 都会决定下一步如何分配任务，所有执行结果都会回流到上下文窗口，因此规模受到上下文长度限制。

Skill 本质是一组供 Claude 遵循的指令文件。虽然流程被写入文件，但实际执行主体仍然是 Claude，本质上仍依赖上下文完成任务。

Dynamic Workflows 则进一步将规划和执行从上下文中抽离出来。Claude 负责生成 Workflow 脚本，而运行时系统负责执行脚本，中间结果保存在变量中，不占用上下文窗口资源。

简而言之：

• Subagent：计划在 Claude 脑中。
• Skill：计划在文件中，但执行仍在 Claude 脑中。
• Dynamic Workflows：计划与执行都在代码中。

为什么 Dynamic Workflows 要把计划写成代码

将编排逻辑迁移到代码层面后，解决了传统上下文驱动模式中的多个关键问题。

1. 更大的任务规模

上下文窗口容量有限，大量 Subagent 的执行结果会迅速消耗上下文资源。

Dynamic Workflows 支持调度最多 1000 个 Agent，并允许最多 16 个 Agent 同时并发执行，中间状态无需进入 Claude 上下文。

2. 更强的可重复性

Subagent 的执行路径可能因 Claude 的实时决策而变化。

Workflow 则以确定性的代码形式存在，相同脚本重复运行时会遵循相同流程。成功验证后的 Workflow 还能够保存为命令并重复复用。

3. 可中断与恢复

传统对话式任务一旦中断往往需要重新开始。

Dynamic Workflows 会追踪每个 Agent 的运行状态。恢复执行时，已完成任务可直接使用缓存结果，仅继续执行未完成部分。

对抗性验证（Adversarial Validation）为何是核心设计

Dynamic Workflows 最重要的创新并不是简单地增加 Agent 数量，而是引入了对抗性验证机制。

在这一模式下，多个独立 Agent 会从不同角度解决同一个问题，并互相审查彼此的结论。

例如：

• 一个 Agent 负责审计与发现问题。
• 另一个 Agent 负责质疑和验证发现结果。
• 只有经过交叉验证的信息才会进入最终输出。

Claude Code 内置的 /deep-research 功能正是采用这一机制。多个 Agent 独立搜索信息，对结果进行投票与验证，未通过交叉审查的内容会被过滤。

在 Bun 的 Zig 转 Rust 项目中，数百个并行 Agent 负责生成行为一致的 Rust 代码。每段代码在合并前都会经历两轮独立审查，从而提高迁移质量。

Dynamic Workflows 的触发方式

方式一：Prompt 中使用 workflow

最直接的方法是在提示词中包含“workflow”关键词。

Claude Code 检测到该关键词后，会优先生成编排脚本，而不是采用普通对话模式逐步处理任务。

方式二：启用 /effort ultracode

在该模式下，Claude 会自动判断任务是否需要 Workflow。

一个复杂请求可能被拆解为多个连续执行的 Workflow，例如：

• 代码理解 Workflow
• 代码修改 Workflow
• 结果验证 Workflow

这种方式能够获得更强能力，但同时会显著增加 Token 消耗。

执行前，Claude 会展示任务阶段与预估消耗，并等待用户确认。

成功运行后的 Workflow 可以通过 /workflows 界面保存为自定义命令，后续直接调用。

适合使用 Dynamic Workflows 的场景

在代码分析场景中，Klarna 使用该能力发现了传统静态分析工具遗漏的死代码。

在代码迁移场景中，Bun 的 Zig 到 Rust 项目是目前公开案例中规模最大的应用之一。

在研究场景中，/deep-research 通过多个 Agent 的独立研究与验证生成最终报告。

不适合使用 Dynamic Workflows 的场景包括：

• 简单单文件修改。
• 普通问答任务。
• 无需并行执行的线性流程。

这些任务使用普通 Claude 对话或 Subagent 即可完成。

与传统 Workflow 和 Agent 框架相比有什么不同

传统 Workflow 引擎如 Airflow、Temporal 需要提前定义 DAG（有向无环图）流程，执行逻辑基本固定。

AutoGen、CrewAI 等 Agent 框架则允许多个 Agent 自由协作，灵活性更高，但执行路径难以预测，也较难保证结果复现。

Dynamic Workflows 处于两者之间：

• 编排逻辑动态生成，具备 Agent 的灵活性。
• 生成后以确定性代码执行，具备 Workflow 的可控性。
• 支持保存、复用与人工审查。

这种模式形成了一条区别于传统 Agent 与 Workflow 的新路径。

目前该功能已支持 Max、Team、Enterprise 计划，并可通过 API、Amazon Bedrock、Google Vertex AI 与 Microsoft Foundry 使用。

常见问题 (FAQ)

Dynamic Workflows 与 Subagent 最大的区别是什么？

Subagent 的计划与执行依赖 Claude 上下文，而 Dynamic Workflows 将计划生成后转化为 JavaScript 编排脚本，由运行时系统执行，中间结果不占用上下文窗口。

Dynamic Workflows 为什么能够支持更大规模任务？

因为任务状态与中间结果保存在 Workflow 脚本执行环境中，而非 Claude 上下文，因此能够调度最多 1000 个 Agent，并支持最多 16 个并发执行。

Dynamic Workflows 最重要的设计创新是什么？

对抗性验证机制是其核心创新。多个独立 Agent 对同一问题进行研究和交叉审查，只有通过验证的结论才会进入最终结果，从而提升可靠性。