Anthropic在五月底发布Claude Opus 4.8时，同步推出了Claude Code的动态工作流功能。这项新特性一经面世，便在AI圈内引发了广泛讨论和关注。

有开发者利用它在11天内完成了75万行代码的语言迁移项目，也有人借此对整个代码库实施了全面的安全审计。更有观点认为，这个功能运行起来所消耗的Token数量，甚至超过了一个人一个月的用量。

最近，有朋友在面试时就被问到了关于“动态工作流”的问题。但说实话，很多人对于这个概念的理解仍然比较模糊——它究竟是模型自身习得的能力，还是工具层面搭建出来的框架？它与之前常见的多Agent编排模式有何区别？如果面试官问你“动态工作流的本质是什么”，你能清晰作答吗？

本文将为你讲透这一点，带你深入理解动态工作流的运作原理、技术架构，以及它在当前AI应用开发中的核心定位。

动态工作流是什么？

动态工作流的本质，是让AI自主编写编排脚本，将一个庞大任务拆解为多个子任务，分发给数十到数百个并行运行的子Agent执行，最后汇总并交叉验证结果。

请注意，关键词在于让AI自己编写。

以往实现多Agent协作时，无论使用LangGraph这类框架，还是手动编写编排代码，任务如何拆分、子Agent如何协调、结果如何整合，所有这些逻辑都需要开发者预先手动定义。你必须提前规划好有几个Agent、每个Agent负责什么任务、上下游之间如何串联。

动态工作流则完全不同。你只需要告诉AI你的目标，例如“帮我把这个项目从Python 2迁移到Python 3”，它就会自动分析代码库结构，自主决定需要多少个子Agent、每个子Agent负责迁移哪些文件、如何并行执行、以及如何验证迁移后代码的正确性。整个编排方案是AI根据当前具体任务实时动态生成的，而非基于预定义的模板。

打个比方，传统的多Agent编排就像你作为项目经理，需要亲自绘制甘特图、分配任务、并主持每日站会跟进进度。而动态工作流更像是你将需求丢给一位值得信赖的技术负责人，他会自行协调团队、分配工作、监控进度、进行验收，最终直接向你交付成果。

Agent系统的分类

要理解动态工作流的技术定位，我们先来看看Anthropic官方是如何对Agent系统进行分类的。早在2024年12月，Anthropic就发布了一篇极具影响力的技术博客，名为Building Effective Agents。

这篇文章将所有Agentic系统归纳为两大类。

第一类是Workflow工作流——LLM与工具的协作路径通过预定义的代码进行编排。你设定好流程，AI遵循流程执行。

第二类是Agent智能体——LLM自主动态地决定下一步行动、使用何种工具、以及如何推进任务。控制权掌握在模型手中。

在Workflow这一大类下，Anthropic进一步细分为5种具体模式。

1、Prompt Chaining提示链：任务被分解为一系列固定的步骤，前一步的输出直接作为后一步的输入。例如，先生成文案，再将其翻译成英文，两步顺序固定。

2、Routing路由：根据输入的类型将请求分发至不同的处理流程。例如，在客服系统中，退款问题走退款流程，技术问题走技术支持流程。

3、Parallelization并行化：将同一个任务拆分为多个独立的子任务并行执行，最后汇总结果。例如，让多个Agent分别从不同角度审查同一段代码。

4、Orchestrator-Workers编排者-工人：一个中心LLM作为编排者，动态地将任务分解并分配给多个工人LLM执行，然后综合其结果。这里的核心在于“动态”，编排者并非依据预定义规则分配任务，而是根据具体输入判断需要多少个工人以及每个工人应承担什么职责。

5、Evaluator-Optimizer评估者-优化器：一个LLM生成结果，另一个LLM负责评估并反馈，通过循环迭代直至达到预期质量。

你发现了吗？动态工作流本质上就是第4种模式——Orchestrator-Workers的产品化实现。

注意，这并不是一种全新的模式，而是同一模式的不同实现方式。其区别在于由谁搭建这个编排系统。

传统做法是你自己通过代码实现Orchestrator-Workers。例如，要进行一次全代码库的安全审计，你需要使用LangGraph或手写Python来搭建这套编排逻辑：

# 这是开发者自己编写的编排器files = scan_all_files(project_path)risk_groups = classify_by_risk(files)agents = []for group in risk_groups.high: agents.append(Agent(task="deep_audit", targets=group))for group in risk_groups.low: agents.append(Agent(task="quick_scan", targets=group))results = run_parallel(agents)report = merge_results(results)

这段代码运行起来确实是“动态”的，能够根据实际文件情况灵活分配。但关键在于，这个编排器本身是你编写的。从如何扫描文件、如何分级风险，到启动几个Agent、每个Agent采用何种策略，所有这些决策规则都需由你设计。

而Dynamic Workflows的特点在于，Claude Code将这一过程完全自动化。你只需说一句“帮我审计这个项目的安全漏洞”，Claude就会自动生成类似上述的编排逻辑并执行。扫描文件、评估风险、分配任务、汇总结果，全部由模型在运行时自主完成。

一句话总结：传统方式下你是Orchestrator-Workers模式的开发者，而在Dynamic Workflows中，你则是该模式的使用者。

动态工作流的运作机制

动态工作流的执行过程大致可分为几个阶段。

1）首先接收任务、制定计划。Claude会分析你的输入，理解任务的规模和复杂度，然后动态生成一份编排方案，决定需要启动多少个子Agent以及每个子Agent的具体职责。这就像接到一个大项目后，技术负责人先评估工作量，再拟定一份招人计划和分工表。

2）计划确定后便进入分发执行阶段。子Agent并行启动，各自处理分配到的子任务。目前系统最多支持同时运行16个并发子Agent，总计上限为1000个。

3）接下来是交叉验证，这是动态工作流的一大亮点。它并非简单地将子任务的结果拼接在一起，而是会安排独立的验证Agent去检查其他Agent的输出。对于高风险任务，甚至会启动“对抗性Agent”，专门尝试寻找漏洞、挑战前面Agent产出的结果。

如果验证未通过，相关的子Agent会被要求进行修正。这个循环会持续进行，直至所有结果达到一致性标准。

是不是很熟悉？没错，这体现了Loop Engineering的思想。之前我们分享过Claude Code官方的循环工程设计理念，其核心就是让AI反复运行、反复修改，直到目标达成。动态工作流将这一思路发挥到了极致，不仅是一个Agent自身循环，而是一群Agent相互验证、相互纠错地协同循环。

4）最终，将验证通过的结果汇总成一份完整的交付物，返回给用户。整个过程中的进度会持续保存，如果任务中途被打断，恢复后可以从断点继续执行，无需从头开始。

此外，还有一个关键设计——这个编排的执行独立于对话上下文。你可以这样理解：主对话窗口是你与“技术负责人”沟通的会议室，而那些子Agent则在各自独立的工位上执行任务。无论有多少并行工作在进行，都不会占用你主对话的空间。因此，无论任务规模多大、涉及多少个子Agent，都不会撑爆Claude的上下文窗口。这正是它能够处理跨越数百个文件的大规模任务的关键所在。

动态工作流实战案例

动态工作流最令人印象深刻的案例来自Ja vaScript运行时Bun的开发者Jarred Sumner。他利用动态工作流将Bun从Zig语言移植到了Rust，整个过程仅用时11天，产出了大约75万行Rust代码，原有测试套件的通过率达到了99.8%。

这个迁移是如何完成的呢？Anthropic官方博客透露了大致流程。

首先，一个工作流负责遍历整个Zig代码库，为每一个结构体的每个字段映射出对应的Rust生命周期标注。这一步需要分析大量的类型关系和所有权语义。

然后，另一个工作流将数百个.zig文件分配给并行的Agent，每个Agent负责将分配到的.zig文件翻译为行为等价的.rs文件。而且，每个文件会安排两个审查Agent来交叉检查翻译结果的准确性。

接下来是修复循环。一个工作流反复执行构建和测试过程，将编译错误和测试失败的结果分发给对应的Agent去修复，直到整个项目能够正常编译并通过测试套件。

最后，一个通宵运行的工作流负责消除不必要的数据拷贝，并为每处优化单独创建一个Pull Request供人工审查。

在整个过程中，人类开发者所做的事情就是定义目标、确认方案、最终审查PR。中间的具体实施工作全部由动态工作流自主完成。

动态工作流是模型能力还是工具能力？

这是一道非常尖锐的面试题：动态工作流究竟是模型自身具备的能力，还是平台工具所提供的功能？答案是两者缺一不可，但职责分工不同。

模型层面提供的是“智能”。例如：任务规划能力，能够将一个模糊的大目标拆解为具体、可执行的子任务；上下文理解能力，能够分析代码库结构，理解各文件之间的依赖关系；工具调用能力，能够正确生成并执行编排脚本；以及自我纠错能力，能够判断子任务的输出是否正确并知道如何进行修复。

这正是动态工作流与Opus 4.8同步发布的原因。Opus 4.8在任务规划和判断力方面有显著提升，其对自己代码中缺陷的检出率是前代模型的4倍。这种自我检验的能力是动态工作流实现“交叉验证”和“对抗性检查”的基础。

平台层面提供的是“基础设施”。例如：子Agent的生命周期管理，包括创建、调度与销毁；并发控制，限制最多16个同时运行；进度持久化，中断后可恢复；上下文隔离，确保编排逻辑不占用主对话的上下文窗口；以及最终的结果聚合与交付。

通过一个类比来理解：模型能力就像一位优秀的技术负责人的大脑，他知道如何拆解任务、如何分配人员、如何验收成果。而平台能力则像一个公司的项目管理系统和基础设施体系，提供了会议室、协作工具、版本控制、持续集成等。光有聪明的大脑而缺乏执行体系不行，光有系统而无人懂得规划也不行。

所以，如果面试官问及这个问题，最准确的回答是：动态工作流是一种建立在强大模型能力基础上的平台产品特性。模型提供规划和决策的智能，平台提供并行执行和生命周期管理的基础设施，两者结合才构成了完整的动态工作流。

和多Agent框架的区别

理解了上述架构分层之后，我们再来审视动态工作流与LangGraph、CrewAI这些多Agent框架的区别，就会变得非常清晰了。

传统多Agent框架的思路是：开发者自行定义Agent的角色和能力，亲手编写编排逻辑，决定哪个Agent先执行、哪个后执行、结果如何传递，异常情况也需自己处理。框架提供了大量现成的模块和连接方式，但具体如何组装完全取决于你。

动态工作流的思路则完全相反：开发者只需描述最终目标，模型便会自动完成角色定义、任务拆解、编排逻辑生成、异常处理以及结果验证。你甚至不需要编写编排代码，因为Claude会自行完成。

这两种方式没有绝对的好坏之分，而是各自适应不同的适用场景。如果你的任务是高度标准化、流程固定的，例如每天定时运行一轮数据分析报告，那么使用传统框架将流程固化会更稳定、更可控、成本也更低。如果你的任务是一次性的、规模庞大、并且子任务不可预测的，例如代码库迁移、安全审计或大规模重构，那么动态工作流的优势便极为显著，因为你根本无法预先定义好所有的子任务和执行路径。

怎么用起来？

动态工作流目前在Claude Code的CLI、桌面端以及VS Code扩展中均可使用，也可以通过API调用。其他AI编程工具也在积极探索类似的多Agent并行模式，例如Cursor推出了Cloud Agents和后台Agent并行能力。不过，目前“由模型自己编写编排脚本”这类功能，Claude Code的动态工作流无疑是做得最为完善、产品化程度最高的。

启动动态工作流的方法非常简单，主要有两种方式。

第一种是直接告诉Claude创建一个工作流，比如：“创建一个工作流，协助我审计整个代码库的安全漏洞。”

第二种是在Claude Code的effort菜单中开启ultracode设置。此设置会将推理力度调整至最高，同时让Claude自动判断当前任务是否适合采用工作流模式。如果适合，它会自动切换到工作流模式。首次触发工作流时，Claude Code会显示即将执行的计划并要求你确认，而不会直接开始执行。

有一点需要特别留意：动态工作流的Token消耗量远超普通的Claude Code会话。道理很简单，你同时雇佣了几十甚至上百个助手来帮你工作，其成本自然高于仅雇佣一个人。因此，建议根据实际需求按需使用，先从小范围的任务开始尝试，感受其消耗量级，再逐步扩大规模，切勿一开始就针对整个代码库进行大规模操作。

最后哔哔

看完这篇文章，你会发现AI应用开发正在从“开发者编排Agent”向“Agent编排Agent”逐步演进。开发者的角色正在向上移动，从编写编排代码的执行者，转变为定义目标和审查结果的管理者。

这一趋势意味着，未来面试AI应用开发岗位时，仅仅会使用框架编写Agent可能已不够，面试官更看重你对整个Agent架构体系的深入理解。Anthropic那篇Building Effective Agents所提出的5种模式，基本上就是这个领域的面试必考知识点，建议反复研读。