之前讲子代理归纳出四种使用模式只读型、高噪声、并行探索、流水线编排。这四种模式的共同前提是主对话作为编排者每一步派谁、谁拿到上一步的结果、什么时候收尾都由 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_WORKFLOWS1环境变量。三、控制流谁来持有如果只能用一句话概括 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 dont 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 previewAPI 表面和触发方式都可能演化本文里写的命令、路径、上限数字都以你看到这篇文章时的官方文档为准。可以确定的是它在原语层级的位置和 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%免费】