核心要点
- 动态工作流（dynamic workflows）让 Claude 能为当下任务现场编写一套定制 harness（驾驭系统）——不再依赖固定脚手架，而是按需生成。
- 单一上下文窗口里长时间作业会暴露三种失效模式：智能体偷懒（agentic laziness）、自我偏好偏差（self-preferential bias）、目标漂移（goal drift）。工作流通过编排多个各自拥有独立上下文、目标聚焦的 Claude 来对抗这些问题。
- 相比为所有边界情况兜底、因而更通用的静态工作流，动态工作流借助 Claude Opus 4.8 的能力为具体场景量身定制 harness。
- 六种可组合的常用模式：分类路由（classify-and-act）、扇出再汇总（fan-out-and-synthesize）、对抗式验证（adversarial verification）、生成再过滤（generate-and-filter）、锦标赛（tournament）、循环至完成（loop until done）。
- 工作流在非技术性工作上往往更有价值（迁移重构、深度研究、事实核查、排序、规则遵循、根因排查、大规模分诊、探索品味、评测、模型路由）；但它更耗 token，并非每个任务都需要——常规编码任务通常用不上五人评审团。
原文链接 English Original
上周，我们在 Claude Code 中发布了动态工作流（dynamic workflows）。现在 Claude 可以现场为手头的任务写出一套量身定制的 harness（驾驭系统）。
Claude Code 默认的 harness 是为编码打造的，但它对很多其他类型的任务同样有用——因为事实证明，许多任务在形态上都很像编码任务。不过，确实存在一些任务类别，我们必须在 Claude Code 之上构建定制 harness 才能达到最佳表现，例如研究（Research）、安全分析、智能体团队（agent teams）或代码评审（Code Review）。
工作流让你能够动态创建 harness，使 Claude 在 Claude Code 内部原生地解决上述所有问题——还有更多。你也可以把这些工作流分享、复用给他人。
本文中，我会分享自己使用工作流的初步经验与心得，帮你充分发挥它的价值。
话虽如此，最佳实践仍在不断演进！动态工作流往往会消耗更多 token，因此要谨慎权衡何时、如何使用它。
在深入技术细节之前，我想先用一些示例 prompt 让你感受一下工作流能带来的可能性：
动态工作流执行的是一个 JavaScript 文件，其中包含若干专用函数，用来派生（spawn）和协调子智能体（subagents）。动态工作流也内置了 JSON、Math、Array 等标准 JavaScript 函数，方便处理数据。
有一点特别值得知道：动态工作流可以决定每个智能体使用哪个模型、以及子智能体是否在各自独立的 worktree 中运行——这让 Claude 能为任务选择所需的智能等级与隔离程度。
如果工作流被中断（例如用户主动操作或退出终端），恢复会话即可让工作流从上次中断处继续。
当你让默认的 Claude Code harness 去做一个任务时，它需要在同一个上下文窗口里既做规划又做执行。对许多编码任务而言这非常高效，但在长时间运行、大规模并行、和/或高度结构化的对抗式任务上，有时会失灵。
原因在于：Claude 在单一上下文窗口里处理复杂任务的时间越长，就越容易陷入几种特定的失效模式：
创建一个工作流，通过编排各自拥有独立上下文窗口、目标聚焦且互相隔离的多个 Claude，有助于对抗这些问题。
你以前或许用 Claude Agent SDK 或 claude -p 创建过静态工作流，把多个 Claude Code 实例协同起来。
但由于静态工作流需要应对所有边界情况，它们通常更通用、更泛化。借助 Claude Opus 4.8 和动态工作流，Claude 现在已经足够聪明，能为你的具体用例写出一套量身定制的 harness。
你只需让 Claude 做一个工作流，就能开始使用动态工作流；或者使用触发词 "ultracode" 来确保 Claude Code 创建一个工作流。
不过，建立一套关于动态工作流如何运作的心智模型，有助于你理解何时该用它、以及如何通过 prompt 来引导 Claude。
Claude 在构建工作流时可能用到、并组合在一起的常用模式有几种：
分类路由（Classify-and-act） — 用一个分类器智能体判定任务类型，然后根据任务路由到不同的智能体或行为。或者在末尾用一个分类器来决定输出形态。
扇出再汇总（Fan-out-and-synthesize） — 把任务拆成许多更小的步骤，对每个步骤跑一个智能体，再把这些结果汇总。这在步骤数量很多、或每个步骤都受益于自己干净的上下文窗口（以免相互干扰或交叉污染）时特别有用。汇总步骤是一个屏障（barrier）——它会等待所有扇出的智能体完成，再把它们的结构化输出合并成一个结果。
对抗式验证（Adversarial verification） — 对每个被派生的智能体，再派生一个独立的智能体，对照评分标准或准则去对抗式地验证它的输出。
生成再过滤（Generate-and-filter） — 围绕某个主题生成一批想法，然后按评分标准或验证来过滤、去重，只返回质量最高、经过检验的想法。
锦标赛（Tournament） — 不是分摊工作，而是让智能体在同一件事上互相竞争。派生 N 个智能体，各自用不同的方法尝试同一个任务，再用一个评判智能体让 prompt 或模型对结果进行两两对比，直到决出胜者。
循环至完成（Loop until done） — 对于工作量未知的任务，循环派生智能体直到满足某个停止条件（没有新发现，或日志里不再有错误），而不是固定跑几轮。
发挥创造力，去想象在什么场景、以什么方式让 Claude Code 创建动态工作流。我发现，工作流有时在非技术性工作上甚至更有用。
Bun 就是用工作流从 Zig 重写为 Rust 的。你可以在 Jarred 的 X 帖子里读到更多细节。
关键是把任务拆解成一系列需要被逐一处理的步骤，例如调用点（callsites）、失败的测试、模块等等。为每一处修复在 worktree 里派生一个子智能体去改，再让另一个智能体对抗式评审，然后合并。可以考虑告诉智能体不要使用资源密集型命令，这样你就能在不耗尽机器资源的前提下最大化并行度。
我们在 Claude Code 内部发布了一个深度研究技能（/deep-research），它使用动态工作流。具体来说，它扇出网页搜索、抓取来源、对抗式验证这些来源的断言，再综合成一份带引用的报告。
但这类研究不止可以用于网页搜索。例如，你可以让 Claude 从 Slack 的上下文里汇编一份状态报告，或者通过深入探索代码库来研究某个功能是如何工作的。
反过来，如果你有一份报告，想核查并为它引用的每一个事实性断言找到出处，你可能想生成一个工作流：让一个智能体识别出所有事实性断言，再为每一条派生一个子智能体去逐一详查。你甚至可以再让一个验证智能体去检查那个找来源的子智能体，确保它的来源足够高质量。
你可能有一份清单，想按某种你认为 Claude Code 擅长评估的定性指标来排序，例如：按 bug 严重程度排序的支持工单。但如果你试图在一个 prompt 里给 1000+ 行排序，质量会下降，而且根本塞不进上下文。改用锦标赛、一条两两对比智能体组成的流水线（对比判断比绝对打分更可靠），或者并行分桶排名再合并。每一次对比都是它自己的智能体，因此确定性的循环负责掌控赛程，只有当前的排序顺序停留在上下文里。
如果有一组规则你发现 Claude 总是漏掉或处理不好，哪怕已经写进了 CLAUDE.md，那就建一个工作流，列出必须被检查的规则——每条规则配一个验证智能体。再创建一个"怀疑论者"人格的子智能体来审视这些规则、确保它们合理，有助于避免过多误报。
反方向同样可行：从你最近的会话和代码评审评论里挖出你反复在做的纠正，用并行智能体把它们聚类，对每个候选做对抗式验证（这条规则当初真能避免一次真实的失误吗？），再把幸存下来的规则提炼回 CLAUDE.md。
调试最有效的做法是提出若干彼此独立的假设并逐一验证；但如果你只用一个上下文窗口，Claude 会陷入自我偏好偏差。工作流可以从结构上防止这一点——派生若干智能体，从互不相交的证据中各自生成假设。例如，分别处理日志、文件、数据的智能体。每个假设随后都要面对一组验证者与反驳者的"答辩"。
这不只适用于代码。工作流也可用于销售（为什么 3 月销量下滑？）、数据工程（这条流水线为什么挂了？），或任何复盘（post-mortem）场景。
每个团队都有支持队列、bug 报告或某种积压，多到人力无法完全处理。
一个分诊（triage）工作流会对每一项分类、与已跟踪的事项去重，然后采取行动——可能是尝试修复，也可能是上报给人类用户。
分诊工作流有一个有用的模式叫隔离（quarantine）：禁止那些读取不可信公开内容的智能体执行高权限操作，这些操作改由专门负责依据信息采取行动的智能体来完成。
把分诊工作流和 /loop 搭配，就能让 Claude 持续不断地做这件事。
当你在探索某个解法的不同路径时，工作流会很有用，尤其当它偏品味判断（如设计或命名）、且适合用一份评分标准来衡量时。
可以试着让 Claude 探索一堆解法，并给一个评审智能体一份"好解法长什么样"的评分标准。当评审智能体认为已经达标时，任务即告完成。解法也可以基于评分标准，通过锦标赛来排序或选优。
你可以为特定任务跑轻量级评测：在 worktree 里派生若干独立智能体，再派生若干对比智能体，对照评分标准去比较和评分具体的输出。例如，针对某个标准评测、并进而打磨你创建的某个技能。
创建一个针对你的任务调校过的分类器智能体，由它决定该用哪个模型。当你的任务会涉及大量工具调用、且在执行前先做一番调研有助于识别最适合的模型时，这会很有帮助。
例如，"解释 auth 模块如何工作"这个任务的最佳模型，取决于 auth 模块里有多少文件、以及代码库的形态。一个分类器智能体可以先做这番调研，再根据任务的预期复杂度路由到 Sonnet 或 Opus。
工作流是新东西。虽然有许多用例能带来超额回报，但并非每个任务都需要它，而且它可能最终消耗多得多的 token。
最好把工作流创造性地用在那些你以前没尝试过、需要把 Claude Code 往前推一把的地方。对于常规编码任务，先问问自己：它真的需要更多算力吗？比如，大多数传统编码任务并不需要一个五人评审团。
Prompting — 运用我们上面描述的具体技巧、写出细致的 prompt，能让动态工作流产出最好的结果。工作流不只为大任务而生。你可以提示模型使用"快速工作流"，例如对某个假设做一次快速的对抗式评审。
与 /goal 和 /loop 搭配 — 对于可重复执行的工作流（如分诊、研究或核实），把它和 /loop 搭配以按固定间隔运行，并用 /goal 设定一个硬性的完成要求。
Token 用量预算 — 你可以为动态工作流设定明确的 token 用量预算，限制一个任务消耗多少 token。可以用类似"用 10k token"这样的预算来提示它，从而设定上限。
保存与分享动态工作流 — 在工作流菜单里按 "s" 即可保存工作流。你可以把它们签入 ~/.claude/workflows，或通过技能（skill）分发。要通过技能分享，就把你的 JavaScript 工作流文件放进技能文件夹，并在 SKILL.md 中引用它们。为了更灵活，你可能想提示 Claude 把技能里的工作流当作模板、而非必须逐字运行的脚本来看待。
工作流是扩展 Claude Code 的一种有用的新方式。我鼓励你把这当作一个起点——关于如何最好地使用它们，仍有很多有待发掘。期待你的发现。
Thariq Shihipar 和 Sid Bidasaria（@sidbid）是 Anthropic 的技术团队成员，从事 Claude Code 的工作。