一文了解 Dynamic Workflows

01 简单任务很顺，复杂任务不稳

使用 Claude Code、Codex、Cursor 这类 AI 编程工具时，很多人会发现一个现象：简单任务很顺，复杂任务不稳。

解释一个函数、补一个字段、改一个简单样式，通常不会有太大问题。但如果任务变成大规模重构、排查偶发失败测试、审查一篇技术文章里的所有事实、分析一批工单并找出重复根因，结果就容易变得不可靠。

常见问题包括：任务只完成了一部分，却提前宣布完成；输出结构完整，但关键细节没有验证；前面明确说过的限制，后面执行时被忘掉；让它检查自己的方案，它往往倾向于认为自己的方案没有问题。

这些问题不一定说明模型能力不够。更准确地说，是任务组织方式不够可靠。很多复杂任务失败，原因在于 AI 没有被放进一个清晰的执行结构里。

过去我们经常把复杂任务直接塞进一个长对话，让同一个 Agent 同时负责理解目标、制定计划、执行任务、检查结果和输出总结。这个方式对小任务有效，但面对复杂任务时，单一上下文会逐渐暴露出明显缺陷。

Claude Code 的 Dynamic Workflows 解决的正是这个问题。它不是简单地让 AI 多做几步，也不是普通提示词模板，而是让 Claude 根据当前任务动态生成一套执行流程，把复杂任务拆成多个角色、多个阶段和多个验证环节。

本文的核心观点是：Dynamic Workflows 的价值在于让 AI 更会组织复杂任务。

02 Dynamic Workflows 到底是什么

Dynamic Workflows 是 Claude Code 中的一种动态工作流机制。它允许 Claude 根据当前任务临时生成一套多 Agent 执行框架，用来拆分任务、分配子任务、并行处理、隔离上下文、安排验证、合并结果，并判断任务是否真正完成。

这里有一个关键概念：harness。

harness 可以理解为"任务执行框架"。模型负责理解、推理和生成内容；harness 负责规定任务如何被组织和推进。也就是说，模型解决的是"怎么思考"，harness 解决的是"怎么执行"。

一个完整的 harness 通常会决定以下问题：

任务应该如何拆解。
哪些子任务需要独立执行。
哪些 Agent 负责执行，哪些 Agent 负责验证。
哪些部分可以并行，哪些部分必须串行。
是否需要隔离上下文或使用独立 worktree。
多个结果如何合并。
什么条件下任务才算完成。

这和普通提示词有本质区别。普通提示词主要告诉模型"你要做什么"；Dynamic Workflows 更进一步，规定"这件事应该如何组织起来做"。它把复杂任务从一个长对话，变成一个有分工、有检查、有停止条件的执行流程。

所以，理解 Dynamic Workflows，不能只把它看成 Claude Code 的一个新功能。更准确地说，它代表了一种新的 Agent 使用方式：从"让一个 AI 做完全部事情"，转向"让 AI 为当前任务设计一套可靠流程"。

03 为什么复杂任务不能只靠一个 Agent

要理解 Dynamic Workflows 的必要性，先要理解单一长对话为什么会失败。核心原因有三个。

Agentic laziness：有进展不等于已完成

复杂任务中，Agent 很容易把"做了很多"误判成"已经完成"。

例如，你让它检查 50 个安全项。它可能认真检查了其中 30 个，写出一份结构完整、语言严谨的报告，然后告诉你任务完成。但剩下 20 个并没有真正处理。

这类问题的危险之处在于，它不是完全失败，而是部分成功。部分成功的结果最容易让用户放松警惕，因为它看起来像一份完整交付物。真正的问题不在于没有产出，而在于产出和完成标准之间存在缺口。

复杂任务必须区分两个概念：进展和完成。进展说明任务被推进了，完成说明所有必要条件都满足了。如果没有明确的完成条件，Agent 很容易在中途收尾。

Self-preferential bias：自己验证自己并不可靠

第二个问题是自我偏好。

如果一个 Agent 先提出方案，再让它自己检查方案，它往往会倾向于维护前面的判断。即使你要求它"严格审查"，它也可能对关键风险处理得过于宽松。

原因很简单：同一个上下文里的验证者，继承了生成者的假设、推理路径和表达方向。它很难真正站到独立审查的位置。

更可靠的方式，是把执行者和验证者拆开。一个 Agent 负责生成方案，另一个独立 Agent 按照明确 rubric 检查问题。验证者不需要照顾前面的思路，它的职责就是找漏洞、找遗漏、找证据不足的地方。

这也是 Dynamic Workflows 的重要价值：它可以把"生成"和"验证"拆成两个相对独立的环节，降低自我确认偏差。

Goal drift：长任务会稀释原始目标

第三个问题是目标漂移。

任务越长，上下文越复杂，最初目标越容易被稀释。比如你一开始明确要求"不要改数据库结构"，但经过多轮修改、摘要和补充后，Agent 后面可能为了实现功能而忽略这个限制。

长上下文的问题不只是内容变多，还包括优先级变模糊。哪些要求是硬约束，哪些只是建议，哪些风险必须避免，在多轮执行后都可能变得不清楚。

所以，复杂任务不能只依赖一开始的一段说明。更稳妥的方式，是把目标、约束和停止条件写进流程，让每个子任务都围绕明确边界执行。

Dynamic Workflows 正是针对这三类失败设计的：防止提前结束，降低自我偏见，减少目标漂移。

04 Dynamic Workflows 如何提高可靠性

Dynamic Workflows 的解决方式可以概括为四个动作：拆分、隔离、验证、停止。

拆分任务

复杂任务首先要拆成多个更小的子任务。

例如排查一个线上故障，可以让一个 Agent 查看错误日志，一个 Agent 阅读相关代码，一个 Agent 检查最近提交，一个 Agent 查找历史 issue，最后由汇总 Agent 合并可能根因。

拆分之后，每个 Agent 的目标更具体，上下文更干净，输出也更容易检查。大任务靠结构化拆解降低认知负担，而不是让一个 Agent 硬扛。

隔离上下文

不同 Agent 可以拥有独立上下文。这样做的价值是减少相互污染。

如果所有分析都发生在同一个上下文里，后面的判断很容易被前面的假设带偏。独立上下文可以让不同 Agent 从不同角度提出结论，尤其适合根因分析、方案评估和事实核查。

在代码任务中，某些子 Agent 还可以运行在独立 worktree 中。这样多个方案可以互不干扰，最后只合并通过验证的结果。

安排对抗验证

执行完成不等于任务完成。对于高风险任务，必须加入验证环节。

例如技术文章事实核查中，一个 Agent 可以先识别所有事实性 claim，多个 Agent 分别查证，最后再由 verification Agent 检查来源质量和结论可靠性。

代码任务也是一样。一个 Agent 修改代码，另一个 Agent 检查是否遗漏调用点、是否破坏测试、是否违反项目规则。这样做的重点在于把"挑错"变成流程中的必要步骤，而不是增加形式。

设置停止条件

复杂任务不能靠"看起来差不多"结束，而要规定清楚什么叫完成。

例如：所有测试通过才结束；所有事实性 claim 都有验证结论才结束；没有新的错误日志才结束；所有高优先级问题都有处理方案才结束。

停止条件越清楚，任务越不容易半途收尾。Dynamic Workflows 的意义就在于把这些条件放进执行流程，而不是只放在一句提醒里。

05 六种常见工作流模式

掌握 Dynamic Workflows，不需要一开始就研究底层实现。先理解常见模式，更容易在真实任务中使用。

Classify-and-act：先分类，再处理

这个模式先判断任务类型，再决定后续处理方式。

例如面对一批 bug 报告，先判断它们属于前端问题、后端问题、数据问题还是文档问题，再交给不同 Agent 处理。

它适合工单分流、问题分类、严重程度判断和模型路由。核心原则是：先判断问题属于哪一类，再决定用什么方法处理。

Fan-out-and-synthesize：并行拆解，再统一合并

这个模式把大任务拆成多个小任务并行执行，最后统一汇总。

例如审查一个大型代码库，可以让不同 Agent 分别检查认证模块、支付模块、数据库层和 API 层。每个 Agent 独立输出发现，最后由汇总 Agent 合并成总报告。

它适合多文件审查、大规模迁移、多来源研究和长文事实核查。核心原则是：大任务拆开做，结果再合并。

Adversarial verification：对抗式验证

这个模式让一个 Agent 负责生成结果，另一个 Agent 负责挑错。

它适合安全审查、代码 review、事实核查和方案评估。核心原则是：重要结果不能只让生成者自己确认。

对抗验证的关键，是给验证 Agent 明确标准，而不是只让它泛泛地"检查一下"。标准可以包括测试是否通过、事实是否有来源、方案是否覆盖边界条件、改动是否符合项目规则。

Generate-and-filter：大量生成，再筛选

这个模式先生成大量候选，再通过规则过滤、去重、排序。

它适合命名、标题、产品方案、设计方向和文案探索。核心原则是：创意任务不要追求一次命中，先扩大候选池，再用标准筛选。

这里的重点是过滤标准。如果没有标准，大量生成只会制造噪音；有了标准，候选池才有价值。

Tournament：锦标赛式比较

这个模式让多个 Agent 提出不同方案，再通过两两比较选出更优结果。

很多时候，模型做"两个方案哪个更好"的判断，比做绝对评分更稳定。因为相对比较的认知负担更低，也更容易暴露差异。

它适合方案选择、简历排序、架构评估和命名筛选。核心原则是：复杂判断可以转化为一系列相对比较。

Loop until done：循环直到完成

这个模式不预设固定轮次，而是持续执行，直到满足停止条件。

例如复现一个偶发失败测试，不能只跑三轮就结束。更合理的方式是持续提出假设、修改验证方法、运行测试，直到找到能解释失败的稳定证据。

它适合 flaky test、根因调查、日志清理和大规模问题排查。核心原则是：不要问"跑几轮"，要问"什么条件下才算完成"。

06 哪些任务最适合 Dynamic Workflows

Dynamic Workflows 不是日常小任务的默认选择。它适合复杂、高价值、容易遗漏、需要验证的任务。

典型场景包括：大规模代码重构、多模块代码审查、深度资料研究、技术文章事实核查、复杂 bug 根因分析、大量工单或简历排序、从历史会话中提炼规则并写入项目说明。

这些任务有一个共同点：如果只交给一个 Agent 在一个长上下文里完成，风险比较高。

更具体地说，当任务满足以下条件时，可以考虑使用 Dynamic Workflows：步骤很多；信息来源很多；可以并行拆分；需要独立验证；做错代价较高；结果质量比 token 成本更重要。

一句话判断：Dynamic Workflows 最适合那些"单 Agent 容易漏，漏了代价又高"的任务。

07 什么时候不要用 Dynamic Workflows

Dynamic Workflows 也有成本。

它会启动更多 Agent，消耗更多 token，执行时间也可能更长。如果任务本身很简单，强行使用 workflow 只会增加复杂度。

例如修改一个小 bug、补一个字段、改一个简单样式、解释一个函数、写一段普通脚本、回答一个范围明确的问题，通常不需要 Dynamic Workflows。普通 Claude Code 工作流就够了。

使用前可以先问一句：这个任务真的需要更多算力和组织结构吗？

如果答案是否定的，就不要使用。Dynamic Workflows 不是省成本工具，而是质量增强工具。它的合理用法，是在值得投入的复杂任务上，用更多结构换取更高可靠性。

08 新手如何正确提示 Claude

新手最容易犯的错误，是只说"帮我用 workflow 做这个任务"。这种提示太宽泛，Claude 很难知道你真正需要什么结构。

更好的提示方式，是把目标、模式、分工、验证标准和停止条件写清楚。可以使用下面这个模板：

请为这个任务创建一个 Dynamic Workflow。
任务目标：
[写清楚最终要完成什么]
建议模式：
[例如 fan-out-and-synthesize / adversarial verification / loop until done]
分工要求：
[哪些 Agent 负责执行，哪些 Agent 负责验证]
验证标准：
[用什么标准判断结果是否合格]
停止条件：
[什么条件下才算真正完成]
预算限制：
[例如控制在 10k tokens 内]

例如，要核查一篇技术文章，可以这样写：

请为这篇技术文章创建一个 quick workflow。
目标是验证文章中所有技术性事实是否准确。
先识别所有事实性 claim，再让独立 Agent 逐条核查。
每个 claim 都必须给出结论：准确、不准确、证据不足。
最后让 verification Agent 检查来源质量。
只有所有 claim 都有明确结论后，才输出最终报告。

这个提示比"帮我检查一下文章"更可靠，因为它规定了流程，而不只是提出了愿望。

09 从会提问，到会组织任务

AI Agent 的进化，不只是模型回答更流畅。更重要的是，复杂任务的组织方式正在变成熟。

Prompt 解决的是如何把需求说清楚。Tool use 解决的是如何让模型操作外部工具。Subagent 解决的是如何让模型分工。Dynamic Workflows 进一步解决的是如何组织分工、验证和收尾。

对普通用户来说，Dynamic Workflows 不是每天都要使用的功能。真正需要掌握的是它背后的工作方法：复杂任务不要只依赖一个长对话。要拆分，要隔离，要验证，要设置停止条件。

会提问只是使用 AI 的第一步。更高阶的能力，是把一个复杂任务设计成可靠流程。这正是 Dynamic Workflows 最重要的价值。