MCP、Plugin、Skills：三者区别与层级关系

从一场争论说起

最近在技术社区里，经常看到这样的提问：

"MCP 和 Plugin 到底有什么区别？"
"Skills 又是干什么的？有了 MCP 为什么还要 Skills？"
"我该用哪个来扩展 Claude Code？"

这三个概念确实容易混淆——它们都能"让 Claude 做更多事"，但定位、实现方式和适用场景完全不同。本文将逐个拆解它们的定义，然后用层级关系把它们串联起来，帮你做出清晰的判断。

一、MCP：工具连接层

1.1 什么是 MCP

MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 于 2024 年 11 月发布的一个 开放标准协议，用于定义 AI 应用如何连接外部工具、数据源和服务。业界常把它比作 "AI 世界的 USB-C 接口"——一个统一的、厂商无关的接口规范。

MCP 采用 客户端-服务器 架构，基于 JSON-RPC 2.0 通信：

1.2 四种核心能力

每个 MCP Server 可以提供四种能力：

🔧 Tools（工具）：模型驱动的函数调用。Claude 根据任务描述自动决定调用哪个 Tool，Server 执行并返回结果。例如：查询数据库、创建 Jira 工单、读写文件。

📄 Resources（资源）：应用上下文数据。以 URI 标识的只读数据，Claude 可以像读取文件一样获取。例如：文件内容、API 响应、数据库表结构。

💬 Prompts（提示模板）：可复用的提示模板。Server 可以提供标准化的提示词，用户选择后即可使用。

🎯 Sampling（采样）：Server 主动请求 LLM 补全。允许 Server 在需要时向 Claude 发起补全请求，适用于复杂的多步推理场景。

1.3 为什么 MCP 重要

MCP 解决的是 "N × M 集成问题"：没有 MCP 时，连接 N 个 AI 模型到 M 个业务系统需要 N × M 个定制集成。有了 MCP，只需 N + M 个——编写一个 MCP Server 即可被所有兼容的 AI 客户端使用。

关键里程碑：

• 2024.11 Anthropic 发布 MCP，Claude Desktop / Claude Code 首批支持
• 2025.03 Streamable HTTP 替代 HTTP+SSE 成为远程传输标准
• 2025.05 OpenAI 和微软同步采用 MCP；Google 在 Gemini 中集成
• 2025.12 Anthropic 将 MCP 捐赠给 Linux Foundation 的 Agentic AI Foundation
• 2026.01 MCP Apps（交互式 UI 组件）和 MCP Tool Search（工具按需加载）发布

截至 2026 年初，已有 10,000+ 公开 MCP Server、9700 万月 SDK 下载量，四大 AI 平台（Anthropic、OpenAI、Microsoft、Google）全部支持。

1.4 MCP 的局限

• 安全性：约 25% 的社区 Server 缺少认证；工具投毒和提示注入是新型攻击面
• 延迟：基线 300-800ms 端到端延迟，不适合实时场景
• 治理：可观测性、审计和访问控制工具仍在成熟中

二、Skills：行为定义层

2.1 什么是 Skills

Skills 是一种 纯 Markdown 指令文件，用于定义 Claude 的行为方式和工作流程。它不连接任何外部系统，而是告诉 Claude "遇到某类任务时应该怎么做"。

Skills 的核心是 程序性知识（Procedural Knowledge）的编码——把人类专家的操作流程、审查清单、编码规范写成结构化的指令，让 Claude 按图索骥。

2.2 Skills 的工作方式

用户输入 → Claude 读取 Skill 描述 → 匹配到合适的 Skill → 加载 SKILL.md → 按指令执行

Skills 存放在 .claude/skills/（项目级）或 ~/.claude/skills/（用户级）目录中。每个 Skill 是一个包含 SKILL.md 文件的目录，文件头部有 frontmatter 元数据：

---
name: code-review
description: 对当前分支的改动进行代码审查，检查安全、性能和可维护性
---

# 代码审查 Skill

## 审查流程
1. 使用 `git diff` 获取所有改动
2. 按以下维度逐文件审查：
   - 安全性：SQL 注入、XSS、敏感信息泄露
   - 性能：N+1 查询、不必要的重渲染
   - 可维护性：命名、重复代码、边界处理
3. 输出分级报告：严重 / 警告 / 建议

2.3 Skills 的核心特征

2.4 Skills 的典型场景

• /deploy——定义部署流程：构建 → 测试 → 推送 → 发布
• /pr-review——定义 PR 审查清单和安全检查项
• /code-style——定义团队编码规范，让 Claude 自查
• /new-article——定义新增文章的步骤和格式要求

核心判断：问题是"怎么做"而非"连接什么"时，用 Skills。

三、Plugins：分发打包层

3.1 什么是 Plugins

Plugins 是 Claude Code 的 打包分发机制，它将 Skills、MCP Server、Hooks（生命周期钩子）和 Agents（子代理）打包为一个可安装的单元。

如果把 MCP 比作零件、Skills 比作说明书，那么 Plugins 就是"工具箱"——把零件和说明书打包好，贴上标签，方便分发和复用。

3.2 Plugin 的结构

每个 Plugin 是一个包含 .claude-plugin/plugin.json 清单文件的目录：

my-plugin/
├── .claude-plugin/
│   └── plugin.json        # 清单：名称、版本、包含的组件
├── skills/
│   └── my-skill/
│       └── SKILL.md
├── mcp/
│   └── my-server/          # MCP Server 实现
│       └── server.py
└── hooks/
    └── on-start.sh

plugin.json 示例：

{
  "name": "company-code-review",
  "version": "1.0.0",
  "description": "公司代码审查插件",
  "skills": ["code-review"],
  "mcpServers": {
    "github": { "command": "npx", "args": ["-y", "@anthropic/mcp-github"] }
  },
  "hooks": {
    "PostToolUse": ["on-review-done.sh"]
  }
}

3.3 Plugins 的核心特征

核心判断：需要将多个扩展组件打包分发给团队或社区时，用 Plugins。

四、三者对比：一张表看清区别

核心差异速查

能力矩阵

五、层级关系：层层递进的三层架构

三者的关系不是"选 A 还是选 B"的互斥关系，而是 层层递进、下层为上层提供基础 的架构关系：

5.1 第一层：MCP（工具连接层）

这是最底层的能力提供者。MCP Server 把外部系统封装成 Claude 可以理解和调用的工具接口。没有 MCP，Claude 无法"伸手"到外部世界。

关键特征：MCP 是协议，不是程序。它规定了 Client 和 Server 之间的通信格式，但不管 Server 具体做什么。

5.2 第二层：Skills（行为定义层）

这是中间层的行为编排者。Skills 不提供新能力——它告诉 Claude 如何组合使用已有的能力（包括 MCP 提供的工具）来完成特定任务。

例如：你有一个 GitHub MCP Server，但 Claude 不知道"做代码审查"应该先做什么后做什么。code-review Skill 告诉 Claude："先获取 diff → 逐文件检查安全性 → 检查性能 → 检查可维护性 → 输出分级报告"。

5.3 第三层：Plugins（分发打包层）

这是最上层的分发单元。当你的团队同时需要 GitHub MCP Server + 代码审查 Skill + 部署 Skill + 几个钩子脚本时，Plugin 把它们打成"一个包"，团队成员一条命令搞定。

5.4 一个完整示例

以"公司自动化代码审查流水线"为例：

1. MCP 层：连接 GitHub MCP Server，获取 PR 信息、diff、文件列表
2. Skills 层：
   • code-review Skill 定义审查维度、输出格式、严重等级标准
   • deploy-checklist Skill 定义上线前必须确认的项目
3. Plugins 层：打包成 @company/devops-plugin，团队成员执行 claude /plugin install @company/devops-plugin 即可获得完整能力

六、实践建议：什么时候用什么

6.1 选择 MCP

当你的场景满足以下条件时，写一个 MCP Server：

• 需要查询私有数据库、内部 API 或文件系统
• 需要与组织专有系统交互（Jira、Confluence、GitLab）
• 需要浏览器自动化或操作系统级操作
• 需要让 Claude 产生真实的外部副作用

6.2 选择 Skills

当你的场景满足以下条件时，写一个 Skill：

• 需要让 Claude 遵循特定流程（代码审查、部署、故障排查）
• 需要定义一个 /custom-command 快捷命令
• 需要把团队惯例编码为可执行的规范
• 需要写提示模板但不涉及代码

6.3 选择 Plugins

当你的场景满足以下条件时，写一个 Plugin：

• 需要把多个 Skills + MCP Server 打包分发给团队
• 需要在多个项目间复用同一套配置
• 需要添加 Hooks（生命周期钩子）做自动化触发
• 想发布到社区插件市场

6.4 推荐起步组合

大多数开发者只需要：

• 2-3 个 MCP Server：如 GitHub + Filesystem + 一个领域专用
• 几个自定义 Skills：如部署流程、代码审查、项目约定
• 暂不需要 Plugin：等积累到需要团队分发时再考虑

七、总结

三者的关系不是竞争而是协作：MCP 提供工具，Skills 编排流程，Plugins 打包分发。理解这一层级关系，就能根据实际需求准确选择扩展方式。

MCP 正在从 Anthropic 的实验性协议演变为由 Linux Foundation 托管的行业标准。Skills 和 Plugins 则代表了 Claude 生态中"行为编码"和"能力分发"这两个维度的最佳实践。三者共同构成了 Claude Code 可扩展性的完整拼图。

延伸阅读：如果你对 AI 架构模式感兴趣，推荐阅读本站的 Workflow 与 Agent 的区别：从原理到实践的完整指南。