apm::badge
[](https://apm-p1ls2dz87-atlamors-projects.vercel.app/packages/@wwsun/clippings)80 多个节点的 workflow，稳定性和可调整性真的不是 subagent 能比拟的吗？本文通过五步框架，展示如何用 Agent + Skills 架构实现复杂工作流，并正面回应稳定性、成本和门槛三大质疑。
apm install @wwsun/clippings[](https://apm-p1ls2dz87-atlamors-projects.vercel.app/packages/@wwsun/clippings)---
description: 80 多个节点的 workflow，稳定性和可调整性真的不是 subagent 能比拟的吗？本文通过五步框架，展示如何用 Agent + Skills 架构实现复杂工作流，并正面回应稳定性、成本和门槛三大质疑。
source: https://baoyu.io/blog/2026/01/10/agent-skills-replace-workflow
author:
created: 2026-01-14
tags:
- clippings
- claude-code
---
"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.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 生成图片，最后将图片插入文章对应位置。”
**一个 skill 可以调用另一个 skill，组合出复杂的工作流** 。
![[Pasted image 20260114145132.png]]
### 第三步，存储
这一步特别重要： **所有中间结果都保存成本地文件** 。
三个好处：
- **可追溯** ：出问题了能看到每一步的输出
- **可断点续传** ：中途停了，下次从上次的位置继续
- **可人工干预** ：不满意某一步的结果，手动改完让 Agent 继续
我的文件结构是这样的：
```
source.md → analysis.md → outline-a.md → draft-outline-a.md → final.md
```
每一步的产出都有迹可循。配图流程同理，生成的图片按目录组织，和文章关联。
![[Pasted image 20260114145157.png]]
### 第四步，分摊
**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”，不妨想想：真的吗？还是只是没找到正确的拆分方式？
---
[See all posts](https://baoyu.io/translations)