一、为什么需要 Skill

1.1 从重复 Prompt 到可复用能力包

  • 普通 Prompt 适合一次性任务说明。
  • Skill 适合沉淀长期、重复、稳定的任务流程。
  • Skill 的核心价值是减少重复解释，让模型在合适场景下自动进入专业工作流。

1.2 Skill 解决的主要问题

  • 避免每次都重新说明背景、规则和输出格式。
  • 把专业领域知识、流程和模板集中管理。
  • 降低上下文占用，让模型按需读取信息。
  • 让 Agent 从“会聊天”变成“会执行某类任务”。

二、概述

2.1 Skill 是什么

  • Skill 是一个以文件夹形式组织的能力包。
  • 每个 Skill 至少包含一个 SKILL.md 文件。
  • SKILL.md 负责说明 Skill 什么时候触发，以及触发后应该如何工作。
  • Skill 还可以附带脚本、模板、参考资料和资源文件。

2.2 Skill 的核心结构

Metadata 层（元数据层）

位于 SKILL.md 的 YAML front matter 中。

  • 作用：路由与触发器，决定 Agent 何时调用、何时不调用
  • 核心字段：name、description、category、tags、should_trigger / should_not_trigger
  • 原则：边界优于描述，description 是给模型看的路由规则，而非宣传文案

Instructions 层（指令层）

位于 SKILL.md 正文中（YAML front matter 后），描述具体工作流。

  • 作用：定义契约、流程边界、执行步骤、约束规则
  • 内容：执行步骤、输入输出格式、Gotchas（避坑指南）、异常处理、退出条件
  • 原则：命令式步骤，而非松散建议；明确禁止行为 > 只描述允许行为

Resources / Scripts 层（资源/脚本）

位于 Skill 目录下的 references/、scripts/、assets/ 等子目录中。

  • 作用：承载确定性逻辑、模板、脚本、外部资源
  • 内容：代码片段、CLI/SDK 调用逻辑、模板文件、配置、可执行函数
  • 原则：易变信息外置，复杂逻辑脚本化，减少 prompt 负担

image-20260519232352991

2.3 Skill 的目录结构

最小结构

1
2
my-skill/
└── SKILL.md

推荐结构

1
2
3
4
5
6
my-skill/
├── SKILL.md
├── references/
├── scripts/
├── assets/
└── examples/

各目录职责

  • SKILL.md：核心入口，包含元数据和主要工作流。
  • references/：存放详细说明、规范文档、领域知识。
  • scripts/：存放可执行脚本，用于处理稳定、机械、可验证的步骤。
  • assets/：存放模板、图片、字体、样例文件等资源。
  • examples/：存放输入输出示例，帮助模型理解完成标准。

2.4 Skill 与长 Prompt 的区别

  • 长 Prompt 是一次性塞入上下文。
  • Skill 是按需加载的结构化能力。
  • 长 Prompt 更像临时说明，Skill 更像可复用 SOP。
  • Skill 更适合团队共享、版本管理和持续迭代。

三、工作机制：渐进式披露

3.1 第一层：元数据常驻

  • 模型启动或会话开始时，只读取 Skill 的名称和描述。
  • description 决定模型是否知道这个 Skill 适合当前任务。
  • 这一层通常只占用较少 token。

3.2 第二层：核心指令按需加载

  • 当用户任务匹配某个 Skill 的描述时，模型读取完整 SKILL.md。
  • 此时工作流、输出格式、边界条件和示例才进入上下文。
  • 这一步让模型获得完成任务的具体方法。

3.3 第三层：资源和脚本按需读取

  • 复杂 Skill 可以把细节拆到独立文件中。
  • 需要时再读取参考资料、模板或执行脚本。
  • 脚本执行结果进入上下文，脚本源码本身不一定需要全部进入上下文。

四、设计原则

  • 单一职责原则

每个skill只做一类明确的事情，不要把多个能力混在一起。

  • 输入输出明确

有明确的输入和输出格式。

  • 可组合性

不应该只能在一个固定场景中使用，而应该可以被多个流程复用。

  • 最小权限原则

只应该拥有完成任务所必需的权限。

  • 可观测性

Skill 的执行过程应该可以被记录、追踪和解释。

  • 安全边界清晰

明确哪些事情能做，哪些事情不能做。

  • 幂等性

在相同输入下多次执行，应该尽量产生相同结果，避免重复副作用。

  • 失败可恢复

Skill 设计时要默认它可能失败，并提供明确的失败信息，而不是只返回“失败”。

五、Skill、MCP 与 Subagent 的关系

5.1 Skill 解决什么

  • Skill 解决“Agent 自己应该怎么做某类任务”。
  • 更偏向流程、知识、模板和领域 SOP。
  • 适合标准化、可复用的内部能力。

5.2 MCP 解决什么

  • MCP 解决“Agent 如何连接外部系统”。
  • 更偏向工具调用、数据访问和服务集成。
  • 适合连接数据库、文档系统、CRM、API 等外部资源。

5.3 Subagent 解决什么

  • Subagent 解决“复杂任务是否需要交给独立专家处理”。
  • 更偏向多步骤、长上下文、需要隔离思考的子任务。
  • 适合代码审查、数据分析、研究整理等复杂任务。

5.4 三者如何协同

  • 用 MCP 获取外部数据。

  • 用 Skill 固定处理流程和输出标准。

  • 用 Subagent 拆分复杂分析或并行任务。

  • 最后由主 Agent 汇总结果并交付。

六、思考

10.1 Skill 的核心思想

  • Skill 不是简单的提示词集合。
  • Skill 是面向 Agent 的可复用能力封装。
  • 它把“知识、流程、资源、工具调用方式”组织成可加载的结构。

10.2 对个人工作流的启发

  • 高频任务值得沉淀成 Skill。
  • 写作、开发、博客维护、文档处理都适合 Skill 化。
  • Skill 可以成为个人知识库和自动化工作流之间的桥梁。

10.3 后续实践方向

  • 为博客写作创建专用 Skill。
  • 为 Hexo 维护创建专用 Skill。
  • 为代码审查创建专用 Skill。
  • 为学习笔记整理创建专用 Skill。
  • 尝试将 Skill 与 MCP、Subagent 联合使用。