Claude Code 这次最打动我的，不是它又加了一个命令，而是它终于开始认真对待“编排”这件事了。
/workflows 表面上像一个功能开关，实际上更像一条分界线。它把 agent 从“会回答问题的助手”，往“按规则干活的执行单元”推了一步。变化不吵，也不花哨，但我觉得它很实。
以前聊 agent，大家常问的是：它会不会想，会不会写，能不能帮我省点事。现在 Claude Code 把问题换了一种问法：一组 agent 怎么配合，谁先谁后，谁负责输出结构化结果，谁负责验证，谁来管预算。
这就不是聊天了。这是流程。
我为什么觉得它重要
我一直对那种“贴一个神奇 prompt，AI 突然就开窍了”的说法挺怀疑的。大多数时候，真正拉开差距的不是一句咒语，而是系统有没有把工作拆成稳定、能复用、也能追责的步骤。
Claude Code 这次正好踩在这个点上。
它不是在教你怎么更会提问，而是在给你一套更接近工程的东西：
CLAUDE.md管规则Skills管可复用能力/workflows管多步编排Routines管云端自动触发
这四层合在一起，就有点像把团队里的 SOP 慢慢写进机器里。
我挺吃这一套。因为它比“模型又聪明了”更踏实，也比“AI 会取代一切”更克制。
四层栈，干的不是一回事
CLAUDE.md 解决的是“你应该知道什么”。它像项目的规矩本身，告诉 agent 这个仓库的约束、习惯和边界。
Skills 解决的是“你应该怎么做一类事”。它把多步骤动作包起来，按需加载，轻，而且实用。
/workflows 才是最关键的一层。它解决的是“多个 agent 怎么一起干活”。一旦你开始定义顺序、分支、并行、验证，agent 就不再只是一个个孤立能力了，而是可以被组织起来的工作流节点。
Routines 解决的是“谁来在外面替你盯着跑”。这一步已经很接近自动化系统了，不再只是一次对话。
如果只看表面，这几层都像“AI 新功能”。但本质上不一样。前两层是能力封装，后两层是执行编排。前者让 AI 更好用，后者让 AI 更像能上生产线的东西。
我最看重的，不是并行，而是确定性
很多人看到多 agent，第一反应是：哇，可以同时跑很多个。
这个当然有用，但不是重点。
重点是，Claude Code 这次给 workflow 的，不只是并行能力，而是一个能拿来认真做事的编程模型：
- 用 JavaScript 定义控制流
- 用
pipeline()、parallel()、agent()这些原语组织执行 - 用 schema 强制结构化通信
- 用验证步骤拦住胡说八道
- 用预算控制别把 token 烧穿
这些东西放在一起，才像一个能交付的系统。
我尤其喜欢 pipeline()。很多任务不是“全部并行完再一起看”，而是“前一步一旦有了足够信号，下一步就能接上”。这种设计比纯并行更像真实工作，也更省等待时间。
还有 schema。这个东西看着技术，其实特别朴素：别让 agent 用自然语言互相传话，格式不对就重试。说白了，就是把“希望它理解”改成“格式不对就别过”。这比任何口头上的“更智能”都靠谱。
它真正改变的，是人的位置
当 workflow 真的能跑起来之后，人的角色就会慢慢变。
以前人主要是执行者，自己写、自己改、自己盯着。
以后更像设计者。
你要做的不是一行行盯结果，而是定义规则、拆任务、设计验证、设置边界、看失败日志。人的价值会从“手工干活”往“搭框架、定标准、做判断”移动。
我觉得这是好事。人最该保留的，本来就不是重复劳动，而是判断力。
一个 workflow 大概长什么样
只讲概念还是有点虚，还是看代码最直观。
export default workflow("review-issue", async ({ agent, pipeline, parallel }) => {
const plan = await agent("planner", {
prompt: "阅读需求，输出 JSON 计划，只保留 steps / risks / budget",
schema: {
type: "object",
properties: {
steps: { type: "array", items: { type: "string" } },
risks: { type: "array", items: { type: "string" } },
budget: { type: "number" }
},
required: ["steps", "risks", "budget"]
}
})
const result = await pipeline(
agent("researcher", {
prompt: `根据这份计划做资料整理：${JSON.stringify(plan)}`
}),
parallel(
agent("writer", {
prompt: "根据前面的结果写出执行草案"
}),
agent("reviewer", {
prompt: "检查草案是否漏掉风险和边界条件"
})
),
agent("verifier", {
prompt: "检查前面的输出是否符合 schema，不符合就返回错误原因"
})
)
return result
})
不用纠结这个例子是不是 Claude Code 里唯一正确的写法，重点是结构：先产出计划，再分工，再验证，最后收口。真正值钱的不是某一个函数名，而是你终于可以把 agent 当成流程里的节点来排。
如果这一步能和 Skills、Routines、沙箱、连接器继续接起来，很多原本只存在于 SOP 文档里的动作，才真的有机会变成能跑的系统。
如果让我一句话总结
/workflows 不是让 Claude Code 更会聊天，而是让它第一次有了“编排别人干活”的能力。
这件事的分量不小。
它把 agent 从“聪明的助手”往“可编程的流程节点”推了一步。等这一步再和 Skills、Routines、沙箱、连接器、验证链条接起来，很多原本只存在于 SOP 文档里的动作，才真的有机会变成能跑的系统。
我不觉得它会立刻改变所有人。但我觉得它会悄悄改掉一些很关键的东西：
谁来设计流程，谁来验证结果，谁来负责边界，谁来决定机器可以自动到什么程度。
这类变化通常不会先出现在发布会最响的那一段。它先发生在工具深处。
这次我觉得，Claude Code 是往那里下手了。