Claude Code 动态工作流详解：当 AI 自己写脚本指挥上百个分身干活

上周有个朋友给我发消息："Claude Code 不是早就能开 subagent 了吗？现在这个 workflow，不就是一次多开几个分身嘛，有啥新鲜的？"

我反问他："你有没有试过让 Claude 一次审计整个代码库的安全漏洞？"

他说："试过啊，开了几个 subagent 并行找。但找着找着它就'忘事'了——后面的发现把前面的挤出了上下文，最后给我的报告漏了一半。"

"对，"我说，"这就是关键。subagent 是 Claude 亲自带的几个分身，所有分身的汇报都得塞进它自己的脑子里。脑子就那么大，分身一多就装不下。而 workflow，是 Claude 写了一个脚本，让脚本去指挥这些分身——它自己只看最后那份汇总好的结论。"

他愣了一下："等等……所以 AI 现在是自己写代码来管理自己的分身？"

"差不多。而且这不是几个分身，是几十到几百个。"

2026 年 5 月 28 日，Anthropic 随 Claude Opus 4.8 一起，给 Claude Code 上线了一个叫动态工作流（Dynamic Workflows）的功能。它把"AI 干活"这件事，从"一个聪明人埋头硬扛"，变成了"一个项目经理写好流程、调度一整个团队"。今天我就带你把这个东西从里到外拆一遍——它解决什么问题、脚本长什么样、怎么跑起来，以及我自己踩过的那些坑。

---

一、它到底解决了什么问题？

先说一个反直觉的事实：限制 AI 干大活的，从来不是它"不够聪明"，而是它的上下文窗口——也就是它的"工作记忆"。

你可以把 Claude 想象成一个超级聪明、但只有一张办公桌的人。桌子再大也有限。让它做小事——改个 bug、写个函数——绰绰有余。可一旦任务变成"把这个 500 个文件的项目从 Vue 2 迁移到 Vue 3"，桌子立刻就堆爆了：第 480 个文件的改动还没处理完，前面 470 个文件的细节早被它从桌上挤掉了。

过去的解法是开 subagent（子代理）。Claude 派几个分身出去并行干活，每个分身有自己的桌子。听起来很美。但问题在于——分身干完活，得回来汇报，汇报内容还是堆在 Claude 自己那张主桌上。分身越多,主桌堆得越快。本质上没逃出"工作记忆有限"这个魔咒。

workflow 的破局点,在于它换了个思路:既然 Claude 的脑子装不下这么多过程,那就别往它脑子里装。

它让 Claude 先写一段 JavaScript 脚本,把"先干什么、再干什么、谁验证谁、中间结果存哪"全都写进代码变量里。然后一个独立的运行时(runtime)在后台执行这段脚本,几十上百个分身的中间产物全都待在脚本变量里,压根不经过 Claude 的脑子。Claude 只在最后,收到一份已经整理、去重、交叉验证过的结论。

这个差别有多大?官方给的数据是:单次 workflow 运行可以协调几十到几百个并行分身,处理那种"过去要花几周、甚至按季度算"的工程任务。代码库级别的全量 bug 扫描、跨几千个文件的框架迁移、需要互相印证来源的深度研究——这些原来一个会话根本扛不动的活,现在能在一次运行里端到端跑完。

所以你看,workflow 不是"subagent 的豪华套餐"。它是换了一种把计划交给代码、而不是交给记忆的干活方式。记住这句话,下面的一切都好理解了。

二、一个 workflow 长什么样？

讲了半天"脚本",那这脚本到底长啥样?别担心,你不用自己写——Claude 帮你写。但你得看懂它,才知道它在替你调度什么。

一个 workflow 脚本,核心就靠几个"积木函数"搭起来。我挑最重要的三个给你讲透。

第一个是 agent()。这是最小单位,意思是"派一个分身去干一件事"。你给它一段提示词,它返回干完的结果。如果你想要结构化的数据(而不是一段大白话),还能给它一个 schema,分身就会被强制按照这个格式吐结果——省去了你解析文本的麻烦。

第二个是 parallel()。意思是"这一批分身一起上,我要等他们全部干完再继续"。它像一道闸门:所有人到齐了,闸门才开。适合那种"必须集齐所有结果才能下一步"的场景,比如先把所有发现汇总去重,再统一验证。

第三个,也是最妙的,叫 pipeline()。它是"流水线":每个任务各自独立地走完所有工序,工序之间没有闸门。A 文件已经在做第三道工序了,B 文件可能还在第一道。谁也不用等谁。

光说有点抽象,我画给你看。下面是官方内置的 /deep-research(深度研究)工作流的真实骨架——它就是用这几个积木搭的:

翻译成大白话:它先把你的问题拆成几个搜索角度,并行去搜;搜到的网页一边抓取一边去重;然后每一条声明都派 3 个独立分身去"挑刺",得有 2 个分身都说"这条不靠谱"才把它毙掉;最后,只有活下来的、带引用出处的结论,才汇成一份报告交到你手上。

看到那个"3 票否决"了吗?这才是 workflow 真正的杀手锏——它不只是"人多力量大",而是能把一套质量保证流程固化进代码。让独立的分身互相对抗审查,比单个 AI 一遍过的结果,可信度高得多。

所以,一个 workflow 长什么样?它长得像一条你能读、能改、能重跑的生产流水线。AI 不再是给你表演"一气呵成",而是给你一张可审计的工序图。

三、subagent、skill、workflow 到底怎么选？

到这你可能有点懵:Claude Code 里能"多步干活"的东西好几个——subagent、skill、还有现在的 workflow。它们到底啥区别,我该用哪个?

官方文档里有一句话点破了天机:区别在于"谁拿着那份计划"。

我给你打个比方。假设你要办一场婚礼。

subagent,就像你临时叫了几个朋友帮忙:"你去订花,你去联系酒店。"每个人办完都回来跟你汇报,下一步派谁、干什么,全由你当场临时决定。灵活,但你脑子得一直转着,事一多就乱。

skill,就像你手里拿了一本《婚礼筹备手册》。手册告诉你"第一步做什么、第二步做什么",你照着做。计划是写死的指令,但执行还是你一个人盯着,中间结果还是堆在你脑子里。

workflow,则像你雇了一个婚礼策划师,并且把整套流程写成了一份可执行的合同。合同里写明:订花和订酒店同时进行,花到了再插花,三个验菜员独立验收……策划师拿着这份合同去调度一整个团队,你只在最后收到"一切就绪"的通知。

维度	subagent 子代理	skill 技能	workflow 工作流
本质是什么	Claude 派出的工人	Claude 遵循的指令	运行时执行的脚本
谁决定下一步	Claude，一回合一回合地定	Claude，照着提示走	脚本自己定
中间结果存哪	Claude 的上下文	Claude 的上下文	脚本变量里
规模量级	每回合几个	同 subagent	每次几十到几百个
中断后	整个回合重来	整个回合重来	同会话内可断点续跑

看这张表,你应该能立刻判断了:

任务小而灵活、几个分身就够、需要 Claude 边想边调整?用 subagent。任务有固定套路、希望 Claude 每次都按你定的规矩来?用 skill。任务规模大到一个脑子装不下,或者你想把这套编排沉淀成能反复重跑的资产?那就是 workflow 的主场。

所以选择题的答案,从来不是"哪个最强",而是"谁该拿着计划"。任务越大、越需要可复现,就越该把计划从 AI 的记忆里,搬进代码里。

四、怎么把它跑起来？

原理讲透了,该上手了。好消息是:你不需要会写 JavaScript。触发一个 workflow,有三种姿势,从简单到进阶。

姿势一:直接喊一个内置的

最快感受 workflow 的方式,是跑官方内置的 /deep-research。给它一个问题,它就在后台帮你把上一节那条五阶段流水线跑一遍:

/deep-research Node.js v20 到 v22 的权限模型有哪些变化？

回车之后,它会在后台开始干活,而你的会话照常能用——这是 workflow 的一大爽点:它跑它的,你聊你的。

姿势二:在提示里带上"workflow"这个词

想让 Claude 给你当前这个任务临时写一个 workflow?简单,在你的话里任何位置带上 workflow 这个词就行:

Run a workflow to audit every API endpoint
under src/routes/ for missing auth checks
（跑个工作流，审计 src/routes/ 下每个 API 端点有没有漏掉鉴权检查）

Claude Code 会把这个词高亮出来,提示你"我要触发工作流了哦",然后 Claude 就替你写脚本。如果你只是顺嘴提了"workflow"并不想真触发,按 alt+w 就能忽略这一次。

姿势三:让 Claude 自己决定(ultracode)

如果你想彻底放手,有个叫 ultracode 的设置。它把推理强度拉到最高的 xhigh,并且让 Claude 自己判断什么任务值得开 workflow:

/effort ultracode

开了之后,一个请求可能会变成一串 workflow:一个用来理解代码,一个用来改,一个用来验证。它对这个会话里的每个任务都生效——所以,更费 token、也更慢。这个开关只在当前会话有效,新会话自动重置。干常规活时记得用 /effort high 切回来。

有一个权限细节值得留意:不管你当前是什么权限模式,workflow 派出的分身一律在 acceptEdits 模式下跑,文件改动自动批准。但 shell 命令、网络抓取、不在白名单里的 MCP 工具,运行中还是可能弹窗问你。所以跑长任务前,最好提前把分身需要的命令加进白名单,免得跑到一半卡住等你点确认。

三种姿势,一个内核:你负责说"我要什么",Claude 负责把它翻译成一条可执行的流水线。你从"操作员",升级成了"下订单的人"。

五、我踩了哪些坑？

工具再好,也有它的脾气。这一节我把社区和我自己趟过的坑摊开讲——省得你重蹈覆辙。

坑一:token 是真的烧。

这是最大的一个,必须放在最前面。一次 workflow 会派出几十上百个分身,每个分身都在烧 token。官方原话是它消耗"远超典型 Claude Code 会话"。有位开发者实测时,跑一个深度研究工作流,直接撞上了速率限制,连最终报告都没看到。

坑二:跑到一半,我能插话吗?不能。

workflow 运行期间不接受中途的用户输入。只有分身的权限弹窗能让它停一下。如果你的流程需要"做完第一阶段我先看看、拍板了再继续",别指望在一个 workflow 里实现——正确做法是把每个阶段拆成独立的 workflow,一个跑完你确认,再手动启下一个。

坑三:它没有手脚,只有嘴。

这点容易误解。workflow 脚本本身不能直接读写文件、也不能跑 shell 命令。真正动手的是分身;脚本只负责"调度"分身。所以你别期待脚本里有什么文件操作逻辑——它就是个总指挥,具体的活全是分身在干。

坑四:退出 Claude Code,进度就没了。

workflow 是可断点续跑的——你暂停它,再恢复时,已经干完的分身直接返回缓存结果,剩下的接着跑。但这个"续跑"只在同一个会话里有效。你要是在 workflow 跑着的时候退出了 Claude Code,下次进来,它得从头再来。长任务跑起来后,别手贱关窗口。

还有两个数字你最好记住:最多 16 个分身并发(CPU 核心少的机器更少),单次运行总共最多 1000 个分身——后者是个防止脚本无限循环的安全闸。

这些坑说到底,都指向同一件事:workflow 是一台重型机械。它能干一个人扛不动的活,但你得像操作重型机械一样,先读说明书,再轻踩油门。

六、写在最后：你该现在就试吗？

我们从朋友那句"不就是多开几个 subagent 嘛"出发,绕了一大圈。现在你应该能给他一个漂亮的回答了。

把这篇的核心,浓缩成几句你能直接转发的话:

• 它换的是范式,不是数量:workflow 把"计划"从 AI 的记忆里搬进了代码,中间结果存在脚本变量,不再撑爆上下文。
• 它的灵魂是流水线:agent 派活、parallel 设闸门、pipeline 走流水线,默认优先用流水线,让快的先走。
• 它真正的价值是质量固化:像"3 票否决"那样的对抗验证,能把一套质保流程写死进脚本,可信度远超一遍过。
• 它是重型机械:烧 token、跑中途不能插话、退出会话就重来——能干大活,但得带着说明书开。

我的看法:动态工作流真正的意义,不在于"AI 变快了",而在于AI 干活第一次变得"可审计、可复现、可沉淀"。你能看它的脚本、能存成自己的命令、能反复重跑同一套编排。这意味着 AI 协作正从"每次都靠运气的一次性表演",走向"像写代码一样可以版本管理的工程实践"。这一步,我认为比模型本身又聪明了几个点,重要得多。

当然它还在 research preview 阶段(需要 Claude Code v2.1.154 及以上,各付费档位可用),烧钱、有限制。但方向已经很清楚了。

那么,今天就给你一个具体挑战:

打开你的 Claude Code,敲一句 /deep-research,问它一个你最近真正想搞懂、又懒得自己查一下午的技术问题。然后敲 /workflows,钻进那个"验证"阶段,亲眼看看那几个分身是怎么互相"挑刺"、把不靠谱的结论一条条毙掉的。

如果你看懂了那个过程——恭喜,你就理解了为什么"让 AI 自己写脚本指挥分身",不是噱头,而是 Agent 协作的下一站。如果你被它烧的 token 吓了一跳——那也是个宝贵的认知:你刚刚摸到了当前这台重型机械真实的油耗边界。

两种结果,你都赢了。去试试吧。