MCP vs Skills

引言

随着 LLM（大语言模型）在工程实践中的深入落地，”如何让模型更好地使用外部工具”成为了一个核心命题。工具调用（Tool Use / Function Calling）能力的出现，使得 AI 从一个纯文本的对话系统，逐步演变为可以感知和操作外部世界的智能体（Agent）。

在这一背景下，MCP（Model Context Protocol，模型上下文协议） 和 Skills（技能系统） 作为两种截然不同的工具扩展范式，正在各自的场景中发挥着重要作用。前者是 Anthropic 主导的开放标准，致力于在协议层解决模型与外部系统的集成问题；后者是在应用层对高频、可复用工作流进行封装的轻量方案。本文将深入分析两者的设计理念、工作原理与核心差异，帮助你在实际场景中做出更合适的选择。

MCP（模型上下文协议）

什么是 MCP

MCP（Model Context Protocol） 是由 Anthropic 在 2024 年底提出并开源的一套标准化协议，旨在解决 LLM 与外部数据源、工具、服务之间的集成碎片化问题。

在 MCP 出现之前，每一个需要接入外部工具的 AI 应用，都必须编写定制化的集成代码。接入 N 个工具，就需要维护 N 套相互独立的接口逻辑，缺乏统一的抽象，导致生态极度碎片化。MCP 的目标正是在这个层面做标准化——就像 USB-C 统一了硬件接口一样，MCP 试图为 AI 模型的工具接入提供一个通用的”接口规范”。

MCP 的核心理念：让任何 AI 模型都能通过统一协议接入任何外部系统，而无需为每一次集成重新造轮子。

MCP 的核心架构

MCP 采用经典的 Client-Server 架构：

┌─────────────────────────────────────┐
│            Host Application         │
│  ┌──────────┐      ┌─────────────┐  │
│  │  AI 模型  │ ←──→ │ MCP Client  │  │
│  └──────────┘      └──────┬──────┘  │
└─────────────────────────── │ ───────┘
                             │ MCP Protocol
              ┌──────────────┼──────────────┐
              ↓              ↓              ↓
        ┌──────────┐  ┌──────────┐  ┌──────────┐
        │ MCP      │  │ MCP      │  │ MCP      │
        │ Server A │  │ Server B │  │ Server C │
        │ (文件系统) │  │ (数据库)  │  │  (API)   │
        └──────────┘  └──────────┘  └──────────┘

Host：运行 AI 模型的宿主应用（如 Claude Desktop、Claude Code、IDE 插件等）
MCP Client：内嵌在 Host 中，负责与各个 MCP Server 建立和维护连接
MCP Server：独立运行的服务进程，对外暴露具体的能力（工具、资源、提示词）

通信层面，MCP 支持两种传输方式：

stdio：适用于本地进程通信，MCP Client 通过标准输入输出与 Server 交互
SSE（Server-Sent Events）：适用于远程 HTTP 服务，支持跨网络的 MCP Server 部署

MCP 的三大原语

MCP Server 通过三种标准化原语向 Client 暴露能力：

1. Tools（工具）

Tools 是 MCP 中最核心的原语，对应模型可以主动调用的函数。每个 Tool 包含名称、描述和参数 Schema（JSON Schema 格式），模型根据描述自主决定何时以及如何调用。

{
  "name": "search_documents",
  "description": "在知识库中搜索相关文档",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string", "description": "搜索关键词" },
      "limit": { "type": "integer", "description": "返回结果数量" }
    },
    "required": ["query"]
  }
}

2. Resources（资源）

Resources 代表 Server 可以提供的数据内容，类似于”只读的数据端点”。与 Tools 不同，Resources 不由模型主动触发，而是由 Host 应用在合适的时机注入到上下文中。

典型场景：

将当前打开的文件内容作为 Resource 注入
将数据库中某张表的 Schema 作为 Resource 提供给模型

3. Prompts（提示词模板）

Prompts 允许 Server 定义可复用的提示词模板，并支持参数化。Host 可以列出并展示这些模板，用户选择后由 Client 填充参数并发送给模型。

这三种原语的关系如下：

原语	谁触发	方向	典型用途
Tools	模型（AI）	模型 → Server	执行操作、查询数据
Resources	Host 应用	Server → 模型上下文	注入背景知识、文件内容
Prompts	用户	Server → 用户界面	预设工作流模板

MCP 的工作流程

以”查询数据库并总结”为例，一次完整的 MCP 交互流程如下：

初始化阶段：MCP Client 启动时，向各 Server 发起 initialize 握手，获取 Server 的能力列表（Tools/Resources/Prompts）
能力注入：Host 将可用的 Tools 列表以 System Prompt 的形式注入模型上下文
模型决策：用户提问后，模型根据问题语义和 Tools 描述，决定调用哪个 Tool 及其参数
调用执行：MCP Client 将模型的 Tool Call 请求转发给对应的 MCP Server
结果回传：Server 执行操作，将结果返回给 Client，进而注入模型上下文
最终生成：模型结合工具执行结果，生成最终回答

用户提问
  │
  ↓
模型推理 → 决定调用 Tool
  │
  ↓
MCP Client 转发请求
  │
  ↓
MCP Server 执行（查 DB / 调 API / 读文件）
  │
  ↓
结果注入上下文
  │
  ↓
模型生成最终回答

Skills（技能系统）

什么是 Skills

Skills 是在 AI 编程工具（如 Claude Code）中出现的一种更高层次的工作流封装机制。如果说 MCP 解决的是”模型如何接入工具”的协议层问题，那么 Skills 解决的则是”如何把复杂的多步骤工作流标准化、可复用”的应用层问题。

Skills 本质上是一段结构化的任务描述（Prompt），通过特定的触发条件（通常是斜杠命令 /skill-name）激活。当 Skill 被触发时，系统会将预设的 Prompt 模板展开注入到当前会话，引导模型按照既定流程完成特定任务。

Skills 的工作原理

一个典型的 Skill 定义包含以下要素：

触发词：用于激活 Skill 的斜杠命令，如 /commit、/review-pr
触发条件：除命令触发外，还可以通过特定的代码模式、关键词或上下文条件自动触发
任务描述 Prompt：展开后注入会话的完整指令，可包含工作步骤、输出格式要求、注意事项等
可选参数：支持用户在触发时传入额外参数，如 /commit -m 'fix bug'

以 commit Skill 为例，当用户输入 /commit 时，系统实际上注入了一段包含以下指令的 Prompt：

1. 运行 git status 查看未追踪文件
2. 运行 git diff 查看已暂存和未暂存的变更
3. 运行 git log 了解当前仓库的提交风格
4. 分析所有变更，起草符合规范的 Commit Message
5. 暂存相关文件并创建提交
...

模型接收到这段展开后的 Prompt，即可按照既定流程，一步步完成完整的 Git 提交流程。

Skills 的触发机制

Skills 的触发方式分为两类：

1. 主动触发（User-Invocable）

用户显式输入斜杠命令触发，适用于有意识地发起特定工作流的场景。

/commit：规范化的代码提交流程
/review-pr：PR 代码审查
/pdf：文档生成
/oss-upload：文件上传

2. 被动触发（Auto-Triggered）

系统根据上下文条件自动触发，对用户透明。常见的触发条件包括：

代码导入特定模块（如检测到 import anthropic，自动激活 Claude Developer Platform Skill）
用户意图匹配（如用户询问”如何配置快捷键”，自动触发 keybindings-help Skill）

这种被动触发机制，使得 Skills 能够在不打断用户工作流的前提下，悄无声息地提供”恰好合适”的专业指导。

MCP vs Skills 核心对比

维度	MCP	Skills
抽象层次	协议层（低层次）	应用层（高层次）
核心目标	标准化工具接入	工作流封装复用
触发方式	模型自主推理调用	斜杠命令或自动匹配
扩展单元	Tool / Resource / Prompt	Skill（Prompt 模板）
执行主体	MCP Server（独立进程）	AI 模型本身
副作用	可对外部系统产生操作	通常无直接外部副作用
实现复杂度	需开发独立 Server	编写 Prompt 模板即可
跨应用复用	支持（标准协议）	通常局限于特定工具
状态管理	Server 可维护状态	无状态（每次展开 Prompt）

从本质上看，两者的关系并非竞争，而是分工不同的互补关系：

MCP 解决的是“连接”问题——让模型能感知和操作外部世界（数据库、API、文件系统等）
Skills 解决的是“复用”问题——让特定工作流能被标准化、快速复现

一个完整的 AI 工作流，完全可以同时用到两者：Skill 定义了工作的”SOP”（标准操作流程），而 MCP 提供了在执行 SOP 中所需的”外部能力”。

适用场景

优先选择 MCP 的场景：

需要实时读取外部数据（数据库记录、API 接口、文件系统）
需要对外部系统执行写操作（发送消息、更新数据库、调用云服务）
需要在多个 AI 应用中共享同一套工具能力
构建需要动态感知环境状态的 AI Agent

优先选择 Skills 的场景：

有明确的、可文档化的多步骤操作流程（如代码审查、发布上线）
团队内存在高频重复的工作流，希望降低操作门槛
需要在特定上下文中自动激活特定的工作模式
希望在不改动底层工具的前提下，快速定制 AI 助手的行为

两者结合的场景：

在实际工程中，Skills 和 MCP 往往是协同工作的。例如一个”代码审查”Skill，可能在其 Prompt 中引导模型使用 MCP Server 提供的”获取 PR 差异”Tool、”查询 CI 状态”Tool，最终完成一次全面的代码审查。此时，Skill 定义了审查的标准流程和输出格式，MCP 提供了获取真实数据的能力，二者缺一不可。

展望

MCP 协议的出现，标志着 AI 工具集成正在从”手工作坊”走向”标准化生产”。随着越来越多的服务提供商（数据库、云服务、开发工具）陆续推出官方 MCP Server，AI 模型接入外部世界的门槛将大幅降低，生态的规模效应也将逐渐显现。

而 Skills 代表的工作流封装范式，则预示着”AI 使用方式”本身也在走向标准化。当我们把积累的最佳实践沉淀为 Skill，AI 助手便从一个”需要精细调教的模型”，逐渐成为一个”可以直接复用团队知识的协作者”。

可以预见，未来的 AI 编程环境将是：MCP 负责打通数据与工具的基础管道，Skills 负责将团队经验封装为可分发、可复用的工作流单元，共同构成下一代 AI 原生开发范式的基础设施。

MCP vs Skills

MCP vs Skills

引言

MCP（模型上下文协议）

什么是 MCP

MCP 的核心架构

MCP 的三大原语

MCP 的工作流程

Skills（技能系统）

什么是 Skills

Skills 的工作原理

Skills 的触发机制

MCP vs Skills 核心对比

适用场景

展望

参考文献

FEATURED TAGS