2026 年 5 月 28 日，Anthropic 发布 Claude Opus 4.8。模型升级当然重要，但这次更值得开发者关注的，是同一轮推出的 Claude Code Dynamic workflows。
它的核心能力很直接：Claude Code 可以把一个大任务拆成多个子任务，再调度数十到数百个并行 subagents 一起处理，最后对结果做复核、合并和汇总。
这不是"多开几个 AI 对话窗口"。更准确地说，它是在 Claude Code 里引入了一种新的工程编排方式：让 Claude 不只写代码，还能组织一组 AI agents 按阶段完成复杂任务。
如果说早期 AI 编程工具像一个聪明的助手，那么 Dynamic workflows 更像是一支临时组建的小工程队。
先说结论
Dynamic workflows 解决的不是"写一个函数"这种小问题，而是大型工程任务里的协调问题。
它特别适合这些场景：
- 代码库级别的 bug 搜索
- 大规模 API 迁移
- 安全审计
- 性能审计
- 复杂重构
- 多方案评审
- 多轮交叉验证
- 需要查阅大量资料的研究任务
它的价值不只是"并发更多 agents"，而是把复杂任务变成一个可执行、可观察、可复用的 workflow。
也就是说，Claude Code 不再只是"听你一步步指挥"，而是可以先制定计划，再按计划派工、收集结果、检查质量，最后给出相对完整的交付物。
什么是 Dynamic workflows？
一句话解释：
Dynamic workflows 是 Claude Code 中的一种动态工作流能力。Claude 会根据你的任务生成一个工作流脚本，由这个脚本调度多个 subagents 并行执行任务。
官方文档里有一个很关键的点：Dynamic workflow 本质上是一个 JavaScript 脚本。Claude 根据你的需求写出这个脚本，runtime 在后台执行它。
这件事很重要。
以前，Claude 在对话里一边思考、一边决定下一步做什么。上下文里会混入大量搜索结果、日志、文件内容和中间推理，任务越大，越容易混乱。
Dynamic workflows 把"下一步该做什么"这件事放进脚本里。脚本负责控制流程、循环、分支、中间变量和 agents 调度。Claude 的主上下文只需要接收最终结果或关键摘要。
这就是它能处理更大任务的根本原因。
什么是 subagent？
可以把 subagent 理解成一个"专项小助手"。
它不是主 Claude 的一个普通回答片段，而是一个独立工作的 AI agent。它有自己的上下文窗口、系统提示词、工具权限和权限策略。主 Claude 可以把某个明确任务分配给它，等它完成后，只拿回结果摘要。
用工程团队类比会更容易理解：
| 角色 | 类比 | 职责 |
|---|---|---|
| 主 Claude | 技术负责人 / 项目经理 | 理解目标、拆分任务、合并结果 |
| Workflow 脚本 | 项目计划 / 自动化流水线 | 控制阶段、并发、循环和验收 |
| Subagent | 专项工程师 | 处理某个模块、文件、风险点或验证方向 |
| Reviewer agent | Code reviewer / QA | 独立复核、找漏洞、反驳结论 |
所以，Dynamic workflows 的关键不是"Claude 多叫了几个帮手"，而是 Claude Code 开始具备一种工程组织能力。
它和普通 Claude Code 有什么区别？
普通 Claude Code 更像一对一结对编程。你提出需求，Claude 搜索代码、修改文件、运行命令、给你反馈。
这对于小任务很好用，比如：
- 改一个函数
- 修一个测试
- 解释一段错误日志
- 生成一个工具类
- 补几个边界条件
但大型任务会遇到瓶颈。
比如你让 Claude 审计整个代码库的鉴权问题。它可能需要阅读几十个目录、几百个文件、追踪多个调用链、理解路由注册、识别中间件、检查测试用例。单个 agent 顺序执行，会很慢，也容易遗漏。
Dynamic workflows 的思路是：
- 先把大任务拆开。
- 让多个 subagents 并行探索。
- 每个 agent 只关注自己的子问题。
- 中间结果不污染主对话。
- 最后用复核 agents 检查结论。
- 再汇总成最终报告或代码改动。
这和真实工程团队处理大任务的方式更接近。
它是怎么工作的？
一个典型流程大概是这样：
text
用户提出复杂任务
↓
Claude 分析目标和边界
↓
Claude 生成 workflow 脚本
↓
用户确认是否运行
↓
Runtime 在后台执行脚本
↓
多个 subagents 并行处理子任务
↓
Reviewer agents 交叉验证结果
↓
合并结论、过滤不可靠发现
↓
返回最终报告、修改或 PR 建议这个流程里有几个关键点。
第一，workflow 可以在后台运行。主会话不需要被长时间阻塞。
第二，中间状态可以留在脚本变量里，而不是全部塞进 Claude 的上下文。
第三，每个 subagent 可以独立探索。一个 agent 负责支付模块，一个 agent 负责订单模块，一个 agent 负责用户模块，另一个 agent 专门复核高风险结论。
第四，workflow 可以复用。一次效果好的运行脚本，可以保存成后续命令。
这也是它和普通"多 agent 聊天"的核心差异：它不是临时并发，而是可编排、可观察、可复用的并发。
为什么大型代码库需要这种能力？
真实工程项目的复杂度往往不在单个函数，而在跨模块关系。
一个安全问题可能涉及：
- 路由层有没有鉴权
- 中间件有没有正确挂载
- handler 有没有二次校验
- service 层有没有越权判断
- DAO 查询有没有 tenant 过滤
- 测试是否覆盖了异常路径
一个迁移任务可能涉及：
- 旧 API 有多少调用点
- 新 API 的参数语义是否一致
- 错误处理是否变化
- 日志字段是否需要调整
- 测试快照是否需要更新
- 回滚方案是否明确
这些任务不适合让一个 agent 从头线性做到尾。更合理的方式是分治。
Dynamic workflows 让 Claude Code 可以用"分治 + 并行 + 复核"的方式处理大型任务。这正是软件工程里非常经典的思路。
典型场景一：代码库级安全审计
假设你有一个后端项目，想检查所有 API 是否缺少鉴权。
普通 prompt 可能是：
text
帮我检查这个项目有没有鉴权问题。这个说法太宽泛。更适合 Dynamic workflows 的写法是：
text
Run a workflow to audit every API endpoint under src/routes for missing auth checks.
For each finding, include file path, route, evidence, risk level, and suggested fix.
Use independent reviewer agents to verify each high-risk finding.
Do not modify files.这个任务可以自然拆分：
- agent A 扫描路由注册方式
- agent B 分析用户模块接口
- agent C 分析订单模块接口
- agent D 分析支付模块接口
- reviewer agents 复核高风险结论
- 最终汇总成审计报告
它比单次扫描更稳，因为高风险结论会被独立复核。
典型场景二：大规模迁移
大规模迁移是 Dynamic workflows 非常适合的场景。
比如你想把项目里的旧日志库迁移到新的结构化日志库。
可以这样写：
text
Run a workflow to migrate all usages of oldLogger to the new structured logger.
Group files by package.
Preserve behavior.
Run existing tests after changes.
If tests fail, identify failing cases and attempt fixes.
Return a summary of changed call sites and unresolved risks.这类任务不是简单字符串替换。
真正的迁移需要理解：
- 旧日志参数的含义
- 新日志字段如何映射
- 是否有错误对象需要特殊处理
- 是否影响监控查询
- 是否会改变日志采集格式
- 测试是否需要更新
Dynamic workflows 可以先盘点调用点，再按目录或 package 分发修改，之后运行测试，最后把失败点交给修复 agents 继续处理。
这比"让 AI 一口气改完整个项目"可靠得多。
典型场景三：复杂重构
重构最怕两件事：一是改得太散，二是没有验收标准。
比如一个 user_service.go 已经膨胀到几千行，里面混了注册、登录、权限、风控、积分、通知等逻辑。
你可以让 Claude Code 用 workflow 先做分析，而不是直接改代码：
text
Run a workflow to analyze user_service.go and propose a refactoring plan.
Split responsibilities into smaller components.
Have independent agents review the plan from API compatibility, test impact, rollback risk, and maintainability.
Do not modify files yet.这类任务特别适合多视角评审。
一个 agent 从架构角度看，一个 agent 从测试影响看，一个 agent 从兼容性看，一个 agent 专门找回滚风险。最后再合成方案。
这更像真实项目里的技术设计评审，而不是简单让模型"给我一个重构方案"。
典型场景四：多轮验证
Dynamic workflows 的一个重要价值是"验证"，而不只是"执行"。
对于高风险任务，最怕的是 AI 很自信，但其实错了。
引入多个 agents 后，可以让一部分 agents 提出结论，另一部分 agents 专门反驳结论。比如：
- 第 1 组 agents 负责找问题
- 第 2 组 agents 负责验证证据
- 第 3 组 agents 负责尝试推翻结论
- 第 4 组 agents 负责给出修复建议
这个模式很适合：
- 安全审计
- 线上事故复盘
- 性能瓶颈定位
- 架构方案评审
- 重要 PR 的风险检查
它的目标不是让 AI "更会编"，而是让 AI 的结论更经得起检查。
一个官方提到的案例：Bun 迁移
官方博客提到一个很有冲击力的案例：Jarred Sumner 使用 Dynamic workflows 将 Bun 从 Zig 移植到 Rust。
根据官方描述，这次迁移生成了大约 75 万行 Rust 代码，已有测试套件通过率达到 99.8%，从首次提交到合并约 11 天。其中一个 workflow 负责为 Zig 代码库中的每个 struct 字段映射合适的 Rust lifetime，另一个 workflow 并行编写 .rs 文件，并让 reviewer agents 对每个文件做复核。
这个案例很容易让人误解成"AI 可以一键重写任何项目"。
我认为更准确的解读是：当任务边界足够清晰、测试体系足够扎实、目标足够可验证时，多 agent 编排可以显著压缩大型工程任务的周期。
这里真正关键的不是"生成了多少代码"，而是"有测试、有复核、有阶段性验证"。
没有这些基础设施，Dynamic workflows 只会更快地产生混乱。
和 subagents、skills、agent teams 有什么区别？
Claude Code 里已经有 subagents、skills、agent teams。Dynamic workflows 和它们的区别，核心在于：谁来持有计划。
| 能力 | 计划在哪里 | 适合什么任务 |
|---|---|---|
| Subagents | 主 Claude 在对话中临时派工 | 少量辅助任务、上下文隔离 |
| Skills | 预定义说明和资源 | 标准化、可复用的专项能力 |
| Agent teams | 多个会话或 agents 协作 | 更像多人协作项目 |
| Dynamic workflows | 可执行脚本 | 大规模并行、分阶段、可复核任务 |
Dynamic workflows 的关键是"计划进入代码"。
这意味着它不仅能并行，还能保存中间变量、控制循环、记录阶段结果、恢复部分运行，并把一次成功的流程沉淀成后续可复用的命令。
这也是为什么它更适合代码库级任务，而不是日常小改动。
怎么启动 Dynamic workflow？
截至发布时，Dynamic workflows 处于 research preview。官方文档说明它需要 Claude Code v2.1.154 或更新版本，可在 Claude Code CLI、Desktop、IDE 扩展、API 以及部分云平台环境中使用。不同计划的默认开关略有差异，团队和企业环境还会受管理员配置影响。
最简单的触发方式有三种。
方式一：在 prompt 里直接写 workflow
text
Run a workflow to audit every API endpoint under src/routes for missing auth checks.Claude Code 会识别 workflow 这个关键词，并为这个任务生成工作流脚本。
方式二：使用内置的 /deep-research
bash
/deep-research What changed in the Node.js permission model between v20 and v22?这是 Claude Code 内置的 workflow，用来围绕一个研究问题做多角度搜索、交叉检查和带引用的报告生成。
方式三：打开 ultracode
bash
/effort ultracodeultracode 可以理解为更激进的工程模式。它会把 effort 提高到更高水平，并让 Claude 自动判断哪些实质性任务应该使用 workflow。
这适合复杂任务，不适合日常小修小补。
使用时要特别注意什么？
Dynamic workflows 很强，但它不是免费的。
1. Token 成本会更高
因为一次 workflow 可能会启动很多 agents，每个 agent 都会消耗 token。任务越大、验证越多、并行越多，成本越高。
所以第一次使用时，建议从范围清晰的小任务开始。
不要一上来写：
text
帮我全面优化整个项目。更好的写法是：
text
Run a workflow to find unused exports under packages/api only.
Do not modify files.
Return file path, symbol name, evidence, and confidence level.先做只读扫描，再决定是否进入修改阶段。
2. 权限要收紧
Dynamic workflows 会调度多个 agents。虽然 workflow 脚本本身不直接访问文件系统和 shell，但 agents 可以读写文件、运行命令，具体取决于你的权限配置。
因此，高风险任务建议先限制为只读模式。比如：
text
Do not modify files.
Do not run destructive commands.
Only inspect code and produce a report.等报告可信后，再开启修改型 workflow。
3. 一定要有验收标准
AI 生成代码不等于任务完成。
对于修改型任务，prompt 里应该明确写出验收条件：
text
Run the existing test suite after changes.
If tests fail, list failing cases and try to fix them.
Do not mark the task complete until tests pass or unresolved failures are clearly documented.验收标准越清楚，workflow 越不容易跑偏。
4. 不要把它当成代码评审的替代品
Dynamic workflows 可以提高发现问题和验证结果的能力，但它不应该替代人类 code review、CI、静态扫描和安全审计流程。
更合理的做法是让它进入现有工程流程：
- 先由 workflow 发现问题
- 再由测试和扫描工具做自动验证
- 最后由人类 reviewer 判断是否合并
AI 可以承担大量机械探索和初步修复，但最终责任仍然在人。
我建议的落地方式
如果你所在团队想尝试 Dynamic workflows，可以按这个顺序来。
第一步：先做只读任务
优先选择不会改代码的任务，例如：
- 死代码扫描
- 安全风险盘点
- 依赖调用关系梳理
- 测试覆盖薄弱点分析
- 性能热点初查
这类任务失败成本低，适合建立信任。
第二步：把任务边界写清楚
一个好的 workflow prompt 至少包含五个要素：
| 要素 | 示例 |
|---|---|
| 目标 | 找出缺少鉴权的 API |
| 范围 | 只检查 src/routes 和 src/middleware |
| 权限 | 不修改文件，只生成报告 |
| 输出格式 | 文件路径、证据、风险等级、建议修复 |
| 验证方式 | 高风险问题必须由独立 agents 复核 |
边界越清楚，workflow 的输出越稳定。
第三步：引入测试闭环
只要 workflow 涉及修改代码，就必须让测试参与验收。
没有测试的项目，不建议直接使用 Dynamic workflows 做大规模改动。它可能真的能改很多文件，但你很难判断改得对不对。
第四步：沉淀可复用命令
如果某类 workflow 很有价值，可以保存成命令。
比如：
- 每次大 PR 前运行一次安全风险扫描
- 每次版本发布前运行一次 API 兼容性检查
- 每次框架升级前运行一次迁移影响分析
这会让 Dynamic workflows 从"偶尔惊艳的功能"变成团队工程流程的一部分。
给开发者的 prompt 模板
下面这些模板可以直接改成你的项目路径使用。
模板一：只读安全审计
text
Run a workflow to audit authentication and authorization risks in this repository.
Scope: src/routes, src/middleware, src/services.
Do not modify files.
For each finding, include:
- file path
- related route or function
- evidence from code
- risk level
- suggested fix
High-risk findings must be independently verified by reviewer agents.模板二：大规模 API 迁移
text
Run a workflow to migrate all usages of OLD_API to NEW_API.
Group work by package.
Preserve existing behavior.
Update tests when necessary.
Run the existing test suite after changes.
Return a summary of changed files, unresolved failures, and risky assumptions.模板三：复杂重构方案评审
text
Run a workflow to analyze the current user service implementation and propose a refactoring plan.
Do not modify files.
Have separate agents review the plan from these angles:
- API compatibility
- test impact
- rollback risk
- maintainability
- performance impact
Return a final plan with phased steps and risks.模板四：代码库级死代码扫描
text
Run a workflow to find likely dead code and unused exports in packages/api.
Do not modify files.
For each candidate, include the symbol name, file path, search evidence, confidence level, and safe removal suggestion.
Filter out findings that cannot survive cross-checking.模板五：技术调研
text
/deep-research Compare the migration risks from Node.js 20 to Node.js 22 for a backend service using Express, Prisma, and Redis.
Focus on breaking changes, dependency compatibility, runtime flags, and testing strategy.同一轮更新里还有两个值得关注的点
虽然这篇文章重点讲 Dynamic workflows，但 Anthropic 同一轮还发布了两个和 agent 工程化密切相关的能力。
Effort control
Effort control 允许用户控制 Claude 在任务中投入多少"思考强度"。更高 effort 通常意味着更深入的推理和更多 token 消耗；更低 effort 则更快、更省用量。
这对开发者很实用。不是所有任务都需要最高强度。解释一个错误日志和做一次大型迁移，显然不应该使用同样的计算预算。
Messages API 支持中途 system message
Messages API 现在支持在对话中途插入 system 消息。开发者可以在长任务运行过程中更新权限、预算或环境上下文，而不必把这些控制信息伪装成用户消息。
这对 agent 框架很关键。真实 agent 执行任务时，经常会进入不同阶段：只读分析、方案评审、允许修改、运行测试、收敛总结。不同阶段需要不同规则。中途 system message 让这些规则变化更加结构化。
我的判断：AI 编程进入"编排时代"
过去几年，AI 编程工具经历了几个阶段。
第一阶段是补全。AI 帮你补代码，像一个更聪明的 autocomplete。
第二阶段是对话。你把问题交给 AI，它解释代码、生成函数、修复错误。
第三阶段是执行。AI 可以读写文件、运行命令、修改项目。
Dynamic workflows 指向的是第四阶段：编排。
所谓编排，就是 AI 不只是执行一个动作，而是能把一个复杂目标拆成多个阶段，组织多个 agents 并行工作，再通过验证机制合并结果。
这会改变开发者和 AI 工具的协作方式。
未来，优秀开发者不只是会写 prompt，还要会定义任务边界、设计验收标准、拆分风险、配置权限、规划测试闭环。
换句话说，AI 编程时代的核心能力正在从"如何让模型写代码"转向"如何让模型可靠地完成工程任务"。
Dynamic workflows 不是终点，但它是一个明显信号：AI coding 正在从"助手模式"走向"工程组织模式"。
总结
Claude Code Dynamic workflows 的意义，不是让 Claude 多开几个 agent 干活，而是让 Claude Code 拥有了更强的任务编排能力。
它把大任务拆成小任务，把线性执行变成并行执行，把单次生成变成多轮复核，把临时对话变成可复用脚本。
这类能力最适合代码库级任务：迁移、安全审计、复杂重构、多轮验证和大型调研。
但它也对使用者提出了更高要求。你需要给出清晰目标、明确范围、限制权限、定义输出格式，并把测试作为验收底线。
如果用得好，它会成为工程团队的加速器。如果用得粗糙，它也可能只是更快地产生一堆难以验证的改动。
我的建议很简单：先从只读审计开始，用小范围任务建立信任；再逐步进入修改型 workflow；最后把稳定流程沉淀成团队命令。
AI 编程的下一步，不只是更强的模型，而是更可靠的工程编排。
参考资料
- Anthropic：Introducing Claude Opus 4.8
- Claude Blog：Introducing dynamic workflows in Claude Code
- Claude Code Docs：Orchestrate subagents at scale with dynamic workflows
- Claude Code Docs：Create custom subagents
- Claude Platform Release Notes
- Claude API Docs：Mid-conversation system messages
- Claude API Docs：Effort