MCP 与 Skill：搞清楚 AI 能力扩展的两个核心概念

MCP 与 Skill：搞清楚 AI 能力扩展的两个核心概念

在 AI 和智能体（Agent）开发领域，MCP（Model Context Protocol，模型上下文协议） 和 Skill虽然都与「扩展 AI 的能力」有关，但它们处于完全不同的架构层级。

简单来说：MCP 是「接口标准」，而 Skill 是具体的「功能实现」。 就像 MCP 是电脑上的 USB 接口协议，而 Skill 则是插在这个接口上的 U 盘、鼠标或打印机。

核心概念对比

MCP (Model Context Protocol)

MCP 是由 Anthropic 开源的一种标准化通信协议。它解决的是「AI 模型如何安全、统一地连接外部数据源和工具」的问题。

  • 本质： 一套 Client-Server 架构的底层基础设施。
  • 作用： 过去，开发者要让 AI 查数据库、读本地文件、调用外部 API，需要为每个平台写定制化的集成代码。MCP 提供了一套通用标准，只要数据源封装成了「MCP Server」，任何支持 MCP 的 AI 客户端（如 Claude Desktop、Cursor、各类 IDE 插件）都可以无缝接入，读取上下文或调用工具。
  • 关注点： 安全性、连接性、标准化、跨平台。

Skill (技能)

Skill 通常指的是 AI Agent 能够执行的具体任务或业务逻辑。这个概念在 AI 行业存在已久（比如 Amazon Alexa Skills，或者智能体框架中的 Tools/Actions）。

  • 本质： 封装好的业务能力。
  • 作用： 赋予 AI 完成特定指令的能力。例如：「搜索网络」、「查询天气」、「总结指定的本地 PDF 代码库」、「在 Jira 中创建一个 Bug 工单」。
  • 关注点： 业务逻辑、Prompt 设计、输入输出的处理。

详细区别

{% table %}

  • 维度
  • MCP (模型上下文协议)
  • Skill (技能)
  • 层级定位
  • 底层/架构层 (Infrastructure)
  • 上层/应用层 (Application/Logic)
  • 核心问题
  • AI 如何与外部世界建立标准化的连接？
  • AI 能够为用户完成什么具体任务？
  • 通用性
  • 极高。跨平台、跨模型通用。
  • 较低。通常依赖具体的提示词或特定的 AI 框架。
  • 开发对象
  • 开发「MCP Server」，定义资源（Resources）和工具（Tools）的暴露方式。
  • 编写代码逻辑或 Prompt，定义输入参数、执行动作和输出结果。 {% /table %}

它们是如何协同工作的？

在现代的 AI 架构中，MCP 往往是实现 Skill 的底层通道。

假设你正在为运维团队开发一个基于 RAG（检索增强生成）的企业知识库系统：

没有 MCP 之前开发 Skill： 你需要写一个大长串的 Python 脚本，直接把 AI 的 API 和公司内部的 Confluence API 绑死在一起。这个「查文档」的 Skill 只能在你的代码库里运行。

使用 MCP 之后开发 Skill：

  1. 你开发一个连接 Confluence 的 MCP Server。
  2. 这个 Server 向外暴露了一个叫 search_internal_docs 的 Skill（或 Tool）。
  3. 现在，不仅是你自己写的代码，团队里的开发者用 Cursor 写代码时，或者用 Claude 客户端聊天时，只要连接了这个 MCP Server，他们的 AI 就瞬间具备了「查询公司内部运维文档」的 Skill。

总结：你可以通过 MCP 协议，将各种强大的 Skill 标准化地分发给不同的 AI 应用。

有了 MCP，为什么还到处是 Skill？

这是一个很敏锐的问题。你可能会觉得：「既然已经有了一个统一的底层协议（MCP），为什么还要反复强调或者大量去写上层的 Skill 呢？」

其实，MCP 的出现不仅没有消灭 Skill，反而直接促成了 Skill 的「大爆发」。像 Claude、Cursor 现在之所以大量依赖 Skill，正是因为 MCP 把开发和接入 Skill 的门槛降到了前所未有的低。

1. 模型本质上是「缸中之脑」，它永远需要手和眼

无论是多么强大的大语言模型（Claude 3.5 Sonnet、GPT-4o），它们的本质都只是一个「文本预测引擎」。如果没有任何外部工具，它们既不知道现在是几点，也无法读取你 MacBook 上的本地文件，更无法帮你执行终端命令。

  • Skill 就是 AI 的手和眼睛（例如：读取本地文件、执行终端命令、搜索网页）。
  • MCP 是连接大脑（AI）和手眼（Skill）的神经系统。

神经系统再好，没有手眼也干不了活。因此，要想让 AI 真正帮你干活，依然需要大量具体的 Skill。

2. 「解耦」带来了类似 App Store 的效应

在 MCP 出现之前，如果 AI 厂商想让 AI 拥有一个新 Skill（比如「读取本地代码库」），他们必须亲自在自己的客户端里硬编码写死这套逻辑。这导致 AI 能干的事情非常受限。

有了 MCP 之后，发生了类似「苹果推出 App Store」的效应：

  • 以前： Claude 团队自己吭哧吭哧写几百个集成逻辑。
  • 现在： Claude 只需要说「我支持 MCP 协议」。然后，全世界的开发者就可以用几行代码写出一个「读取本地 Git 仓库」的 Skill，或者「查询 Jira 状态」的 Skill，封装成 MCP Server 喂给 Claude。

正因为 MCP 提供了一个标准的「插座」，现在任何开发者都可以轻松地把成千上万个 Skill（U盘）插到 Claude 这个主机上。

3. 具体到代码开发场景

假设你在本地 macOS 环境下进行开发，遇到了依赖管理或编译报错的问题，AI 需要帮你排查。AI 要真正解决问题，它可能需要调用以下几个 Skill：

  1. read_file：读取你本地的配置文件
  2. execute_command：在你的终端跑一下相关的环境检查命令
  3. search_internal_knowledge：去你们公司的内部运维知识库检索

在这个过程中，MCP 和 Skill 是如何配合的？

  • Claude/Cursor 客户端 会通过 MCP 协议 与你本地机器上的服务建立安全连接。
  • 通过这个连接，AI 会发现你暴露给了它上述三个 Skill（工具）。
  • AI 大脑经过思考后决定：「为了排查这个依赖报错，我需要调用 execute_command 这个 Skill。」

一句话总结

MCP 是修好的高速公路，而 Skill 是跑在上面的货车。

正因为高速公路（MCP）修通了且标准统一了，你才会看到现在马路上跑着比以前多得多的货车（Skill），去帮你运送数据、执行任务。

未来，随着企业知识库、自动化工作流的普及，这种原子化的 Skill 只会越来越多。搞清楚这两个层级的关系，是理解 AI 工程化、构建真正有用的 AI Agent 系统的关键第一步。