大家好，我是程序员鱼皮。
Anthropic 在 5 月底发布 Claude Opus 4.8 的时候，同步推出了 Claude Code 的 动态工作流 功能。
有人用它 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 的上下文窗口。这是它能处理跨越数百个文件的大规模任务的关键。
动态工作流实战案例
动态工作流最震撼的案例来自 JavaScript 运行时 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 的角色和能力，自己编写编排逻辑决定谁先执行、谁后执行、结果怎么传递，异常情况也要自己处理。框架给你提供了一堆现成的模块和连接方式，但具体怎么组装是你的事。
动态工作流的思路完全相反，开发者只需要描述最终目标，模型自动完成角色定义、任务拆解、编排逻辑生成、异常处理和结果验证。你连编排代码都不用写，因为 Claude 自己会写。
这两种方式没有绝对的好坏之分，适用场景不同。
如果你的任务是高度标准化的、流程固定的，比如每天定时跑一轮数据分析报告，用传统框架把流程写死会更稳定、更可控、成本更低。
如果你的任务是一次性的、规模大的、子任务不可预测的，比如代码库迁移、安全审计、大规模重构，动态工作流的优势就很明显了，因为你根本没法提前定义好所有的子任务和执行路径。
怎么用起来？
动态工作流目前在 Claude Code 的 CLI、桌面端和 VS Code 扩展中都可以使用，也可以通过 API 调用。
其他 AI 编程工具也在探索类似的多 Agent 并行模式，比如 Cursor 推出了 Cloud Agents 和后台 Agent 并行能力。不过目前「由模型自己编写编排脚本」这种玩法，Claude Code 的动态工作流是做得最完整、产品化程度最高的。
启动动态工作流的方法非常简单，有 2 种方法。
第一种是直接告诉 Claude 创建一个工作流，比如：
创建一个工作流，帮我审计整个代码库的安全漏洞
第二种是在 Claude Code 的 effort 菜单里开启 ultracode 设置。这个设置会把推理力度调到最高，同时让 Claude 自动判断当前任务是否适合用工作流来处理。如果适合，它会自动切换到工作流模式。
第一次触发工作流时，Claude Code 会显示即将执行的计划并要求你确认，不会直接就跑起来。
有一点需要注意，动态工作流的 Token 消耗量远超普通的 Claude Code 会话。道理很简单，你同时雇了几十上百号人帮你干活，工资当然比只请一个人贵得多。
所以建议按需使用，先从一个小范围的任务开始试，感受一下消耗量级，再逐步扩大规模，别上来就对着整个代码库一把梭。
最后哔哔
看完这篇文章，你会发现 AI 应用开发正在从「开发者编排 Agent」向「Agent 编排 Agent」演进。开发者的角色在往上移，从写编排代码的执行者，变成定义目标和审查结果的管理者。
这个趋势意味着，以后面试 AI 应用开发岗位，光会用框架写 Agent 可能不够了，面试官更想知道你对整个 Agent 架构体系的理解有多深。Anthropic 那篇 Building Effective Agents 提出的 5 种模式，基本就是这个领域的面试必考知识点，建议反复读。我的 面试刷题神器《面试鸭》 上也整理了不少 AI 应用开发面试题，覆盖了 LangChain、RAG、多智能体协作这些方向，尤其建议找工作的朋友刷一刷。
我是鱼皮，持续分享 AI 编程和 AI 应用开发的干货。觉得有用的话记得点赞收藏和关注~
也欢迎在评论区聊聊，你有没有用过动态工作流？跑一次花多少钱的 Token？