之前讲子代理，归纳出四种使用模式：只读型、高噪声、并行探索、流水线编排。这四种模式的共同前提是主对话作为编排者：每一步派谁、谁拿到上一步的结果、什么时候收尾，都由 Claude 在当前上下文里临场判断。

到了 Claude Code v2.1.154，第三种编排原语正式进入：Workflow。它和 sub-agent、skill 并列，目前是 research preview。这篇加餐需要补充的内容是：Workflow 不是"更强的 sub-agent"，它把编排逻辑从对话搬到了脚本里，由此带来一套不同的契约。

说明：Workflow 还在 research preview 阶段，本文涉及的版本号、并发上限、命令名、目录路径都以官方文档为准，后续版本可能调整。

一、从 12 个文件并行审查说起

回到《Claude Code工程化实战》SubAgent中的例子。我们配置过一个 code-reviewer 子代理：YAML frontmatter 里写好 description 和工具白名单，主对话把 PR diff 派给它，回来一份审查意见。它有独立的上下文窗口、限定的工具集、可复用的定义文件，在"一次派一个工人"的场景下表现稳定。

现在把这个例子放大一个量级。假设一个 PR 改了 12 个文件，你想让 12 个 reviewer 并行各看一份，最后合并成一份报告。第 6 讲的并行编排能做到这件事——主对话起 12 次 Task，等它们陆续返回，自己负责整合。整段编排在主对话里大致是这样：

1. 你（主对话）：起 12 个 Task 子代理，每个看一个文件2. 12 个子代理并行跑，结果陆续回到主对话上下文3. 你（主对话）：在被塞满的窗口里读完 12 份，自己合成最终报告

能跑，但当编排规模继续放大，会出现三类痛点。

• 第一类痛点是中间结果都要回主对话上下文。12 份审查意见加上每个 reviewer 自己派生的中间产物，全部塞进当前会话窗口，而主对话还要在这个被塞满的窗口里做合并。
• 第二类痛点是中断后没有缓存机制。审到第 9 份的时候网络断了或者你想停下来看一眼，前面 8 份的产物会丢失，恢复时通常得从头再排一遍。
• 第三类痛点是同事 fork 这条流程跑不出同一份报告。"先派 12 个 reviewer，再让 summarizer 合并，最后让 critic 找漏审"这一整套编排逻辑写在你当时的 prompt 里。下一次换一个人、换一个 PR、prompt 措辞略有不同，跑出来的结构就不一样。

这三类痛点都不是 sub-agent 本身的缺陷，而是编排逻辑活在对话里带来的副作用。当编排本身值得被命名、复用、版本化的时候，它需要从 prompt 搬到代码里。这就是 Workflow 想解决的问题。

二、Workflow 的工程定义

官方文档对 Workflow 的定义可以总结为：一段 JavaScript 脚本，由 Claude 写，运行时在隔离环境后台执行，用来大规模编排子代理。在 Claude Code 的原语体系里，它和 sub-agent、skill 并列，是第三种编排原语。

这里有一个反直觉的设计点要先澄清。Workflow 的脚本是 Claude 写的，不是用户写的。用户描述任务，模型生成编排代码，运行时去执行。这和普通 SDK 里"开发者写代码调用 LLM"的关系反过来了——LLM 写代码、运行时跑代码、用户只看最终结果。

脚本本身是 deterministic 的 JavaScript：循环的轮数、分支的走向、并行调度的数量，都由代码静态决定。脚本内部派生 sub-agent 去做实际工作，sub-agent 才是非确定性的部分。换句话说，Workflow 是包在非确定性 agent 外面的确定性胶水。

中间结果存在脚本变量里，不进 Claude 的上下文。这是整段设计的核心。脚本可以跑几百个 agent、产生几百份中间产物，主对话窗口里只会看到最终汇总后的答案。后台隔离运行、上下文卸载、agent 之间互不污染，这三项性质都从这个设计点派生出来。

触发 Workflow 有三种方式：显式调用 /deep-research（目前自带的唯一 workflow 命令）、在普通 prompt 里包含 “workflow” 关键词强制走 workflow 模式、或者通过 /effort ultracode 让 Claude 把每一个实质性任务都自动编排成 workflow（一次请求甚至可能串成多个 workflow：先理解代码、再做修改、再验证）。组织级别禁用可以通过 disableWorkflows: true 设置或 CLAUDE_CODE_DISABLE_WORKFLOWS=1 环境变量。

三、控制流谁来持有

如果只能用一句话概括 Workflow 和 sub-agent 模式的差别，那就是：控制流到底在哪里。

sub-agent 加 skill 的模式下，控制流在 Claude 的上下文里。Claude 看到当前状态，决定下一步派谁；sub-agent 跑完把结果交回来；Claude 再看状态、再决策。每一步的"接下来怎么走"由模型在当前 turn 里临场判断，整段编排逻辑只在这一次会话里存在。

Workflow 模式下，控制流在脚本变量里。循环、分支、并行调度都在 JavaScript 代码中静态表达。Claude 不再逐步做编排决策，它只在最开始写一次脚本，然后看最终输出。运行时按脚本走，跑出来的路径是 deterministic 的。

围绕这条核心区别，其余几乎所有可观察到的差异都可以推导出来：

维度	SubAgent / Skill 模式	Workflow 模式
控制流持有者	Claude 主对话上下文	脚本变量
中间结果存放	进入 Claude 上下文窗口	留在脚本变量，不进上下文
可恢复性	中断后需要重派	同一 session 内可 resume，已完成 agent 走缓存
并发上限	每个 turn 几个 delegated task	单次运行 16 并发、1000 agent 上限
可复用单位	工人的定义（子代理文件）	编排本身（保存为 /<name> 命令）
权限模式	沿用 session 设置	派生子代理强制 acceptEdits + 继承用户工具白名单

下面是一段 Workflow 脚本骨架，用于感受结构。这是对 /deep-research 类编排的抽象示意，不是确切的 API——底层 SDK 原语是 AgentDefinition，包含 description / prompt / tools / model / effort / background / permissionMode / maxTurns / skills / memory / mcpServers 等字段。

// 示意伪代码，真实 API 见 AgentDefinitionconst angles = ["security", "performance", "maintainability"];// 阶段一：扇出。每个角度独立扫描，不同阶段可以路由到不同模型const drafts = awaitPromise.all(  angles.map(angle =>agent({prompt: `Audit src/routes/ from a ${angle} perspective`,model: "claude-haiku-4-5",  // 扫描类任务用更小的模型  })));// 阶段二：对抗审查。每份草稿被独立 agent 检查const verified = awaitPromise.all(  drafts.map(draft =>agent({prompt: `Review this draft for claims that don't hold up: ${draft}`,model: "claude-sonnet-4-5",  })));// 阶段三：合并。只有这一步的结果会回到主对话上下文returnsynthesize(verified);

model 参数说明了 Workflow 自带的一项成本控制能力：不同阶段可以路由到不同大小的模型，扫描类用小模型，合并类用大模型。

对照流水线编排能看清楚两种风格的差别。在那一讲中，我们让主对话"先调 Locator 找出问题位置，再交给 Analyzer 分析根因，最后让 Fixer 改"，这是 prompt-driven 的编排，每一步走不走、走哪一支由主对话临场判断；同一段流程冻进 Workflow 脚本就成了 schema-driven 的版本，控制流由 JavaScript 持有，跨 session 跑出来路径一致。两种方式都能完成这件事，区别在于编排逻辑是否需要被冻结和复用。

四、确定性换来的三件事

把控制流从 Claude 的临场判断转移到脚本中，代价是灵活性下降，换得的是三项具体收益。

第一项是可重复性。同一份脚本跑十次走同一条路径。当你跑出一次满意的结果，可以在 /workflows 视图里按 s 把它保存成 /<name> 命令。存到 .claude/workflows/ 是项目级，跟着 git 走全队共享；存到 ~/.claude/workflows/ 是用户级，跨项目可用。下一次同事在他的机器上跑同一个命令，编排逻辑是同一份。

第二项是并行规模。单次运行 16 并发、1000 agent 的硬上限，这个量级超出了主对话单点协调的能力范围。文档举的几个旗舰场景都在这个量级上：扫描 src/routes/ 下所有 API endpoint 找出缺失的鉴权检查、对 500 个文件做批量迁移、跨整个 codebase 做一次结构化审计。这一类任务从结构上就需要把编排外化。

第三项是会话内可恢复。运行时缓存每个完成 agent 的产物，跑到一半 pause 或 stop，再 restart 时已经完成的 agent 直接走缓存，没跑完的接着跑。

除此之外还有一项不太直观但很关键的价值：质量模式可以被固化在脚本里。Claude Code 目前自带的唯一 workflow 命令 /deep-research 内部就是这种组合——多角度扇出搜索、独立 agent 对彼此的发现做对抗审查、对每条 claim 投票、把没扛过 cross-check 的 claim 过滤掉、最后给出带引用的报告。这种 panel-of-judges 风格的编排，靠 prompt 让一个 sub-agent “记得做 self-critique” 其实写不稳——模型有时记得、有时忘了、有时 critique 自己变成了附和。写进脚本就稳定下来：第二个 agent 看到的就是第一个 agent 的结论加上"你的任务是独立审查"的明确指令，这是契约而不是模型记忆。

五、灵活性的代价

把 Workflow 当作"sub-agent 升级版"的看法是不准确的。它换走了几样具体的东西，使用前需要清楚。

首先，Workflow 不接受中途用户输入。跑起来就是一次性跑完，跑完才能下一轮。如果你的流程需要在 stage 之间人工 sign-off——比如审完代码要人确认才能改，改完要人确认才能 verify——官方文档明确建议把每个 stage 拆成独立的 workflow，跑完一个停一下、看一眼、再触发下一个，不要试图把"等用户点头"塞进单个 workflow。

其次，脚本本身没有文件系统和 shell 权限。只有它派生的 agent 能动磁盘、跑命令。这条约束是 Workflow 能安全在后台运行、会话仍然响应的前提，但它意味着如果你想让 orchestrator 本身读写一个临时目录、追加一个日志文件、调一个 shell 工具，做不到。

第三，脚本生成本身也要消耗 token。Workflow 适合编排逻辑值得被冻结的场景，一次性的小任务直接让主对话起一两个 sub-agent 更经济。官方原话是 Workflow 可能比在对话里做同样的任务用掉显著更多 token。

第四，Workflow 不适合互动调试和目标不固定的探索性任务。它默认在后台执行，编排过程不会逐步反馈进展，用户只看得到最终答案和事后的 phase 视图。在你还在摸索"这件事到底该怎么拆"的阶段，留在 sub-agent 层靠主对话做 turn-by-turn 决策更合理。

六、什么时候用 Workflow

《Claude Code工程化》实战的专栏的加餐建立了一个判断 Skill 还是 SubAgent 的体例，靠几个具体问句来推。这里照搬同一种结构，给 Workflow 四个判断维度。

第一个问句是流程是否已经稳定下来。这是最先要问的——流程还在变形的时候冻进脚本是负担，因为你会在 prompt 里调整方向，但脚本不会跟着调整。Workflow 适合那种你已经在主对话里手工跑过好几次、节奏摸熟了、想固化下来的流程。

第二个问句是是否需要跨会话、跨 PR、跨人复用同一条编排。这是 /<name> 命令的真正价值所在。如果这套编排只在你这一次 session 里跑一遍以后再也不用，没必要写成 workflow；如果它会在每个 PR 上跑、每周巡检跑、新同事入职跑，把它保存成项目级命令，编排本身就成了团队资产。

第三个问句是是否需要超过一次对话能协调的 agent 数量。codebase-wide 扫描、500 文件迁移、几十个 endpoint 的并发审计，这一类任务规模超出了主对话单点协调能处理的范围。粗略的尺度是估算下来需要的 agent 数超过十个时，主对话单纯做编排已经会显得吃力。

第四个问句是是否需要把质量模式固化在流程里。如果你需要的不是"跑更多 agent"，而是"必须有第二批独立 agent 做对抗审查"或者"必须从多个角度起草再相互权衡"，这种 panel-of-judges 风格的契约靠 prompt 维持不稳，靠脚本维持很稳。

第五节列出的四种代价，反过来就是不应该用 Workflow 的信号：流程需要逐步签批、orchestrator 自己要做 IO、一次性的小任务、目标不固定的探索性工作。

七、与 Sub-Agent / Skill / Headless 的边界

SubAgent加进 Workflow 以后，几个原语之间的关系值得简单梳理一下。Sub-agent 是隔离上下文的工人，由主对话即兴调度；Skill 是声明式的步骤包，喂给单个 agent 用，描述某种能力或某种流程的步骤；Workflow 是声明式编排，把多个 agent 组装成可重复的流水线。Sub-agent 和 skill 解决"谁去做"和"怎么做"，Workflow 解决"多工人编排如何被复用"。

这里要单独说明一点，避免概念混淆：Workflow 和 Headless 是正交的。Headless 是 claude -p 非交互运行时，把会话从前台搬到后台的开关，让 Claude Code 能在 CI/CD、GitHub Actions、pre-commit hook 里跑。Workflow 在交互模式下也能跑——在 REPL 里输入 /deep-research 就是交互模式下跑 workflow。两者放进 CI/CD 时通常配合使用，但它们处在不同层次。还要注意 GitHub Actions 的 YAML 也叫 “workflow”，那是 GitHub 的术语，和 Claude Code 的 Workflow 原语不是同一回事。

八、第五种使用模式

之前文章《量体裁衣》中也给出过四种 sub-agent 使用模式：只读型、高噪声、并行探索、流水线编排。Workflow 在这张图里补上第五种——声明式编排。

使用模式	解决的问题	控制逻辑位置
只读型	信息收集不污染主对话	LLM 临场
高噪声	大量低信息内容的压缩	LLM 临场
并行探索	同一问题多角度展开	LLM 临场
流水线编排	多 agent 顺序协作	LLM 临场
声明式编排	编排逻辑本身需要被复用	脚本冻结

Workflow 不是替代流水线编排，而是它的工程化形态。流水线编排在 sub-agent 层是 prompt-driven 的，每一步走不走、走哪一支由主对话临场判断；同一个流水线放进 Workflow 就是 schema-driven 的，控制流冻在 JavaScript 里，跨 session 一致。

回到开篇那个 12 个文件并行审查的场景。在 sub-agent 层做，主对话亲自协调 12 个 reviewer 加一个 summarizer，能跑但不稳；在 Workflow 层做，把这套编排写成脚本保存为 /review-pr-files，编排逻辑就从某一次 session 的 prompt 沉淀成了项目里的一份可执行契约。下一次 PR 改了 50 个文件，跑同一个命令，编排不变，脚本内部并行起 50 个 reviewer。

九、临场判断与冻结契约

Workflow 和 sub-agent 不是替代关系，而是两种不同的"控制流位置"选择。临场判断的优势是灵活，能随会话调整方向，代价是不可重复、上下文压力大、跨人难以复现。冻结的契约反过来：可重复、可保存、可大规模并发、可固化质量模式，代价是不接受中途用户输入、orchestrator 本身没有 IO 权限、生成脚本本身也要花 token。

这两种位置不是优劣关系，而是不同的工程权衡。当编排还在变形的阶段，留在主对话里更合适；当编排稳定下来、值得被命名、需要被团队复用，把它从 prompt 搬到脚本里就是合理的下一步。Workflow 目前还在 research preview，API 表面和触发方式都可能演化，本文里写的命令、路径、上限数字都以你看到这篇文章时的官方文档为准。可以确定的是它在原语层级的位置：和 sub-agent、skill 并列，作为 Claude Code 的第三种编排原语，承担的角色是让编排本身成为可被复用的工程产物。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】