去年在扣子上折腾了不少智能体，几个产品的使用量累计突破200万，还混了几次榜单。那会儿一边吐槽它画布味儿太重，一边又不得不承认，它确实把不少原本只有工程师能碰的自动化流程，递到了运营、产品、内容团队手里。
后来“龙虾智能体”这类更强形态出现，有人问：工作流时代是不是要被淘汰了？答案一直没变：不会，因为企业里的大量SOP，天生就是固定流程。
扣子工作流为什么让人又爱又恨？
公平地说，扣子工作流是国内做得相当顺手的低代码编排工具之一。运营和产品都能上手，飞书、微信、知识库、定时任务这些能力接得自然，早期能靠它冲上200万使用量，正是因为解决了真实的用户场景问题。
image.png
但问题同样真实。流程由平台解释执行，变量怎么传、异常怎么处理、某个节点为什么没进分支，很多时候只能靠日志和猜。一旦让LLM在条件节点里做“意图识别”或“下一步选择”，本来确定的控制流就可能变成概率事件。所以扣子工作流本质上是给业务人员设计的流水线——它擅长把已知流程快速跑通，但很难成为可复用的工程资产。
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负责执行，代码负责固定规则。
维度 | 扣子工作流 | Claude Code Workflows |
|---|---|---|
控制流谁来定 | 画布连线 | 纯JS硬编码确定执行 |
模型权限 | 严格执行节点路径 | 在agent()内执行 |
版本管理 | 画布版本管理 | JS文件可入Git |
可观测性 | 平台日志 | TUI面板逐Agent追踪 |
如果这个判断成立，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则在尝试证明：工作流不只是低代码玩具，也可以是严肃的工程组件。关键前提只有一个——把流程控制权从模型手里拿回来，还给代码。
可以说，这一次的工作流，已经不是低代码工具那么简单了，它把“口喷式生成工作流”这件事推上了新台阶。
