第二大脑 / Knowledge Bank

skills

14分钟阅读

Skills（技能）

Skill 是一种把“做某类任务的知识和流程”打包成可复用模块的方式。它不是模型本身，也不是单个工具，而是“告诉 Agent 在某种场景下该怎么做”的一份说明书 + 配套资源。

本质：Skill = 说明文档（何时用、怎么做） + 可选的脚本/工具 + 可选的参考资料。模型在需要时才把它加载进上下文，用完即走。

对比记忆：

  • Tool 是“一个具体动作”（查天气）。
  • MCP 是“工具如何被统一接入的协议”，见 mcp.md。
  • Skill 是“完成某类任务的整套方法论 + 资源包”，粒度更大，偏“流程与知识”，而不是单次调用。

为什么需要 Skill

如果把所有专业知识、流程规范都塞进系统提示词，会有两个问题：

  • 上下文膨胀：内容越堆越多，既占 token 又稀释注意力。
  • 难以复用/维护：知识散落在各处，无法在不同项目、不同 Agent 间共享。

Skill 的思路是按需加载（progressive disclosure，渐进式披露）：平时只让 Agent 知道“有哪些 skill、各自适用于什么场景”（一句话简介），只有当任务真正匹配时，才把该 skill 的完整内容展开进上下文。

典型结构

一个 skill 通常是一个文件夹，核心是一份带元信息的说明文档：

my-skill/
  SKILL.md        # 核心：元信息 + 使用说明
  scripts/        # 可选：可执行脚本
  references/     # 可选：参考资料、模板、示例

SKILL.md 里一般包含：

  • name / description：名称与“何时该用它”的简短描述——这部分会常驻，供 Agent 判断是否触发。
  • 正文（instructions）：详细的操作步骤、注意事项、最佳实践——只有触发后才加载。

加载机制：三层渐进披露

  1. 元信息层：启动时只加载所有 skill 的 name + description（很少的 token）。
  2. 正文层：当任务匹配某 skill 时，加载它的 SKILL.md 正文。
  3. 资源层：正文里若引用了脚本或参考文件，Agent 按需再去读取。

这样既让 Agent “知道自己会什么”，又避免一次性把所有细节塞满上下文。

Skill vs Tool vs MCP vs Workflow

概念粒度回答的问题
Tool小“能做什么动作”
MCP接入层“工具如何被统一接入”（见 mcp.md）
Skill中大“某类任务该怎么做、要用到哪些知识和资源”
Workflow流程“固定步骤按顺序执行”（流程写死，见 agent.md）

Skill 和 Workflow 都涉及”流程”，区别在于：Workflow 是写死的执行路径；Skill 更像给 Agent 的方法论，具体怎么走仍由 Agent 结合上下文决策。

类比：Skill / MCP 与”应用商城”

常有人问：能不能把 MCP 理解成”应用商城里的应用”？准确答案是——这个比喻对应的是 Skill，不是 MCP（呼应 openclaw.md：ClawHub 就是 “Skill 的应用商店”）。MCP 本身不是应用，是协议/标准。

应用商城里的概念Agent 生态对应说明
商城的接口标准 / 规矩MCP（协议）规定工具怎么接入、被发现（mcp.md 比成 “AI 的 USB-C”）
一个已上架的 USB 设备 / 插件MCP Server具体能力提供方（filesystem / github / postgres server）
商城里的**“应用”**SkillClawHub = 应用商店，装的是 Skill
应用商店本身ClawHub分发、安装、更新的平台

记忆法：应用商城卖的是”应用”(Skill)，MCP 是商场定的”接入规矩 / USB 标准”；单个 MCP Server 才近似”一个已安装的插件 / 设备”。两者都”给 Agent 加能力”、都能靠类似商店的机制分发，但层次不同——MCP 解决”工具怎么被统一接进来”（管道/接口），Skill 解决”某类任务怎么做”（知识/方法）。别把 MCP（协议）和”应用”（Skill）画等号。

给传统程序员的视角：为什么 Agent 要把”流程”和”经验”拆开

如果你写过普通程序，会觉得”一个小程序的功能不就是个 workflow 吗”——这话在传统代码里完全对。因为传统程序把两件事一次性写死在代码里了：

  • 步骤顺序（先 A 再 B）——这就是 workflow（控制流）
  • 每一步怎么做、有什么讲究（领域知识、边界情况）——这就是 know-how（经验）

Agent 世界的不同在于：harness（运行时）是通用的，它不认识你的业务。所以这两件事被拆开供给：

  • Workflow（编排） = 只管”步骤按什么顺序连”（控制流，写死的 DAG）
  • Skill = 只管”做某类任务的方法论 / 最佳实践 / 资源包”，在需要时灌进模型上下文，让通用模型真的会做这件事

换句话说：普通程序把”骨架 + 脑子”焊在一起；Agent 把**骨架（workflow）和脑子里的经验（skill）**分开供给。

Workflow（编排）Skill（技能）
回答的问题步骤按什么顺序走某类任务该怎么做、注意什么
性质控制流，写死、确定性知识/方法论，按需加载进上下文
谁来决定builder 设计时定死Agent 结合上下文临场决策是否遵循
类比流水线 / 菜谱（顺序固定）厨师手里的”秘方笔记”（知道咋做，但不必每道菜照搬）

它们的关系（不是二选一）：Workflow 的每一步可以调用某个 Skill 的方法论；Skill 的正文里也常写”推荐步骤”——但 Agent 自己决定是否照走。以 OpenClaw 为例（见 openclaw.md）：

  • Skill agent-browser = 告诉 Agent “浏览网页要用哪些工具、注意登录墙、记得截图留存”——这是经验。
  • Workflow “每天早 8 点新闻简报” = 固定三步：搜索（用 brave-search skill）→ 总结（LLM）→ 发邮件（messaging 工具）——这是顺序。
  • 顺序（workflow）是骨架，经验（skill）填进每一步让它能做好。

使用场景

  • 让 Agent 掌握某个领域规范或团队约定（如代码风格、文档格式、审查清单）。
  • 把重复出现的复杂流程沉淀下来，跨项目复用。
  • 需要控制上下文成本：知识很多但不必每次全量加载时，用 skill 按需引入。

作为 builder，何时该创建一个 Skill（判断清单）

不是”想到一个流程”就建 skill。skill 是”某类任务的方法论 + 资源包”，按需加载。用下面信号判断——满足 2 条以上，基本就该建了：

  1. 同一类任务反复出现：你（或 Agent）第三次开始重复同一套多步操作 / 说明。一次性的事，写进当次 prompt 即可。
  2. 是一套”方法论”而非”一个动作”：它包含”何时用、按什么顺序、注意什么”，不是单次函数调用 → 用 Skill，而不是 Tool / MCP。
  3. 知识体量大、但只偶尔需要：全塞系统提示会膨胀上下文、稀释注意力 → Skill 按需加载，省 token。
  4. 要跨项目 / 跨团队复用：同一套规范（代码风格、PRD 模板、审查清单）在多处要用 → 沉淀成 skill 便于共享。

不该建 Skill 的情况

  • 只是一个原子动作（查天气、发请求）→ 用 Tool / MCP。
  • 执行路径完全固定、不需要 Agent 临场决策 → 用 Workflow（写死步骤）。
  • 只在这一个会话用一次、且内容很短 → 直接写在 prompt 里更简单。
  • 知识来自未过滤的外部内容 → 进上下文有注入风险，先清洗（见 agent_security.md）。

一句话判断法

当你发现”又在重复解释同一套做法”，且它”是一类比一个动作更大的知识包”，还”想在不同地方复用”——这就是建 Skill 的信号。

遇到一类任务
   │
   ├─ 只做一次、内容短？──────────▶ 写进当次 prompt
   ├─ 一个原子动作？─────────────▶ Tool / MCP
   ├─ 步骤固定写死？─────────────▶ Workflow
   └─ 反复出现 + 是方法论 + 想复用？ ▶ 建 Skill

SKILL.md 具体长什么样（补充示例）

以一个”代码审查”技能为例，直观感受”元信息常驻 + 正文按需加载”：

---
name: code-review
description: 当用户要求审查代码、检查 PR、找代码问题时使用。   ← 这一行常驻，供 Agent 判断是否触发
---
 
# 代码审查技能                                              ← 下面正文只有触发后才加载
 
## 审查清单
1. 安全：是否有注入、硬编码密钥、未校验输入
2. 正确性：边界条件、错误处理
3. 可维护性：命名、重复代码、复杂度
...
 
## 参考
详细的安全规则见 references/security-checklist.md      ← 资源层，用到才读

注意 description 那行的分量：它是”元信息层”里唯一常驻的东西，Agent 全靠它一句话判断”这个任务要不要展开这个 skill”。写得准不准，直接决定 skill 会不会被正确触发。

Skill 与上下文工程的关系（深化）

Skill 本质是 Context Engineering 的一种落地手段（见 context_engineering.md）：

  • 上下文工程的核心难题是”上下文窗口是稀缺资源，不能什么都塞”。
  • Skill 用”渐进式披露”回应这个难题：平时只放一句话简介（省 token），真用到才展开正文（保证信息密度）。
  • 所以可以说：Skill = 把”某类任务的知识”做成一个可被上下文工程按需调度的模块。

呼应记忆：context_engineering.md 里”选择 / 压缩 / 外置”三类手段，Skill 同时占了”选择”（按场景挑）和”外置”（正文平时不在窗口里）两项。

常见坑 / 误区（补充）

  • ❌ “Skill 就是把文档塞给模型” → 关键在按需加载，全量塞进去就退化成了臃肿的系统提示，失去意义
  • ❌ “description 随便写” → 它是触发的唯一依据，写模糊了 Agent 要么该用时不用、要么乱用
  • ❌ “Skill 和 Tool 是一回事” → Tool 是一个动作，Skill 是一整套方法论 + 资源（粒度差很多）
  • ❌ “Skill 和 Workflow 都定流程，等价” → Workflow 写死执行路径；Skill 只给方法论，具体怎么走仍由 Agent 决策
  • ❌ “Skill 里可以放不可信的外部内容” → 它会进上下文，同样有提示词注入风险（见 agent_security.md）

延伸阅读 / 关联概念

  • 上下文工程 — Skill 是它的典型落地手段（渐进式披露）；见 context_engineering.md
  • Token — Skill 省 token 的意义所在；见 token.md
  • MCP — 工具接入协议，和 Skill 分工不同；见 mcp.md
  • Tool Calling — Skill 里常调用具体工具；见 tool_calling.md
  • 斜杠命令 — 人为触发 vs Skill 自动触发；见 slash_commands.md
  • Agent 运行机制 — Skill 在循环里按场景被加载；见 agent.md
  • Agent 安全 — Skill 内容进上下文，注意注入风险；见 agent_security.md

关系图谱

反向链接