Claude Code Dynamic Workflows 功能详解与实用场景

这两天花时间仔细研究了Claude Code新推出的Dynamic Workflows功能。需要先说明，本文并非一次全面的极限压力测试。

真正适合workflows的任务，往往是代码库审计、大规模迁移、复杂方案交叉验证这类场景。这些任务固然能充分展现该功能的上限，但不太适合通过文章来演示——原因有三：一是执行过程过于冗长；二是上下文高度依赖具体项目环境；三是读者很难从截图中捕捉到关键信息。

因此，这次我选了一个相对容易展示的任务：先完成一次技术调研，再基于调研结果生成下一步的workflow。这个任务算不上最复杂，但足以清晰展现Dynamic Workflows的核心运作机制。

初看之下，你可能会认为这只是Claude Code又多开了几个Agent。但实际运行后你会发现，重点并不在于Agent的数量。真正的价值在于：它将复杂任务的中间处理过程，从主对话中剥离了出去。

先说结论：这个功能不是用来修复小bug的。如果只是修改一个函数、解决一个具体的报错、询问一个小问题，直接使用Claude Code即可，无需启动workflows。Dynamic Workflows真正适合的是另一类任务——规模大、流程长、中间资料繁多，且需要多角度相互验证。例如：

• 技术调研
• 代码库审计
• 大规模迁移
• 复杂方案设计
• 发布前检查
• 多角度交叉验证

这次演示的路径如下：首先使用 /deep-research 生成了一份关于Java虚拟线程在Spring Boot生产系统中应用的研究报告，然后基于这份报告，让Claude Code继续生成一个Spring Boot虚拟线程实验项目的workflow。运行完毕后，最大的感受不是“它开启了多少个Agent”，而是：它将一个复杂任务的流程，编写成了可运行、可观察、可保存的JS脚本。这件事的意义远远超过“多开几个Agent”。

为什么已经有了Subagent、Skills、Agent Teams，还需要Workflows？

这个问题非常关键。因为Claude Code此前已经提供了Subagent和Agent Teams，许多人第一次见到Dynamic Workflows时，可能会觉得：这不就是又多开了几个Agent吗？

并非如此。它们解决的问题各不相同。

可以这样简单理解：

再浓缩成一句话：Subagent解决的是“派谁去干一小块”；Skills解决的是“以后按什么方法干”；Agent Teams解决的是“多个角色如何协作”；Dynamic Workflows解决的是“整个复杂任务如何被编排、保存和重复执行”。

Subagent的价值在于，让子任务不污染主对话。比如你让它搜索支付模块的相关代码，它会自行读取文件、执行命令、整理结果，最后将摘要带回。Skills的价值在于，将一套固定的做法沉淀下来。例如写公众号文章，可以拥有自己的写作skill，规定先检索、再出大纲、再写初稿、再进行多角色审阅。Agent Teams的价值在于，让多个角色协同工作——一个Agent负责后端，一个Agent负责前端，一个Agent负责测试，一个Agent负责汇总。它更像一个小团队，核心在于角色分工和相互反馈。

而Dynamic Workflows则更进一步。它不仅仅是派遣一个Agent，也不是仅仅给Claude一份说明书，更不是单纯让几个Agent互相协作。它是将流程本身编写进JS脚本里。脚本负责：划分阶段、每个阶段派遣哪些Agent、哪些任务可以并行执行、哪些任务必须等待前置结果、每一步的结果如何传递给下一步、最后如何汇总。这就是workflows的新价值——不是“又多了一个Agent”，而是“流程本身可以被执行”。

它真正解决的，是主对话难以承载的问题

Dynamic Workflows最值得单独探讨的一点，是上下文管理。以往在执行复杂任务时，一个常见的问题是：Claude Code一路搜索、读取文件、分析、总结，所有中间过程都堆积在当前对话中。开始时思路清晰，越往后信息越多，上下文越来越混乱，后续再追问时，它可能已经开始产生混淆。

Dynamic Workflows的机制则不同。它生成的是一个JS脚本，该脚本在隔离的运行环境中执行。中间结果存储在脚本变量里，而不是将大量中间过程塞入Claude Code当前的主对话。这意味着：每个Agent搜索到的资料、阶段分析结果、交叉验证结果、临时JSON数据，都不需要一股脑地涌入你的主对话——主对话最终只接收收敛后的结果。普通对话是在不断消耗主上下文，而workflow则是将中间结果保存在脚本变量中。

这正是它适合处理繁重任务的原因。因为许多复杂任务真正的难点，不在于“模型不会思考”，而在于中间过程过多，导致上下文被挤爆。Workflows解决的不仅是并行问题，还有上下文污染问题。这并不意味着workflow不消耗token——每个Agent自身仍然会消耗上下文和token。区别在于，它不会将所有中间过程都倒灌回你当前的主对话中。

这里也需要理解一个边界：workflow脚本本身不直接读写文件，也不直接执行shell命令。它主要负责调度。真正执行读文件、改代码、运行命令操作的是它所派遣的Agent。你可以将workflow理解为一个在隔离环境中运行的项目计划——它不亲自执行每个动作，但它决定谁先做、谁后做、谁等待谁、结果存放在哪里。

如何触发它，不是重点，但需要先了解

在Claude Code中输入：/config，找到 Dynamic workflows。只要此处设置为 true，就代表可以使用动态工作流。

然后可以执行：/effort ultracode，开启后，Claude Code会根据你的任务自动判断是否需要使用workflow。除了 ultracode，还有一个更直接的触发方式：在提示词中输入 workflow 或 workflows，一旦该词变为彩色，就说明这次请求将触发workflow。

第一类适合 workflows 的任务：复杂技术调研

Claude Code内置了一个workflow：/deep-research。我用它研究了一个比较工程化的问题：Java虚拟线程在Spring Boot生产系统中的适用边界和潜在风险。启动后，它会自动进入workflow模式。

这份报告超过1000行。阅读完毕后，我认为它并非那种泛泛而谈的科普内容。判断 /deep-research 是否有价值，不是看它写了多少字，而是看它是否挖掘出了真实工程中可能踩坑的地方。它覆盖了以下要点：

• 虚拟线程、传统线程池、Reactor/Netty之间的差异
• Java 21和Java 24在pinning问题上的关键区别
• spring.threads.virtual.enabled=true 开启后对Spring Boot的影响
• Tomcat、Jetty、@Async、@Scheduled 的执行变化
• JDBC和HikariCP在虚拟线程下的性能瓶颈
• 如何通过JFR观察 jdk.VirtualThreadPinned
• 老Java Web项目如何分阶段迁移
• 灰度发布和回滚策略

其中有一个判断非常关键：虚拟线程并不意味着数据库能处理更多查询。如果请求线程不再是瓶颈，那么HikariCP、数据库连接数、下游服务限流反而会变成更明显的瓶颈。这类结论对Java后端开发者来说具有很高的参考价值。

对 /deep-research 的评价是：它非常适合制作高质量的调研底稿。特别是那些资料分散、需要多角度搜索、还需要互相校验的主题。以往让一个Agent做这类调研，很容易出现两个问题：一是资料搜得过多，主对话被撑满；二是前面搜索到的内容，后面可能无法被很好地组织起来。/deep-research 这种workflow更适合这类任务，因为它天然就是先分角度搜索，再交叉验证，再过滤掉不可靠的说法，最后生成一份收敛的报告。

但我不建议将其视为最终结论。例如虚拟线程这类问题，报告可以告诉你风险点在哪里、应该如何进行压力测试、应该关注哪些指标，但性能结论、连接池瓶颈、生产环境风险，最终还是需要依靠自己的实验来验证。因此，我会把 /deep-research 当作研究助理，而不是最终决策者。

长任务最怕黑盒，/workflows 解决了这个问题

workflow开始运行后，可以输入 /workflows 查看当前和历史workflow。多Agent并不可怕，看不见多Agent在做什么才真正可怕。

进入具体的workflow后，可以看到不同的阶段。每个阶段中有多少个Agent、使用了多少token、运行了多长时间，都能一览无余。这里顺便说明一下，截图中能看到当时是在Claude Code里接入GPT模型进行测试，这仅仅是测试环境，并非本文的重点。真正需要关注的，是Dynamic Workflows这套任务编排机制。

你可以使用键盘的上下左右方向键选择不同的阶段或不同的Agent。进入某个Agent后，可以查看它的运行详情。如果某个Agent尚未开始，也能看到它处于等待状态。部分内容默认会折叠，按回车键可以展开。

这部分体验非常关键。因为多Agent最怕的就是黑盒——你只看到它在运行，但不知道各个Agent具体在做什么。/workflows 至少让你能够看到：当前运行到哪个阶段、哪些Agent已经完成、哪些Agent仍在等待、某个Agent具体接收了什么任务、它最终返回了什么结果。这对于长任务至关重要。以前你只能相信“它正在忙”，现在你至少能看见“它到底在忙什么”。

第二类适合 workflows 的任务：将一次经验沉淀为流程

完成Java虚拟线程研究报告后，我继续测试：能否基于刚才的报告，再生成一个实验项目的设计workflow？在提示词中带上了 workflow，关键词变色后，它便开始创建新的workflow。进入详情后，可以看到新的工作流阶段。继续保存workflow后，项目路径下多了两个JS脚本文件。

打开其中一个相对简单的脚本查看，大致结构如下：

phase('Analyze')constanalysis = awaitagent(`读取研究文档，并分析要实现的 Spring Boot 虚拟线程实验项目需求`, {label:'analyze-research-doc',phase:'Analyze',agentType:'Explore',schema: { type:'object', properties: {endpoints: {type:'array',items: {type:'string'} },profiles: {type:'array',items: {type:'string'} },metrics: {type:'array',items: {type:'string'} },scripts: {type:'array',items: {type:'string'} },implementationNotes: {type:'array',items: {type:'string'} },risks: {type:'array',items: {type:'string'} }} }})phase('Design')constdesign = awaitagent(`基于上面的分析，设计一个可执行的项目蓝图`, {label:'design-project-blueprint',phase:'Design'})return{ analysis, design }

这个脚本很有启发性。第一阶段名为 Analyze，它会派遣一个Agent去读取刚才的研究报告，提炼出端点、profiles、指标、脚本、实现建议和风险点。第二阶段名为 Design，它会基于第一阶段的 analysis 变量，继续派遣另一个Agent设计项目蓝图。

请注意这里的关键点：analysis 并未塞入主对话，而是作为workflow脚本中的变量。第二个Agent可以直接使用这个变量继续工作，最后再统一 return { analysis, design }。这正是前文提到的，Dynamic Workflows的真正价值在于：中间结果被脚本妥善保存，而不是每一步都向主对话中倾倒。因此，它非常适合“步骤多、中间产物多、最终只需一个结果”的任务。

真正有价值的是：它可以保存为项目资产

进入 /workflows 后，可以按 s 键保存workflow，默认保存到项目scope。按Tab键可以切换保存位置。项目scope适合团队共享——比如某个仓库中经常需要进行发布前检查，就可以保存一个项目workflow。个人scope适合个人跨项目复用——比如经常进行技术调研、代码审计、迁移评估，就可以保存成自己的workflow。

这一步非常关键。因为prompt最大的问题在于一次性的使用效果——你这次写得很出色，下次可能就忘了如何复现。而workflow保存下来之后，它更像一个可复用的脚本，未来可以直接运行，也可以打开进行修改。这就从“对话技巧”转变成了“流程资产”。

到底该用来做什么？

回到标题。Claude Code新推出的Dynamic Workflows，到底应该用来处理什么任务？

我的判断是：用来处理那些主对话难以承载的繁重任务。

什么情况下主对话无法承载？第一，中间过程过多。例如调研一个复杂的技术主题，需要查阅大量资料，从多个角度进行分析，还需要相互校验。第二，任务可以拆解。比如代码库审计，可以按模块拆解；迁移评估，可以按入口、数据、任务、测试拆解；实验设计，可以按需求、架构、配置、脚本、验证拆解。第三，结果需要复核。比如安全审计、性能风险评估、生产迁移方案，都不适合单Agent一次性通过。第四，流程值得复用。比如每个项目都需要进行发布前检查，每次大改动都需要进行风险扫描，每次技术选型都需要进行资料交叉验证。

这类任务就适合使用workflows。相反，以下任务则不适用：

• 修改一个小bug
• 询问一个小问题
• 调整一段文案
• 修改一个具体的函数
• 需要你每一步都确认的任务

一个简单的判断标准：任务越容易拆解、过程越长、结果越需要校验、流程越值得复用，就越适合使用Dynamic Workflows。

最后

那么，Dynamic Workflows到底应该用来做什么？答案很明确：不要用它来处理小任务。用它来处理那些上下文会膨胀、步骤会混乱、结果需要复核、流程还值得下次复用的繁重任务。小任务不要使用workflows，繁重任务则不要再手动编写提示词。

这也是本次实测之后，我认为它值得单独撰写一篇文章的原因。