WorkBuddy Skill 全拆解：从创建到自进化

我们现在开发一个Agent，如果没有Skill，感觉这个Agent就是不完整，可以说Skill已经成了Agent开发默认的一个标配。

今天我们就来详细解读下workbuddy的Skill是如何配置和使用的。介绍之前 我们先来看看 skills 是什么：

什么是SKill

最开始把Skill这个概念引入Agent是 Anthropic 公司，它在claude code中引入了skill机制，它把 Skill 定义成一种可复用能力包，里面包含说明文档、脚本、参考资料等，可以让 Claude 在特定任务上表现更加稳定，比如做 Excel、PPT、品牌文案、内部流程等：

这个SKill机制再发布之后，很快就在全网走红，大家都在构建自己的skills，并且在社交媒体上 分享自己的Skill。

skills主要由三个核心要素组成：

• 元数据：技能的名称、描述、标签等信息

• 指令：技能具体的执行逻辑

• 资源：技能附带的相关资源（比如文件、可执行代码等）

一个Skill，本质上就是一个能力包，它把完成某件事的个方法论和步骤沉淀下来。而且Skill特别容易服用和分享，它使用文件夹的方式来呈现，一个文件夹就代表一个技能，每一个技能的目录大概如下:

Skills本质上是工程化的产物，它并不能让 AI 变得更聪明，但它能把我们的最佳实践、流程和经验，以一种可维护、可复用的的能力资产

过去，我们靠复盘沉淀经验，把方法将经验保存下来，记录到文档中或者靠老员工口口相传。但这些东西都有一个共同问题，它们能被阅读，却不能被执行。

Skills 做的事情，就是把这些原本静态存在的方法，变成一种可以被 Agent 调用、被模型理解、被工具执行的能力单元。

Skills 三大核心价值

理解了什么是 Skills，我们再来看看  skills为什么会出现。

我们在开发Agent应用的时候，会面临着三大工程化痛点：

提示词臃肿、维护困难

一个复杂的任务，特别是多步工作流的任务，需要写几百甚至上千字的提示词。里面装满了各种要求、规则、格式说明、示例，提示词会变得又长又难读。

提示词变多了之后，模型的注意力就会被分散，不能聚焦当前任务，就很容易出现幻觉，开始胡说八道，程序执行的流程就变得不稳定。

上下文窗口限制

如果我们的任务流程很长，模型需要处理多个复杂流程的时候，如果我们把这些流程全部放到提示词里面，会占用大量的上下文窗口，很容易导致上下文窗口不够用

能力复用困难

当你调教好了一个 代码重构专家 ，明天同事也想用，怎么办？只能通过聊天发给他？这既不优雅，也很难保证执行效果一致。

Skills就是为了解决这些问题。

它的核心价值可以收敛成三点：

1. 知识的沉淀与复用：反复使用的流程被固化为技能，避免重复造轮子

2. 模块化架构：每个技能都是独立的，易于测试、维护和扩展

3. 无限的可能性：通过组合不同技能，可以构建复杂的工作流

除了上述三个，Skills 真正带来的是 Workflow 执行的稳定性；

在之前只靠 ReAct架构，依赖 Tools Calling，很多复杂的流程执行是非常不稳定的，Skills 里面会将 SOP 写死，其中就包括了各种工具调用，最终的结果就是：用户相同的输入，可以拿到稳定的结果了！

在 Skills 出现之前，我们也可以让Agent稳定的执行 Workflow，但通常需要自己写调度器、做状态管理、搞复杂的 prompt engineering，工程成本很高。Skills 相当于把这套能力标准化了，让所有人都能以更低成本获得可靠的执行体验。

渐进式披露

渐进式披露的设计：模型开始的时候，只会加载 skill 的基础元数据，当模型判断需要使用这个 skill 的时候，才会加载完成的指令（skill.md）

整个加载过程分为三个层次，对应核心的三要素：

元数据（始终加载）

name: douyin-summary
description: 抖音视频总结助手。当用户提供抖音视频链接并请求总结时，使用此技能。

Agent启动时就会加载所有 Skills 的元数据，只包含最基本的信息，占用上下文极小，这样模型就能知道自己拥有哪些技能，哪些事情可以做。

核心指令（触发时加载）

# 抖音视频总结助手

## 工作流程
1. 识别抖音链接
2. 调用脚本获取内容
3. 总结内容
4. 友好输出

当模型判断 用户的请求 需要使用对应技能来完成工作的时候，Agent会加载对应技能的的 SKILL.md 文件，为Agent提供清晰指令文档、指导模型完成任务。

代码与资源（按需加载）

scripts/
└── fetch_douyin.py

每当模型判断需要执行技能脚本的时候，就会输出指令，让工具调用对应的脚本来执行，获取结果反馈给模型。

这个三层设计平衡了灵活性和效率：

• 元数据层让 Agent 快速了解自己有哪些能力

• 指令层只在需要时才加载，节省上下文

• 资源层按需调用，避免不必要的开销

Workbuddy的Skills

我们从三个方面（安装，创建，使用）来看看workbuddy是如何使用skills的。

skills的安装

workbuddy的skill，可以通过点击左边菜单栏 专家-技能-连接器 按钮，选择中间的技能模块，可以看到下面列出了很多的技能，只需要点击右上角的 + 号，就可以安装对应的技能到系统中，后续在对话中就可以使用相关的技能。

右上角还有一个添加技能的按钮,点击之后可以看到 查找技能，上传技能，创建技能

这里查找技能是让Agent去skill市场查找对应的技能安装

上传技能是通过上传一个本地的zip包来安装技能，必须包含SKILL.md这个文件，这种本地上传没有经过安全检查，要注意风险。

技能创建

我们点击 创建技能 的时候，默认会跳转到聊天页面，并且默认使用系统内置的一个skill。

Workbuddy内置 skill 叫做 skill-creator，位于app 包内 builtin-skills目录下，它是一个用来创建技能的技能。是一份技能制作规范和流程指南，告诉 WorkBuddy 一个标准的 skill 应该是什么样子、格式是什么，在那个目录创建，有哪些文件组成、创建的步骤是什么，先做什么，后做什么。

在它的根目录下有一个 SKILL.md，这是整个技能的的核心文件。WorkBuddy 会读取这个文件，从而掌握创建 skill 的标准做法：

• SKILL.md（必需）：技能的元数据（name、description）+ Markdown 指令，决定技能何时被触发、如何执行；

• scripts/（可选）：可执行脚本，用于处理需要稳定可靠或反复重写的任务；

• references/（可选）：参考文档，按需加载进上下文，避免主文件臃肿；

• assets/（可选）：模板、图片、字体等"输出素材"。

这是一个标准的skill配置说明，配合渐进式加载机制（元数据常驻系统提示词，SKILL.md 按需加载，其他资源需要使用时才加载），这样技能就可以承载丰富内容，也不会过度占用上下文窗口。

skill-creator这个技能除了 SKILL.md说明文件，它还自带了三个 Python 脚本来辅助制作流程:

1. init_skill.py（初始化脚本）

根据技能名词和目标路径（默认是用户的技能目录 ~/.workbuddy/skills/ ），从模板生成一个完整的skill骨架目录，包含带 TODO 占位符的 SKILL.md，以及 scripts/、references/、assets/ 三个示例目录和对应的示例文件。开发者只需要把占位符的内容替换成真实业务流程，就能创建好一个技能，这个相当于一个 技能生成脚手架 ，避免了手动创建目录和写样板代码。

2. quick_validate.py（校验）

对技能目录做基础的元数据做检查，例如SKILL.md 是否存在、YAML frontmatter 格式是否正确、name 和 description 是否齐全、命名是否符合连字符小写格式（hyphen-case）、description 中是否混入了非法的尖括号等。它返回校验结果，是后续打包的一道质量关卡，必须检查通过后才能走后续流程。

3. package_skill.py（打包）

把整个技能目录压缩成一个以技能名命名的 zip 文件，便于分发和分享。打包前它会先调用 quick_validate.py 做校验，只有校验通过才会真正生成 zip；一旦发现问题就直接报错退出，避免把不合格的技能包发出去。

使用workbuddy的skill-creator 创建技能完成后，在workbuddy中可以直接使用，同时也可以下载zip分享给别人

skill-creator 把技能开发的最佳实践固化成了一份指南 + 三个脚本。WorkBuddy 借助它，就能像一个熟练的工程师那样，根据SKILL.md 的指令，帮用户一步步生成结构规范、可分发、可复用的新技能。

workbuddy的技能层级

workbuddy 技能分为4个层级，通过存放的位置决定了它的可见范围

我们平时创建的都是用户级技能，所有项目和专家都可以使用呢

专家内置技能，当我们需要自定义专家的时候，workbuddy会询问这个专家是否需要skills，如果我们选择需要配置，那么就会为这个专家创建一个内置的专家级技能。

如果需要创建其他层级的技能，可以到对应的目录下去创建。

技能的使用

我们可以在聊天框中@技能，或者模型自动选择，或者直接选择一个技能就可以正常使用，但是它背后的执行原理是什么呢。手动选择技能很简单，模型WorkBuddy直接就加载技能的指令来完成任务。

模型自动选择技能的机制是什么，模型如何知道自己有哪些技能。

WorkBuddy把可用的技能放到了提示词中，格式如下

<available_skills>
- qq-mail: QQ邮箱(QQ Mail)全功能操作技能。触发场景：看邮箱、查邮件、收件箱、看看邮件、有没有新邮件、未读邮件、帮我看看邮箱、打开邮箱、最近的邮件、邮件列表、发邮件、写邮件、发一封邮件、回复邮件、转发邮件、删除邮件、搜邮件、找邮件、搜索邮箱、下载附件、邮件附件、check email、inbox、s… 
(location: /Users/jdoer/.workbuddy/connectors/skills/connector-qq-mail/SKILL.md)
</available_skills>

available_skills 中列出了系统中所有可用的工具。同时系统提示词里面还提到技能是如何被使用

大概的意思是，优先使用技能来完成用户的任务，如果需要使用技能的时候，可以使用skill 这个工具来加载技能的指令（SKILL.md）到系统提示词中。

skill 工具描述如下

使用这个工具加载指令后，模型就会看到技能的完整说明，就可以按照技能说明来完成任务。

自进化机制

WorkBuddy的skill机制里面，还有一个关键的自进化闭环机制。

根据上面这个提示词说明，我们可以看出WorkBuddy可以自动将当前完成的任务，保存为一个新的技能，上面提示词的大概意思是：当模型跑通一个复杂任务、修改掉一个麻烦的问题，或者摸索出一套可复用流程时，它不仅仅只把结果回复给用户，还需要把这套方法沉淀成新的 Skill。

同时已有的 Skill 也不是写完以后就不动了。每次使用Skill之后，模型还要检查这个 Skill 里的步骤有没有缺失，工具名称有没有写错，流程是不是太绕，哪些地方可以写得更清楚。如果发现问题，就要当场修正，立即修改这个Skill。

这些创建和更新skill都是通过内置的SkillManage工具来完成

WorkBuddy 的技能自进化是把一次次真实任务里的经验，变成后面可以继续使用的工作方法。用得越多，Skill 库里沉淀的方法就越多，Agent 下次处理同类问题时，也就不需要每次都从头摸索。

结语

我们之前说过：Skill 本质上是一种工程化产物。

它做的事情，和 Agent 架构一脉相承，把一部分原本由工程师在开发期显式写死的控制流，迁移到运行时由模型来决定；

只不过 Skill 更进一步，把那些被验证有效的方法论和流程，又封装成了可复用、可进化的能力单元。

虽然看上去很美好，但有代价：代码 Bug 是确定的，Prompt Bug 是随机的。以前维护 100 个分支头疼，现在维护一套 Skill 体系加几十个工具描述，一样掉头发，只是疼法不同。

所以 Skill 也好，Agent 也好，都没那么玄乎。它们本质上是在用 AI 的泛化能力，去解决确定性流程中的非确定性应对。谁能把这层关系理清楚，谁就能在 Agent 工程化这条路上少踩很多坑。