Skill 是什么

一句话理解：Tool 让 Agent “能做”，Skill 让 Agent “会做”。Skill 是一个按需加载的文件夹，里面装着做某一类任务的方法、SOP、脚本和参考资料。

假设你每周都让 Agent 做一次 SEO 诊断。第一次，你花二十分钟交代清楚：先查哪些页面、标题多长算合格、canonical 怎么判断、报告按什么格式写。第二周换了个会话，这些它全忘了，你又得重新贴一遍检查清单。第三周同事也想用，你只能把那段长长的 Prompt 私信过去。

Skill 就是为这件事准备的：把“怎么做好这类任务”沉淀成一个文件夹，Agent 遇到相关任务时自己去翻，用不上的时候几乎不占上下文。不理解 Skill，你很容易走向两个极端：要么把所有 SOP 都塞进 System Prompt，让上下文越来越臃肿；要么每次靠人重新交代，经验永远留在个人脑子里。

从“每次重新交代”到“按需翻手册”

同样是让 Agent 掌握 SEO 诊断方法，有三种做法：

做法	什么时候进入上下文	优点	问题
每次在对话里贴 Prompt	你贴的时候	零成本起步	靠人记得，无法复用和共享
写进 System Prompt 或 CLAUDE.md	每一次对话都在	永远不会忘	与 SEO 无关的任务也在付 Token，规则一多互相干扰
做成 Skill	任务相关时才加载	可复用、可版本管理、平时几乎不占上下文	需要写好“何时使用”的描述，否则不会被触发

把这三种做法放进连续几次对话里看，差别就在于内容什么时候进入上下文：

Anthropic 的工程博客用了一个很贴切的比喻：写 Skill 就像给新同事准备一份入职手册。新同事不会在第一天背下所有手册，但知道手册在哪、哪本讲什么，遇到具体问题再去翻对应的章节。Skill 的加载方式正是这样：Agent 平时只记得每个 Skill 的名字和一句话简介，判断相关时才读正文，正文里提到的附件再按需读取。加载的细节在「Skill 如何被发现与加载」一课展开。

Skill 里装的是什么

一个 Skill 至少包含一个 SKILL.md 文件：开头是元数据（名字和描述），后面是用 Markdown 写的指令。除此之外，它还可以附带任意文件。按用途大致分三类：

• 方法：做事的步骤、判断标准、决策分支，例如“客服工单先判断问题类型，再按类型走对应的核查步骤”。
• 知识：Agent 自己不知道的业务事实，例如公司内部的工单分类表、销售口径定义、“测试账号必须排除”这类规则。
• 脚本：需要每次都做得一模一样的确定性操作，例如解析网页的 meta 标签、统计工单的首次响应时长。脚本由 Agent 运行，通常只有输出进入上下文，代码本身不占 Token。

这三类内容和 Tool 的分工，可以画成下面这张图：

Skill 格式最初由 Anthropic 提出，后来作为开放标准发布在 agentskills.io 上。现在 Claude Code、Claude、Codex、Gemini CLI、Cursor、GitHub Copilot、Hermes Agent 等很多 Agent 产品都支持这一格式，同一个 Skill 文件夹通常可以在多个产品里复用，只是放置位置和扩展字段各有差异。

Skill 的两种形态

按使用方式，Skill 大致分为两类，设计重点不同：

形态	作用	例子	设计重点
参考型	提供 Agent 在工作中持续遵守的知识和规范	销售数据口径说明、API 设计规范、品牌文案风格	准确、精炼、容易查找
任务型	给出完成某个具体任务的步骤	SEO 诊断、客服工单处理、发布前检查	步骤清晰、每步可验证、有明确产出

Claude Code 的文档也采用了类似的区分：参考型内容与当前对话一起使用，任务型内容往往更适合由用户用 /skill-name 主动触发。

来看一个真实例子。本站作者写过一个 Search Router，它把 Tavily、Serper、Exa、Brave 四个搜索渠道放在同一个入口后面。它同时包含三类内容：

• 方法：新闻快讯优先用速度快的渠道，深度研究优先用全文检索强的渠道，失败时依次回退。
• 知识：各渠道擅长什么、免费额度多少。
• 脚本：真正发请求、轮换 Key、统一输出格式的 Python 代码。

用户只需说“帮我查一下英伟达最近的新闻”，Agent 就能判断该用这个 Skill、选哪个渠道。选择的逻辑写在 Skill 里，不用每次交代。

为什么 Skill 值得单独成为一个模块

1. 上下文经济：一个 Agent 可能装了几十个 Skill，但一次任务只加载其中一两个，这是「渐进式披露」原则的直接落地。
2. 经验变成资产：Skill 是普通文件，可以放进 Git、做 Code Review、记录版本。优秀员工的做事方法不再只存在于个人脑子里。
3. 可移植：因为有开放标准，为一个 Agent 写的 Skill 往往稍加调整就能用在另一个 Agent 里。
4. 把“会做”和“能做”解耦：工具和权限由研发与安全团队管，方法和标准由业务专家写。产品经理可以直接参与 Agent 能力建设，而不必改代码。

常见误区

• “Skill 就是一段很长的 Prompt。” 两者的差别在加载时机和结构：Skill 平时只露出一句描述，正文和附件按需读取，还能附带可执行脚本。把 Skill 写成一大段不分层的 Prompt，就浪费了这些好处。
• “装了 Skill，Agent 就能连上新系统。” Skill 只教方法，不提供连接能力。要查工单系统，仍需要对应的 Tool 或 MCP Server；Skill 负责告诉 Agent 怎么用好这些工具。
• “什么经验都值得做成 Skill。” 每个 Skill 的描述在每轮对话里都会占用上下文，描述互相重叠还会让 Agent 选错。模型本来就会的通用知识（比如“什么是 HTTP”），不需要写进 Skill。

产品经理检查清单

评估“要不要把这件事做成 Skill”时，先问：

• 这是不是一个会反复出现的任务或知识需求？一年只做一次的事，不值得维护一个 Skill。
• Agent 不看这份材料会不会做错？如果模型本来就做得很好，Skill 就没有增量价值。
• 这些内容是每次都需要，还是只在特定任务里需要？每次都需要的，更适合放进 System Prompt 或项目说明文件。
• 缺的是“方法和知识”，还是“连接和权限”？后者应该交给 Tool 或 MCP。
• 谁是这份方法的负责人？Skill 需要有人随业务变化持续更新。

练习

花 30 分钟完成下面的盘点：

1. 回忆最近一个月你反复向 AI 交代过的 5 件事，比如周报格式、SEO 检查项、数据口径。
2. 按下表分类：

反复交代的内容	每次都需要 / 特定任务才需要	缺的是方法知识 / 系统连接	建议形态
例：SEO 诊断检查项与报告格式	特定任务才需要	方法知识	Skill
例：代码里统一用 pnpm	每次都需要	方法知识	项目说明文件

3. 挑一个最适合做成 Skill 的，用一句话写出“它做什么，什么时候该用它”。这句话就是下一课要讲的 description 的雏形。

延伸阅读

• Agent Skills 官网：开放标准的概览与支持该格式的客户端列表。
• Agent Skills 概览（Claude 文档）：Skill 在 Claude API、Claude Code 与 claude.ai 中的工作方式。
• Equipping agents for the real world with Agent Skills：Anthropic 工程博客对 Skill 设计思路的介绍。

下一步

下一课「Skill 的结构」会打开一个 Skill 文件夹，逐项讲清 SKILL.md、元数据、脚本、参考资料和模板应该怎么组织。