Claude Code 动态工作流使用教程
Claude Code 的动态工作流可以为不同任务临时生成一套 Agent 编排。适合长链路排查、并行研究、批量分类、对抗验证和规则沉淀。
Claude Code 最近加入了动态工作流。它的思路很直接：让 Claude 在任务进行中临时写出一套执行框架，按当前目标生成合适的子 Agent 、评审 Agent 、循环条件和汇总方式。
默认的 Claude Code 很适合写代码，但很多复杂任务会遇到同一个问题：计划、执行、验证、返工都挤在同一个上下文里。任务一长，容易提前收工、偏向自己的结论，或者在多轮压缩后丢掉边界条件。动态工作流就是把这些动作拆开，让不同 Claude 在独立上下文里协作。
适合先试的提示词
动态工作流可以直接通过自然语言触发。下面这些提示词适合复制后按场景改：
这个测试大约 50 次失败 1 次。请搭建一个工作流来复现它，提出假设，并在不同 worktree 里做对抗测试。/goal：不要停止，直到有一个假设被验证有效。
请用一个工作流查看最近 50 次 Claude Code 会话，找出反复出现的修正意见，把高频问题整理成 CLAUDE.md 规则。
请用工作流翻查过去 6 个月 #incidents 频道，找出反复出现但还没有建 ticket 的根因。
这里有一份商业计划。请运行一个工作流，让不同 Agent 分别从投资人、客户、竞争对手视角挑问题，再汇总最值得修的部分。
这里有一个包含 80 份简历的文件夹。请用工作流按后端岗位要求排序，并复核前 10 名。需要评分标准时，用 AskUserQuestion 工具提问。
需要给这个 CLI 工具取名。请用工作流生成多组候选名，再用锦标赛机制选出前 3 个。
请用工作流把代码库里的 User model 全部重命名为 Account。
请用工作流检查这份技术博客草稿里的每个技术说法，逐条对照代码库验证，避免发布错误信息。
动态工作流怎样运行
动态工作流会执行一个 JavaScript 文件，文件里带有一些用于创建和协调子 Agent 的特殊函数。工作流也可以使用常规 JavaScript 能力，例如 JSON、Math、Array，方便处理中间数据。
工作流可以决定每个子 Agent 用什么模型，也可以决定是否把子 Agent 放到单独 worktree 中执行。这样一来，复杂任务可以按智能程度和隔离需求分配资源：简单分类用轻量模型，关键判断交给更强模型；需要改代码的分支放进独立 worktree，减少互相污染。
如果工作流被中断，例如终端退出或者手动打断，恢复会话后可以继续从中断处往下走。
常见编排模式
动态工作流常见的价值不在“多开几个 Agent”，而在于选择合适的编排结构。下面这些模式可以组合使用。
1. 分类后执行
先让分类 Agent 判断任务类型，再路由到不同 Agent 或不同行为。结尾也可以放一个分类 Agent，用来判断输出是否符合交付要求。
2. 扇出后综合
把一个大任务拆成很多小任务，每个小任务由独立 Agent 处理，最后再综合结果。适合大量相似子任务，也适合每个步骤都需要干净上下文的任务。
3. 对抗验证
每个执行 Agent 产出结果后，再启动一个验证 Agent，按 rubric 或验收条件做反向检查。安全审查、事实核验、复杂重构都适合这个模式。
4. 生成后筛选
先大量生成候选方案，再按评分标准筛掉重复项和低质量项，只留下经过检查的结果。命名、设计方案、研究方向都适合这样跑。
5. 锦标赛
多个 Agent 面向同一个问题，分别走不同路径求解。再让评审 Agent 进行两两比较，直到选出胜出方案。适合审美、产品判断、方案选择这类没有唯一答案的任务。
6. 循环直到完成
面对工作量未知的任务，可以不预设固定轮数。让工作流反复生成 Agent，直到停止条件满足：没有新发现、日志里没有新错误，或者验收清单全部通过。
适合落地的任务
动态工作流可以用于代码之外的任务，关键是任务本身是否长、是否并行、是否需要验证、是否容易被单一上下文带偏。
迁移与重构
Bun 从 Zig 重写到 Rust 时就用到了工作流。迁移类任务可以拆成一系列可操作步骤：调用点、失败测试、模块、接口边界等。每个修复在独立 worktree 里完成，再由另一个 Agent 做对抗 review，最后合并。
深度研究
Claude Code 里的 /deep-research skill 就使用了动态工作流。它会扇出 Web 搜索、抓取来源、逐条验证结论，再合成带引用的报告。同样的结构也可用于 Slack 上下文、代码库调研、业务复盘。
深度验证
如果有一份报告需要逐条检查事实，可以让一个 Agent 先识别所有可验证声明，再为每条声明启动子 Agent 深挖来源。最后再用独立验证 Agent 检查结论是否可靠。
排序与筛选
当列表规模很大时，例如 1000 条支持工单、简历、 bug 报告，单轮提示很容易塞不进上下文，质量也会下降。更稳的方式是分批排序、分层比较，再让汇总 Agent 统一校准。
记忆与规则遵守
如果某些规则经常被 Claude 忽略，可以建立一个规则检查工作流：每条规则交给一个验证 Agent 。也可以反向操作：从近期会话和 code review 里挖出反复出现的修正意见，聚类、验证，再沉淀回 CLAUDE.md。
根因调查
调试复杂问题时，单一上下文容易偏向最初假设。工作流可以把证据拆成几组，让不同 Agent 独立提出假设，再分别验证。这个方法也适合销售下滑、数据管道失败、事故复盘等非代码问题。
大规模分诊
支持队列、 bug backlog 、公开反馈都可以交给分诊工作流：分类、去重、对照已有记录、尝试修复或升级给人工。这里有一个重要设计：读取不可信公开内容的 Agent 不应拥有高权限操作；负责执行动作的 Agent 需要被隔离出来。
探索与品味问题
命名、设计、方案选择这些任务没有标准答案，但可以有 rubric 。让多个 Agent 探索不同方向，再由评审 Agent 按标准打分，直到满足条件。
轻量评测
可以用工作流跑轻量 eval：在 worktree 里启动多个 Agent 产出结果，再用比较 Agent 按 rubric 打分。比如评测一个 skill 是否满足某个标准，或者比较两套提示词输出质量。
模型与智能路由
可以训练一个分类 Agent 先判断任务复杂度，再决定使用 Sonnet 还是 Opus 。例如“解释 auth 模块如何工作”这个任务，难度取决于 auth 模块文件数量、依赖形状、代码组织方式。先调研，再路由，通常比一开始固定模型更省。
什么时候别用
动态工作流还很新，并且通常会消耗更多 token 。普通编码任务、很短的修复、单文件改动，大多不需要 5 个评审 Agent 。更适合使用工作流的条件是：任务链路长、信息源多、需要并行验证、需要隔离上下文，或者明确存在提前收工和目标漂移风险。
构建动态工作流的几个技巧
提示词要具体
动态工作流吃提示词质量。目标、验收条件、停止条件、可用工具、禁止事项，都应该写清楚。复杂任务可以配合 /goal，把完成条件写成硬约束。
可以要求 quick workflow
工作流不只适合大任务。需要快速验证一个假设时，可以要求创建 quick workflow，例如只做一次对抗 review 或一次事实检查。
和 /loop 配合
重复运行的任务适合配合 /loop，比如持续分诊、周期性研究、持续验证。/goal 用来定义完成要求，/loop 用来控制重复执行。
设置 token 预算
可以给动态工作流设置明确预算，例如：
请使用 10k tokens 以内完成这个工作流。
这样可以控制成本，也能迫使工作流在必要时做取舍。
保存和分享
工作流菜单里按 s 可以保存工作流。保存后的文件可以放到 ~/.claude/workflows，也可以通过 skill 分发。
如果通过 skill 分发，把 JavaScript 工作流文件放进 skill 文件夹，并在 SKILL.md 中引用。为了保持灵活性，提示时可以把 skill 里的工作流当成模板，不必逐字执行脚本。
一套实用判断
动态工作流适合把 Claude Code 从“单个 Agent 处理一切”扩展成“按任务临时组织一支小队”。它的重点是结构：谁负责生成、谁负责验证、谁负责汇总、何时停止、哪些动作要隔离。
先从小任务试：一次不稳定测试复现、一组技术声明核验、一次简历筛选、一个命名锦标赛。能明显改善质量后，再把同样模式沉淀到 ~/.claude/workflows 或 skill 中。