Claude Code 本次发布的 Workflow 是什么？有哪些场景值得用？

公众号名称：阿南的技术手记

作者名称：j5land

发布时间：2026-06-01 08:00

最近Claude Opus 4.8 发布，同时Claude Code 也一起更新了，发布了新特性 Dynamic Workflows，它不是一个简单的功能，而是一种处理大任务的方式

当然，如果只是一个很小需求使用简单对话就完全够用了，但一旦换成大型任务，比如：代码库进行安全审计、代码库比如ios翻译成安卓，类似的任务只主对话上下文很快就会变得拥挤、上下文爆炸

本次更新的 workflows 的处理方式比较直接：首先会让 Claude 先写一段 JavaScript workflow 脚本，再由脚本在后台调度一批 Agent，在主对话不用反复接收中间过程，而是只等整理过的结果。

表面看是多开 Agent进行编排，更大的变化在任务计划的位置：编排从聊天窗口，搬到了脚本里来控制

一句话说清楚底层逻辑

我会把 workflows 理解成一种可落盘的任务脚本

我只需要把任务和约束说清楚，Claude 会先生成一段 JavaScript 脚本，再由脚本去拆任务、调 subagent、汇总结果。中间执行过程不会一直刷进主对话，主线程只保留最后整理好的输出。

这和临时 prompt 最大的区别是：workflow 可以放到项目的 .claude/workflows/ 里。下次做类似的代码审计、技术调研、方案评审时，我不用重新组织一大段 prompt，只要改一改脚本就能继续跑，团队里其他人也能复用同一套流程

所以我对它的理解很简单：脚本负责流程，Agent 负责执行

装修房子的比喻

我用装修来理解这几种能力。

普通多轮对话像盯着一个师傅干活，改函数、补测试、追报错，直接说清楚就够了

Skill 像施工手册，把规则、步骤、验收标准写好，让师傅同类任务每次按同一套方式执行

Subagents 像临时多叫几个师傅并行干活，它解决的是“多几双手”，但流程和结果合并还得我来判断与指定

Agent Teams 像带领班的施工队，适合多角色一起校准，比如前端、后端、测试、架构、安全一起看一个方案

Workflow 更像施工流程图：顺序、返工、验收都写进脚本里，Agent 负责执行，流程本身可以保存和复用

如何区分使用也比较简单：小需求直接聊；稳定工作沉淀成 Skill；在并行任务用 subagents；多角色讨论用 Agent Teams；要分阶段、复核、复用大型任务，再用 Dynamic Workflows

什么时候该用 workflow

日常小改动，根本用不上 workflow

它有启动成本，也更耗 token，适合处理流程本身就很重要的任务

在 workflow 之前，我一般会先看能不能用 Skill 解决。比如 PR review 看哪些点、发版前跑哪些检查、性能问题先查哪些日志、数据库变更要补哪些字段，这些都更适合写进 SKILL.md

Skill 解决的是“别忘步骤”。Claude 还是在主对话里做事，只是会按团队约定执行。如果任务一个人顺着做就能完成，只是希望过程更稳定，用 Skill 就够了

但如果任务变成了枚举、分组、并行检查、二次复核、去重汇总，那就更适合 workflow

研究类任务也类似，Claude Code 的 /deep-research 本身就是一个 workflow：多方向收集资料，交叉检查关键断言，最后输出带引用的报告。技术选型、竞品分析、方案调研，都可以借这个思路

需要多阶段、多视角、可复核，并且下次可能还要跑，就考虑 workflow，只做一次的小任务，别把工具用重了

怎么启动

官方文档要求 Claude Code v2.1.154 或更高版本。Pro 用户还需要在 /config 里打开 Dynamic workflows。如果要用 /deep-research，还要确认 WebSearch 可用。

想先感受一下，可以先跑官方内置的 deep research：

/deep-research Java 8 到 Java 20 之间有哪些主要变化？按版本归纳，并补充来源。

自己触发 workflow 也不复杂。最直接的办法，是在 prompt 里明说这次要跑 workflow：

请运行一个 workflow，审计 src/routes/ 下所有 API endpoint 是否缺少鉴权检查。
返回文件路径、endpoint 名称、代码证据、严重级别和建议修复方式。
没有代码证据的结论不要报告。

这句话的作用就是把执行方式说死：这次不要在主对话里一点点查，直接生成 workflow 来跑。

另一种办法是把 effort 调高：

/effort ultracode

Ultracode 会让 Claude 自己判断要不要用 workflow。复杂请求可能会拆出不止一个 workflow，比如先理解代码，再执行修改，最后验证结果。它省心，但也更贵。小改动做完后，记得切回 /effort high。

怎么看进度，怎么保存

workflow 启动后，用 /workflows 看进度。

这个界面会列出当前会话里正在跑和已经跑完的 workflows。点进去还能看某个 phase、某个 agent 的 prompt、工具调用和结果。

实际用起来，先记住几个键就够了：p 暂停或恢复，x 停止，r 重启正在运行的 agent，s 保存 workflow 脚本。

比如一个安全审计 workflow，第一阶段可能只是扫描，下面挂几个子 Agent；第二阶段才做验证，要等扫描结束后再分配。按 p 暂停以后，只要还在同一个 Claude Code 会话里，就可以继续跑，已经完成的 Agent 结果会被缓存下来。

不过退出 Claude Code 以后，运行状态不会原样保留。想长期复用，就要保存脚本。保存到 .claude/workflows/，它属于当前项目，可以跟着仓库走；保存到 ～/.claude/workflows/，它就是你个人的常用命令。保存之后，workflow 会像 slash command 一样出现。

一次好 prompt 只是这次聊得顺。能保存、能复跑、能让团队一起用，才算真正沉淀下来。

Prompt 要写得像任务合同

workflow prompt 不要写成“帮我全面审计一下”。这种说法太宽，Claude 会自己补很多细节，最后结果也容易发散。

我一般会把目标、范围、阶段和证据要求提前写清楚，比如：

请为下面的研发任务运行一个 workflow：

目标：审计订单服务里的接口鉴权是否完整，输出可进入修复排期的问题清单。

范围：
- 只检查 services/order/src/routes、services/order/src/controllers、services/order/src/middleware。
- 排除 tests、mock、generated 目录。

阶段：
1. 枚举所有 HTTP endpoint，记录路由、handler 和调用链入口。
2. 按业务模块分组，检查是否经过 auth、permission、tenant 校验。
3. 对可疑发现做二次复核，必须回到代码证据。
4. 合并重复问题，按影响面和可利用性分级。

输出：
- 使用 Markdown 表格。
- 字段包含：模块、endpoint、文件路径、handler、证据行、风险说明、严重级别、建议修复方式。

规则：
- 没有代码证据不要报告。
- 不要修改代码，只做审计报告。
- 不确定的结论放入「需要人工确认」。

这个模板的重点不是格式，而是先把边界钉住。

目标 决定方向，范围 限制扫描边界，阶段 固定执行顺序，规则 用来挡住没证据的结论。

我不需要自己写 JavaScript，只需要把任务讲细一点。任务越清楚，Claude 生成 workflow 脚本时自由发挥就越少。

边界和成本

Dynamic Workflows 不是无限并发机器。

官方限制是：单次 run 最多 16 个并发 Agents，总 Agent 数最多 1000 个。

它可以在一次任务里调度几十到上百个 Agent，但不会同一瞬间无限并发。workflow 脚本也不是直接操作层，不读写文件，不跑 shell，只负责协调；真正干活的是被调度出去的 Agent。

还有一个限制容易被忽略：workflow 不适合中途频繁问你意见。官方文档说明，run 过程中没有普通的用户输入节点，只有权限提示可能暂停。要是你希望“第一阶段结束后我先确认，再进入第二阶段”，最好拆成两个 workflow。

成本也要提前算。一个 workflow 会启动很多 Agent，每个 Agent 都会消耗当前 session 的模型 token。除非脚本把简单阶段路由到更便宜的模型，否则账单会很快变厚。

跑大任务前，先看一眼 /model，再确认 shell、WebFetch、MCP 这些工具权限有没有放开。长任务跑到一半才卡在 allowlist 上，会很影响节奏。

这个功能该怎么看

Dynamic Workflows 更适合大型任务，尤其是那种一放进主对话就会有上下文压力的任务。

它看起来像 Skill + subagent 的组合，但本质不一样。Skill 让 Claude 按固定规则做事，subagent 负责把局部任务拆出去执行，而 workflow 是把整套执行计划写进脚本里：怎么拆、怎么并行、怎么复核、怎么汇总，都由脚本来控制。

这也是它和普通多 Agent 最大的区别。普通对话里，Claude 还在主线程里一边判断、一边调度，中间结果会不断挤进上下文；workflow 则把中间状态留在运行时里，主对话只接最后整理过的结果。

所以 workflow 主要解决的不是多Agent编排，而是让复杂任务有一套可保存、可检查、可复跑的执行流程。

我的理解是：小任务用 prompt，稳定规则用 Skill，局部并行用 subagent；当任务大到需要分阶段、控上下文、交叉复核，并且下次还可能再跑时，才是 workflow 的主场。

参考资料

Anthropic: Introducing Claude Opus 4.8
https://www.anthropic.com/news/claude-opus-4-8
Claude Code Docs: Orchestrate subagents at scale with dynamic workflows
https://code.claude.com/docs/en/workflows
Claude Code Docs: Run agents in parallel
https://code.claude.com/docs/en/agents
Claude Code Docs: Orchestrate teams of Claude Code sessions
https://code.claude.com/docs/en/agent-teams

cover_image

原创 j5land 阿南的技术手记

内容效果不满意？点此反馈