别再造 Agent 了！关于 Agent Skills 的详细总结来了

让我们通过一个具体的例子来理解这种差异。假设你要构建一个智能体来帮助团队进行代码审查：

MCP 的职责：

# MCP 提供对 GitHub 的标准化访问
github_mcp = MCPTool(server_command=["npx", "-y", "@modelcontextprotocol/server-github"])
# MCP 暴露的工具（简化示例）：
# - list_pull_requests(repo, state)
# - get_pull_request_details(pr_number)
# - list_pr_comments(pr_number)
# - create_pr_comment(pr_number, body)
# - get_file_content(repo, path, ref)
# - list_pr_files(pr_number)

MCP 让智能体"能够"访问 GitHub，能够调用这些 API。但它不知道"应该"做什么。

Skills 的职责：

---
name: code-review-workflowdescription: 执行标准的代码审查流程，包括检查代码风格、安全问题、测试覆盖率等
---# 代码审查工作流
## 审查清单
当执行代码审查时，按以下步骤进行：
1. **获取 PR 信息**：调用 `get_pull_request_details` 了解变更背景
2. **分析变更文件**：调用 `list_pr_files` 获取文件列表
3. **逐文件审查**：
   - 对于 `.py` 文件：检查是否符合 PEP 8，是否有明显的性能问题
   - 对于 `.js/.ts` 文件：检查是否有未处理的 Promise，是否使用了废弃的 API
   - 对于测试文件：验证是否覆盖了新增的代码路径
4. **安全检查**：
   - 是否硬编码了敏感信息（密钥、密码）
   - 是否有 SQL 注入或 XSS 风险
5. **提供反馈**：
   - 严重问题：使用 `create_pr_comment` 直接评论
   - 建议改进：在总结中提出
## 公司特定规范
- 所有数据库查询必须使用参数化查询
- API 端点必须有权限验证装饰器
- 新功能必须附带单元测试（覆盖率 > 80%）
## 示例评论模板
**严重问题**：
⚠️ 安全风险：第 45 行直接拼接 SQL 字符串，存在注入风险。
建议改用参数化查询：`cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))`

Skills 告诉智能体"应该"做什么、如何组织审查流程、需要关注哪些公司特定的规范。它是领域知识和最佳实践的容器。

2. 上下文管理策略的本质差异

图 3 MCP 急切加载 vs Skills 惰性加载对比

3. 互补而非竞争：Skills + MCP 的混合架构

理解了两者的差异后，我们会发现：Skills 和 MCP 不是竞争关系，而是互补关系。最佳实践是将两者结合，形成分层架构：

图 4 Skills + MCP 混合架构设计

典型工作流：

1. 用户问："分析公司内部谁的话语权最高"

2. Skills 层识别这是一个数据分析任务，加载 mysql-employees-analysis 技能

3. Skills 层根据技能指令，将任务分解为子步骤：查询管理关系、薪资对比、任职时长等

4. MCP 层执行具体的 SQL 查询，返回结果

5. Skills 层根据技能中的领域知识，解读数据并生成综合分析

6. 返回结构化的答案给用户

这种架构的优势是：

• 关注点分离：MCP 专注于"能力"，Skills 专注于"智慧"

• 成本优化：渐进式加载大幅降低 token 消耗

• 可维护性：业务逻辑（Skills）与基础设施（MCP）解耦

• 复用性：同一个 MCP 服务器可以被多个 Skills 使用

四、技术实现：如何创建和使用 Skills

1. SKILL.md 规范详解

让我们深入了解 SKILL.md 文件的标准结构：

---
# === 必需字段 ===
name: skill-name
  # 技能的唯一标识符，使用 kebab-case 命名
description: >
  简洁但精确的描述，说明：
  1. 这个技能做什么
  2. 什么时候应该使用它
  3. 它的核心价值是什么
  # 注意：description 是智能体选择技能的唯一依据，必须写清楚！
# === 可选字段 ===
version: 1.0.0
  # 语义化版本号
allowed_tools: [tool1, tool2]
  # 此技能可以调用的工具列表（白名单）
required_context: [context_item1]
  # 此技能需要的上下文信息
license: MIT
  # 许可协议
author: Your Name <email@example.com>
  # 作者信息
tags: [database, analysis, sql]  # 便于分类和搜索的标签
---# 技能标题
## 概述
（对技能的详细介绍，包括使用场景、技术背景等）
## 前置条件
（使用此技能需要的环境配置、依赖项等）
## 工作流程
（详细的步骤说明，告诉智能体如何执行任务）
## 最佳实践
（经验总结、注意事项、常见陷阱等）
## 示例
（具体的使用案例，帮助智能体理解）
## 故障排查
（常见问题和解决方案）

2. 编写高质量 Skills 的原则

根据 Anthropic 官方文档和社区最佳实践，编写有效的 Skills 需要遵循以下原则：

1. 精准的 Description

description 是智能体决策的关键。它应该：

• 精确定义适用范围：避免模糊的描述如"帮助处理数据"

• 包含触发关键词：让智能体能够匹配用户意图

• 说明独特价值：与其他技能区分开来

❌ 不好的 description：

description:处理数据库查询

✅ 好的 description：

description:>
  将中文业务问题转换为 SQL 查询并分析 MySQL employees 示例数据库。
  适用于员工信息查询、薪资统计、部门分析、职位变动历史等场景。
  当用户询问关于员工、薪资、部门的数据时使用此技能。

2. 模块化与单一职责

一个 Skill 应该专注于一个明确的领域或任务类型。如果一个 Skill 试图做太多事情，会导致：

• Description 过于宽泛，匹配精度下降

• 指令内容过长，浪费上下文

• 难以维护和更新

建议：与其创建一个"通用数据分析"技能，不如创建多个专门的技能：

• mysql-employees-analysis：专门分析 employees 数据库

• sales-data-analysis：专门分析销售数据

• user-behavior-analysis：专门分析用户行为数据

3. 确定性优先原则

对于复杂的、需要精确执行的任务，优先使用脚本而不是依赖 LLM 生成。例如，在数据导出场景中，与其让 LLM 生成 Excel 二进制内容（容易出错），不如编写一个专门的脚本来处理这个任务，SKILL.md 中只需要指导智能体何时调用这个脚本即可。

4. 渐进式披露策略

合理利用三层结构，将信息按重要性和使用频率分层：

• SKILL.md 主体：放置核心工作流、常用模式

• 附加文档（如 advanced.md）：放置高级用法、边缘情况

• 数据文件：放置大型参考数据，通过脚本按需查询

五、行业动态与生态演进

1. 标准化进程与厂商支持

Agent Skills 虽然由 Anthropic 提出，但其设计理念正在影响整个行业。

Anthropic Claude：

• Claude Desktop 和 Claude Code 原生支持 Skills

• 提供官方 SDK 和开发工具

• 维护官方技能库

OpenAI 的响应： 虽然 OpenAI 尚未官方采用 "Skills" 这个术语，但在 2025 年 3 月的更新中，ChatGPT 引入了类似的概念：

• Custom Instructions 增强：支持更复杂的多步骤指令

• Memory 与 Context Profiles：允许用户保存和复用特定领域的知识

• GPTs 的"知识库"功能：可以附加文档和脚本，按需加载

这些功能本质上是 Skills 理念的不同实现形式。

Google Vertex AI： Google 在 Gemini 模型中引入了 "Grounding with Functions"，允许开发者定义"函数包"（Function Packages），每个包包含：

• 函数定义（类似 MCP 的 tools）

• 使用指南（类似 Skills 的 instructions）

• 示例（examples）

这种设计与 Skills + MCP 的混合架构高度相似。

2. 分层架构的必然性

综合各方观点，我们认为：Skills 和 MCP 代表了智能体架构中两个必然分离的层级。随着智能体系统的复杂度增加，这种分层是不可避免的：

应用层（Application Layer）
  ↓ Agent Skills
  ↓ 领域知识、工作流、最佳实践
传输层（Transport Layer）
  ↓ MCP
  ↓ 标准化接口、工具调用、资源访问
基础设施层（Infrastructure Layer）
  ↓ 数据库、API、文件系统、外部服务

这与传统软件架构的演进路径完全一致（从单体到分层到微服务），只是在 AI 领域重新演绎了一遍。

3. 标准化的趋势

随着行业对智能体技术的重视，我们预见以下趋势：

1. 协议融合

未来可能出现统一的智能体能力描述协议，融合 MCP 的连接性和 Skills 的知识表达：

# 未来的统一协议示例（假想）
apiVersion:agent.io/v1
kind:Capability
metadata:
name:enterprise-data-analysis
spec:
transport:
protocol:mcp
server:database-mcp-server
tools:[query,schema]
knowledge:
type:skill
workflow:data-analysis-workflow.md
examples:examples/

2. 市场化与生态系统

类似于 NPM、PyPI，未来可能出现智能体能力的包管理系统：

# 假想的未来命令
agent-cli install @anthropic/frontend-design-skill
agent-cli install @google/data-analysis-suite
agent-cli install @openai/code-review-assistant

开发者可以发布、分享、售卖自己的 Skills 和 MCP 服务器，形成繁荣的生态系统。

3. 自动化能力发现

智能体可能发展出自动发现和学习新能力的机制：

# 未来的智能体可能具备自主学习能力
agent = SelfEvolvingAgent()
# 智能体在执行任务时发现缺少某种能力
response = agent.run("生成 3D 建模文件")
# 智能体自动搜索并安装相关 Skill
# [内部日志] 检测到未知任务类型：3D建模
# [内部日志] 搜索技能库...发现 "blender-3d-modeling" skill
# [内部日志] 请求用户授权安装...已授权
# [内部日志] 技能安装完成，重新执行任务

六、挑战与风险

与此同时，我们也需要警惕潜在的风险：

安全性挑战：

• Skills 包含可执行脚本，存在代码注入风险

• MCP 服务器可能暴露敏感数据接口

• 第三方技能的可信度难以验证

上下文污染：

• 随着 Skills 数量增加，即使是元数据也可能占用大量上下文

• 需要更智能的技能索引和检索机制

碎片化风险：

• 虽然 MCP 正在标准化，但 Skills 格式尚未统一

• 不同厂商可能推出不兼容的 Skills 规范

七、Agent Skills 和 MCP 总结与选型

Agent Skills 和 MCP 代表了智能体技术栈中两个关键的抽象层：

• MCP（Model Context Protocol）：解决"连接性"问题，是智能体与外部世界交互的标准化接口，相当于"神经系统"或"双手"

• Agent Skills：解决"能力"问题，是领域知识和工作流的封装，相当于"大脑皮层"或"操作手册"

两者不是竞争关系，而是互补关系：

图 5 MCP 与 Agent Skills 全面对比总结

关键洞察：

1. 分层架构是必然趋势：随着智能体系统复杂度增加，"连接层"和"知识层"的分离是不可避免的

2. 上下文效率是核心矛盾：Skills 的渐进式披露机制将 token 消耗降低 90% 以上，这是其最大的技术优势

3. 领域知识的民主化：Skills 让非开发者也能贡献智能体能力，这将极大拓展 AI 应用的边界

4. 混合架构是最佳实践：在企业级应用中，MCP 提供基础设施连接，Skills 提供业务逻辑，两者结合才能构建高效、可维护的智能体系统

实践建议：

• 对于外部服务连接（数据库、API、云服务），优先使用 MCP

• 对于复杂工作流（多步骤任务、领域专业知识），优先使用 Skills

• 在上下文受限的场景（长对话、大量工具），使用 Skills 进行渐进式管理

• 构建企业级智能体时，采用 MCP + Skills 的分层架构

智能体技术仍在快速演进中。MCP 已成为连接层的事实标准，Skills 的理念也在影响整个行业。掌握这两种技术，将帮助你在 AI 浪潮中构建更强大、更实用的智能体应用。

参考资料

5. 第十章：智能体通信协议（hello-agents）