Agent Skills
1. 什么是 Agent Skills
在 AI Agent 开发中，我们常常遇到两个核心问题：上下文爆炸和能力鸿沟。
上下文爆炸（Context Overload）：为了让智能体能够具备灵活性，例如灵活查询数据库，MCP 服务器通常会暴露数十甚至上百个工具（不同的表、不同的查询方法）。这些工具的完整 JSON Schema 在连接建立时就会被加载到系统提示词中，可能占用数万个 token。
能力鸿沟（Capability Gap）：MCP 解决了“连接”问题，但没解决“精通”问题。拥有数据库访问权，不代表智能体能写出高性能 SQL；能读写文件，不代表它理解你项目的架构规范。这就像给新手程序员开了所有服务器权限，却没给他任何操作手册和 SOP。
这正是 Agent Skills 要解决的核心问题。
1.1 核心设计理念
Agent Skills 是一种标准化的程序性知识封装格式。如果说 MCP 为智能体提供了"手"来操作工具，那么 Skills 就提供了"操作手册"或"SOP（标准作业程序）"，教导智能体如何正确使用这些工具。
这种设计理念源于一个简单但深刻的洞察：连接性（Connectivity）与能力（Capability）应该分离。MCP 专注于前者，Skills 专注于后者。这种职责分离带来了清晰的架构优势：
- MCP 的职责：提供标准化的访问接口，让智能体能够"够得着"外部世界的数据和工具
- Skills 的职责：提供领域专业知识，告诉智能体在特定场景下"如何组合使用这些工具"
用一个形象的类比：MCP 像是 USB 接口或驱动程序，它定义了设备如何连接；而 Skills 像是软件应用程序，它定义了如何使用这些连接的设备来完成具体任务。你可以拥有一个功能完善的打印机驱动（MCP），但如果没有告诉你如何在 Word 里设置页边距和双面打印（Skill），你仍然无法高效地完成打印任务。
2. 渐进式披露机制
Agent Skills 最核心的创新是**渐进式披露（Progressive Disclosure）**机制。这种机制将技能信息分为三个层次，智能体按需逐步加载，既确保必要时不遗漏细节，又避免一次性将过多内容塞入上下文窗口。
2.1 第一层：元数据（Metadata）
在 Skills 的设计中，每个技能都存放在一个独立的文件夹中，核心是一个名为 SKILL.md 的 Markdown 文件。这个文件必须以 YAML 格式的 Frontmatter 开头，定义技能的基本信息。
当智能体启动时，它会扫描所有已安装的技能文件夹，仅读取每个 SKILL.md 的 Frontmatter 部分，将这些元数据加载到系统提示词中。
这与 MCP 的工作方式形成了鲜明对比。在典型的 MCP 实现中，当客户端连接到一个服务器时，通常会通过 tools/list 请求获取所有可用工具的完整 JSON Schema，可能立即消耗数万个 token。
典型的元数据结构如下：
---
name: mysql-employees-analysis
description: >
将中文业务问题转换为 SQL 查询并分析 MySQL employees 示例数据库。
适用于员工信息查询、薪资统计、部门分析、职位变动历史等场景。
当用户询问关于员工、薪资、部门的数据时使用此技能。
---2.2 第二层：技能主体（Instructions）
当智能体通过分析用户请求，判断某个技能与当前任务高度相关时，它会进入第二层加载。此时，智能体会读取该技能的完整 SKILL.md 文件内容，将详细的指令、注意事项、示例等加载到上下文中。
技能主体通常包含以下内容：
- 工作流程：详细的步骤说明，告诉智能体如何执行任务
- 最佳实践：经验总结、注意事项、常见陷阱
- 示例：具体的使用案例，帮助智能体理解
- 故障排查：常见问题和解决方案
2.3 第三层：附加资源（Scripts & References）
对于更复杂的技能，SKILL.md 可以引用同一文件夹下的其他文件：脚本、配置文件、参考文档等。智能体仅在需要时才加载这些资源。
例如，一个 PDF 处理技能的文件结构可能是：
skills/pdf-processing/
├── SKILL.md # 主技能文件
├── parse_pdf.py # PDF 解析脚本
├── forms.md # 表单填写指南（仅在填表任务时加载）
└── templates/ # PDF 模板文件
├── invoice.pdf
└── report.pdf在 SKILL.md 中，可以这样引用附加资源：
- 当需要执行 PDF 解析时，智能体会运行
parse_pdf.py脚本 - 当遇到表单填写任务时，才会加载
forms.md了解详细步骤 - 模板文件只在需要生成特定格式文档时访问
这种设计有两个关键优势：
无限的知识容量：通过脚本和外部文件，技能可以"携带"远超上下文限制的知识。例如，一个数据分析技能可以附带一个 1GB 的数据文件和一个查询脚本，智能体通过执行脚本来访问数据，而无需将整个数据集加载到上下文中。
确定性执行：复杂的计算、数据转换、格式解析等任务交给代码执行，避免了 LLM 生成过程中的不确定性和幻觉问题。
2.4 渐进式披露的效果：从 16k 到 500 Token
社区开发者分享的实践案例充分证明了渐进式披露的威力。在一个真实场景中：
- 传统 MCP 方式：直接连接一个包含大量工具定义的 MCP 服务器，初始加载消耗 16,000 个 token
- Skills 包装后：创建一个简单的 Skill 作为"网关"，仅在 Frontmatter 中描述功能，初始消耗仅 500 个 token
当智能体确定需要使用该技能时，才会加载详细指令并按需调用底层的 MCP 工具。这种架构不仅大幅降低了初始成本，还使得对话过程中的上下文管理更加精准和高效。
3. Agent Skills 与 MCP 的协作关系
3.1 互补而非竞争
Skills 和 MCP 不是竞争关系，而是互补关系。它们在智能体架构中扮演不同的角色，共同构建完整的能力体系。
3.2 分工明确
简单来讲，MCP 和 Skills 的分工可以这样理解：
- MCP 提供数据：例如查询昨天的销售记录、读取订单的物流状态
- Skills 告诉如何使用数据：例如会议总结必须要有议题、汇报文档必须包含数据图表等
典型的工作流程：
- 用户提问："分析公司内部谁的话语权最高"
- Skills 层识别这是一个数据分析任务，加载
mysql-employees-analysis技能 - Skills 层根据技能指令，将任务分解为子步骤：查询管理关系、薪资对比、任职时长等
- MCP 层执行具体的 SQL 查询，返回结果
- Skills 层根据技能中的领域知识，解读数据并生成综合分析
- 返回结构化的答案给用户
3.3 为什么不直接在 Skills 中连接数据？
你可能会问：既然 Skills 中也有 scripts，也可以连接数据，为什么不直接用 script 连接数据呢？为什么还要使用 MCP 呢？
核心原因在于本质的不同：
- MCP 本质上是一个独立运行的程序，具有完整的生命周期管理、错误处理、安全隔离等特性
- Agent Skills 本质上是一段说明文档，主要用于指导智能体的行为逻辑
它们的适用场景也因此不同：
| 特性 | Agent Skills Scripts | MCP Server |
|---|---|---|
| 复杂度 | 轻量级脚本 | 完整的服务程序 |
| 安全性 | 较低（直接执行） | 高（进程隔离、权限控制） |
| 稳定性 | 依赖主进程 | 独立进程，崩溃不影响主程序 |
| 资源管理 | 简单 | 完善（连接池、缓存等） |
| 适用场景 | 简单数据处理、文件操作 | 数据库连接、API 服务、复杂业务逻辑 |
最佳实践：
- 对于简单的文本处理、文件读写、轻量级计算，可以使用 Skills 中的 scripts
- 对于数据库连接、外部 API 调用、需要持久连接的场景，应该使用 MCP
- 在企业级应用中，建议采用 Skills + MCP 混合架构，发挥各自优势
4. 未来展望
随着行业对智能体技术的重视，我们预见以下趋势：
协议融合：可能出现统一的智能体能力描述协议，融合 MCP 的连接性和 Skills 的知识表达
市场化与生态系统：类似于 NPM、PyPI，可能出现智能体能力的包管理系统
自动化能力发现：智能体可能发展出自动发现和学习新能力的机制
智能体技术仍在快速演进中。MCP 已成为连接层的事实标准，Skills 的理念也在影响整个行业。掌握这两种技术，将帮助你在 AI 浪潮中构建更强大、更实用的智能体应用。