ENZOMEGA.
Clipping 微信公众号

Claude Code 隐藏新功能 -workflows：确定性多 Agent 编排引擎深度拆解

by AI兴观点 原文 ↗
Created: 2026-05-27
#公众号文章

公众号名称：程叙架构与AI.

作者名称：AI兴观点

发布时间：2026-05-27 19:45

✅点击上方🔺公众号🔺关注我✅

你有没有想过一个问题——Claude Code 的 agent 替你干活时，它下一步要做什么，你知道吗？

不知道。因为流程是模型自己决定的，你只管给目标，它自己琢磨怎么做。大多数时候这没问题，但复杂任务上你就开始心里打鼓了——它会不会跑偏？会不会漏掉关键步骤？

Anthropic 显然也在想这个问题。他们的答案不是让模型更强，而是换了一条路：把流程控制权从模型手里拿回来，写成代码。

这个答案被做成了一个叫 /workflows 的命令，你描述一个目标，它先生成一段 JavaScript 脚本定义完整的执行路径，然后才按脚本执行。

先给一句话定义：Workflows 是在 Claude Code 内部用一段 JavaScript 脚本调度多个 Subagent 的工具。

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

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

先搞清楚它怎么启动

Workflows 当前是隐藏功能，需要两步才能开：

export CLAUDE_CODE_WORKFLOWS=1

然后在对话中带上 ultrawork 关键字：

ultrawork 帮我审查这个分支的代码质量

它不会立刻执行。它会先：

  1. 生成 context.md 分析任务
  2. 现场写一段 JavaScript 脚本——定义了完整的执行流程
  3. 保存到本地临时目录
  4. 启动 Node.js 按脚本执行

注意第二点。它不是在脑子里规划，是写了一段真实的代码。这段代码你能看、能改、能存到 Git、能分享给同事。

Anthropic 还给了一个防呆设计：生成的脚本默认只保留 3 天，到期静默删除。如果你觉得这套流程值得保留，需要通过自然语言告诉 Claude 把它复制到全局配置下。

/workflows 的 6 个 JS 原语

这是 Workflow 最值得先搞懂的部分。它提供了 6 个 JavaScript 函数，用来编排 Agent。

// 1. agent() - 派一个 Subagent 干一件事
const result = await agent('find-bugs', {
  schema: BUGS_SCHEMA,  // 强制输出结构化 JSON
  phase: 'Review',       // 归属阶段
  label: 'review:bugs'   // 日志标签
})

// 2. parallel() - 多个 Agent 并发跑
const findings = await parallel([
  agent('find-bugs', { schema: BUGS_SCHEMA }),
  agent('find-perf', { schema: PERF_SCHEMA }),
  agent('find-security', { schema: SEC_SCHEMA }),
])

// 3. pipeline() - 流水线执行
// item1 进 stage2 时，item2 还在 stage1
// wall-clock 时间 ≈ 最慢阶段的耗时
await pipeline(items, stage1, stage2, stage3)

// 4. phase() - 把流水线切成阶段
phase('Review')   // 第一阶段
phase('Verify')   // 第二阶段
phase('Synthesize') // 第三阶段

// 5. log() - 写日志
log('开始扫描 30 个文件...')
log('发现 5 个疑似 bug')

// 6. workflow() - 嵌套调用另一个 workflow
await workflow({ scriptPath: './audit.workflow.js' })

这 6 个原语不是拍脑袋想出来的。2024 年 12 月 Anthropic 发过一篇白皮书叫《Building Effective Agents》，里面定义了 5 种 agent 协作模式：Prompt Chaining（一个 agent 的输出喂给下一个）、Routing（分类器分流）、Parallelization（多 agent 各自跑再合并）、Orchestrator-Workers（中央调度拆任务）、Evaluator-Optimizer（生成+评分循环）。Workflow 的 6 个原语，就是把这 5 种模式变成了可执行的 JS 代码。

官方文档里有一条铁规：默认用 pipeline()，需要全员同步再切 parallel()。并发不是免费的，多一个并行 Agent，就多一份 Token 开销、多一份调度复杂度。

Schema：让模型输出不再”随缘”

用过 Agent 的人都有这个经验：你让模型输出一段结构化数据，它给你一段格式不稳定的 JSON——字段名偶尔被翻译了、嵌套层级变了、该是数组的返回了对象。

Workflow 的解法是在每个 agent() 调用上挂一个 Schema：

const BUGS_SCHEMA = {
  type: 'array',
  items: {
    type: 'object',
    properties: {
      file: { type: 'string' },
      line: { type: 'number' },
      severity: { type: 'string', enum: ['low', 'medium', 'high', 'critical'] },
      description: { type: 'string' }
    },
    required: ['file', 'line', 'severity', 'description']
  }
}

const bugs = await agent('find-bugs', { schema: BUGS_SCHEMA })

这个 Schema 在传统 agent 调用里是个老大难问题。Workflow 把它变成了内置能力——每个 agent 节点的输出都会被 Schema 校验，不合规的让模型重试。

Budget：控制 Token 不失控

多 Agent 编排最怕什么？Token 烧完了活还没干完。

据社区分析和反向工程的代码来看，Workflow 提供了一套 budget 机制：

while (budget.remaining() > 50000) {
  const result = await agent('find-bugs', { schema: BUGS_SCHEMA })
  bugs.push(...result.bugs)
}

功能逻辑是：在每次调用 agent() 之前检查剩余 Token 预算，快不够了就停止调用，防止无限消耗。

⚠️ 补充说明：由于 /workflows 尚未正式发布，budget API 的具体实现以官方正式版为准。以上信息来自社区分析。

缓存与恢复：断了不从头跑

据社区分析的代码来看，Workflow 可能还有缓存机制：

// 相同脚本 + 相同参数 → 直接返回缓存结果
// 如果中途断了，不需要从头重来
await Workflow({ scriptPath, resumeFromRunId })

逻辑是：如果执行中断，下次可以从断点继续，不用重跑已完成的部分。

⚠️ 补充说明：由于 /workflows 尚未正式发布，缓存和恢复的具体实现以官方正式版为准。以上信息来自社区分析。

Workflow 在 Claude Code 的能力栈里排在哪

说到这，有一个问题绕不开：Workflow 跟 Claude Code 已有的 Subagent、Agent Teams、Skills 这些能力到底是什么关系？

你可以把 Claude Code 想象成一辆车。模型是发动机。MCP、Skill、Subagent、Agent Teams 这些工具是底盘、悬挂、刹车——每个部件管一摊事。但在此之前，没有一个部件管「这些工具按什么顺序配合工作」。以前这个活靠司机（模型）临场判断，今天挂几档、先踩离合还是先给油，全靠模型自己琢磨。

Workflow 就是这个部件。它不管具体的工具怎么实现，它只管「先做什么、再做什么、哪些可以并行」。这个活从模型脑子里搬到了代码里。

与这些已有能力的边界在哪里，对照着看更清楚：

  • Workflow 跟 Agent Teams 是并列关系。Agent Teams 让模型自己协调多个 agent（涌现式），Workflow 让脚本协调（确定性）。两条路线，不是替代，是你选哪条。
  • Workflow 跟 Subagent 是编排层和被编排层的关系。Workflow 内部调用 agent() 实际上就是派 Subagent 出去干活。Workflow 是导演，Subagent 是演员。
  • Workflow 跟 Skill 是互补关系。Skill 装在 Subagent 里告诉它「代码 review 应该按什么标准来」；Workflow 决定派几个 Subagent 跑、谁先谁后、出错怎么处理。

Workflow 不是替代这些已有工具，它是在这些工具之上加了一层：编排层。以前靠模型临场发挥的活儿，现在可以写成代码了。

Workflow 比传统 Agent 好在哪

一张表说清楚区别：

维度传统 Agent 调用Workflow
流程控制模型临场决定代码写死
并行能力手动管理内置 parallel/pipeline
输出格式靠 prompt 引导Schema 强制校验
缓存无自动缓存 + 断点续跑
Token 预算无内置控制budget.remaining()
可观测性无phase/log + TUI 仪表盘

核心区别不是”Workflow 更强”，而是Workflow 把控制权从模型手里还给了代码。

生成好的脚本怎么管理

Workflow 生成的脚本存在本地 .claude/workflows/ 目录下。你可以：

  • 手动编辑：想调流程顺序，直接改 JS
  • 存到 Git：团队共享，新人 clone 即用
  • 设置触发条件：支持 Cron 定时跑、API 触发、GitHub Webhook 触发
  • 嵌套调用：一个 workflow 里调用另一个 workflow

一个真实的代码审查任务，生成的脚本大概 300 行。拆成三个阶段：Review → Verify → Synthesize，调动 6 个专业审查器，跑了 97 个 Agent 轮次。整个过程在后台自动完成，终端上可以用 workflows 命令调出仪表盘查看进度。

这个仪表盘类似 htop——上下键选 Agent，Enter 看详情，ESC 回退。能看每个 Agent 在干什么、跑了多久、花了多少 Token、正在调用哪个 MCP 工具。

一些值得注意的地方

Workflow 不是万能的。简单任务上用它是浪费——Termdock 的复盘数据：简单任务（改 typo、加注释）用 Subagent，Token 消耗会膨胀到单 Session 的 4 倍。Workflow 的威力在复杂、多视角、需要审查的任务上。

当前它是双道门控：环境变量 CLAUDE_CODE_WORKFLOWS=1 + 后端 GrowthBook flag tengu_workflows_enabled 按账号灰度。设了 env 发现还没反应，不是你的问题，是账号还没进灰度。

VS Code 插件端目前冻在 2.1.145，因为 Workflow 引入的改动带出了几个回归 bug（Windows 文件锁、Bash exit code 127），Anthropic 为了不波及插件端用户，主动冻结了发布线。CLI 端在 2.1.147 到 2.1.150 之间快速迭代修补，等修完这些回归，才会推送到插件端。

这个功能目前也没有正式文档，GitHub 上 claude-code 仓库中有 13 次提交引用了这个变量，核心贡献者 ray-amjad 放出了 workflow-creator 预览仓库。

最后

Anthropic 在 Claude Code 里选择了用 JS 代码来编排 Agent——这个选择本身就是一种表态。

现在的 AI agent 主流方向是给模型更强的能力、更大的上下文窗口、更多的工具。Workflow 的方向不太一样：不是让模型更强，而是用代码把它框进一个可预期的执行框架里。模型只能在每个 agent() 节点里发挥，跳不出代码画好的跑道。

这两种思路不矛盾，但它们说明了同一个问题正在被行业认真对待：纯 prompt 驱动的 agent 不够可靠，我们需要给 AI 画跑道。

如果你想先看看 Workflow 生成的脚本长什么样，可以去看 OneRedOak/claude-code-workflows（GitHub 3.8k stars），那里有很多社区提交的 workflow 模板。

如果觉得这篇文章有帮助，欢迎点赞、在看、转发！

cover_image

Original AI兴观点 程叙架构与AI.

内容效果不满意？点此反馈

输入关键词开始搜索