Claude Code 动态工作流：从“单次对话”到“端到端自动化”的范式跃迁

背景

随着软件工程复杂度的指数级增长，传统的 AI 辅助编程模式正面临瓶颈。过去，开发者通常依赖单次对话或简单的代码补全来解决局部问题，但在面对遗留代码库重构、跨数百个文件的大型迁移，或是需要全链路压力测试的复杂架构时，单一 Agent（智能体）的“一次性”处理能力往往显得力不从心。

Anthropic 于 2026 年 5 月 28 日发布了 Claude Code 的最新功能——动态工作流（Dynamic Workflows）。这一更新旨在解决那些通常需要季度规划才能完成的宏大工程任务，将其压缩至数天内完成。通过引入动态编排脚本和并行子智能体机制，Claude Code 不再仅仅是一个代码助手，而是演变为一个能够自主规划、执行、验证并迭代复杂工程任务的自动化引擎。

核心内容

动态工作流是 Claude Code 的一项重大架构升级，它允许 Claude 在单个会话中编写编排脚本，并行运行数十甚至数百个子智能体（subagents），并在将结果呈现给用户之前进行自我检查。这一功能目前已在研究预览阶段开放，适用于 Claude Code CLI、桌面版、VS Code 扩展（Max、Team 和 Enterprise 计划，需管理员启用），以及 Claude API、Amazon Bedrock、Vertex AI 和 Microsoft Foundry。

1. 触发机制与使用方式

为了获得最佳体验，Anthropic 建议在动态工作流中使用“自动模式”（Auto Mode）。用户有两种主要方式启动工作流：

• 直接指令：直接要求 Claude 创建动态工作流（例如输入“Create a workflow”）。
• Ultracode 设置：开启一个名为 ultracode 的新设置。该设置通过“努力程度”菜单访问，将努力级别设置为“极高”（xhigh），并允许 Claude 自动判断何时使用工作流来处理任务。

2. 核心应用场景

内部早期用户和 Anthropic 团队已在多种场景下验证了动态工作流的有效性：

• 全库级问题排查与安全审计：Claude 可以并行搜索服务或仓库，对每个发现的问题运行独立的验证程序，从而确保报告中的问题均为真实存在。同样的逻辑也适用于加固流程，如全代码库的身份验证检查、输入验证和不安全模式扫描。
• 大规模迁移与现代重构：无论是框架替换、API 弃用处理，还是跨越数千个文件的语言端口迁移，动态工作流都能端到端地处理。
• 高风险任务的二次校验：当错误成本极高时，工作流允许 Claude 对问题进行独立的多重尝试，并引入对抗性智能体（adversarial agents）试图破坏结果，从而在用户看到最终方案前完成多轮压力测试。

3. 实战案例：Bun 引擎的重写

动态工作流的能力在 Bun 引擎从 Zig 语言重写为 Rust 语言的项目中得到了极致体现。开发者 Jarred Sumner 利用动态工作流完成了这一艰巨任务：

• 规模：涉及约 75 万行 Rust 代码，99.8% 的现有测试套件通过。
• 效率：从首次提交到合并仅耗时 11 天。
• 流程：
  1. 第一个工作流为 Zig 代码库中的每个结构体字段映射正确的 Rust 生命周期。
  2. 后续工作流并行编写 .rs 文件，作为 .zig 对应文件的精确行为移植，每个文件由两个审查者并行处理。
  3. 修复循环驱动构建和测试套件，直到两者均通过。
  4. 移植完成后，夜间工作流处理不必要的数据拷贝，并为每个优化打开 PR 进行最终审查。

4. 技术原理

动态工作流的工作机制类似于人类专家团队的协作：

• 动态规划与分发：当工作流启动时，Claude 根据提示词动态规划，将任务分解为子任务，并并行分发给子智能体。
• 独立验证与收敛：结果在合并前会被检查。智能体从独立角度解决问题，其他智能体则试图反驳这些发现。运行持续迭代，直到答案收敛。这种机制使得工作流能够达成单次传递无法实现的复杂结果。
• 持久化与恢复：工作流专为并行和长时间运行的工作设计（可长达数小时或数天）。进度会实时保存，中断的任务可以从断点恢复，而非从头开始。
• 会话外协调：由于协调过程发生在对话之外，无论任务规模多大，计划都能保持正轨。

5. 资源消耗与管理

值得注意的是，动态工作流的 Token 消耗远高于典型的 Claude Code 会话。Anthropic 建议用户从范围较小的任务开始，以评估使用量。首次触发工作流时，Claude Code 会显示即将运行的内容并请求确认。组织管理员也可以通过托管设置选择禁用工作流。

关键要点

• 范式转变：从“单次对话辅助”转向“端到端自动化”，将季度级规划任务压缩至数天完成。
• 并行架构：支持在单个会话中并行运行数十至数百个子智能体，通过编排脚本进行协调。
• 自我验证机制：引入独立验证和对抗性智能体，确保输出结果的准确性和鲁棒性，特别适用于高风险任务。
• 高资源消耗：Token 消耗显著增加，需用户确认启动，且建议从小范围任务开始测试。
• 广泛可用性：支持 CLI、桌面版、VS Code 扩展及主流云服务平台（Bedrock, Vertex AI, Foundry）。
• 断点续传：支持长时间运行任务的进度保存与中断恢复，确保工程连续性。
• 默认策略差异：Max/Team 计划及 API 用户默认开启；Enterprise 计划默认关闭，需管理员手动启用。

意义与影响

动态工作流的发布标志着 AI 编程助手从“工具”向“同事”甚至“团队”角色的关键跨越。

首先，它极大地降低了处理遗留系统和复杂架构的门槛。过去，大型迁移和安全审计往往需要耗费数周甚至数月的人工协调，现在通过并行化的智能体协作，可以在极短时间内完成初步重构和验证。这不仅提升了开发效率，更通过“独立验证”和“对抗性测试”机制，显著提高了代码质量和安全性。

其次，它重新定义了软件工程中的“规划”与“执行”边界。传统上，规划是人类的专属领域，而执行是机器或初级开发者的任务。动态工作流让 AI 具备了动态拆解复杂问题、分配资源、监控进度并自我纠错的能力。这种能力使得开发者可以从繁琐的工程协调中解放出来，专注于更高阶的架构设计和创新。

最后，这一功能对企业的研发流程管理提出了新要求。由于 Token 消耗巨大且涉及自动化执行，企业需要建立更精细的成本监控机制和权限管理体系（如管理员开关）。Anthropic 提供的研究预览和默认关闭策略，也反映了其在推动技术创新与保障企业稳定性之间的平衡考量。随着这一功能的成熟，未来我们可能会看到更多由 AI 自主驱动的大型软件工程项目的出现。