Skills 的出现并不是因为 MCP 有“大问题”，而是因为 MCP “做得太少了”。
1. 为什么有了 MCP 还要有 Skills？
想象你是一个刚入职的厨师（AI Agent）：
- MCP 是你的“刀具箱”：它给了你一把锋利的刀、一个炒锅、一个搅拌机。工具都是标准化的，很好用。
- 但是，如果你只拿着刀和锅，你还是不知道怎么做一道“宫保鸡丁”。你不知道先放肉还是先放葱，不知道火要开多大。
- Skills 就是“菜谱 + 老师傅的经验”：它不仅告诉你“用这把刀（MCP Tool）”，还告诉你“先把肉切成丁，然后腌制10分钟，油温7成热下锅…”。
MCP 解决了“能力的有无”，Skills 解决了“能力的质量”。
Anthropic 发现，虽然 MCP 让 Agent 能连上工具了，但 Agent 经常乱用工具：
- 参数填错：给 SQL 查询传了个自然语言。
- 流程错误：还没查库存就直接下单了。
- 上下文过载：如果一股脑把几百个 MCP 工具的定义都塞给 Agent，它会晕，不知道选哪个。
Skills 通过封装解决了这个问题：它把“一组相关的 MCP 工具” + “使用说明书” + “最佳实践文档” 打包在一起。Agent 按需加载，既聪明又专注。
2. 怎么入手写一个 Skill？（实战指南）
一个标准的 Anthropic Skill 其实就是一个结构化的文件夹。它不需要复杂的编程，更多的是文档工程。
标准结构
一个 Skill 文件夹通常包含以下内容：
my-awesome-skill/ ├── SKILL.md # [核心] 技能的总入口文件，告诉 Agent 这个技能是干嘛的 ├── README.md # 给人类看的说明书 ├── examples/ # [关键] 放几个“满分作业”的例子，让 Agent 照猫画虎 │ ├── case1.txt │ └── case2.txt ├── reference/ # [知识库] 相关的 API 文档、数据库 Schema、业务规则 │ ├── api_docs.md │ └── db_schema.sql └── scripts/ # (可选) 一些辅助脚本编写步骤（以“私有文档查询 Skill”为例）
第一步：创建SKILL.md(这是 Agent 的大脑)
这是最重要的文件。你需要用清晰的 Markdown 告诉 Agent 怎么干活。
# Private Document Search Skill ## 描述 这是一个用于查询公司私有技术文档的技能。当你需要回答关于“公司内部架构”、“API 参数”或“部署流程”的问题时，请加载此技能。 ## 工作流程 (SOP) 1. **分析意图**：先判断用户问的是哪个项目（A项目还是B项目）。 2. **构建查询**： - 使用 `search_docs` 工具（这是底层的 MCP 工具）。 - 关键词必须是英文技术术语。 3. **验证结果**：如果检索结果为空，尝试去掉修饰词重新搜索。 4. **生成回答**：必须引用文档来源（Source）。 ## 依赖工具 - `search_docs` (MCP Tool)第二步：提供reference/api_docs.md(这是 Agent 的字典)
如果你的 MCP 工具参数很复杂，在这里写详细文档。
- “
search_docs工具接受query和limit两个参数。query长度不能超过 50 字符…”
第三步：提供examples/best_practice.txt(这是 Agent 的榜样)
Few-Shot Learning 是让 Agent 变聪明的捷径。
用户：帮我查一下 A 项目的部署端口。 Agent 思考：用户问的是 A 项目，关键词是 "deployment port"。 Agent 操作：调用 search_docs(query="A project deployment port") Agent 回答：根据文档 [deploy.md]，A 项目的默认端口是 8080。3. 你的下一步行动
如果你想做 Agentic RAG，我强烈建议你把你之前的 RAG 系统封装成一个 Skill。
- MCP 层：我们之前提到的 LightRAG 脚本，把它包装成一个 MCP Server，暴露一个
query(text)函数。 - Skill 层：写一个
SKILL.md，教 Claude：“当你遇到用户问私有资料时，不要瞎编，去调用query函数，并且把返回的 Markdown 格式化一下再告诉用户。”
想试试吗？写好这个MCP Server 代码和配套的Skill 定义文件。只需要把它们放到 Claude Desktop 的配置里，你的 Claude 就能瞬间学会“查你的资料”这个技能了。
