Claude Code 新推出的 Dynamic Workflows 功能，将复杂任务的中间过程从主对话中剥离出去，通过 JS 脚本实现任务编排、结果传递和流程复用。这不是"多开几个 Agent"，而是流程本身可以被执行、保存和复跑。

本文通过实测，拆解 Dynamic Workflows 的核心机制、适用场景以及与 Subagent、Skills、Agent Teams 的区别。

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

很多人第一次看到 Dynamic Workflows，可能会觉得这不就是又多开几个 Agent 吗？不是。它们解决的问题不一样：

一句话总结：Subagent 解决"派谁干一小块"；Skills 解决"以后按什么方法干"；Agent Teams 解决"多个角色怎么协作"；Dynamic Workflows 解决"整个复杂任务怎么被编排、保存和复跑"。

Subagent 的价值是让子任务不污染主对话；Skills 的价值是把固定做法沉淀下来；Agent Teams 的价值是让多个角色协作。而 Dynamic Workflows 往前走了一步——它把流程本身写进 JS 脚本里。

脚本负责：分几个阶段、每个阶段派哪些 Agent、哪些任务可以并行、哪些任务必须等待前置结果、每一步结果怎么传给下一步、最后怎么汇总。这就是 workflows 的新价值。

它真正解决的，是主对话扛不住的问题

以前做复杂任务，一个很常见的问题是：Claude Code 一路搜索、读文件、分析、总结，所有中间过程都往当前对话里堆。刚开始还挺清楚，越往后信息越多，上下文越来越脏，后面你再追问，它可能已经开始混乱了。

Dynamic Workflows 的机制不一样。它生成的是一个 JS 脚本，在隔离的运行环境里执行。中间结果放在脚本变量里，而不是把大量中间过程塞进 Claude Code 当前主对话。也就是说，每个 Agent 搜到的资料、阶段分析结果、交叉验证结果、临时 JSON 数据，不需要一股脑进入你的主对话，主对话最后只需要接收收敛后的结果。

这就是它适合重活的原因。因为很多复杂任务真正难的，不是"模型不会想"，而是中间过程太多，把上下文挤爆了。Workflows 解决的不只是并行问题，还有上下文污染问题。

苏米注：workflow 脚本本身不直接读写文件，也不直接执行 shell，它主要负责调度。真正读文件、改代码、跑命令的是被它派出去的 Agent。可以把 workflow 理解成一个在隔离环境里运行的项目计划——它不亲自执行每个动作，但它决定谁先做、谁后做、谁等谁、结果放哪里。

怎么触发 Dynamic Workflows

在 Claude Code 里输入 /config，找到 Dynamic workflows，确保这里设为 true。

然后在提示词里输入 workflow 或 workflows，只要这个词变成彩色，就说明这次请求会触发 workflow。

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

Claude Code 里内置了一个 workflow：/deep-research。用它研究了一个比较工程化的问题：Java 虚拟线程在 Spring Boot 生产系统里的适用边界和风险。

生成的报告超过 1000 行，覆盖了这些关键工程点：

• 虚拟线程、传统线程池、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 很适合做高质量调研底稿，特别是那种资料分散、需要分角度搜索、还要互相校验的主题。但也不要把它当成最终结论——性能结论、连接池瓶颈、生产风险，最后还是要靠自己的实验验证。把它当成研究助理，不是拍板的人。

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

workflow 跑起来后，可以输入 /workflows 查看当前和历史 workflow。多 Agent 不可怕，看不见多 Agent 在干什么才可怕。

进入具体 workflow 后，可以看到不同阶段。每个阶段里有多少 Agent、用了多少 token、跑了多久，都能看到。

可以用键盘方向键选择不同阶段或不同 Agent。进入某个 Agent 后，可以看到它的运行详情。

按回车可以展开折叠的内容，查看完整的执行过程。

这部分体验很关键。因为多 Agent 最怕的就是黑盒——你只看到它在跑，但不知道谁在干什么。/workflows 至少让你能看到：现在跑到哪个阶段、哪些 Agent 已经完成、哪些 Agent 还在等待、某个 Agent 具体拿到了什么任务、它最后返回了什么结果。这对长任务很重要。

第二类适合 workflows 的活：把一次经验沉淀成流程

做完 Java 虚拟线程研究报告后，继续测试：能不能基于刚才的报告，再生成一个实验项目设计 workflow？

在提示词里带上 workflow，关键词变色后就开始创建新的 workflow。进入详情后，可以看到新的工作流阶段。

保存 workflow 后，项目路径下多了两个 JS 脚本文件。

打开其中一个脚本，结构大致如下：

phase('Analyze')
const analysis = await agent(`读取研究文档，并分析要实现的 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')
const design = await agent(`基于上面的分析，设计一个可执行的项目蓝图`, {
  label: 'design-project-blueprint',
  phase: 'Design'
})

return { analysis, design }

第一阶段叫 Analyze，派一个 Agent 去读研究报告，提炼端点、profiles、指标、脚本、实现建议和风险。第二阶段叫 Design，基于第一阶段的 analysis 变量，继续派另一个 Agent 设计项目蓝图。

关键在这里：analysis 不是塞进主对话里，它是 workflow 脚本里的变量。第二个 Agent 可以直接使用这个变量继续工作，最后再统一 return { analysis, design }。

真正值钱的是：它可以保存成项目资产

进入 /workflows 后，可以按 s 保存 workflow。默认保存到项目 scope，适合团队共享——比如某个仓库里经常要做发布前检查，就可以保存一个项目 workflow。

也可以按 Tab 切换到个人 scope，适合自己跨项目复用——比如经常做技术调研、代码审计、迁移评估，就可以保存成自己的 workflow。

这一步很关键。因为 prompt 最大的问题是一次性的——你这次写得很好，下次可能就忘了怎么写。而 workflow 保存下来之后，它更像一个可复用脚本，以后可以直接运行，也可以打开改。这就从"对话技巧"变成了"流程资产"。

到底该用来干什么？

Claude Code Dynamic Workflows 适合处理那些主对话扛不住的重活：

• 中间过程太多——调研复杂技术主题，需要查很多资料，分很多角度，还要互相校验
• 任务可以拆——代码库审计按模块拆，迁移评估按入口、数据、任务、测试拆
• 结果需要复核——安全审计、性能风险、生产迁移方案，不适合单 Agent 一遍过
• 流程值得复用——每个项目都要做发布前检查，每次大改动都要做风险扫描

反过来，这些任务不适合 workflows：改一个小 bug、问一个小问题、调整一段文案、改一个具体函数、需要你每一步都拍板的任务。

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

总结：别拿它处理小活，拿它处理那些上下文会爆、步骤会乱、结果需要复核、流程还值得下次复用的重活。小活别用 workflows，重活别再手搓提示词。