五步框架：把 Workflow 变成可进化的 Skill

AI Agent + Skills 架构到底怎么碘伏传统 workflow？有没有一套方法论，能帮我们快速上手？

核心内容：

• 传统 workflow 编排的优势与局限性分析
• Agent + Skills 架构的降维打击优势
• 五步框架实战：从写作到配图的可组合技能设计

“80 多个节点的 workflow，稳定性和可调整性，不是 subAgent 能比拟的”。

前段时间，在 X 上和朋友 pippingg 聊到 Dify 这类可视化拖拽 workflow 和 Claude Code Skills 的对比，就提到了这句话。

这话对，也不对。

对在哪里？传统 workflow 编排的确有其核心价值——每次执行结果可控，出了故障能一步步倒查，非技术人员也能轻易看懂流程图。这些实打实的优势，谁都无法否认。

不对在哪里？很多人低估了 AI Agent + Skills 架构的潜力。从实践来看，一个激进的观点是：

。

Workflow 编排的“舒适区”

可视化工作流工具能火起来，不是没有道理。

拖拽节点、连连线，一个自动化流程就搭好了。不用写代码，改起来也直观。更重要的是，它给你

——节点 A 执行完一定是节点 B，不会突然跳到节点 C。对于需要审计、需要合规的业务场景，这种确定性弥足珍贵。

但 workflow 编排也有硬伤。

。可视化节点能做的事情有限，复杂逻辑很难表达。

。一旦流程定型，遇到输入变化就容易出问题。你设计的流程是处理 A 类文档的，来了 B 类文档，整个流程可能就卡住了。

。搭了个很厉害的工作流，想给别人用？导出导入一通操作，还得在对方环境里调半天。平台锁定效应明显。

Agent + Skills 的“降维打击”

一个看法可能比较激进：几乎所有能用 workflow 完成的 AI 任务，都可以用 Agent + Skills 实现。

关键在于怎么理解 skill。很多人把 skill 当成单一技能——比如一个 skill 负责翻译，另一个负责总结。这样用太浪费了。

。你可以把多个 skill 串起来，用自然语言描述它们之间的协作关系。换句话说，用自然语言去编排工作流，而不是用拖拽。

一个五步框架值得关注，用写作工作流来演示最直观。

第一步，拆分

把工作流拆成单一职责的 skill 或 subagent。每个模块只做一件事，并且把这件事做好。

以写作工作流为例，拆成了这些模块：

• article-analyzer：分析素材，输出 analysis.md
• outliner：生成 2-3 个提纲方案
• writer-agent：根据提纲写草稿（可并行启动多个）
• polish：润色定稿

再看配图工作流，也是同样的思路：

• generate-image：原子技能，调用图像生成 API
• article-illustrator：组合技能，分析文章内容，在需要视觉辅助的位置生成插图
• cover-image：组合技能，基于文章内容生成 2.35:1 的封面图

然后写作和配图又可以组合成一个更完整的写作工作流。你原来在 workflow 工具里画的每个功能节点，基本都可以对应一个 skill。

第二步，编排

在主 skill 里用自然语言描述整个流程。不需要写代码，就像给同事交代任务一样说清楚就行。

比如 outliner 技能里会写：“先调用 article-analyzer 分析素材，分析完成后保存 analysis.md，然后根据分析结果生成 2-3 个不同风格的提纲方案，为每个方案并行启动 writer-agent 写草稿。”条件分支、并行执行、错误处理，都可以用自然语言描述，Agent 能理解。

再看 article-illustrator 的编排逻辑：“读取文章内容，识别需要配图的位置（概念抽象处、信息密集处、情感转折处），为每个位置生成图像描述，调用 generate-image 生成图片，最后将图片插入文章对应位置。”

。

第三步，存储

这一步特别重要：

。

三个好处：

• 可追溯
  ：出问题了能看到每一步的输出

• 可断点续传
  ：中途停了，下次从上次的位置继续

• 可人工干预
  ：不满意某一步的结果，手动改完让 Agent 继续

文件结构是这样的：

source.md → analysis.md → outline-a.md → draft-outline-a.md → final.md

每一步的产出都有迹可循。配图流程同理，生成的图片按目录组织，和文章关联。

第四步，分摊

。

这条规则很关键。如果直接把一大段内容塞给 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 呢？每次执行可能走不同的路径，结果不可预测。

一个公平的回应是：

。

你可以把需要确定性的部分写成脚本。那 80 个节点里，有多少是需要 AI 判断的？有多少只是固定的数据处理？固定的部分用脚本实现，skill 调用这个脚本就行。

举个例子，写作流程里有个格式化步骤：把中文引号换成全角、中英文之间加空格。这种规则明确的操作，写了个 format-markdown.ts 脚本。polish 技能执行完润色后，自动调用这个脚本处理格式。

Anthropic 在设计 Skills 时也强调了这一点：“Skills 可以包含可执行代码，用于那些传统编程比 token 生成更可靠的任务。”这是

的思路：代码处理确定性逻辑，Agent 处理需要判断的任务。两者各司其职，取长补短。

质疑二：成本太高

没错，Agent 执行确实更费 token。每调用一次模型都在烧钱，复杂任务可能要调用几十次。

但成本要算总账。

• 开发成本
  ：workflow 的节点要一个个配，skill 可以用自然语言描述。后者更快。

• 维护成本
  ：workflow 改起来要小心翼翼怕影响其他节点，skill 改起来更灵活。

• 迭代成本
  ：workflow 优化需要人工分析，skill 可以让 AI 帮你改进。

几个案例很说明问题。

用 Claude Skills 处理财务报表，自动处理多个电子表格、捕捉关键异常、按公司流程生成报告。原本一天的工作现在一小时完成，。

用 Skills 让用户可以即时将存储的文件转换为 PowerPoint、Excel、Word 文档，并自动遵循企业风格指南。为团队节省了数小时的手工操作。

这些案例说明：token 成本在整体效率提升面前根本不算什么。而且 Skills 采用“按需加载”的设计——只加载当前任务需要的信息，而不是把所有上下文都塞给模型。这本身就是在优化成本。

质疑三：门槛太高

把 workflow 转化成 skill 需要抽象能力。普通用户搭可视化流程可以，让他写 skill 配置文件？太难了。

但这个问题正在被解决。

。借用 /skill-creator，你把需求描述清楚，Claude Code 可以帮你生成 skill 的配置。很多 skill 不是手写的，是让 AI 帮忙生成然后再调整。

长期来看，skill 比 workflow 更易维护。因为它是文本文件，可以用 Git 管理版本，可以代码审查，可以在不同机器间同步。Workflow 呢？锁在平台里，换个环境就得重来。

边界在哪里

这并不意味着 workflow 毫无价值。两种方案各有适用场景。

• 输入多变、需要判断的任务
  。比如处理不同格式的文档，分析各种类型的数据。Agent 可以根据输入灵活调整处理方式。

• 跨系统协调的复杂流程
  。需要调用多个 API、访问多个数据源、协调多个工具。Agent 配合 MCP（Model Context Protocol）可以即插即用地接入各种服务。

• 需要频繁迭代的工作流
  。今天这样做，明天可能要调整。Skill 改起来比 workflow 方便得多。

• 需要分享复用的自动化逻辑
  。Skill 就是几个文件，打包发给别人就能用。比导出 workflow JSON 再导入方便多了。

• 严格审计要求的合规流程
  。金融、医疗这类行业，每一步操作都要可追溯、可审计。固定的 workflow 更容易满足监管要求。

• 超高频执行的简单任务
  。每秒执行几百次的简单操作，固定脚本比 Agent 划算得多。

• 非技术用户的可视化需求
  。让业务人员自己看懂、自己调整流程，可视化编排确实更友好。

一个被低估的优势：可进化

Skill 架构有个经常被忽略的好处：

。

传统 workflow 一旦搭好，基本就定型了。改动需要人工介入，要小心测试，改完可能还会引入新问题。

但 skill 不一样。它是基于本地文件系统的，你可以让 Claude Code 帮你维护更新。用了一段时间，积累了一些问题，直接让 AI 分析并改进。

更激进一点的玩法是 pippingg 提到的：subagent 可以自我迭代 system prompt。

Claude Code 还有一个很强但很少人用的地方，是可以自己迭代 subagent 的 system prompt，配合 ralph-loop，已经可以完成自我迭代进化了。在 token 和系统资源充足的情况下，能进化成非常恐怖的存在。

听起来有点科幻，但已经有人在实践了。

McKinsey 的报告也印证了这一点：在一个法律文档审核流程中，agent 系统会记录每次人工修正，然后用这些反馈来改进自己的 prompt，逐渐将新的专业知识编码进系统。

这意味着什么？你投入时间打造的 skill，会随着使用越来越好。而不是像 workflow 那样，搭好就开始慢慢过时。

把你常用的 workflow 沉淀为 skill 吧。这不只是换个工具的问题，而是在积累可复用、可进化的自动化资产。

下次有人说“这个流程太复杂，只能用 workflow”，不妨想想：真的吗？还是只是没找到正确的拆分方式？