Claude Code Dynamic Workflows：把长任务拆给一组 Agent

AI 编程工具过去一年一直在往两个方向演进：一边是更强的单次推理，另一边是更复杂的工程编排。Claude Code 的 dynamic workflows 属于后者。它不是单纯让一个 Agent 继续多想几步，而是让 Claude 为当前任务临时写出编排脚本，把任务拆成多个阶段，再调度一组并行子 Agent 分别执行、交叉验证和汇总。

这也是它最值得关注的地方：dynamic workflows 试图把“让 Agent 自己做完长任务”从一段长对话，推进到一种带阶段、带并行、带验证的运行方式。

Dynamic Workflows 是什么

Anthropic 在 2026 年 5 月 28 日发布 dynamic workflows，并把它描述为 Claude Code 中面向复杂端到端任务的研究预览能力。官方给出的典型场景包括跨代码库查 bug、性能分析、安全审计、大规模迁移、现代化改造，以及需要多轮独立检查的高风险工作。

它的核心机制可以拆成四步：

1. Claude 根据用户提示动态规划任务。
2. 它把任务拆成多个子任务，并生成对应的编排脚本。
3. 多个子 Agent 并行工作，从不同角度执行、审查或反驳结果。
4. 工作流持续迭代，直到结果收敛，再把一个协调后的答案交给用户。

官方博客里有一句关键描述：Claude 会在一个会话中运行数十到上百个并行子 Agent，并在结果交给用户前检查工作。这说明 dynamic workflows 的目标不是“更快打字”，而是把复杂任务变成一个临时的多 Agent 执行系统。

用一张图看，它更接近这样：

flowchart TD
    A[用户提出复杂任务] --> B[Claude 生成动态工作流]
    B --> C[拆解阶段和子任务]
    C --> D1[子 Agent: 搜索与分析]
    C --> D2[子 Agent: 实现或迁移]
    C --> D3[子 Agent: 审查与反驳]
    D1 --> E[汇总发现]
    D2 --> E
    D3 --> E
    E --> F[运行测试、构建、审计等验证]
    F --> G{结果是否收敛}
    G -- 否 --> C
    G -- 是 --> H[输出协调后的结果]

这和传统 Claude Code 会话的差别在于：普通对话主要依赖一个上下文窗口内的连续推理；dynamic workflows 则把“拆分、并行、审查、收敛”显式变成执行结构。官方还强调，这类工作流面向可以持续数小时甚至数天的并行长任务，并会保存进度；如果任务中断，可以从已保存的进度继续，而不是从头开始。对大型代码库来说，这个变化很重要，因为单个 Agent 长时间滚动上下文时，很容易出现注意力漂移、遗漏约束或审查不充分。

它适合解决什么问题

dynamic workflows 最适合的任务有一个共同点：任务可以被拆开，而且有明确的验证方式。

例如代码库范围内的安全审计。一个 Agent 可以负责搜索认证逻辑，一个 Agent 检查输入校验，一个 Agent 复核不安全模式，另一个 Agent 专门反驳前面几个 Agent 的结论。最后，工作流再把发现收敛成可操作的报告。

再比如大规模迁移。官方提到的 Bun 案例中，Jarred Sumner 使用 dynamic workflows 将 Bun 从 Zig 移植到 Rust：测试套件通过率达到 99.8%，生成约 75 万行 Rust 代码，从第一次提交到合并用了 11 天。官方还说明，其中一个工作流负责为 Zig 代码库中每个 struct 字段映射合适的 Rust lifetime，另一个工作流把每个 .zig 文件移植为行为一致的 .rs 文件，并让大量 Agent 并行工作，每个文件还有两个 reviewer。后续修复循环持续驱动构建和测试，直到两者都能干净运行。

这个案例很强，但也要看清它的前提：这类任务有大量相似工作单元，也有庞大的测试套件作为反馈。dynamic workflows 在这种场景里能发挥“批量执行 + 批量验证”的优势。

更日常一点的场景包括：

• 在大仓库里找死代码、重复逻辑和可清理区域。
• 对一次重构做多轮独立 code review。
• 把框架升级、API 废弃迁移、依赖替换拆成多个可验证阶段。
• 让 Agent 先写方案，再由独立 Agent 从安全、性能、兼容性角度挑战方案。
• 用 profiling、测试、lint、fuzzing 之类的确定性工具持续约束 Agent 输出。

如果任务本身无法拆分，或者没有清晰验收标准，dynamic workflows 反而可能只是把不确定性放大。

如何启用

截至官方发布时，dynamic workflows 处于 research preview。它可用于 Claude Code CLI、Desktop、VS Code 扩展中的 Max、Team 和 Enterprise 计划，其中 Enterprise 需要管理员启用；也可用于 Claude API、Amazon Bedrock、Vertex AI 和 Microsoft Foundry。

官方建议在使用 dynamic workflows 时打开 auto mode。启动方式有两种：

1. 直接让 Claude 创建 dynamic workflow，例如在 Claude Code 中要求它 “Create a workflow”。
2. 打开 Claude Code 专用的 ultracode 设置。它位于 effort menu，会把 effort level 设置为 xhigh，并让 Claude 自动判断什么时候需要使用 workflow。

默认开关也需要注意：Max、Team 计划以及通过 Claude Code API 使用时，dynamic workflows 默认开启；Enterprise 计划在发布时默认关闭，需要管理员在 Claude Code settings 中打开。第一次触发 workflow 时，Claude Code 会展示即将运行的内容并要求用户确认。组织管理员也可以通过 managed settings 禁用 workflows。

它不是免费的正确性

HN 上的讨论很快抓住了一个关键问题：开发者真正缺的未必是“让 Claude 更快跑完更多代码”，而是“如何确认它真的做对了”。

有评论认为，dynamic workflows 的理论价值在于让不同 Agent 从独立角度处理问题，再让其他 Agent 反驳和验证，直到结果收敛。这很像把很多开发者已经手动执行的流程自动化：先让 Agent 实现，再开新的会话做 review，再让 Agent 修，再 review。

但也有人指出，共识不等于事实。多个 Agent 都同意一个错误方案，仍然是错误。尤其在需求描述不准确、测试覆盖不足、评审标准不明确时，工作流只会更快地产生一个看起来完整但方向错误的结果。

所以，dynamic workflows 的正确使用方式不是“交给它就完了”，而是提供更硬的约束：

• 具体规格，而不是一句宽泛目标。
• 可重复运行的测试、lint、构建和性能基准。
• 明确的不可违反约束，例如兼容性、安全边界、迁移范围。
• 独立 review 阶段，但最终仍保留人工审查。

HN 上有一个很务实的观点：ground truth 不能是 AI 评出来的模糊共识，而应该是测试是否通过、lint 是否通过、性能是否改善、原始目标是否真的满足。这个判断很适合作为 dynamic workflows 的使用准则。

成本和可控性才是边界

官方明确提醒，dynamic workflows 会比典型 Claude Code 会话消耗明显更多 usage，并建议第一次使用时从范围较小的任务开始。HN 讨论里也有用户提到，一个相对小的 package code review 触发了大约 90 个 Agent，直接撞到了 Claude Max 使用上限。

这不是小问题。dynamic workflows 把一个任务扩展成多阶段、多 Agent、带复核的执行过程，Token 成本天然更高。它适合“错误成本很高，验证收益大于推理成本”的任务，不适合随手问答、轻量脚手架、几行代码修改。

另一个边界是交互性。有 HN 用户提问：workflow 到底是类似 prompt/skill，还是确定性的 workflow？讨论中有人回答说，它更接近后者，可以查看细粒度进度，但目前不能在运行过程中交互式介入。由于这不是官方博客里的正式说明，更稳妥的判断是：至少在早期用户讨论里，动态工作流的“中途人工校准”仍是一个被期待增强的能力。这会影响一些长任务的体验，因为真实工程任务经常需要在中途重新校准方向。

还有用户关心复用性、团队共享、DAG 建模、是否能暂停/恢复/重试、是否能混用本地模型或非 Anthropic 模型。这些问题说明 dynamic workflows 虽然已经把多 Agent 编排产品化了一步，但离“企业级可治理工作流系统”还有距离。

和 Hooks、Subagents、Agent Teams 的关系

从工程抽象看，Claude Code 里这些能力解决的是不同层的问题。

Subagents 更像一次性委派：你让某个子 Agent 带着特定上下文去完成一块工作。Hooks 更像生命周期扩展：在工具调用、提交前检查、权限控制、格式化或日志记录等节点插入确定性动作。Agent Teams 更偏固定团队结构。而 dynamic workflows 处在中间：它根据当前任务动态生成阶段和编排，让很多子 Agent 按任务需要临时组成一支队伍。

可以这样理解：

所以 dynamic workflows 并不是 Hooks 的替代品。相反，越复杂的 workflow，越需要 Hooks、测试脚本、静态分析和 CI 这类确定性机制来约束它。没有这些约束，多 Agent 只是更多不确定性的叠加。

我会怎么用它

如果要在真实项目里尝试 dynamic workflows，我会从三类任务开始。

第一类是只读分析任务，例如“找出大仓库里可能未使用的模块，并给出证据”。这类任务风险低，适合让多个 Agent 分头扫描，再用独立 Agent 复核误报。

第二类是有强测试保护的大规模机械迁移。例如 API 替换、类型迁移、框架升级准备工作。这里要把范围收窄到一组目录或一类调用点，让 workflow 每一步都有测试和 diff 审查。

第三类是多角度 review。比如让 workflow 针对一个 PR 分别从安全、性能、可维护性、兼容性角度审查，再合并出高置信度问题清单。这比让一个 Agent 一口气 review 全部内容更有可能发现遗漏。

我不会把它直接用于需求仍然模糊的新功能开发，也不会让它在没有测试保护的核心业务代码里长时间无人值守运行。dynamic workflows 提高的是执行吞吐，不自动提供产品判断、架构判断和最终责任。

小结

Claude Code dynamic workflows 是一个重要信号：AI 编程工具正在从“单个 Agent 聊天”走向“面向任务临时生成执行系统”。它把并行子 Agent、阶段化计划、独立审查和迭代收敛放进同一个工作流里，适合处理大仓库分析、批量迁移、复杂审计和高风险 review。

但它的边界同样清楚：Token 消耗更高，可控性还在演进，正确性仍然依赖清晰规格、确定性验证和人工复核。真正值得投入 dynamic workflows 的，不是所有任务，而是那些规模足够大、验证足够硬、错误成本足够高的任务。

换句话说，它不是让 Agent 脱离工程纪律，而是把工程纪律放大到一组 Agent 上运行。

参考资料

• Introducing dynamic workflows in Claude Code
• Dynamic Workflows in Claude Code | Hacker News