引言
在使用 JoyCoder、Claude Code、Cursor 等 AI Agent 工具时，我们常会接触到两个核心概念 ——MCP（Model Context Protocol） 与 Skill（Agent Skill） 。二者看似都是为扩展 AI 能力而生，但其底层逻辑、技术路径与适用场景却截然不同。本文将从设计哲学、技术架构、使用场景三个维度，深度拆解这两种扩展机制，厘清它们的本质区别、存在价值与选型思路。
概述
MCP 解决 “连接”问题：打通 AI 与外部服务、数据源的通路，让 AI 能触达外部世界 ；
Skill 解决“方法论” 问题：赋予 AI 完成特定任务的流程化知识，教 AI 如何把事做好。
用一个生动的比喻概括：
MCP 是 AI 的 “手” ，负责伸到外部环境抓取数据、调用工具；
Skill 是 AI 的 “技能书” ，负责指导 AI 按步骤处理任务、输出结果。
二者往往需要配合使用才能发挥最大价值：比如 MCP 让 AI 连接到业务数据库并获取查询结果，Skill 则教 AI 如何清洗数据、分析趋势、生成可视化报表。
MCP 简介
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月发布的开源协议，用于标准化 AI 应用与外部系统的交互方式。
官方的比喻是"AI 应用的 USB-C 接口"——就像 USB-C 提供了一种通用的方式连接各种设备，MCP 提供了一种通用的方式连接各种工具和数据源。
关键点：MCP 不是 Claude 专属的。
它是一个开放协议，理论上任何 AI 应用都可以实现。截至 2025 年初，已经被多个平台采用：
•Anthropic: Claude Desktop、Claude Code
•OpenAI: ChatGPT、Agents SDK、Responses API
•Google: Gemini SDK
•Microsoft: Azure AI Services
•开发工具: Zed、Replit、Codeium、Sourcegraph
到 2025 年 2 月，已经有超过 1000 个开源 MCP 连接器。
MCP 的架构
MCP 基于 JSON-RPC 2.0 协议，采用客户端-主机-服务器（Client-Host-Server）架构：
•Host：用户直接交互的应用（Claude Desktop、Cursor、Windsurf）
•Client：Host 应用中管理与特定 Server 通信的组件
•Server：连接外部系统的桥梁（数据库、API、本地文件等）
MCP 的三个核心原语
MCP 定义了三种 Server 可以暴露的原语：
1. Tools（工具）—— 模型控制
可执行的函数，AI 可以调用来执行操作。
{
"name": "query_database",
"description": "Execute SQL query on the database",
"parameters": {
"type": "object",
"properties": {
"sql": { "type": "string" }
}
}
}
AI 决定什么时候调用这些工具。比如用户问"这个月的收入是多少"，AI 判断需要查数据库，就会调用 query_database 工具。
2. Resources（资源）—— 应用控制
数据源，为 AI 提供上下文信息。
{
"uri": "file:///Users/project/README.md",
"name": "Project README",
"mimeType": "text/markdown"
}
资源由应用控制何时加载。用户可以通过 @ 引用资源，类似于引用文件。
3. Prompts（提示）—— 用户控制
预定义的提示模板，帮助结构化与 AI 的交互。
{
"name": "code_review",
"description": "Review code for bugs and security issues",
"arguments": [
{ "name": "code", "required": true }
]
}
用户显式触发这些提示，类似于 Slash Command。
MCP 与 Function Calling 的关系
很多人会问：MCP 和 OpenAI 的 Function Calling、Anthropic 的 Tool Use 有什么区别？
Function Calling 是 LLM 的能力——把自然语言转换成结构化的函数调用请求。LLM 本身不执行函数，只是告诉你"应该调用什么函数，参数是什么"。
MCP 是在 Function Calling 之上的协议层——它标准化了"函数在哪里、怎么调用、怎么发现"。
两者的关系：
LLM (Function Calling) → "需要调用 query_database"
↓
MCP Protocol
↓
MCP Server 执行
↓
返回结果给 LLM
Function Calling 解决"决定做什么"，MCP 解决"怎么做到"。
MCP 的传输方式
MCP 支持两种主要的传输方式：
| 传输方式 | 适用场景 | 说明 |
|---|---|---|
| Stdio | 本地进程 | Server 在本地机器运行，适合需要系统级访问的工具 |
| HTTP/SSE | 远程服务 | Server 在远程运行，适合云服务（GitHub、Sentry、Notion） |
大部分云服务用 HTTP，本地脚本和自定义工具用 Stdio。
MCP 的代价
MCP 不是免费的午餐，它有明显的成本：
1. Token 消耗大
每个 MCP Server 都会占用上下文空间。每次对话开始，MCP Client 需要告诉 LLM "你有这些工具可用"，这些工具定义会消耗大量 Token。连接多个 MCP Server 后，光是工具定义可能就占用了上下文窗口的很大一部分。
2. 需要维护连接
MCP Server 是持久连接的外部进程。Server 挂了、网络断了、认证过期了，都会影响 AI 的能力。
3. 安全风险
特别是能获取外部内容的 MCP Server（比如网页抓取），可能带来 prompt injection 风险。
MCP 的价值
尽管有这些代价，MCP 的价值在于标准化和可复用性：
•一次实现，到处使用：同一个 GitHub MCP Server 可以在 Claude Desktop、Cursor、Windsurf 中使用
•动态发现：AI 可以在运行时发现有哪些工具可用，而不是写死在代码里
•供应商无关：不依赖特定的 LLM 提供商
Agent Skill 简介
Skill（全称 Agent Skill）是 Anthropic 在 2025 年 10 月发布的特性。Skill 是一个"技能"一个文件夹，里面放着指令、脚本和资源，AI 会根据需要自动发现和加载。
Skill 在架构层级上和 MCP 不同。
Skill 是"提示/知识层"，MCP 是"集成层"。两者解决不同层面的问题。
Skill 最精妙的设计是渐进式信息公开（Progressive Disclosure），就像一本组织良好的手册：先看目录，再翻到相关章节，最后查阅附录。
Skill 分三层加载：
这个设计的好处是什么？
传统方式（比如 MCP）在会话开始时就把所有信息加载到上下文。如果你有 10 个 MCP Server，每个暴露 5 个工具，那就是 50 个工具定义——可能消耗数千甚至上万 Token。
Skill 的渐进式加载让你可以有几十个 Skill，但同时只加载一两个，上下文效率大幅提升。 理论上，单个 Skill 可以包含无限量的知识——因为只有需要的部分才会被加载。
上下文工程：Skill 背后的思想
Skill 是 Anthropic "上下文工程"（Context Engineering）理念的产物。
简单说：
•Prompt Engineering：怎么写好提示词
•Context Engineering：怎么管理上下文窗口里的信息
LLM 的上下文窗口是有限的（即使是 200k 窗口，也会被大量信息撑爆）。Context Engineering 的核心问题是：在有限的窗口里，放什么信息能让 AI 表现最好？
Skill 的渐进式加载就是 Context Engineering 的具体实践——只加载当前任务需要的信息，让每一个 Token 都发挥最大价值。
Skill 的触发机制
Skill 是自动触发的，这是它和 Slash Command 的关键区别。
工作流程：
1.扫描阶段：Claude 读取所有 Skill 的元数据（名称 + 描述）
2.匹配阶段：将用户请求与 Skill 描述进行语义匹配
3.加载阶段：如果匹配成功，加载完整的 SKILL.md
4.执行阶段：按照 Skill 里的指令执行任务，按需加载支持文件
用户不需要显式调用。比如你有一个 code-review Skill，用户说"帮我 review 这段代码"，Claude 会自动匹配并加载。
Skill 的本质是什么？
技术上，Skill 是一个元工具（Meta-tool）：
"The Skill tool is a meta-tool that manages all skills. Traditional tools like Read, Bash, or Write execute discrete actions and return immediate results. Skills operate differently—rather than performing actions directly, they inject specialized instructions into the conversation history and dynamically modify Claude's execution environment."
Skill 不是执行具体动作，而是注入指令到对话历史中，动态修改 Claude 的执行环境。
Skill 的文件结构
一个标准的Skill由三个核心部分组成，其结构如下表所示：
| 组件 | 名称 | 功能描述 |
|---|---|---|
| 核心文件 | SKILL.md | 纯文本指南，定义Skill功能及执行方式，包含名称、目的和逐步说明 |
| 支持材料 | 参考材料和资产 | 提供上下文或资源的附加文件，如品牌指南、政策文档等 |
| 执行组件 | 脚本 | 提供直接、一致响应的小段可执行代码 |
Skill 样例：
my-skill/
├── SKILL.md # 必需：元数据 + 主要指令
├── reference.md # 可选：详细参考文档
├── examples.md # 可选：使用示例
├── scripts/
│ └── helper.py # 可选：可执行脚本
└── templates/
└── template.txt # 可选：模板文件
SKILL.md 是核心，必须包含 YAML 格式的元数据：
---
name: code-review
description: >
Review code for bugs, security issues, and style violations.
Use when asked to review code, check for bugs, or audit PRs.
---
# Code Review Skill
## Instructions
When reviewing code, follow these steps:
1. First check for security vulnerabilities...
2. Then check for performance issues...
3. Finally check for code style...
关键字段：
•name：Skill 的唯一标识，小写字母 + 数字 + 连字符，最多 64 字符
•description：描述做什么、什么时候用，最多 1024 字符
description 的质量直接决定 Skill 能不能被正确触发。
Skill 的安全考虑
Skill 有一个潜在的安全问题：Prompt Injection。因为 Skill 本质上是注入指令，恶意的 Skill 可以在长文件中隐藏恶意指令，窃取敏感数据。
应对措施：
1.只使用可信来源的 Skill
2.审查 Skill 中的脚本
3.使用 allowed-tools 限制 Skill 的能力范围
---
name: safe-file-reader
description: Read and analyze files without making changes
allowed-tools: Read, Grep, Glob # 只允许读操作
---
Skill 的平台支持
Agent Skills 目前支持：
•Claude.ai（Pro、Max、Team、Enterprise）
•Claude Code
•Claude Agent SDK
•Claude Developer Platform
需要注意的是，Skill 目前是 Anthropic 生态专属的，不像 MCP 是跨平台的开放协议。
MCP vs Skill
架构层级对比
现在我们可以从架构层级来理解两者的区别：
┌─────────────────────────────────────────────────────────┐
│ 用户请求 │
└────────────────────────┬────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ 提示/知识层 (Skill) │
│ │
│ Skill 注入专业知识和工作流程 │
│ "怎么做某类任务" │
└────────────────────────┬────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ LLM 推理层 │
│ │
│ Claude / GPT / Gemini 等 │
│ 理解请求，决定需要什么工具 │
└────────────────────────┬────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ 集成层 (MCP) │
│ │
│ MCP 连接外部系统 │
│ "能访问什么工具和数据" │
└────────────────────────┬────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ 外部世界 │
│ │
│ 数据库、API、文件系统、第三方服务 │
└─────────────────────────────────────────────────────────┘
Skill 在上层（知识层），MCP 在下层（集成层）。
两者不是替代关系，而是互补关系。你可以：
•用 MCP 连接 GitHub
•用 Skill 教 AI 如何按照团队规范做 Code Review
详细对比
| 维度 | MCP | Skill |
|---|---|---|
| 核心作用 | 连接外部系统 | 编码专业知识和方法论 |
| 架构层级 | 集成层 | 提示/知识层 |
| 协议基础 | JSON-RPC 2.0 | 文件系统 + Markdown |
| 跨平台 | 是（开放协议，多平台支持） | 否（目前 Anthropic 生态专属） |
| 触发方式 | 持久连接，随时可用 | 基于描述的语义匹配，自动触发 |
| Token 消耗 | 高（工具定义持久占用上下文） | 低（渐进式加载） |
| 外部访问 | 可以直接访问外部系统 | 不能直接访问，需要配合 MCP 或内置工具 |
| 复杂度 | 高（需要理解协议、运行 Server） | 低（写 Markdown 就行） |
| 可复用性 | 高（标准化协议，跨应用复用） | 中（文件夹，可以 Git 共享） |
| 动态发现 | 是（运行时发现可用工具） | 是（运行时发现可用 Skill） |
| 安全考虑 | 外部内容带来 prompt injection 风险 | Skill 文件本身可能包含恶意指令 |
什么时候用 MCP，什么时候用 Skill
1. 用 MCP 的场景
•需要访问外部数据：数据库查询、API 调用、文件系统访问
•需要操作外部系统：创建 GitHub Issue、发送 Slack 消息、执行 SQL
•需要实时信息：监控系统状态、查看日志、搜索引擎结果
•需要跨平台复用：同一个工具在 Claude Desktop、Cursor、其他支持 MCP 的应用中使用
2. 用 Skill 的场景
•重复性的工作流程：代码审查、文档生成、数据分析
•公司内部规范：代码风格、提交规范、文档格式
•需要多步骤的复杂任务：需要详细指导的专业任务
•团队共享的最佳实践：标准化的操作流程
•Token 敏感场景：需要大量知识但不想一直占用上下文
3. 结合使用
很多时候，两者是配合使用的：
1. MCP (GitHub) 获取 PR 信息
↓
2. Skill (团队代码审查规范) 提供审查方法论
↓
3. Claude 按照 Skill 的指令分析代码
↓
4. MCP (GitHub) 提交评论
MCP 负责"能访问什么"，Skill 负责"怎么做"。
写好 Skill 的关键
Skill 能不能被正确触发，90% 取决于 description 写得好不好。
1. 差的 description
description: 帮助处理文档
description: 处理数据
太宽泛，Claude 不知道什么时候该用。
2. 好的 description
description: 通过分析 git diff 生成描述性的提交信息。在用户请求帮助编写提交信息或审查暂存更改时使用。
description: 分析 Excel 电子表格、创建数据透视表、生成图表。在分析 Excel 文件、电子表格、表格数据或 .xlsx 文件时使用。
好的 description 应该包含：
1.做什么：具体的能力描述
2.什么时候用：明确的触发场景
3.触发词：用户可能说的关键词
3. 官方建议
1.保持专注：一个 Skill 做一件事，避免宽泛的跨域 Skill
2.SKILL.md 控制在 500 行以内：太长的话拆分到支持文件
3.测试触发行为：确认相关请求能触发，不相关请求不会误触发
4.版本控制：记录 Skill 的变更历史
对比总结
MCP 和 Skill 是 AI Agent 扩展的两种不同哲学：
| MCP | Skill | |
|---|---|---|
| 哲学 | 连接主义 | 知识打包 |
| 问的问题 | "AI 能访问什么？" | "AI 知道怎么做什么？" |
| 层级 | 集成层 | 知识层 |
| Token 策略 | 预加载所有能力 | 按需加载知识 |
一句话总结：MCP 让 AI 能"碰到"数据，Skill 教 AI 怎么"处理"数据，它们不是替代关系，而是互补关系，一个成熟的 AI Agent 系统，两者都需要。
参考资源
MCP 官方资源
•Introducing the Model Context Protocol
Skill 官方资源
