欢迎阅读「从零开始写好 Skill」系列 —— 上一个系列我们用 7 篇文章拆解了 Agent 的骨架，这个系列教你给 Agent 写"工作手册"。

• 第一篇：Skill 是什么？为什么你应该关心它
• 第二篇：一个好 Skill 长什么样——SKILL.md 的解剖
• 第三篇：手把手写你的第一个 Skill
• 第四篇：写 Skill 太费劲？让 skill-creator 来帮你
• 第五篇：拆开写，串起用——Skill 的组合之道（本文）

作者：十一

▍开场：一个 Skill 解决一个问题，多个 Skill 解决一整件事

前四篇我们一直在聊"一个 Skill"——怎么理解它、怎么拆解它、怎么从零写一个、怎么用工具加速迭代。

但真实的工作场景，很少是一个 Skill 就能搞定的。

回到贯穿这个系列的例子：你在群里看到一篇好文章，想保存并总结。这件事需要两步——先抓取，再总结。对应两个 Skill：wespy-fetcher 管抓取，article-summarizer 管总结。

你不会把"抓取"和"总结"写进同一个 Skill 里。那样 Skill 就会变得臃肿——想只抓取不总结？不行，得连带跑一遍总结。想总结一篇本地已有的文章？不行，得先走一遍抓取流程。两个功能绑死在一起，哪个都不灵活。

正确的做法是各管各的，各做各的，需要组合的时候再串起来。

但问题来了：分开之后，它们怎么配合？

▍一、最简单的配合：接力

wespy-fetcher + article-summarizer 就是最典型的接力。

用户说："帮我保存并总结这篇公众号文章。"

Agent 判断这件事需要两个 Skill，于是：

• 第一棒：调用 wespy-fetcher，输入公众号链接，抓取文章内容，输出一个 Markdown 文件，保存到本地。
• 第二棒：调用 article-summarizer，读取刚才保存的 Markdown 文件，按照结构化格式输出要点总结。

第一个 Skill 的输出，就是第二个 Skill 的输入。这就是接力——上一个 Skill 交出"接力棒"（Markdown 文件），下一个 Skill 接住继续跑。

这个过程中，用户只说了一句话。Agent 自己判断该用哪些 Skill、按什么顺序调用。两个 Skill 的作者不需要互相认识，甚至不需要知道对方的 Skill 存在——只要各自的输入输出格式兼容，就能组合。

但"格式兼容"这件事不是自动发生的。接力能成立，有一个前提：两个 Skill 之间有一个约定好的"交接格式"。

wespy-fetcher 输出的是 Markdown 文件。article-summarizer 的操作流程第一步是"通读全文"——它默认输入就是一篇文本内容。Markdown 对接 Markdown，天然兼容。

但如果 wespy-fetcher 输出的是一个特殊的 JSON 结构，而 article-summarizer 只认纯 Markdown 文本呢？接力棒的形状不匹配，交接就断了。

这引出第一个设计意识：写 Skill 的时候，要想一步——你的输出能不能被别的 Skill 接住？

不需要为某个特定的下游 Skill 做适配，只需要遵循通用的格式约定。输出文本内容就用 Markdown，输出结构化数据就用 JSON，输出文件就存到常规路径。这样任何人写的 Skill 都能和你的组合使用。

这其实和 Unix 的管道哲学是一回事：每个程序做一件事，用文本流串起来。Skill 的世界也一样——每个 Skill 做一件事，用通用格式串起来。

▍二、进阶配合：分工

接力是串行的——A 做完，B 接着做。但有些场景需要并行——多个 Skill 同时处理同一个输入的不同方面。

设想一个场景：你写完了一篇技术博客，想在发布前做一次全面检查。

你可能需要三个维度的审查：

• 内容准确性：技术细节有没有错误？引用的数据有没有过时？
• 可读性：结构是否清晰？段落过渡是否自然？有没有行话需要解释？
• 发布规范：标题格式、标签、封面图、SEO 描述是否齐全？

如果写成一个 Skill，它要同时关注这三个维度，SKILL.md 会非常臃肿，而且很难维护——改一条发布规范就要去翻整个 Skill。

更好的做法是三个 Skill 各管一个维度：一个审查内容准确性，一个审查可读性，一个检查发布规范。三个 Skill 看的是同一篇文章，但各自只关注自己的维度。

Agent 可以依次调用三个 Skill，也可以并行调用（部分 Agent 支持通过子代理并发执行），最后把三份审查结果汇总成一份完整的检查报告。

分工模式的关键是：每个 Skill 的职责边界要清晰，不能互相越界。

如果"内容审查 Skill"里也检查了标题格式，"发布规范 Skill"里也评价了内容深度，Agent 就会在汇总时遇到重复甚至矛盾的结论——一个说"标题太长"，另一个说"标题信息量够"。

这就是为什么第二篇反复强调"概述要划边界"——不只是为了单个 Skill 的准确性，更是为了多个 Skill 协作时不打架。每个 Skill 在概述里写清楚"我管什么、不管什么"，就是在和其他 Skill 约定协作边界。

▍三、更高级的配合：编排

接力和分工都有一个共同点：由 Agent 自己判断该调哪些 Skill、按什么顺序调。大多数简单场景这样就够了。

但有些复杂的工作流，步骤固定、顺序不能乱、中间还有条件判断——你不想每次都靠 Agent 临场发挥，希望有一个 Skill 专门负责"指挥"其他 Skill。

这就是编排模式：一个 Skill 不干具体的活，只负责按顺序调用其他 Skill，串起整个流程。

wlzh/skills仓库（https://github.com/wlzh/skills）里有一个真实案例：youtube-to-xiaoyuzhou。它的任务是把 YouTube 视频转成小宇宙播客，整个流程涉及好几步：

1. 调用 video-downloader 下载 YouTube 视频/音频
2. 调用 audiocut-keyword 过滤掉音频中的广告关键词
3. 调用 voice-changer 对音频进行变声处理
4. 调用 image-generator 生成封面图
5. 按照小宇宙的发布要求打包上传

youtube-to-xiaoyuzhou 自己不会下载视频，不会过滤关键词，不会变声——这些活都是其他 Skill 干的。它只负责一件事：按正确的顺序把这些 Skill 串起来，在它们之间传递参数和文件。

它的 SKILL.md 里会直接写明：

• 第一步调用 video-downloader，传入 YouTube 链接
• 拿到音频文件后调用 audiocut-keyword，传入关键词配置
• 过滤完成后调用 voice-changer，传入声音预设
• ……

这和前面的"接力"有什么区别？

接力模式下，Agent 自己判断"下一步该调什么"。编排模式下，流程写死在 Skill 里，Agent 不需要判断，按剧本执行就行。

什么时候该用编排？当一个工作流满足这三个条件时：

• 步骤固定：每次都是同样的几步，顺序不变
• 频繁重复：你发现自己总是手动触发同样的 Skill 组合
• 中间有依赖：上一步的输出是下一步的输入，而且参数传递有讲究

如果你只是偶尔"先抓取再总结"，让 Agent 自己判断就够了。但如果你每天都在做"下载 → 过滤 → 变声 → 发布"这个固定流程，就值得写一个编排 Skill 把它固化下来。

编排 Skill 还有一个好处：它是一个可以分享的工作流。你把 youtube-to-xiaoyuzhou 分享给同事，他不需要知道背后有哪些 Skill、怎么串，一条命令就能跑通整个流程。

▍四、反面案例：什么时候不该拆

讲完了怎么组合，还要讲一个容易犯的错误：过度拆分。

不是所有事情都要拆成多个 Skill。如果你把一个简单任务拆成了三个 Skill，每个 Skill 只做一小步，会出现什么情况？

Agent 需要先判断"这件事要调哪几个 Skill"，然后判断"按什么顺序调"，中间还可能遇到"这步的输出格式和下步的输入不匹配"的问题。整体效果可能还不如一个 Skill 直接搞定。

拆分的依据是"复用"，不是"好看"。

wespy-fetcher 和 article-summarizer 值得拆成两个 Skill，是因为它们各自有独立的使用场景：

• 有时候你只想抓取文章存下来，不需要总结
• 有时候文章已经在本地了（比如你自己写的草稿），只需要总结
• wespy-fetcher 可以和其他处理类 Skill 组合（比如翻译、朗读）
• article-summarizer 可以接住任何来源的文本（不只是公众号）

每个 Skill 都有独立存在的价值，拆开之后组合可能性反而更大了。

但如果两个步骤永远绑定在一起——从来不会单独使用其中一个，那就不要拆。强行拆成两个 Skill 只是增加了复杂度，没有带来任何好处。

一个简单的判断方法：问自己——"这个步骤单独拿出来，有没有人会单独用？"如果答案是"有"，拆；如果答案是"不可能"，留在一起。

▍五、让 Skill 更容易被组合：四条设计原则

基于前面的分析，总结四条让 Skill 之间更容易配合的设计原则。这些原则不是额外的负担——如果你前几篇的内容都读进去了，会发现它们都是自然推导出来的。

原则一：单一职责

一个 Skill 只做一件事，做好一件事。wespy-fetcher 只管抓取，不管总结。article-summarizer 只管总结，不管抓取。

判断标准很简单：用一句话描述这个 Skill 的功能，如果这句话里需要用"并且"连接两个动作，说明你可能该拆了。

"抓取公众号文章并转为 Markdown"——这里的"并且"没问题，因为"抓取"和"转格式"是同一件事的两步，不会单独使用。

"抓取公众号文章并总结要点"——这里的"并且"就有问题了，因为"抓取"和"总结"是两件独立的事。

原则二：输出格式通用化

用 Markdown、JSON、纯文本这类通用格式作为 Skill 的输出。不要发明只有自己能理解的私有格式。

通用格式意味着任何下游 Skill 都能接住你的输出，不需要专门适配。你写 Skill 的时候不需要预测它将来会和谁组合——只要输出格式是通用的，组合就是自然而然的事。

原则三：边界声明显式化

在概述里写清楚"我做什么"和"我不做什么"。

article-summarizer 里有一句："不负责文章抓取（抓取请使用 wespy-fetcher），只处理已有内容的总结。"

这句话有三重作用：

• 告诉 Agent 不要拿这个 Skill 去做抓取
• 告诉 Agent 如果需要抓取，去找 wespy-fetcher
• 告诉其他 Skill 的作者，article-summarizer 的对接点在哪里

一句话，三重效果。

原则四：输入假设最小化

你的 Skill 对输入的假设越少，能接住的上游 Skill 就越多。

article-summarizer 只要求"一篇 Markdown 格式的文章"。它不关心这篇文章是从哪来的——wespy-fetcher 抓的、x-fetcher 从 Twitter 抓的、video-downloader 转写的字幕、还是用户自己粘贴的，统统都能处理。

如果它的要求是"必须是 wespy-fetcher 输出的、包含特定 YAML 头部的、存放在 ~/Documents/articles/ 目录下的 Markdown 文件"，那能和它组合的 Skill 就只剩 wespy-fetcher 一个了。

假设越少，兼容性越强，组合可能性越大。

▍六、从两个 Skill 到 Skill 体系

当你积累了十几个 Skill 之后，它们会自然形成层次。

拿 wlzh/skills ( https://github.com/wlzh/skills ) 这个仓库举例，里面的 Skill 天然分成了几层：

采集层：负责从各种来源获取内容

• wespy-fetcher：公众号文章
• x-fetcher：Twitter 推文和长文章
• video-downloader：YouTube 视频

处理层：负责对内容进行加工

• article-summarizer：文章总结（我们第三篇写的）
• voice-changer：音频变声
• text-to-speech：文字转语音

输出层：负责把处理结果发布出去

• youtube-publisher：发布到 YouTube
• quark-mswnlz-publisher：发布到夸克网盘和资源站

采集层的任何一个 Skill 的输出，都能对接处理层的 Skill。处理层的输出，又能对接输出层。层与层之间通过通用格式串联——文本内容用 Markdown，音视频用标准的文件格式。

这意味着什么？

每加一个新 Skill，就多了一组新的组合可能。

加了一个 x-fetcher（抓 Twitter），它就能自动和 article-summarizer（总结）、text-to-speech（朗读）组合。加了一个 youtube-publisher（发布到 YouTube），所有处理层的音视频输出都能对接上去。

这不是你预先设计好的，是单一职责 + 通用格式自然涌现的效果。

不过别急着追求搭建体系。对大多数人来说，从两三个 Skill 的简单接力开始就够了。当你发现"我总是先抓取再总结再翻译"这种固定组合反复出现时，再考虑要不要把它固化成一个工作流——甚至写一个专门的"编排 Skill"来统一调度。

你的 Skill 库就像一个工具箱：先有几把趁手的工具，用着用着自然知道还缺什么、怎么组合最顺手。不要一开始就试图设计一套完美的工具体系——那样你会花大量时间在设计上，而不是在解决实际问题上。

▍七、全篇总结

单个 Skill 的设计：
  ✅ 单一职责——只做一件事
  ✅ 通用格式——输出别人能接住
  ✅ 显式边界——写清楚我管什么不管什么
  ✅ 最少假设——对输入要求越少越好

Skill 之间的三种配合方式：
  接力：A 的输出 → B 的输入（串行）
  分工：同一输入 → A 审查维度1 + B 审查维度2 + C 审查维度3 → 汇总（并行）
  编排：一个 Skill 当指挥，按固定流程调用其他 Skill（流水线）

什么时候拆，什么时候不拆：
  拆的标准 = 这个步骤能不能被单独复用
  不拆的标准 = 两个步骤永远绑在一起

▍下一篇预告

这篇我们聊了 Skill 之间怎么配合——接力、分工、以及什么时候不该拆。

下一篇是收官。我们把 Skill 放回 Agent 的整体架构中，看它和 Rules、Memory、MCP 的关系，回答一个更大的问题：在 Agent 时代，Skill 处于什么位置？

「从零开始写好 Skill」系列是「从零开始理解 Agent」系列的姊妹篇。如果你还没有读过 Agent 系列，建议先从第一篇：Agent 的底层原理开始。

关注 AGENT 魔方公众号，回复 Agent

免费领取「从零开始理解 Agent」全套资料包

加速入门和掌握 Agent: