Claude Code Dynamic Workflows 教程：会自己写“工作流脚本”的 Agent，到底怎么用？

Claude Code 最近加了一个很猛的新能力：Dynamic Workflows。

一句话说清楚：

它不再只是“跟你聊天、按步骤执行”，而是会现场写一段工作流脚本，拉起一堆 subagent 并行干活，再让它们互相检查、反驳、修正，直到答案更稳为止。

听着很爽，对吧？

但别急着狂喜。这个功能有两个关键词必须记住：

• Research Preview：还在预览阶段，不是稳定生产形态。
• 极其烧 token：真的烧。不是一点点，是那种你看账单会沉默的烧。🔥

这篇咱们不吹概念，直接讲清楚：它是什么、适合干什么、怎么用、哪里容易翻车。

Dynamic Workflows 到底变了什么？

过去你让 Claude Code 做复杂任务，大概是这样：

你说需求。
Claude 做计划。
Claude 一步步执行。
中间遇到问题再调整。

这套方式能用，但有个问题：计划主要停留在对话里。

Dynamic Workflows 的变化在于：

它把“计划”搬进了代码。

Claude 会根据任务现场生成一段编排逻辑。这个逻辑可以调度多个 subagent，让它们同时处理不同分支。

比如你让它分析一个大型项目的架构问题，它可能会这样分工：

• 一个 subagent 看后端 API
• 一个 subagent 看数据库模型
• 一个 subagent 查前端调用链
• 一个 subagent 专门挑 bug
• 一个 subagent 负责反驳前面几个结论
• 一个 subagent 汇总并验证最终建议

这就不是“一个 AI 慢慢想”。

更像你临时拉了一个小组开会：有人查资料，有人写方案，有人唱反调，有人做验收。

爽点在这里。

它强在哪里？不是模型变聪明，而是调度变猛

很多人会误解 Dynamic Workflows。

它不是让 Claude 突然获得神力。

真正增强的是：任务拆解和并行调度能力。

普通 Agent 容易卡在一个思路里。一路想下去，错了也不一定知道。

Dynamic Workflows 会更像团队协作：

• 把复杂任务拆成多个子任务
• 让不同 subagent 同时跑
• 让它们互相验证
• 让不同观点碰撞
• 把结果收敛成一个更可靠的答案

举个场景。

你不是问：

“帮我写个按钮组件。”

你问的是：

“帮我审查这个 20 万行代码仓库，找出影响构建速度的主要原因，给出可落地的优化方案，并标出风险。”

这类任务，一个 Agent 慢慢翻，容易漏。

Dynamic Workflows 就有价值了。它可以并行查构建配置、依赖树、缓存策略、CI 日志、测试耗时，再把线索合起来。

这才是它该上场的地方。

适合用在哪些任务？

别把它当万能按钮。

它适合那些“一个人查很慢、多个角度看更稳”的任务。

1. 大型代码仓库分析

适合场景：

• 查架构债务
• 找性能瓶颈
• 分析模块依赖
• 审查重构影响面
• 排查复杂 bug

示例提示词：

请使用 Dynamic Workflows 分析这个仓库的构建耗时问题。
请拆分为依赖分析、构建配置、测试耗时、缓存策略、CI 流程几个方向并行检查。
每个方向都要给出证据文件和具体修改建议。
最终输出优先级列表，标注风险和预期收益。

这个提示词的重点不是“帮我优化”。

重点是你明确告诉它：拆哪几个方向、要什么证据、最后怎么交付。

别让它自由发挥太多。不然 token 会像开闸放水。

2. 技术方案对比

比如你要选：

• Next.js 还是 Remix
• PostgreSQL 还是 MySQL
• LangChain 还是直接调用模型 API
• 单体应用还是微服务

Dynamic Workflows 可以让不同 subagent 分别站队，再互相质疑。

示例提示词：

请用 Dynamic Workflows 对比 Next.js 和 Remix 是否适合我们的新项目。
项目背景：B2B SaaS，后台管理为主，需要 SSR、权限系统、表格密集页面、长期维护。
请安排不同 subagent 分别从开发效率、性能、生态、团队学习成本、部署复杂度、长期维护风险进行分析。
要求输出推荐结论，不要中立废话。

注意最后一句：不要中立废话。

AI 很爱端水。你不压它，它能写出一篇“取决于你的需求”。

谁不知道取决于需求啊！咱们要的是判断。

3. 深度调研和资料交叉验证

比如你要研究一个新框架、新 API、新模型能力。

单 Agent 容易只抓到一个角度。

Dynamic Workflows 可以做成这样：

• 一个 subagent 查官方文档
• 一个 subagent 查 GitHub issue
• 一个 subagent 查社区反馈
• 一个 subagent 专门找负面案例
• 一个 subagent 汇总可落地建议

示例提示词：

请使用 Dynamic Workflows 调研 Claude Code Dynamic Workflows 的使用方式、限制和适用场景。
请分别从官方说明、开发者反馈、实际成本、失败案例、最佳实践几个角度并行研究。
输出一份适合团队内部分享的中文教程，必须包含使用建议和避坑清单。

这种任务很适合它。

因为信息源多，观点容易冲突，需要验证。

不适合用在哪些任务？

有些任务用 Dynamic Workflows，纯属拿高射炮打蚊子。

小任务别用

比如：

• 改一个变量名
• 写一个正则
• 解释一段短代码
• 生成一个简单函数
• 问一个明确概念

这些任务开 Dynamic Workflows，结果可能没变好，token 倒是烧起来了。

你本来 500 token 能解决，结果它拉一堆 subagent 开会，最后告诉你：变量名建议叫 userId。

这谁顶得住。

怎么写提示词更省 token？

Dynamic Workflows 的核心成本来自“并行”和“反复验证”。

你不给边界，它就可能越查越多。

想控制成本，提示词要写得硬一点。

给它明确范围

别说：

帮我分析这个项目。

改成：

只分析构建速度相关问题，范围限制在 package 配置、构建脚本、CI 配置和测试耗时。
不要分析 UI、业务逻辑和数据库。

范围越清楚，越不容易烧穿。

限制 subagent 数量

可以直接写：

最多使用 5 个 subagent。
每个 subagent 只负责一个方向。
如果信息不足，先列出缺口，不要继续扩展搜索范围。

这句话很有用。

它能把“无限探索”拉回“有限交付”。

要求输出证据

别只要结论。

加一句：

所有建议都必须附带证据来源，比如文件路径、配置项、日志片段或文档依据。
没有证据的推测单独放到“待验证”区域。

这样能减少幻觉，也方便你快速判断哪些建议能直接动手。

让它先报价

不是让它真算钱，而是让它估任务规模。

开始前请先评估任务复杂度、预计需要的分析轮次、可能消耗较多 token 的环节。
等我确认后再执行完整 Dynamic Workflows。

这个技巧很实用。

尤其你在公司项目里跑，别一上来就让它全仓库深挖。

推荐工作流：别一口气跑到底

我更建议大家这样用：

第一步：让它拆任务，不执行

请为这个任务设计 Dynamic Workflows 拆解方案。
只输出 subagent 分工、检查范围、预期产物和风险点。
暂时不要执行。

你先看方案。

不合理就改。

这一步能省很多钱。

第二步：缩小范围后再跑

比如它给了 10 个方向，你砍到 4 个。

只执行以下 4 个方向：构建配置、依赖体积、测试耗时、CI 缓存。
不要分析其他方向。

你是老板，它是执行者。

别反过来。

第三步：要求收敛成行动清单

跑完后，不要让它只写分析报告。

直接要行动：

请把结果整理成可执行清单。
每一项包含：问题、证据、修改建议、风险、预计收益、优先级。

你拿到的就不是一篇作文，而是一张可以开工的任务表。

避坑清单

用 Dynamic Workflows 前，建议把这几条贴脑门上。

• 别给开放题：比如“全面分析一下”，很容易无限扩散。
• 别默认它省钱：并行 subagent 越多，token 越猛。
• 别迷信反驳机制：互相反驳能降低错误率，不等于没有错误。
• 别跳过证据要求：没有文件、日志、文档依据的建议，只能当参考。
• 别把小任务丢进去：简单问题用普通对话更快更便宜。
• 别在生产仓库乱改：让它先出计划和 diff，再决定是否应用。
• 别一次跑全量：先抽样、再扩大，成本更可控。

一个可直接复制的模板

下面这个模板适合代码分析、架构审查、技术调研。

请使用 Dynamic Workflows 处理以下任务：

任务目标：
[写清楚你要解决的问题]

限制范围：
[写清楚只看哪些文件、模块、日志或文档]

Subagent 分工：
最多使用 [数字] 个 subagent。
每个 subagent 只负责一个方向。
需要包含一个负责反驳和验证结论的 subagent。

输出要求：
1. 每个结论必须有证据来源。
2. 没有证据的内容放到“待验证”。
3. 最终输出可执行清单。
4. 每项包含问题、证据、建议、风险、优先级。

执行策略：
开始前先给出工作流设计方案。
等我确认后再执行完整分析。

把这段存起来。

以后别再用“帮我看看这个项目”这种模糊提示词了。那不是在用 AI，是在给账单点火。

什么时候值得用？

判断很简单。

如果这个任务满足下面任意两条，就值得考虑 Dynamic Workflows：

• 需要查很多文件
• 需要多个角度交叉验证
• 单次错误成本很高
• 需要比较多个方案
• 需要输出能直接执行的计划
• 人工处理要花半天以上

比如：

• 发布前做一次架构风险审查
• 接手老项目时摸清技术债
• 大版本升级前评估影响面
• 排查 CI 为什么越来越慢
• 给团队选型前做技术调研

这类任务，用它才值。

如果只是“帮我写个函数”，别开大招。

结论：它很强，但别当免费劳动力

Dynamic Workflows 最值得关注的地方，不是“Claude 又会了一个新招”。

而是 AI 编程工具开始从“单个助手”变成“临时团队”。

它会拆任务，会并行处理，会互相质疑，会把计划写进可执行逻辑里。

这确实是重要变化。

但价格也摆在那儿。

用得好，它能帮你省掉半天调研。
用得随意，它能帮你烧掉一堆 token，然后交付一份你本来 10 分钟就能写完的答案。

我的建议很直接：

大任务用它，小任务别碰。先让它出工作流方案，再让它执行。永远限制范围，永远要求证据。

这样用，Dynamic Workflows 才是真工具。否则它就是一台很会开会的 token 碎纸机。