skill Plugin
详细说明 skill 内建 plugin 如何负责技能发现、安装、读取与 system 注入,以及为什么推荐按 find、install、lookup 的顺序使用
skill Plugin
skill 是当前最适合拿来理解“plugin 到底怎么被用户使用”的内建 plugin。
它把 skill 相关能力统一收敛到了一个插件里:
- 查找 skill
- 安装 skill
- 列出本地已学会 skill
- 读取 skill 内容
- 把 skills 概览注入到 system prompt
它到底做什么
你可以把 skill 理解成“agent 的技能目录层”。
它不是 skill 本身,而是负责管理“agent 已经学会了什么”和“下一步如何真正使用 skill”。
它的核心价值不是替代 skill,而是给 skill 建立一个统一入口。
它使用了哪些 plugin 能力
skill 用到了:
configavailabilityactionssystem
这意味着它同时承担:
- 配置承载
- 显式动作调用
- 运行时提示词增强
为什么它很适合作为第一篇参考
因为 skill 的运行方式足够直接:
- 你主动调用 action
- plugin 返回结构化结果
- system prompt 会自动知道当前已学会的 skills
整个链路没有额外的 provider 安装心智,也没有复杂的 hook 链路。
最推荐的使用顺序
对于一个还没学会的 skill,最推荐的顺序是:
findinstalllookup
为什么不是直接 install 后就结束?
因为 install 只代表 skill 已经装到了本地,真正使用前,agent 仍然应该先读取该 skill 的 SKILL.md 内容。
lookup 的作用就是把 skill 内容读出来,并准备成后续可注入的 user message。
典型场景
场景一:用户说“帮我找一个能联网抓网页的 skill”
这时你通常先调用 find,判断:
- 本地是否已经学过
- 是否需要进入安装流程
场景二:用户说“安装这个新 skill”
这时走 install。
安装完成后,不建议立刻假设 agent 已经掌握了全部用法,下一步仍应先 lookup。
场景三:某个 skill 已经在本地,但 agent 还没读过说明
这时最关键的动作不是 find,而是 lookup。
因为 agent 需要把 SKILL.md 读进当前对话上下文,才能按 skill 的规则工作。
在 SDK 里怎么挂载
import { Agent } from "@downcity/agent";
import { SkillPlugin } from "@downcity/plugins";
const agent = new Agent({
id: "skill-helper",
path: "/path/to/project",
tools: {},
plugins: [new SkillPlugin()],
});配置层做了什么
skill 当前有 project 级配置。
这说明:
- 当前项目可以有自己的 skill plugin 配置
- 这份配置属于插件配置,而不是某个具体 skill 的内容
对于大多数用户来说,skill 的重点不在复杂配置,而在 action 工作流。
主要动作
| Action | 作用 | 推荐用法 |
|---|---|---|
find | 查找未学会 skill,并给出下一步 | 先判断要不要 install |
install | 安装 skill | 安装完后立刻接 lookup |
list | 列出本地已学会 skill | 想先看当前能力目录 |
lookup | 读取 skill 的 SKILL.md | 真正使用 skill 前必做 |
场景化用法示例
先找 skill
const result = await agent.plugins.runAction({
plugin: "skill",
action: "find",
payload: {
query: "web-access",
},
});这个动作的重要意义不是“帮你自动完成一切”,而是给出当前状态判断:
- skill 是不是已经在本地
- 如果不在,下一步是不是该 install
安装 skill
const result = await agent.plugins.runAction({
plugin: "skill",
action: "install",
payload: {
spec: "web-access",
global: true,
yes: true,
agent: "claude-code",
},
});安装成功后,返回结果会强调下一步应该 lookup。
列出已学会 skill
const result = await agent.plugins.runAction({
plugin: "skill",
action: "list",
});这个动作最适合:
- 做能力面板
- 调试当前环境到底学过什么
- 在真正执行任务前先看本地技能目录
读取 skill 内容
const result = await agent.plugins.runAction({
plugin: "skill",
action: "lookup",
payload: {
name: "web-access",
},
});lookup 的关键价值是:
- 找到 skill 元信息
- 读取
SKILL.md - 生成适合后续注入的 skill 内容消息
所以它是“真正开始使用 skill”之前最关键的一步。
system 在这里起什么作用
skill 不只是一组 action。
它还会把当前 skill 概览注入 system prompt,让 agent 在运行时知道:
- 当前环境有哪些 skills
- 哪些 skill 已经学会
- 应该如何把 skill 用作外部能力边界
这能显著降低“skill 已安装,但 agent 当前上下文不知道它存在”的问题。
它和 skill 本身的边界
最容易混淆的一点是:
skillplugin 不是 skillskillplugin 管的是 skill 的发现、安装、读取与可见性
换句话说:
- plugin 是“技能目录系统”
- 具体 skill 是“被目录管理的能力单元”
它的自然边界
skill 不需要长期持有后台实例。
它更像一个:
- 目录查询层
- 安装入口层
- 内容注入层
如果你要做的事情主要是“发现并引入外部能力说明”,那优先考虑这种 plugin 模式。
常见边界与误区
install 不等于“现在就能正确使用”
安装完成只是第一步。
如果 agent 没有读取 skill 内容,它仍然可能不会按正确方式使用这个 skill。
lookup 很重要
很多场景里,真正决定 agent 是否“已经学会”某个 skill 的,不只是本地文件是否存在,而是当前执行上下文有没有把 skill 说明读进来。
这个 plugin 更偏工作流编排
它的强项不是复杂运行时状态,而是把“找、装、读、用”变成清晰的步骤。
什么时候优先参考它
如果你要设计这些能力,优先参考 skill:
- 显式 action 驱动型 plugin
- 本地目录发现
- 安装后再读取内容
- 通过
system暴露当前已学会能力