纯度AIClaude Code 动态工作流怎么用：让 Claude 自己编排一组子代理
根据 Claude Code 团队的文章整理：动态工作流让 Claude 为眼前的任务临时写一段编排脚本，调度很多个各有独立上下文的子代理。讲清它解决什么问题、六种常见的编排方式、适合和不适合的场景，以及控制用量、保存和分享的办法。
本文根据公开分享整理，本站尚未实测。操作前请对照文末的原始来源。
这是“Claude Code 开发系列”的第四篇。
这一篇解决的问题是：有些任务，一个 Claude 在一个上下文里从头做到尾，效果就是不好。 比如检查 50 项只做了 35 项就说完成了，或者让它检查自己的结论时总是偏向自己。动态工作流是 Claude Code 给出的办法：让 Claude 为这一个任务临时写一段脚本，调度一组各自独立的子代理去做。
先说代价：动态工作流通常更费 token。 官方自己的建议是把它用在复杂、高价值的任务上。
它是怎么工作的
动态工作流执行的是一个 JavaScript 文件，里面有几个专门的函数用来发起和协调子代理：一个用来发起单个子代理，另外两个用来把很多个子代理组合成并行或流水线。脚本里也能用普通的 JavaScript 来处理数据。
两点值得知道：
- 工作流可以决定每个代理用哪个模型，以及是否让子代理在各自的 worktree 里运行。 也就是 Claude 可以按需选择“多聪明”和“隔离到什么程度”。
- 被打断了可以接着跑。 你中断了它，或者关了终端，恢复会话后工作流会从停下的地方继续。
它解决什么问题
默认情况下，Claude Code 要在同一个上下文窗口里既做计划又做执行。多数编码任务这样很好，但任务很长、要大量并行、结构性很强，或者需要互相挑错时，就容易出问题。原文点名了三种毛病：
| 毛病 | 表现 |
|---|---|
| 偷懒 | 任务又多又杂时，做了一部分就宣布完成。比如安全评审的 50 项只处理了 35 项 |
| 偏向自己 | 让它验证或评判自己的结论时，倾向于认为自己是对的 |
| 目标漂移 | 轮数多了，尤其是压缩过上下文之后，离最初的目标越来越远。每次总结都会丢一些细节，边界条件和“不要做某事”这类限制最容易丢 |
工作流的对策是：让一个个子代理各有自己的上下文窗口，各有一个明确而独立的小目标。
和“静态工作流”的区别：以前用 Agent SDK 或 claude -p 也能把多个 Claude 串起来，但那种固定的流程要照顾所有情况，所以往往比较笼统。动态工作流是 Claude 针对眼前这一个任务现写的。
怎么让它用工作流
直接让 Claude 做一个工作流就行；或者在提示词里用触发词 ultracode，确保它会创建工作流。
原文给的一些提示词（译自原文），可以感受一下它能做什么：
这个测试大概每 50 次失败 1 次。搭一个工作流来复现它。
对这个竞态问题提出几种互相竞争的解释，直到只剩一种经得起证据为止。用一个工作流过一遍我最近的 50 次会话，找出我反复在纠正的地方，
把反复出现的那些变成 CLAUDE.md 里的规则。这个文件夹里有 80 份简历。用工作流按后端岗位给它们排序，并对前十名复核一遍。
先用提问的方式向我问清评分标准。用一个工作流，对照代码库核实我这篇博客草稿里的每一个技术说法。我不想发出任何错的东西。六种常见的编排方式
Claude 写工作流时会用到并组合这几种模式。了解它们，你在提示词里就能点名要哪一种。
| 模式 | 做法 | 适合 |
|---|---|---|
| 先分类再处理 | 一个代理判断任务属于哪一类，再交给不同的代理或走不同的流程 | 一批性质不同的东西 |
| 分散再汇总 | 把任务拆成很多小步，每步一个代理，最后等全部做完再合并结果 | 小步骤很多，或者每一步需要干净的上下文、互不干扰 |
| 对抗式验证 | 每个代理的产出，由另一个代理按标准来挑错 | 结论必须可靠的工作 |
| 生成再筛选 | 先产生一批想法，再按标准筛选、去重，只留下质量最高的 | 起名、出点子 |
| 淘汰赛 | 不拆分任务，让几个代理用不同的办法做同一件事，再两两比较选出最好的 | 靠品味判断的工作 |
| 循环到做完 | 工作量不确定时，不固定跑几轮，而是一直发起代理，直到满足停止条件（比如没有新发现了） | 排查、清理 |
用在哪些地方
原文列了不少，这里挑最有代表性的几类。作者提到，工作流有时在非技术的工作上反而更有用。
迁移和重构。 把任务拆成一系列要处理的单位：调用点、失败的测试、模块。每一处由一个子代理在自己的 worktree 里改，另一个代理对抗式地评审，然后合并。原文提到 Bun 从 Zig 改写成 Rust 就用了工作流。一个实用的提醒：告诉代理不要用很吃资源的命令，这样才能在你的机器上尽量多地并行。
深度调研。 Claude Code 里有一个用动态工作流做的 skill，/deep-research：分散去搜索、读取来源、对抗式地核实其中的说法，最后综合成一份带引用的报告。同样的做法也能用在别处，比如从 Slack 里的上下文整理一份进度报告。
逐条核实。 有一份报告，想核实里面每一个事实说法：一个代理找出所有说法，再给每一条各派一个代理去查。还可以再加一个代理检查来源的质量。
给大量东西排序。 想按某种定性的标准给一千多条东西排序（比如按严重程度排工单），放进一个提示词里质量会下降，也放不下。做法是办淘汰赛：每一次两两比较由一个新的代理来做。原文的说明是，比较两个东西哪个更严重，比直接打一个绝对的分数更可靠。
让规则真的被遵守。 有些规则写进了 CLAUDE.md，Claude 还是会漏。可以做一个工作流：每条规则一个验证代理。再加一个“怀疑者”代理复核，减少误报。
找根本原因。 调试时最好是提出几个独立的假设再分别检验，但在一个上下文里，Claude 容易偏向自己先想到的那个。工作流可以从结构上避免：让不同的代理分别从日志、文件、数据出发提出假设，每个假设再交给一组代理去验证和反驳。这不只适用于代码，“三月份销售额为什么掉了”也可以这样查。
大批量分拣。 工单队列、bug 报告这类人处理不完的积压。工作流给每一条分类、和已有的记录去重，然后采取行动：尝试修复，或者上报给人。
这里有一个和安全有关的做法值得单独记住，原文叫隔离：读取不可信的公开内容的代理，不给它任何高权限的操作；真正执行操作的是另一个代理，它只看得到前者的总结。这样外部内容里夹带的指令，碰不到有权限的那一环。
什么时候不该用
原文的态度很明确：工作流不是每个任务都需要，而且可能明显更费 token。
对普通的编码任务，先问自己一句：它真的需要更多的计算量吗？ 比如多数常规的编码任务，并不需要五个评审员组成的小组。
几条实用的建议
提示词写细一点。 在提示词里点名上面那些模式，效果最好。工作流也不只适合大任务，可以让它做一个“快速的工作流”，比如对某个假设做一次快速的对抗式检查。
和 /goal、/loop 配合。 可以重复的工作流（分拣、调研、核实），配上 /loop 定期运行，用 /goal 设一个必须达到的完成条件。
给它设 token 预算。 可以在提示词里直接写一个预算，比如“用 1 万 token”，它会把这个当作上限。
保存和分享。 在工作流的菜单里按 s 可以保存。保存的工作流可以放在 ~/.claude/workflows 里，也可以通过 skill 分发：把工作流的 JavaScript 文件放进 skill 的文件夹，在 SKILL.md 里引用它。原文的建议是，让 Claude 把 skill 里的工作流当作模板，而不是必须原样执行的脚本，这样更灵活。
控制模型的成本。 Claude Code 2.1.296 新增了一个环境变量 CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL，可以让工作流里的所有代理统一用一个模型，见 Claude Code 2.1.295 到 2.1.296 更新。
小结
作者把动态工作流称为一个新的起点：怎么用好它，还有很多有待发现。从使用者的角度，可以这样记：
- 一个上下文做不好的事，换成多个各管一小块的代理来做；
- 让一个代理检查另一个代理，比让它检查自己可靠；
- 它更贵，所以用在值得的地方，并给它设预算。