Claude Code Workflow 解析
原创 chengable 2026-05-26 10:00 浙江
Claude Code 最近更新了一个大功能。
这个功能叫 Workflow。简单说，它让你用 JavaScript 代码来编排多个 agent 协同工作，而不是用自然语言 prompt。
听起来可能没啥感觉？那我换个说法。
你之前想让 AI 做多步骤任务，得写一段很长的 prompt，「你先做 A，然后根据 A 的结果决定做 B 还是 C，最后汇总成 D」。第一次跑还行，第二次可能就跑偏了。因为 prompt 是意图描述，不是执行契约。
Workflow 做的事就是把这个过程代码化。
if (result.confidence === 'low') { 验证 }
else { 跳过 }复制这行代码，跑一万次都是这个逻辑。prompt 做不到这种确定性。
我的理解是，在流程确定性上更进一步。
怎么触发：ultrawork、显式调用、Skill
先说一下触发方式，这块其实挺有意思的。
最直接的是显式调用，workflow("bughunt") 或者 workflow({ scriptPath，"..." })。第二种是 /reload-plugins 之后，你放在 .claude/workflows/ 下的脚本会自动注册成一个 skill，关键词匹配到就能触发。
但最让我觉得好玩的是第三种。
在你的消息里写 ultrawork 这个词，系统会注入一句提示，告诉主 agent，「这哥们授权你用 Workflow 了，别问了直接上」。
我第一次看到这个词的时候反应是，啥玩意？中二度拉满。
但用了两次之后觉得设计得挺聪明的。Workflow 跑一次 token 消耗不小，系统默认不会主动用，需要你明确说「我要开大了」。ultrawork 就是这个信号。
一句话总结，ultrawork = 「我允许你拉满多 agent 编队，不用问我确认」。
脚本结构：meta 头加异步代码
好了，说正事。脚本到底长什么样。
每一份 Workflow 脚本必须用一个 export const meta 开头。
exportconst meta = {
name: 'multi-agent-research',
description: '多agent协作调研工作流：并行多角度调研 + 交叉验证 + 综合报告',
phases: [
{ title: '分解调研维度' },
{ title: '并行调研' },
{ title: '交叉验证' },
{ title: '综合报告' },
],
}复制注意，这个 meta 必须是纯字面量。不能有变量，不能有函数调用，不能有任何计算。就是硬写在那里的 JSON。
meta 之后就是正常的 JS 异步代码了。你可以定义变量，写条件分支，调 agent()，用 pipeline 和 parallel 编排。
const topic = args?.topic
const dimensions = awaitagent(
'你是调研策略专家...',
{ label: '分解维度', schema: DIMENSION_SCHEMA }
)
const results = awaitpipeline(
dimensions,
(dim) =>agent(RESEARCH_PROMPT(dim), { label: dim.label })
)
const finalReport = awaitagent(SYNTHESIS_PROMPT, { label: '综合报告' })
return { topic, results, report: finalReport }复制看起来挺简单的对吧。
但真正有意思的是，脚本里面到底能放什么类型的节点。
Workflow 的四种节点
Workflow 脚本里能放四层东西。
最底层是编排器。pipeline() 是流水线，每个 item 独立穿越所有 stage，阶段间没有屏障，A 验证完了 B 还在调研，不互相等。parallel() 是屏障，等全部完成才继续，适合需要汇总所有结果再进入下一步的场景。phase() 是纯展示，给 agent 调用分组显示进度。
有个细节挺重要。Workflow 文档里明确写了，默认用 pipeline，只有在真的需要全局结果的时候才用 parallel。我在实践里也确实是这个感受，pipeline 的墙钟时间基本上等于最慢的那条单链，parallel 则是等最慢的那个跑完所有人才能动。
第二层是子 agent。每次 agent() 调用启动一个独立上下文的 agent，可以加 schema 强制结构化输出。子 agent 有完整的工具权限，Bash、MCP、WebSearch、Skill，但通过 ToolSearch 延迟加载，不会一次性灌满上下文。
第三层是纯 JS 计算。filter、map、reduce、条件分支、循环，全部零 token 开销。你可以在 agent 之间无缝插入数据处理逻辑。
第四层是嵌套 workflow。在脚本里调另一个 workflow 作为子步骤，限制一层嵌套。
这四层叠在一起，说到底 Workflow 脚本就是一个可编程的编排运行时。
但重点不在这。重点是它不能做什么。
沙箱边界：编排层只能做 JS 计算
沙箱的边界，才是关键。
Workflow JS 跑在一个沙箱里。
它能做的事，变量、条件、循环、数组操作、调 agent()、调 workflow()。
它不能做的事，文件读写，没有 fs。执行命令，没有 child_process。网络请求，没有 fetch。没有 Date.now()，没有 Math.random()，理由是为了支持 resume，必须确定性执行。没有 require()，没有 import，没有任何外部依赖。
所以呢。
Workflow JS 层是一个纯编排器。它只负责决定谁在什么时候做什么，不负责执行任何实际操作。
想在 workflow 中途调 MCP 工具？
const mcpResult = awaitagent(
'用 ctx_search 工具查询 AI安全 市场规模，返回前 5 条结果',
{ label: 'MCP查询' }
)复制让 agent 去做。
想在 workflow 中途跑 shell 脚本？
const output = awaitagent(
'执行 cat /tmp/data.json | jq .summary，返回 stdout',
{ label: '数据处理' }
)复制让 agent 去做。
这就是 Workflow JS 和子 Agent 的分工边界线。Workflow 管做什么决策，子 Agent 管怎么执行。
我一开始没搞懂这个边界的时候，总觉得 workflow 不够灵活。为什么不能直接在脚本里调 MCP？为什么不能直接读文件？
后来想明白了。如果 workflow JS 能做这些事，它就不是编排器了，它是另一个 agent。而这个 agent 的上下文会跟它 spawn 出来的子 agent 一样膨胀，那就完全失去了编排层的意义。
编排层必须是轻量的、确定性的、零上下文污染的。所以它只能做 JS 计算，剩下的全部委托。
子 Agent 的上下文：三条消息，没有 system prompt
再往下挖一层。子 agent 的上下文到底长什么样。
这块是我看 transcript 才确认的，之前完全是猜的。
子 agent 启动后，收到三条消息。
第一条，user message，就是你在 agent() 里传的那个 prompt 字符串。仅此而已。
第二条，attachment，deferred_tools_delta。一个可用工具名称列表，包括 Bash、Read、Write、全部 MCP 工具、WebSearch 等。但工具的 schema 没有一次性注入，需要通过 ToolSearch 按需加载。
第三条，attachment，skill_listing。全部可用的 skills 的触发描述。但 skill 的完整内容也不是一次性给的，通过 Skill 工具按需加载。
没有 system prompt。没有 CLAUDE.md。没有主会话的历史。没有之前的讨论。
你在 prompt 里写的每一个字，就是子 agent 看到的全部。
所以呢。子 agent 的上下文极其干净，也极其脆弱。你必须把角色、任务、输出格式、工具使用指令全部写在 prompt 里。少写一个字，它就可能跑偏。
Workflow 注入机制：自动注册为 Skill
换个话题。自定义 workflow 怎么注入到主会话的上下文里。
你写的 workflow 脚本放在 .claude/workflows/ 下，/reload-plugins 之后，脚本里 meta.description 那一行字会自动注入到主会话的 skill listing 里。例如
- multi-agent-research: 多agent协作调研工作流：并行多角度调研 + 交叉验证 + 综合报告复制之后主 agent 看到关键词就会自动触发，跟普通 skill 一模一样。
什么时候该用 Workflow
那到底什么时候该用 Workflow。
折腾完这一圈，我的判断是这样的。
适合 Workflow 的场景，流程步骤明确但每步需要 AI 判断。需要确定性编排和条件分支，不是一条直线走到底的那种。需要并行派发多个独立任务然后汇总。需要 schema 验证的强制结构化输出。
不适合的场景，单步任务，没必要引入编排开销。流程还不明确的探索性任务，先用普通 agent 摸清楚再说。需要跟用户交互式确认的，子 agent 没法跟你对话。简单的代码搜索和文件读取，一个 agent 绰绰有余。
说实话，Workflow 不是银弹。它是一种工具选择，在流程确定的时候给你确定性，在流程不确定的时候反而会限制灵活性。
但当你有一个已经想清楚了的流程，想让 Claude Code 用代码而不是用自然语言来执行的时候，Workflow 是当前最好的选择。
从最早的 chat，到 projects 管理上下文，到 agent 独立执行任务，到 skills 封装复用能力，再到现在的 Workflow，用代码编排多 agent。
每一步都是在把控制权从模型还给开发者。
Workflow 让你从「写一段很长的 prompt 祈求 agent 按你的想法走」，变成了「写一段代码让 agent 严格按你的逻辑执行」。在你写下 if (result.confidence === 'low') 而不是「请根据置信度判断是否需要验证」
我有种不祥的预感，相当多的skill 可能需要改成 workflow，效果会更好