首页 · 深度文章 · Claude Code 新功能 Workflow：召唤多 agent 协同

教程 Claude工作流

Claude Code 新功能 Workflow：召唤多 agent 协同

叁笙 2026-05-26 40 分钟阅读公众号原文 ↗

🎵 本文主题曲 · 骨架与轨迹

0:00

2026 年 5 月 21 日，Anthropic 发布 Claude Code 2.1.147。这一版没开新闻发布会、没发推特、changelog 里只有一行字。但全球的 CLI 重度用户用了三天才发现，AI Agent 的编排方式，这一周被悄悄改了。

你的 Claude Code 的 CLI 端和插件端，对得上号吗？

上周三晚上，我盯着 VS Code 看了好几眼。

那台电脑左下角的 Claude Code 扩展是 anthropic.claude-code-2.1.145，已经停在这个数字上一个礼拜没动了。我有点不放心，打开同一台机器的终端敲了一行：

claude --version

返回的是 2.1.150。

Claude Code CLI 端显示 v2.1.150

VS Code 扩展显示 2.1.145

同一台电脑，同一个 Claude Code，CLI 端跟插件端差了整整 5 个号。

这事儿挺反常的。过去一个月，CLI 跟 VS Code 插件几乎是同步迭代的 — 每天升一次小版本，两边对得上号。然后从 5 月 19 日开始，插件端突然不动了，CLI 端却照常每天发一个 patch。8 天里，CLI 从 2.1.145 走到了 2.1.150，插件端纹丝不动。

我以为是更新失败。去 VS Code Marketplace API 拉了完整版本历史，发现这不是单平台 bug — alpine / darwin / linux / win32 八个 build 全部停在 2.1.145，发布日期都是 2026-05-19。Anthropic 整体把插件端冻在了 145 这个稳定版，没有任何一个平台拿到新版本。

带着这个疑问翻 Claude Code 的 GitHub issues 和 Reddit，谜底慢慢拼起来：

CLI 端在 2.1.147 引入了一个重大调整 — 一个叫 Workflow 的新工具。这个工具改了 Anthropic 内部的自动更新策略，碰巧带出了好几个回归 bug（Windows 上的 EBUSY 文件锁、Bash exit code 127 等等）。Anthropic 为了不让这批 bug 影响到桌面端和插件端的更多用户，主动把插件端冻在 2.1.145 这个最后的稳定版，让 CLI 端这条线先快速迭代修补 — 2.1.148、149、150 都是在修 2.1.147 引入的回归。

所以版本号这件事的真相是：CLI 用户在跑实验版，插件端用户拿到的是上一个稳定版。Anthropic 用 CLI 这群用户的反馈做产品验证，等 CLI 跑稳了再放给插件端用户。

而 CLI 跑的这个实验版里，藏着这次重大调整 — Workflow。

触发关键词是 ultrawork。查看进度的命令是 /workflows。开关藏在一个环境变量后面：CLAUDE_CODE_WORKFLOWS=1。但这个变量设了也不够 — 后端还有一道 GrowthBook flag 按账号灰度。设了 env 也不一定能用，要等 Anthropic 把你账号标进 cohort。

这个工具不是小补丁。从 2024 年 8 月的 Sub-agent，到 11 月的 Skills，到 2025 年的 MCP，再到今年 3 月的 Agent Teams — Anthropic 给 Claude Code 加的每一个能力，都在往同一个方向上垒。Workflow 是这条线上的下一块砖。

下面这篇文章我用了一周时间才看明白。版本号那串数字，是这次重大调整的影子 — 顺着影子摸过去，能看到 AI Agent 的整个底座正在变厚。

同一台电脑 5 个版本号差，顺着影子摸到 Workflow

Workflow 到底是什么：6 个原语，5 种官方形态

先说一句话定义：

Workflow 是在 Claude Code 内部用一段 JavaScript 脚本调度多个 Subagent 的工具。

你过去用 Claude Code 跑复杂任务，是这么干的 — 给主 agent 一段 prompt，让它「先调研 A 公司，再让另一个 agent 起草分析，最后让第三个 agent 评分」。主 agent 临场决定该叫哪个 subagent、按什么顺序、什么时候停。每次开新会话，模型都要重新猜一遍这个流程。

Workflow 干的事正好相反 — 它把这套编排冻结成一个文件。这个文件你能看、能改、能存到 git、能分享给同事、能断点续跑、能版本化。

Anthropic 给这个工具配了 6 个 JavaScript 原语函数（出自 Piebald-AI 反向工程的 tool-description-workflow.md）：

原语	干什么
`agent()`	派一个 subagent 干一件事
`pipeline()`	把多个 agent 调用串成顺序流水线（默认形态）
`parallel()`	把多个 agent 调用并发跑（需要全员对齐才用）
`phase()`	把流水线切成可观测的阶段
`log()`	写中间日志，方便复盘
`workflow()`	嵌套调用另一个 workflow（只允许一级）

官方文档里有一条铁规：默认用 pipeline()，需要全员同步再切 parallel()。这条建议直接对应 Anthropic 自己的工程文化 — 并发不是免费的，它带来调度复杂度和 token 翻倍的代价。

如果你回头去看 Anthropic 2024 年 12 月发的那篇《Building Effective Agents》，会发现 Workflow 工具不是凭空冒出来的。那篇白皮书定义了 5 种 workflow 形态，是这个工具的祖宗文献：

◎ Prompt Chaining（提示链）— 一个 agent 的输出，是下一个 agent 的输入，依次串联。

◎ Routing（路由）— 一个分类器先看任务长什么样，再分流给不同专长的 agent。

◎ Parallelization（并行）— 同一个任务派给多个 agent 各自做一遍，再合并（sectioning 切分 + voting 投票）。

◎ Orchestrator-Workers（调度器-工人）— 一个中央 agent 动态拆任务，分给工人 agent，最后综合结果。

◎ Evaluator-Optimizer（评估-优化）— 一个 agent 生成、另一个 agent 评分，循环改到达标为止。

这 5 种是真正的官方命名。

但是 — 这里要插一句诚实话 — 你在中文圈现在看到的「六种形态」（pipeline / aggregate / adversarial / judge / accumulate / nested）不是 Anthropic 钦定的术语。它是社区把 Anthropic 5 形态、Piebald 反编译的 6 个 JS 原语、以及 AI 超元域博客总结的 5 个应用场景揉在一起的拼凑命名。

我也是后来才看明白这一点。你去搜「Claude Code 六种形态」其实搜不到 Anthropic 官方页面，搜出来的全是社区拆解文。这不是说六种形态错了，而是说它是一个半官方、半民间的术语 — 它在帮你理解 Workflow，但如果你拿这个词去跟 Anthropic 的工程师对话，对方可能要愣一下。

值得一提的是，这种「官方定义 + 社区命名」的脱节，恰恰说明 Workflow 还很早期。一个能力如果术语都还没统一，意味着它的窗口才刚刚打开。

回到一个被忽略的元概念：Harness

要看清楚 Workflow 加在哪里，得先讲一个常被忽略的元概念 — Harness。

Harness 这个词，最早被 Stratechery 的 Ben Thompson 在《Agents Over Bubbles》里点透。他原话是：

「让 Agent 工作流跑起来的关键不是模型，而是 harness 那层软件 — 它真正在控制模型……agent 还能调用其他确定性工具来验证自己的结果。」

直译过来，harness 是”缰绳”或者”挽具”— 给一匹烈马套上的那套外壳。

放到 AI Agent 语境里，Harness 是 Claude Code 这个软件约束模型行为的那一整套外壳。模型本身只管推理 — 你给它一段文字，它生成一段文字。但要把模型变成”能帮你干活的 Agent”，得在模型外面套一层 — 这层负责告诉模型：你现在能调哪些工具、能读哪些文件、要按什么顺序做事、出错了怎么办、做完了交差给谁。

这套外壳就是 Harness。

理解 Harness 这个元概念，是看懂这次 Workflow 上线意义的钥匙。MCP、Skill、Subagent、Agent Teams、Workflow — 这 5 个能力全都活在 Harness 这个框架里，它们不是替代模型，是给模型套上不同维度的”约束工具”，让 Claude Code 这个软件能稳定地干活。

我把这层关系画一下：

       Harness（Claude Code 这套软件外壳）
         |
         |-- 模型层：Claude Opus / Sonnet / Haiku（推理引擎）
         |
         |-- 约束工具层：
         |     ├── MCP        给模型接外部数据
         |     ├── Skill      告诉模型某类任务怎么做
         |     ├── Subagent   让模型派出去做隔离任务
         |     ├── Agent Teams 让多个模型协作
         |     └── Workflow   把上面这些怎么串起来写成脚本

Harness 六层架构 -- Workflow 是最新长出来的一根肋骨

Workflow 加在最上面那一格 — 它不是替代下面 4 个，是第一次把”怎么把下面 4 个工具按什么顺序串起来”这件事，从模型脑子里挪到代码里。

以前你让 Claude 跑「调研 → 起草 → 评审 → 整合」这种 4 步流水线，主 Agent 每次开会话都要靠模型临场理解 prompt、决定该调哪个 Subagent、按什么顺序、用哪个 Skill、查哪个 MCP。换一次会话，编排路径就要重来。

Workflow 之后，你写一个 analyst-pipeline.workflow.js 文件，存到 .claude/workflows/ 目录下，下次直接 ultrawork run analyst-pipeline — Subagent 调几个、Skill 用哪个、MCP 抓什么数据，全部按脚本走。这一层不再交给模型临场判断，而是变成确定性的代码。

懂了 Harness 这个元概念之后，Workflow 跟其他 4 个能力的边界就清楚了：

◎ Workflow vs Agent Teams — 这俩在 Harness 同一层，是两条不同的路线。Agent Teams 让模型自己协调（涌现式），Workflow 让脚本来协调（确定性）。不是互补，是并列的两种选择。

◎ Workflow vs Subagent — 编排层 vs 被编排的工人。Workflow 内部要调 agent() 函数才能真正派一个 Subagent 出去干活。Workflow 是”导演”，Subagent 是”演员”。

◎ Workflow vs Skill — 流程结构 vs 节点知识。互补关系。Skill 装在 Subagent 里告诉它”代码 review 该怎么做”；Workflow 决定派几个 Subagent 跑、谁先谁后、出错怎么办。

◎ Workflow vs MCP — 流程结构 vs 数据通道。也是互补。Workflow 里某个 agent() 节点可能要用 MCP 去拉 GitHub PR 的 diff，那就是 Workflow 调用 MCP。

我用了一周才看明白这层关系。最大的认知卡点在第一条 — 我一开始以为 Workflow 是 Agent Teams 的”工程化升级”，后来才反应过来 — 它俩根本是两种哲学：一个让模型自己想，一个让你写好骨架让模型填。

说到底，Workflow 没让 Harness 变小，是让 Harness 变得更厚、更全。Claude Code 这个软件能约束模型的方式，又多了一根肋骨。

不只 Anthropic 一家：全行业的 Harness 都在变厚

如果只看 Anthropic 一家，你可能会以为 Workflow 是个产品决策。但你把视野拉到整个 AI Agent 行业，会发现这是一次集体转向 — 所有头部厂商都在给自己的 Harness 加新东西。

2024 年 10 月，OpenAI 发布 Swarm — 那是它的第一代多 agent 编排实验，思路是「让 agent 自己决定下一步交给谁」，纯靠 LLM handoff。后来 OpenAI 自己承认 Swarm 是教学产品，把它替换成了更工程化的 Agents SDK。

2024 年 12 月，Anthropic 发表《Building Effective Agents》白皮书 — 这是「workflow vs agent」二分法在英文世界的最早正式提法。它的核心观点是：先用 workflow（脚本编排）解决问题，不行再上 agent（模型自治）。

2026 年 4 月，Microsoft 发布 AutoGen 2.0 / Agent Framework GA — 把 agent 协作做成了”对话派”，让 agent 互相聊到收敛。

2026 年 5 月 14 日，Microsoft 又开源了 Conductor，副标题写得直白：“Deterministic orchestration for multi-agent AI workflows”。它跟 Anthropic Workflow 哲学一致 — 用 YAML 描述骨架，路由用 Jinja2 模板做条件判断，编排层零 token 消耗。

2026 年 5 月 21 日，Anthropic 把 Workflow 塞进 Claude Code 2.1.147。

把这条时间线摊开看，5 家头部厂商在 18 个月里做了同一件事 — 给自己的 Harness 加一层”确定性骨架”。每家的 Harness 都在以肉眼可见的速度变厚。

设计哲学光谱 -- 6 家头部厂商在 18 个月集体转向

设计哲学从「让 LLM 自己决定」到「用代码描述路径」的光谱，由高到低排列大概是这样：

产品	设计哲学	表达形式
OpenAI Swarm（已废）	最 LLM-trust：stateless handoff	Python decorator
CrewAI	role-based crew	Python class
AutoGen / MS Agent Framework	conversation 派	Python orchestrator
LangGraph	typed state graph	Python DSL
Anthropic Workflow	代码写骨架，LLM 只填节点	JS 脚本（最薄）
Microsoft Conductor	YAML 写骨架（更 declarative）	YAML

Anthropic Workflow 站在这条光谱最右端 — 骨架最薄、约束最强、LLM 自由度最低。

为什么大家都在往右走？AI 研究者 Mervin Praison 给了一句金句解释：

“Autonomy is not the goal — reliability is.”

自主性不是目的，可靠性才是。

行业用了三年时间才想清楚这件事。2023 年 AutoGPT 时代所有人都在卖「AI Agent 越自主越聪明」，结果跑到生产环境上发现 — 模型每次临场决策都引入一次不确定性，10 步的任务每步 5% 错误率，最后成功率不到 60%。

Foundation Capital 在《What it takes to build AI agents that actually work》里用一个叫「99% step-length」的框架算了这笔账 — 从 90% 准确率涨到 99.9% 才是最贵的那一段路。要做到这一段，不是靠 prompt 工程或者换更强的模型，靠的是给模型套上一层确定性的编排骨架。

所以 Workflow 不是 Anthropic 的新功能，是整个 AI Agent 行业的 Harness 集体在变厚 — 从「让模型自己想」走向「让人写骨架、模型填血肉」。Anthropic 比别人早 6 个月把它做进了产品里。

而 Harness 越厚，意味着两件事 — 一是这个软件能干的事越多、越稳；二是它对你工作的渗透越深、越具体。

真跑出来什么效果：5 组硬数据

理念归理念，效果还是要看真实数字。下面 5 组数据来自不同的工程师在不同任务上的实测，每一条都带 URL 可以点开验证。

Workflow 跑出来的 5 组硬数据 -- 关键是独立挑错不是并行

◎ 王树义 7 倍效应

王树义的 AI Substack 2 月 17 日发了一篇复盘 — 他让 Claude Code 自查一部复杂小说作品。主 agent 跑完报告说”没问题”。他换了一个模式：让一个独立 agent 去审查主 agent 的产出。

结果，独立 agent 找到的问题数和主 agent 完全不在一个量级。

更狠的是后续 — 他做超链接核查（验证文中提到的 URL 是否可访问），用独立 agent 加新规则回扫，找到的错误是已知错误的 7 倍。

他把这条经验固化成了最高优先级的 CLAUDE.md 规则。

这件事对应 Workflow 的「evaluator-optimizer」形态 — 生成者和审查者必须是两个独立的 agent。如果你让同一个 agent 既写又改，它会陷入认知盲区，看不见自己的错。

◎ 3 agent PR 互审 41% 分歧率

Dev.to 上一位叫 kenimo49 的工程师做了一个对照实验 — 同一个 500 行 refactor 的 PR，让 3 个 Sonnet 4.6 subagent 并行审查（read-only 模式）。

结果是这样的：

3 个 agent 都标的问题：18%
2 个 agent 标的问题：41%
单 agent 私见：41%

41% 的分歧率告诉你一件事 — N=3 不是免费的 3 倍 review 效率。你需要按 PR 体量分档：tiny 用 1 agent 就够、medium 用 2、large 才上 3。否则单 agent 私见会淹没真正的关键问题。

这条数据是 Workflow「parallelization with voting」形态的真实落地结果 — 多 agent 投票必须配上聚合机制，不是简单累加。

◎ 20 万行 Java 项目找到 63 个独立漏洞

一个微信公众号文章拆解了用 Claude Code 跑代码审计的实战 — 4.5.3 版的 audit skill 在某大型开源 Java BI 平台上跑了 2 轮，调度 8 个 subagent，共 165 次工具调用。

R1 找到了 59 个漏洞，R2 用 R1 一半的 token 补漏了 4 个 R1 完全遗漏的 Critical 级。总共 63 个独立漏洞，其中 12 个 Critical、19 个 High、10 个安全维度全覆盖。

如果一个人类审计师做这件事，按熟练度 10 分钟一个漏洞算，63 个漏洞要花 10 小时 30 分钟。Workflow 跑完用了大概 90 分钟。

◎ Anthropic Code Review：bug detection +54%

Anthropic 官方 Code Review 功能 3 月 9 日上线，是多 agent 自动审查 PR 的官方实现。PR 一开，自动派一支多 agent 队去 hunt bugs，独立 verify，每条评论挂到具体行号。

官方报告的数据：bug detection 比单 agent review 提升 54%。

这是 Workflow「judge」形态在生产环境的官方背书 — agent 互相挑错，比一个 agent 自己挑错强 54%。

◎ dev.to 公司 14 个月集成：review 时间 4.2 小时 → 1.6 小时

工程师 johalputt 在 dev.to 发的《How we integrated Claude Code》给了一份真实的生产数据。他们公司过去 14 个月把 Claude Code 集成进 PR 流程，Q1 2026 跑了 1200 个 PR。

人工 review 平均花费 4.2 小时，集成 Workflow 后降到 1.6 小时。

单次 review 成本是 $15-25。1200 个 PR 一年算下来，省的人时折算成钱，跟 Workflow 调度成本一比，ROI 是正的。

不过这里要补一句反方观点 — Workflow 不是越多越好。

Termdock 这篇复盘了一个反模式 — 简单任务（比如改一个 typo、加一个注释）也用 subagent，token 消耗会膨胀到单 session 的 4 倍。Workflow 的威力在复杂、多视角、需要审查的任务上；在简单线性任务上，它反而是浪费。

所以 Workflow 真正的价值不在”能跑得更快”，在”能让 AI 互相挑错”。独立的 agent 才是关键，不是单纯的并行。

Harness 越完善，工作就被它越深地影响

讲完了”是什么”和”为什么”，最后回到一个我们躲不开的问题 — 这事儿对我们的工作和生活，到底意味着什么。

先说眼下能不能用。Workflow 当前有双重门控 — 环境变量 CLAUDE_CODE_WORKFLOWS=1 必须设，加上 Anthropic 后端 GrowthBook flag tengu_workflows_enabled 按账号 cohort 灰度，两道都过才能用。VS Code 插件端目前冻在 2.1.145 这个稳定版，等 Anthropic 把 2.1.147 引入的回归 bug 修完才会重启发布。

按 Anthropic 过去几个月的节奏，灰度通常 1-2 周从 5% 放到 100%。一个月内大概率会下放到所有 Claude Code 用户。

到时候，如果你属于这几类人：

普通 AI 用户（用豆包 / 通义 / ChatGPT 写邮件那一档）— 不用急着学怎么写 workflow.js。但记住一件事：你将来在 Claude Code 里说”帮我把每周市场调研做了”，它能直接调用一个写好的 workflow 跑完整个流程 — 抓数据、清洗、出图、写报告。你需要做的，是把”我每周固定要做哪几件事”想清楚。

进阶用户（已经在用 Claude Code CLI）— 等 flag 到你账号那天，先跑两个官方内置的 workflow 看效果：/bughunt（约 80 个 agent 并发扫 bug）和 /deep-research（多源调研 + 综合）。这两个会让你直观感受到 Workflow 的产出质量跟”主 Agent 临场编排”完全不在一个量级。

写代码的 — 可以现在去看 OneRedOak/claude-code-workflows 这个仓库（3.8k stars）。AI-native 创业公司沉淀下来的 workflow 模板库，能给你”workflow.js 应该长什么样”的第一手参照。

往后看，趋势其实已经摆在那里 — Claude Code 的 Harness 还会继续变厚。

这一年里行业出过的几个工具，都指向同一方向：Google 的 Antigravity（试图把 Cursor 那一套 IDE 体验做到极致）、Cursor 自身把 Composer 和 Background Agents 一年内升了 4 次、Codex 把 IDE 和 CLI 双线推进、Windsurf 直接在编辑器里塞 Agent 群。每家都在给自己的 Harness 加新东西 — 这一波加 Workflow，下一波可能是跨会话的长期记忆、再下一波可能是直接连 Slack 和飞书。

每多一层 Harness，AI Agent 能稳定干完的事儿就多一档。

对我们日常工作的具体影响，其实分两种 — 你能看到的和你看不到的。

看得到的那种，是显性效率：一个用 Workflow 跑 PR review 的工程师团队，单次 review 时间从 4.2 小时压到 1.6 小时。一个用 Workflow 跑代码审计的 Skill，能在 20 万行 Java 项目里 90 分钟扫出 63 个独立漏洞（人工要花至少 10 小时）。这种数字会越来越多。

看不到的那种，是工作方式本身被悄悄改写。**以前你做事的颗粒度是”任务”，未来你做事的颗粒度可能是”工作流”。**你不再是想到一件事就去做，而是把”我经常要做的这件事”写成一个 workflow，存起来，下次直接调用。一个人的产能会从”靠手做”变成”靠攒下来的 workflow 跑”。

这件事的影响会渗透到你做 PPT、写报告、做调研、做 OKR 复盘的每一个流程里。

所以最后回到 Workflow 本身 — 它不是一个孤立的功能。它是 AI Agent 这一整套软件从”能聊几句”走向”能稳定干活”过程中，必然要长出来的那一根新肋骨。Anthropic 这次只是先一步把它做了出来。

而你能做的事，其实在版本号显示「2.1.145 vs 2.1.150」对不上号的那一刻就已经开始了 — 注意到这个差异本身，就是注意到 Harness 在变厚的第一个信号。

下次同事提到 ultrawork 的时候，你不会需要假装听过。

更重要的是 — 等灰度到你账号那天，你已经想好了 workflow.js 第一个文件要写什么。

3 类人群面对 Workflow 该怎么办

你的 Claude Code 是几？