Agent Skills 近期热度持续攀升，作为 Anthropic 在 MCP 之后推出的又一 Agent 领域行业标准，它正快速成为开发者关注的焦点。
有趣的是，Skills 的发展路径与 MCP 高度相似。2024 年 10 月刚发布时，仅限 Anthropic 自家产品可用；随后 Cursor、Codex、Opencode、Gemini CLI 等主流工具看到其潜力纷纷接入；社区也涌现出大量开源 Skills 与开放市场。如今，业界已基本默认 Skills 是扩展 Agent 能力的另一种标准实践。
简而言之，Skills 能把重复性、固定流程的专业操作打包成模块。以后使用某项能力时，无需每次翻阅手册或输入长篇提示词，像调用工具一样直接使用即可。
本文将从基础到进阶，逐步拆解以下关键问题：
- Skills 入门：它到底是什么？长什么样？底层如何工作？
- Skills vs MCP：两者本质区别在哪？MCP 会被取代吗？
- Skills 初体验：去哪里找 Skill？怎么用？如何自己创建？
- Skills 实战：如何用它实现外部知识检索？相比传统 RAG 优势在哪？
- Skills 安全：这东西安不安全？使用中有哪些潜在风险？
一、先搞清楚 Skills 到底是什么
1.1 一个更聪明的“实习生”
在传统 AI 聊天模式中，AI 的能力主要取决于两大块：一是它原本学过的知识（训练数据），二是你临时在对话框里告诉它的内容（提示词、工具、记忆）。
这就像你招了个什么都会一点的实习生，但每次干活前都得重新手把手教一遍。
Agent Skills 的出现，则提供了一种完全不同的思路：模块化能力插件。
你可以把支持 Skills 的客户端（比如 Claude）想象成一个超级大脑，而 Skills 就是给它配备的外接工具箱。这个工具箱里不光有工具本身，还附带了一份“官方使用说明书”。大脑不需要事先弄明白每个工具的具体用法，只需要在需要的时候，翻翻说明书，然后直接拿出来用就行。
1.2 Skills 到底长什么样？
在官方文档中，有一个核心关键词：File-system based（基于文件系统）。
写过代码的朋友应该很容易理解。写程序不一定要自己写所有代码，我们可以通过 import xxx 引入外部包，这些包存放在固定的目录下（比如 node_modules）。程序需要用到某个包的能力时，就从对应文件夹里取出代码执行。
Agent Skills 的逻辑也差不多。每个 Skill 都是一个实实在在的文件夹，存放在一个固定的位置（比如 .claude/skills），里面装着下面这些东西：
- 指令（SKILL.md）：告诉 AI 如何执行具体操作的 SOP。
- 参考（reference）：更详细的参考文档（可选）。
- 脚本（scripts）：比如 Python 代码，让 Skill 也能调用外部能力（可选）。
- 资源（assets）：图片、模板等可能用到的资源（可选）。
简单来说，只要你把这个文件夹放到 Agent（比如 Claude Code）的执行目录下（比如你的项目代码目录），下次和 Agent 对话时，它就能自动根据你的需求匹配到这个 Skill，完全不需要你额外配置什么。
举个例子，如果你想写一个用来润色文章的 Skill，大概可以组织成这样：
开头那三根短横线之间的部分，相当于 Skill 的“身份证”：
- name 是它的唯一标识，起个简单好记的英文名就行。
- description 决定了在什么情况下会触发这个 Skill。它描述了这个技能是干什么的，遇到什么样的用户请求应该用它。记住，描述得越具体，越容易在正确的场景下被调用。
- 目标：简单描述清楚这个 Skill 要做的事情。
- 使用步骤：列出具体的操作流程，比如先搞清楚用户想要的风格、再读原文、改写、最后规定输出格式。
- 注意事项：告诉模型“什么不要做”，比如不要乱加内容、不要替用户做决定、遇到有歧义的地方要提醒。
看到这里，你可能会觉得：这看起来也没什么特别的？很多方式似乎都能实现类似的效果，比如直接把这段文字和要润色的文章一起发给大模型，或者把它放进系统提示词，或者封装成一个 Workflow，或者干脆写进项目级的 Rules。
这些方法看似五花八门，但本质上都一样：把提示词放到了不同的位置，你每次和 AI 对话，它都得带着这些提示词。
但在真实的业务场景里，一个 Agent 不可能只干这么一件简单的事。你想一下，如果给 AI 装上 50 个技能，每个技能都有几千字的说明书，系统一启动就把这几十万字全塞进 AI 的“脑子”（Context Window）里，后果会怎样？
- 成本爆炸：每次对话都要消耗几万甚至几十万的 Token。
- 注意力分散：AI 会变得“这也想干，那也想干”，反而什么都干不好。
而 Skills 的核心价值，恰恰就是为了解决这个问题。它引入了一个非常聪明的机制，叫渐进式披露（Progressive Disclosure）。说人话就是：按需加载，用多少拿多少。
1.3 Skills 的核心机制：渐进式披露
这是我觉得 Agent Skills 设计思路里最巧妙的地方。你可以把它想象成在图书馆查资料的三个步骤：
第一层：先看目录（元数据 Metadata）
什么时候加载？系统刚启动的时候。
加载什么？只加载每个技能的名字和一段简短的描述。
有什么用？这一层占用的资源极少，可能就几百个 Token。它的作用就是告诉 Claude：“嘿，你的工具箱里有‘查周报’、‘处理 Excel’这几个工具”。
结果就是：Claude知道自己“会什么”，但还不知道“具体怎么做”。
第二层：翻开手册（指令 Instructions）
什么时候加载？当你下达具体的操作指令时，比如“帮我把这个 Excel 处理一下”。
加载什么？Claude 发现这事儿归“Excel 处理”这个技能管，于是它会通过后台命令，去读取那个文件夹里的 SKILL.md 文件。
有什么用？只有到了这一步，那些详细的操作步骤、注意事项才会进入 AI 的上下文。
第三层：动手干活（运行时资源 Runtime Resources）
什么时候加载？真正开始执行具体步骤的时候。
加载什么？
- 参考（reference）：用户的任务可能是分析 Excel，也可能是创建 Excel。这两个操作的处理步骤可能截然不同，详细的步骤不一定都放在
SKILL.md里，可以分别放在不同的参考文献下。Claude 识别出你要分析 Excel 后，才会去查阅分析 Excel 的那个 reference。 - 脚本（scripts）：Skill 里可以内置一些可执行的脚本。在
SKILL.md或具体的参考文献里，会告诉 AI 应该调用哪个脚本以及如何调用。最关键的是，Claude 只需要按照指引执行脚本就行，脚本本身的代码不会一股脑塞给 AI 去读。你完全不用担心一个超大代码文件会消耗 Token。
二、Skills 和 MCP，到底怎么选？
看到这里，你可能会觉得：Skills 和 MCP 好像有点像？它们似乎都能实现按需加载，给 AI 扩展外部能力？这也是很多同学容易混淆的地方。
2.1 MCP 的“痛”在哪里
在之前关于 MCP 原理的详细拆解中，我们提到过 MCP 的核心价值在于“标准化”——它让给 AI 扩展外部能力这件事变得有章可循。
假如你的 Agent 连接了多个 MCP Server，它似乎也能实现“按需加载”（根据用户的意图决定调用哪个工具）。但问题是，这个“按需加载”背后的代价，其实是很大的。
在 MCP 的架构下，仅仅是“连接”这个动作，就已经在透支你的 Token 了。这是因为 LLM 的工具调用机制决定的。为了让 AI 知道它有哪些能力可用，每一个你连接的 MCP Server，都必须在对话开始前，把它所有工具的完整定义——包括名称、详细描述、参数 Schema、使用示例——一次性完整地注入到 LLM 的上下文中。
一个典型的 MCP Server 往往包含大量工具，比如 Github MCP 自己就有 30 多个工具。假设每个工具消耗 500 个 Token，光链接这一个服务，就需要消耗将近 20000 Token。而在真实环境中，一个 Agent 绝不会只链接一个 MCP Server。
这就导致了一个很尴尬的局面：你只是问了一个极其简单的问题（比如 1+1=？），Agent 就已经烧掉了大几万的 Token。成本之高昂，可见一斑。
更深层的问题在于，当链接的 MCP Server 过多时，LLM 的“注意力”会被严重稀释，从而降低工具调用的准确性。
之前我们聊过一个专门用来测试 MCP Server 调用准确度的基准——MCP Atlas。在那个基准里，包含来自 40 多个不同服务器的、超过 300 个工具的复杂环境。模型必须自己发现合适的工具、正确调用，并把多步结果汇总成最终答案。即使是目前最强的 Claude Opus 4.5，也只能拿到 62% 的准确率，而且随着工具数量的增加，这个数字还会继续下降。
而 Skills 的核心机制——渐进式披露——恰好精准地解决了这两个问题：
- 节省 Token：首次链接时，相比 MCP 需要将 40 多个 Server 下的 300 个工具全部塞进模型上下文（消耗数万 Token），模型只需要加载 40 个 Skills 的元数据（几千 Token）。
- 提升注意力：面对几百个工具，AI 很容易分心。Skills 采用的是“漏斗式”引导：先通过目录判断大方向，确认要干活了，再加载具体的说明，最后通过说明找到详细的文档和脚本再执行。让 AI 每次只专注于当前任务。这样一来，即使是能力稍弱的模型，也能在这种机制下保持极高的调用准确率。
2.2 所以，MCP 会被淘汰吗？
看到这里，你可能会担心：Skills 看起来更智能、更节省资源，那 MCP 是不是就没用了？
先别急。MCP 在协议层上的价值是不可替代的。它的真正价值不在于如何把文本塞进 Prompt，而在于它制定了一套标准接口。它统一了 AI 连接世界的方式。如果你是一个通用的第三方平台（比如高德地图、Notion），想发布一个工具让所有 Agent 都能用上你的能力，那首先选择的还是 MCP。
但反过来，如果你有一些重复性的工作流，比如需要以固定的流程读写本地文件、用一套标准的范式来 Review 代码、或者有一套固定的风格来编写文章，这些场景都强烈推荐使用 Skill 来实现。
过去，这些需求里的本地文件读写、链接 Github、给文章生成图片等需要连接外部世界的能力，都得通过 MCP 去实现。但现在，你可以把它们都打包到 Skill 里。
未来很可能会是这样一个格局：
- Agent 本身 内置部分核心能力（比如 bash、read、edit、write）。
- 少数通用 MCP Server 负责远程连接（比如数据库、云 API、SaaS 集成）。
- 大量 Skills 负责封装标准工作流、连接本地知识库。
- 两者在必要时可以协作，但 Skills 会承担绝大部分“教 AI 怎么做事”的工作，这其中也包括教 AI 怎么用 MCP Server、怎么用其他 Skills、以及如何更好地调用核心能力。
三、动手试一试 Skills
3.1 去哪里找现成的 Skills？
和 MCP 一样，Skills 成为开放标准后，也开始了爆发式增长。社区里涌现了大量开源的 Skills，各种各样的 Skills 开放市场也应运而生。之前不少 MCP Market 也都新加了 Skills 的分类。你可以看到，Skills 的数量正在经历比 MCP 爆火时更快的增长速度。这其中有 Skills 的另一大优点在起作用：编写门槛极低！
MCP 虽然有一套规范的协议，但终究还是要靠代码去实现。即便有 AI 辅助，对于非技术背景的人来说，还是有一定门槛的。而 Skills 就不一样了，只要你写过提示词，就能写 Skill。可以预见的是，那些大量的、重复性的、固定的工作流，在未来大概率都会被封装成 Skill。这也意味着，Agent 的编写门槛被再一次大幅降低了。
3.2 怎么使用一个现成的 Skills？
操作起来非常简单。随便进入一个 MCP 市场，搜索你要用的 Skill。比如，我们以绘图软件 Excalidraw 为例，可以看到社区里已经有大量相关的 Skill 了。选一个 Star 数最高的，进入详情页，找个最简单的安装方式——比如直接通过 wget skill.zip 把文件下载到本地。
把压缩包解压，你会看到我们刚刚说的那个熟悉的目录结构。接下来，你只需要把这个目录放到指定的位置。不同客户端的位置大同小异，基本都是 .agentName/skills 目录。我们以最近比较火的 OpenCode 为例，新建个文件夹，把刚刚下载的文件夹放进去，路径大概是 .opencode/skills。
搞定了。接下来，在这个目录下打开 OpenCode 客户端，输入你的需求。你不需要手动去“安装”或“运行” Skill。文件放对位置后，OpenCode 的 AI 就会自动根据你的需求，判断是不是该调用这个 Skill，然后帮你生成代码。
3.3 创建你的第一个 Skill
接下来，我们一起来尝试创建第一个 Skill。虽然开发门槛很低，但这并不意味着我们要自己硬写。Anthropic 官方很贴心地提供了一个“制造 Skills 的 Skill”——Skill Creator。
你不需要写一行代码或配置文件，只需要用自然语言告诉它你想做什么，它就会自动为你生成一个符合标准的 Skill 包。按同样的流程，把这个 Skill 下载下来，放到 .opencode/skills 目录下，然后给出你的需求提示词。接下来，OpenCode 会识别到你的需求，并开始调用 skill-creator。这时候你打开本地的 .opencode/skills 目录，会发现多了一个新的 Skill 文件夹，里面包含一个 SKILL.md 加上一段获取准确时间的 Node.js 脚本。之后你再问 OpenCode “获取当前系统时间”，它就能自动找到你新生成的 Skill 并调用里面的脚本了。
最后
好了，这期教程就先聊到这儿。大家应该已经对 Agent Skill 的基本原理、如何使用以及如何创建有了一个清晰的认识。
下一期，我们会进入实战环节，一起来试试用 Agent Skill 实现一个知识库检索的功能。跟传统的 RAG 比起来，它究竟能好用到什么程度？我们下期见。
