【黄啊码】你抛弃的扣子工作流，Claude Code 捡回来了

去年我在扣子（Coze）上做过不少智能体，当时几个智能体的使用量已经超过 200w，还多次霸榜，那时候我一边嫌它画布味太重，一边又不得不承认，它确实把很多原本只有工程师能碰的自动化流程，交到了运营、产品、内容团队手里。

后来“龙虾智能体”这类更强的智能体形态出来后，也有人问我：工作流时代会不会被抛弃？我的回答一直是：不会，因为企业里的大量 SOP，它是固定的流程。

扣子工作流为什么让人又爱又恨？

公平地说，扣子（Coze）工作流是国内做得很顺手的低代码编排之一。它能让运营和产品都能上手，飞书、微信、知识库、定时任务这些能力也接得很自然。

image.png

我早期能靠扣子智能体拿到超过 200w 使用量，并且多次冲上榜单，就是因为它确实解决了真实的用户场景问题。

但它的问题也同样真实，流程由平台解释执行，变量怎么传、异常怎么处理、某个节点为什么没进分支，很多时候只能靠日志和猜，但一旦让 LLM 在条件节点里做“意图识别”或“下一步选择”，它就可能把本来应该确定的控制流变成概率事件。

你明明设计的是 A→B→C，它非要“我觉得用户可能想要 D”。我谢谢你哦，不要你觉得，我要我觉得在这里充分表现出来了。

所以我一直觉得，扣子工作流是给业务人员设计的流水线，它擅长把一个已知流程快速跑通，但很难成为可复用的工程资产。

Claude Code /workflows

近期，GitHub 贡献者 ray-amjad 放出了 workflow-creator 预览仓库，不过它出现得快，消失得也很快，现在官方的变更日志里边已经找不到了。

image.png

不过Claude Code v2.1.147+ 里也藏着一个需要手动开启的功能，开启后输入 ultrawork + 需求，它不会立刻执行，它会先生成 context.md，再自己写出一份纯 Node.js 控制脚本，以下是开启指令：

export CLAUDE_CODE_WORKFLOWS=1 claude

image.png

据网友的实测案例里，它为一个 PR 审查任务生成了约 300 行 JS，把流程拆成审查代码、验证结果、生成报告三个阶段，还调起 6 个专业审查器，累计跑了 97 个 Agent 轮次。

还有就是输入 /workflows 还能唤出类似 htop 的 TUI 面板，实时看每个 Agent 的状态、耗时、Token 消耗和调用过的 MCP 工具。

image.png

核心差异：Code as Law，不让模型控制流程

Claude Code Workflows 和扣子工作流最大的区别，不是界面从画布换成终端，而是控制权变了，在扣子或传统 Agent 协作里，流程常常是：节点大概这么连，具体怎么走，看模型理解。

但在 Claude Code Workflows 里，流程是 JS 脚本硬编码出来的。【感觉在 AI 时代，JS 才是最快出效果的方式】。

模型只能在 agent() 节点内部工作。它可以审查代码、总结文档、调用工具、生成报告，但不能跳出 JS 控制逻辑，不能擅自决定“我觉得下一步应该去另一个分支”。

AI 负责执行，代码负责固定规则。

如果这个判断成立，那么 Workflows 的意义是在把企业里的标准化节点，从人手里交给代码，网友将其评价为： Code as Law，代码是最高法律，AI 只是执行者，我觉得这种说法挺有道理的。

SOP as Code

很多团队的 SOP，过去都写在 Confluence、飞书文档、Wiki 里。比如发版前跑静态扫描、检查依赖许可证、跑 API 兼容性测试、生成变更报告、通知负责人、归档审计材料，文档写得很完整，新人就算看多几遍，照样漏步骤。

image.png

Claude Code Workflows 的理想形态，就是把团队沉淀了几年的发版检查、代码审查、安全扫描、内容生产、客服质检流程，写成 JS，放进项目目录 .claude/workflows/，然后跟随 Git 一起版本管理，新人 git clone 下来，就拿到了完整流水线，跑一次，就是标准执行一遍，这跟我们常见的 SOP 简直如出一辙。

Claude Code Workflows的三个代价

技术圈每个月都有“重新定义未来”的东西，最后一半重新定义了收藏夹吃灰方式，Claude Code Workflows 同样不例外，目前至少有三个现实代价。

1. Token 仍然烧钱

本地的 for / while / parallel 控制流不耗 Token，但每一个 agent() 节点都要读上下文、调用模型、产出结果和审查，控制流免费，不代表 tokens 免费。

2. 速率限制会很快撞上

短时间派出多个长文本 Agent，很容易打满云厂商 TPM（Tokens Per Minute），如果像某些大厂提供的并发数，我相信这件事在实现的基础就有一定的难度。

3. 默认只是临时资产

Claude Code 生成的 Workflow JS 脚本默认存在临时目录，通常 3 天后会被静默删除，临场生成的脚本，先当临时资产处理，验证通过后再显式复制到项目工作流目录里，所以做好的工作流，别忘记保存起来了。

工作流不会死，只会换一种形态回来

回到开头那个问题，当更强的智能体出来后，工作流时代会被抛弃吗？我的答案还是：不会。

image.png

智能体适合探索未知问题，工作流适合固化已知流程。企业真实运转里，大量高频任务并不需要天马行空的智能，它们需要的是每次都按同样顺序执行、每个关键节点都有记录、出错能复现、规则能审查、经验能沉淀、新人能直接继承。

扣子让普通人第一次感受到：原来我也能搭工作流，Claude Code Workflows 则在尝试证明：工作流不只是低代码玩具，也可以是严肃的工程组件。关键前提只有一个，把流程控制权从模型手里拿回来，还给代码。

在黄啊码看来，这一次的工作流，不仅仅不是低代码工具了，它把口喷式生成工作流的未来迈进了新的台阶。