你可能不再需要 workflow，大部分场景 skills 足矣——五步框架把 Workflow 变成可进化的 Skill
宝玉
"80 多个节点的 workflow，稳定性和可调整性，不是 subagent 能比拟的。"
上面这话这是我在 X 上和朋友 pippingg 的一次围绕 Dify 这样可视化拖拽 workflow 和 Claude Code Skills 的一次讨论。
这话对，也不对。
对在哪里？传统 workflow 编排的确有它的核心价值——每次执行结果可预测，出了问题能一步步排查，普通人也能看懂流程图。这些优势实实在在。
不对在哪里？很多人低估了 AI Agent + Skills 架构的潜力。我的观点是：大部分 workflow 编排场景，都可以被 Agent + Skills 取代。
Workflow 编排的“舒适区”
可视化工作流工具能火起来，是有道理的。
拖拽节点、连连线，一个自动化流程就搭好了。不用写代码，改起来也直观。更重要的是，它给你确定性——节点 A 执行完一定是节点 B，不会突然跳到节点 C。对于需要审计、需要合规的业务场景，这种确定性很重要。
但 workflow 编排也有硬伤。
它不够强大。可视化节点能做的事情有限，复杂逻辑很难表达。
它不够灵活。一旦流程定死，遇到输入变化就容易出错。你设计的流程是处理 A 类文档的，来了 B 类文档，整个流程可能就卡住了。
它难以移植。你搭了个很厉害的工作流，想给别人用？导出导入一通操作，还得在对方环境里调半天。平台锁定效应明显。
Agent + Skills 的"降维打击"
我的看法可能比较激进：几乎所有能用 workflow 完成的 AI 任务，都可以用 Agent + Skills 实现。
关键在于怎么理解 skill。很多人把 skill 当成单一技能——比如一个 skill 负责翻译，另一个负责总结。这样用太浪费了。
Skill 应该被看作可组合的模块。你可以把多个 skill 串起来，用自然语言描述它们之间的协作关系。换句话说，用自然语言去编排工作流，而不是用拖拽。
我总结了一个五步框架，用我自己的写作工作流来演示。
第一步，拆分
把工作流拆成单一职责的 skill 或 subagent。每个模块只做一件事，做好一件事。
以我的写作工作流为例，拆成了这些模块：
article-analyzer：分析素材，输出 analysis.mdoutliner：生成 2-3 个提纲方案writer-agent：根据提纲写草稿（可并行启动多个）polish：润色定稿
再看配图工作流，也是同样的思路：
generate-image：原子技能，调用图像生成 APIarticle-illustrator：组合技能，分析文章内容，在需要视觉辅助的位置生成插图cover-image：组合技能，基于文章内容生成 2.35:1 的封面图
然后写作和配图又可以组合成一个更完整的写作工作流。
你原来在 workflow 工具里画的每个功能节点，基本都可以对应一个 skill。
第二步，编排
在主 skill 里用自然语言描述整个流程。不需要写代码，就像给同事交代任务一样说清楚就行。
比如我的 outliner 技能里会写：“先调用 article-analyzer 分析素材，分析完成后保存 analysis.md，然后根据分析结果生成 2-3 个不同风格的提纲方案，为每个方案并行启动 writer-agent 写草稿。”
条件分支、并行执行、错误处理，都可以用自然语言描述。Agent 能理解。
再看 article-illustrator 的编排逻辑：“读取文章内容，识别需要配图的位置（概念抽象处、信息密集处、情感转折处），为每个位置生成图像描述，调用 generate-image 生成图片，最后将图片插入文章对应位置。”
一个 skill 可以调用另一个 skill，组合出复杂的工作流。
第三步，存储
这一步特别重要：所有中间结果都保存成本地文件。
三个好处：
可追溯：出问题了能看到每一步的输出
可断点续传：中途停了，下次从上次的位置继续
可人工干预：不满意某一步的结果，手动改完让 Agent 继续
我的文件结构是这样的：
source.md → analysis.md → outline-a.md → draft-outline-a.md → final.md每一步的产出都有迹可循。配图流程同理，生成的图片按目录组织，和文章关联。
第四步，分摊
Subagent 之间只传文件路径，不传内容。
这条规则很重要。如果你把一大段内容直接塞给 subagent，上下文窗口很快就撑满了。但如果只传路径，subagent 自己去读文件，上下文就干净很多。
我的 writer-agent 启动时只需要三个参数：source 文件路径、analysis 文件路径、outline 文件路径。它自己读取内容，写完保存到指定路径，返回输出文件路径。
这样做还有个好处：可以并行启动多个 subagent。三个 writer-agent 同时跑，各自处理一个提纲方案，互不干扰。
第五步，迭代
这是 Agent + Skills 相比传统 workflow 最大的优势：可以持续进化。
发现某个 skill 的提示词不够好？让 Claude Code 帮你改。某个流程步骤可以优化？随时调整。你的 skills 会越用越好，而不是搭完就放在那儿吃灰。
这一点是 pippingg 在讨论中特别强调的：subagent 可以自己迭代 system prompt，配合一些自动化工具，甚至能完成自我迭代进化。在 token 和系统资源充足的情况下，这套系统会变得越来越强。
正面应对三大质疑
有人会说：你这套东西听起来挺美，但……
质疑一：稳定性怎么办？
这是最有力的反驳。80 个节点的 workflow 确实经过了反复验证，每个分支都测试过，稳定性有保障。Agent 呢？每次执行可能走不同的路径，结果不可预测。
我的回应是：确定性逻辑不一定要交给 Agent。
你可以把需要确定性的部分写成脚本。那 80 个节点里，有多少是需要 AI 判断的？有多少只是固定的数据处理？固定的部分用脚本实现，skill 调用这个脚本就行。
举个例子，我的写作流程里有个格式化步骤：把中文引号换成全角、中英文之间加空格。这种规则明确的操作，我写了个 format-markdown.ts 脚本。polish 技能执行完润色后，自动调用这个脚本处理格式。
Anthropic 在设计 Skills 时也强调了这一点：“Skills 可以包含可执行代码，用于那些传统编程比 token 生成更可靠的任务。”这是混合架构的思路：代码处理确定性逻辑，Agent 处理需要判断的任务。两者各司其职，取长补短。
质疑二：成本太高
没错，Agent 执行确实更费 token。每调用一次模型都在烧钱，复杂任务可能要调用几十次。
但成本要算总账。
开发成本：workflow 的节点要一个个配，skill 可以用自然语言描述。后者更快。
维护成本：workflow 改起来要小心翼翼怕影响其他节点，skill 改起来更灵活。
迭代成本：workflow 优化需要人工分析，skill 可以让 AI 帮你改进。
几个案例很说明问题。
Rakuten（乐天） 用 Claude Skills 处理财务报表，自动处理多个电子表格、捕捉关键异常、按公司流程生成报告。原本一天的工作现在一小时完成，8 倍效率提升。
Box 用 Skills 让用户可以即时将存储的文件转换为 PowerPoint、Excel、Word 文档，并自动遵循企业风格指南。为团队节省了数小时的手工操作。
这些案例说明：token 成本在整体效率提升面前根本不算什么。而且 Skills 采用“按需加载”的设计——只加载当前任务需要的信息，而不是把所有上下文都塞给模型。这本身就是在优化成本。
质疑三：门槛太高
把 workflow 转化成 skill 需要抽象能力。普通用户搭可视化流程可以，让他写 skill 配置文件？太难了。
但这个问题正在被解决。AI 本身就能帮你创建 skill。借用 /skill-creator，你把需求描述清楚，Claude Code 可以帮你生成 skill 的配置。我自己就是这么干的——很多 skill 不是我手写的，是让 AI 帮我生成然后再调整。
长期来看，skill 比 workflow 更易维护。因为它是文本文件，可以用 Git 管理版本，可以代码审查，可以在不同机器间同步。Workflow 呢？锁在平台里，换个环境就得重来。
边界在哪里
我不是说 workflow 毫无价值。两种方案各有适用场景。
Agent + Skills 更适合：
输入多变、需要判断的任务。比如处理不同格式的文档，分析各种类型的数据。Agent 可以根据输入灵活调整处理方式。
跨系统协调的复杂流程。需要调用多个 API、访问多个数据源、协调多个工具。Agent 配合 MCP（Model Context Protocol）可以即插即用地接入各种服务。
需要频繁迭代的工作流。今天这样做，明天可能要调整。Skill 改起来比 workflow 方便得多。
需要分享复用的自动化逻辑。Skill 就是几个文件，打包发给别人就能用。比导出 workflow JSON 再导入方便多了。
Workflow 仍有优势的场景：
严格审计要求的合规流程。金融、医疗这类行业，每一步操作都要可追溯、可审计。固定的 workflow 更容易满足监管要求。
超高频执行的简单任务。每秒执行几百次的简单操作，固定脚本比 Agent 划算得多。
非技术用户的可视化需求。让业务人员自己看懂、自己调整流程，可视化编排确实更友好。
一个被低估的优势：可进化
Skill 架构有个经常被忽略的好处：它是活的，可以不断进化。
传统 workflow 一旦搭好，基本就定型了。改动需要人工介入，要小心测试，改完可能还会引入新问题。
但 skill 不一样。它是基于本地文件系统的，你可以让 Claude Code 帮你维护更新。用了一段时间，积累了一些问题，直接让 AI 分析并改进。
更激进一点的玩法是 pippingg 提到的：subagent 可以自我迭代 system prompt。
cc 还有一个很强但很少人用的地方，是可以自己迭代 subagent 的 system prompt，配合 ralph-loop，已经可以完成自我迭代进化了。在 token 和系统资源充足的情况下，能进化成非常恐怖的存在。
听起来有点科幻，但已经有人在实践了。
McKinsey 的报告也印证了这一点：在一个法律文档审核流程中，agent 系统会记录每次人工修正，然后用这些反馈来改进自己的 prompt，逐渐将新的专业知识编码进系统。
这意味着什么？你投入时间打造的 skill，会随着使用越来越好。而不是像 workflow 那样，搭好就开始慢慢过时。
把你常用的 workflow 沉淀为 skill 吧。这不只是换个工具的问题，而是在积累可复用、可进化的自动化资产。
下次有人说“这个流程太复杂，只能用 workflow”，不妨想想：真的吗？还是只是没找到正确的拆分方式？