Built-ins

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 用到了:

  • config
  • availability
  • actions
  • system

这意味着它同时承担:

  • 配置承载
  • 显式动作调用
  • 运行时提示词增强

为什么它很适合作为第一篇参考

因为 skill 的运行方式足够直接:

  • 你主动调用 action
  • plugin 返回结构化结果
  • system prompt 会自动知道当前已学会的 skills

整个链路没有额外的 provider 安装心智,也没有复杂的 hook 链路。

最推荐的使用顺序

对于一个还没学会的 skill,最推荐的顺序是:

  1. find
  2. install
  3. lookup

为什么不是直接 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 本身的边界

最容易混淆的一点是:

  • skill plugin 不是 skill
  • skill plugin 管的是 skill 的发现、安装、读取与可见性

换句话说:

  • plugin 是“技能目录系统”
  • 具体 skill 是“被目录管理的能力单元”

它的自然边界

skill 不需要长期持有后台实例。

它更像一个:

  • 目录查询层
  • 安装入口层
  • 内容注入层

如果你要做的事情主要是“发现并引入外部能力说明”,那优先考虑这种 plugin 模式。

常见边界与误区

install 不等于“现在就能正确使用”

安装完成只是第一步。

如果 agent 没有读取 skill 内容,它仍然可能不会按正确方式使用这个 skill。

lookup 很重要

很多场景里,真正决定 agent 是否“已经学会”某个 skill 的,不只是本地文件是否存在,而是当前执行上下文有没有把 skill 说明读进来。

这个 plugin 更偏工作流编排

它的强项不是复杂运行时状态,而是把“找、装、读、用”变成清晰的步骤。

什么时候优先参考它

如果你要设计这些能力,优先参考 skill

  • 显式 action 驱动型 plugin
  • 本地目录发现
  • 安装后再读取内容
  • 通过 system 暴露当前已学会能力

相关文档