Claude Code工程师详解动态工作流的六种核心模式

在此之前，多次介绍了动态工作流相关的内容。

Claude Code动态工作流上线：单会话跑上百子代理，11天完成75万行Bun代码迁移

AI外包！把Dynamic Workflows成本从6.2万美元狂砍到129美元的秘密

Claude Code 作者Boris：我已经不写 prompt 了，我写 loop

这次负责Claude Code的Anthropic工程师 Thariq 现身说法，发了一篇长文，把 Claude Code 动态工作流又认真的介绍了一次。

先说问题。

默认的 Claude Code 处理复杂任务时，规划和执行挤在同一个上下文窗口里。短平快的活没问题，但任务一长，三个毛病就冒出来了：

Agentic laziness——干到一半就宣布完工。安全审查列了 50 项，检查完 20 项就说搞定了。

Self-preferential bias——让 AI 自己验证自己的结果，它倾向于说"挺好的"。

Goal drift——上下文压缩时，原始目标慢慢走形。"不要做 X"这类约束，压缩几次就丢了。

动态工作流解决这些问题的思路：不靠一个 Claude 从头干到尾，而是让 Claude 自己写一个 JavaScript 调度文件，按需生成子 agent，每个子 agent 有自己的上下文窗口和独立目标。

核心 API 就两个函数。agent(prompt, opts?) 接受一个提示和可选选项，返回 Promise，结果可以是字符串或 JsonSchema 类型的数据。调用示例：

await agent("audit auth.ts", { 
schema: BugList, 
model: "haiku", 
isolation: "worktree", 
agentType: "reviewer" 
})

可以指定模型（Opus、Sonnet、Haiku）、隔离级别（worktree）、输出 schema 和 agent 类型。另一个是 parallel([fns])，做并行调度。配合标准 JavaScript 的 JSON、Math、Array 方法处理数据。

动态工作流和静态工作流的区别：静态工作流需要覆盖所有边界情况，通常更通用。而 Claude Opus 4.8 现在能自己写一个定制化的调度器，专门适配你的任务。

左边是静态方案：五个网络搜索、获取顶级结果、验证、总结，出一份通用报告。右边是动态方案：读取计费代码、逐功能匹配新供应商文档、按交易量定价、考虑反对迁移的最强论据，最后给出具体推荐。

Thariq 总结了六种常用模式，Claude 在构建工作流时会组合使用：

分类并执行（Classify-and-act）

任务进来，先分类，再路由到不同的 agent 处理。比如一个开发任务可能有读代码、改实现、补测试几种路径，以前靠人判断，现在交给分类 agent 先分再干。

分发与合成（Fan-out-and-synthesize）

大任务拆成小步骤，每个步骤跑独立 agent，最后汇总。适合大量小步骤的场景——每个步骤有自己的干净上下文，不会互相干扰。汇总步骤是个屏障，等所有子 agent 跑完，再把结构化输出合并成一个结果。

对抗验证（Adversarial verification）

每个子 agent 的产出，交给另一个独立的子 agent 按标准做对抗性验证。不是让 AI 自己检查自己，而是换一个 agent 来挑刺。

生成并筛选（Generate-and-filter）

先生成一批候选，再按标准过滤、去重，只保留质量最高的。适合命名、方案草稿、测试样例这类场景。

锦标赛（Tournament）

N 个 agent 用不同方法做同一件事，两两比较，决出胜者。比较判断比绝对评分更可靠。

循环直到完成（Loop until done）

不确定工作量的任务，循环 spawn agent 直到满足停止条件——没有新发现、日志没有新错误。停止条件写清楚是关键，不是让模型无限自嗨。

Thariq 举了几个实际用例：

迁移和重构。Bun 从 Zig 重写到 Rust 就是用工作流做的。关键是把任务拆成一系列步骤——调用点、失败测试、模块——每个修复在独立 worktree 里跑子 agent，改完再由另一个 agent 做对抗审查，然后合并。注意别让 agent 用太耗资源的命令，这样才能最大化并行度。

深度研究。Claude Code 内置的 /deep-research skill 就是用动态工作流实现的。分发搜索、抓取来源、对抗验证、综合报告。你也可以让 Claude 去 Slack 里翻上下文出状态报告，或者深入代码库研究某个功能怎么工作的。

深度验证。如果你有一份报告，想核实每个事实性声明，可以生成一个工作流：一个 agent 识别所有事实性声明，然后 spawn 子 agent 逐一核查，再安排一个验证 agent 检查来源质量。

排序。1000 行数据在一个 prompt 里排序，质量会下降，上下文也装不下。用锦标赛模式，两两比较——比较判断比绝对评分更可靠——或者并行分桶再合并。每个比较是一个独立 agent，确定性循环持有 bracket，只有运行顺序留在上下文里。

根因调查。调试最好的方式是提出多个独立假设并分别验证。但一个上下文窗口里，Claude 容易陷入自我偏好。工作流可以结构性地防止这个问题——从日志、文件、数据分别 spawn agent 生成假设，每个假设面对一组验证者和反驳者。这不只是对代码有用，销售（为什么三月销量下滑？）、数据工程（为什么管道失败了？）、任何事后复盘都适用。

记忆和规则遵守。如果 Claude 总是漏掉某些规则，哪怕写进 CLAUDE.md 也没用，可以创建一个工作流：每个规则配一个验证 agent，再创建一个怀疑者角色来审查规则本身，避免误报。反过来也行——挖掘最近的会话和代码审查记录，找出你反复犯的错误，用并行 agent 聚类，对抗性验证每条候选规则，蒸馏回 CLAUDE.md。

大规模分类。每个团队都有处理不完的支持队列、bug 报告。分类工作流可以自动分类、去重、采取行动——尝试修复或升级到人工。一个有用的模式是隔离：读取不可信公共内容的 agent 不能执行高权限操作，这些操作由负责执行的 agent 完成。配合 /loop 可以让 Claude 持续运行。

探索和品味。工作流也适合探索不同方案，尤其是基于品味判断的任务，比如设计或命名。让一个 agent 探索一批方案，给审查 agent 一个评分标准，任务在审查 agent 认为达标时完成。方案也可以通过锦标赛按标准排序。

轻量评估。在 worktree 里 spawn 独立 agent 执行任务，再 spawn 对比 agent 按标准评分。比如评估并优化你创建的 skill。

模型路由。创建一个分类 agent，根据任务复杂度决定用哪个模型。比如"解释 auth 模块怎么工作"这个任务，取决于 auth 模块有多少文件、代码库的结构。分类 agent 先做调研，然后根据预期复杂度路由到 Sonnet 或 Opus。

Thariq 也说了什么时候别用。

工作流消耗更多 token。常规编码任务不需要五个 reviewer 组成的评审团。问自己一句：这活真的需要更多算力吗？

几个实用技巧：

• 提示词要详细，用上面提到的具体模式来引导
• 可以用"quick workflow"做快速对抗验证
• 可重复的工作流（如 triage、research）配合 /loop 和 /goal 使用
• 可以设置 token 预算，比如"用 10k tokens"
• 工作流可以保存到 ~/.claude/workflows，也可以通过 skill 分发

通过 skill 分享时，把 JavaScript 工作流文件放在 skill 文件夹里，在 SKILL.MD 中引用。为了更灵活，可以提示 Claude 把 skill 中的工作流当作模板而不是逐字执行的脚本。