MCP与Skills协议原语对比及使用指南

前记：最近Claude的Skills功能在圈子里激起不少讨论，很多人都在琢磨——Skills是不是可以替代MCP？带着这个疑问深入研究了MCP的实现原理，又上手试了试Skills。结论其实很明确：这不是替代关系，而是协作关系。

Skills介绍及使用

1、Skills是什么

Skills是Claude提供的一种模块化、可复用的能力扩展机制。简单来说，就是把某个领域的专业知识、标准流程和操作规范封装成一个能力单元，让模型能够自动理解和执行。

和一次性Prompt不同，Skills更像是给大模型配置的“专家级操作手册”或者说“标准作业流程（SOP）”。它要解决的核心问题只有一个：让模型在特定场景下稳定、一致、可控地输出高质量结果。

有几个关键特征值得关注：

模块化封装：把复杂任务的知识、步骤和输出规范固化为独立的Skill，方便复用和维护
自动触发：Claude会根据上下文语义自动发现并调用合适的Skill，不需要用户显式指令
结构化约束：通过明确的输入假设、执行步骤和输出格式，大幅降低模型“自由发挥”带来的不确定性
轻量可扩展：一个Skill可以只包含指令，也可以附带模板、示例甚至脚本资源

2、上手实操

安装过程其实很简单，先安装claude-code：

npm install -g @anthropic-ai/claude-code

然后安装pptx skill：

接着就可以用这个技能直接写PPT了：

有意思的是，写完这个PPT之后，claude-code还自动安装了其他需要的skills：

Skills和MCP的区别

Anthropic官方对这两个概念的定义其实很清晰。简单说：

MCP解决的是「模型能用什么」；Skills解决的是「模型该怎么用」。

1、MCP（Model Context Protocol）

核心作用：给大模型接入外部能力
关注重点：数据、工具、系统接口
解决问题：模型去哪拿数据？能调用哪些系统和工具？
本质定位：能力供给层 / 能力接口层

没有MCP，模型“知道怎么做”，但“拿不到数据、干不了活”。

2、Skills

核心作用：规范大模型的做事方式
关注重点：任务方法论、业务逻辑、执行步骤
解决问题：这类事情应该按什么流程做？输出应该长什么样、包含哪些要点？
本质定位：行为规范层 / 方法论固化层

没有Skills，模型“能干活”，但“每次干法不一样、结果不稳定”。

3、一句话总结

MCP是给模型“工具和数据”，Skills是教模型“如何正确使用这些能力”。

放到真实场景里更好理解：

MCP接入监控系统、数据库、日志平台；
Skills规定故障分析要先看什么、再分析什么、最后怎么下结论。

下图很形象地说明了MCP和Skills的关系——协作而非竞争。

MCP底层框架全景解读：协议层与传输层如何解耦

Model Context Protocol（MCP）并不是一个简单的“工具调用协议”，它是一套面向智能体（Agent）场景的通用通信框架。通过清晰的分层设计，把「协议语义」与「通信方式」彻底解耦——同一套Agent协议既能跑在本地进程，也能运行在浏览器、微服务乃至实时双向系统中。

1、整体架构：三层解耦设计

从架构上看，MCP可以清晰拆分为三层：

• 上层应用层：Agent、Tools、Resources、Prompts等业务能力
• 协议层（Protocol Layer）：基于JSON-RPC 2.0的会话协议
• 传输层（Transport Layer）：负责消息在不同通道中的实际传输

这三层的边界非常明确：

协议层只关心「消息语义与会话状态」，
传输层只关心「消息如何收发」，
上层应用完全不需要感知底层通信细节。

2、协议层：把JSON-RPC变成“会话协议”

（1）BaseSession：MCP的通信引擎

协议层的核心是BaseSession。它不是简单封装JSON-RPC，而是解决了Agent场景下最关键的几件事：

• 统一请求（Request）、响应（Response）、通知（Notification）模型
• 自动维护请求–响应的ID关联，支持并发调用
• 屏蔽底层读写流差异（stdio / HTTP / WebSocket）
• 提供统一的错误与异常处理机制

可以理解为：BaseSession把“字节流通信”升级成了“可靠的会话通信”。

（2）ClientSession与ServerSession：角色语义补全

在BaseSession之上，MCP分别为客户端和服务端补齐了角色语义：

ClientSession

• 主动发起initialize请求
• 声明自身能力（capabilities）
• 在握手完成后才能进行正常调用

ServerSession

• 内嵌初始化状态机，严格约束交互顺序
• 校验客户端能力，决定是否允许某些通知或功能
• 确保协议执行的安全性与一致性

这种设计使MCP的通信过程具备明确的生命周期和状态约束，而不是“随便发消息”。

3、标准交互流程：三阶段模型

从通信流程上看，MCP的完整交互可以抽象为三个阶段：

（1）握手初始化
Client发送initialize，双方交换协议版本与能力集，通过initialized确认完成。

（2）正常通信
双方可双向发送Request–Response（同步调用）或Notification（异步事件）。

（3）优雅收尾
任意一端可主动关闭会话，或由底层通道断开触发清理。

这一流程确保了MCP在复杂Agent场景下仍然具备可控的通信秩序。

4、传输层：多形态通信的统一承载

MCP在传输层提供了多种实现，以适配不同部署与性能需求，但所有传输方式都严格遵循同一套协议层逻辑。

（1）Stdio Transport
基于标准输入/输出的本地进程通信，极其轻量，适合CLI工具、编辑器插件和本地Agent。

（2）HTTP + SSE
通过HTTP POST发送消息，SSE单向推送结果，浏览器友好，适合前后端分离和轻量微服务场景。

（3）Streamable HTTP
在同一路径上混合POST与SSE，支持会话管理、断线重连和流式响应，是更偏生产级的HTTP方案。

（4）WebSocket
真正的全双工通道，低延迟、高频交互，适合实时Agent与前端嵌入式Copilot场景。

可以看到，传输层的差异只影响“怎么连”，不影响“怎么用”。

5、总结：为什么MCP适合作为Agent通信底座

从整体设计来看，MCP的核心价值在于：

• 用JSON-RPC 2.0构建了有状态、可并发、可扩展的会话协议
• 通过能力声明与初始化握手，保障交互顺序与安全边界
• 彻底解耦协议与传输，使Agent能在本地、浏览器和生产微服务环境中复用同一通信模型

这也是MCP能成为Agent时代“通用通信底座”的关键原因。

MCP的三大核心概念：Tools、Resources与Prompts

在MCP中，并不是所有能力都通过“工具调用”来完成。为了清晰划分谁来控制、谁来决策、谁来执行，MCP将Agent可用的能力抽象为三类核心原语：

• Prompt：负责“如何提问”
• Resource：负责“提供背景”
• Tool：负责“执行操作”

这三者共同构成了MCP中模型、客户端与服务端之间的职责边界。

1、Resources：为模型提供“可控上下文”

资源（Resources）是MCP中用于向LLM暴露上下文数据的核心原语之一。它的本质不是“能力”，而是可被读取的背景信息。

资源可以是任意类型的数据，包括但不限于：

• 文件内容（文档、日志）
• 数据库记录（结构化数据）
• API响应
• 实时系统状态
• 截图、图片、音频、视频等二进制内容

（1）资源的核心特征

URI唯一标识
每个资源都通过URI定位，例如：

file:///home/user/docs/report.pdf
postgres://db.example.com/customers/schema
screen://localhost/display

应用控制（App-controlled）
资源由客户端应用决定：何时暴露、暴露哪些、是否提供给模型作为上下文。换句话说：模型不能“主动索取资源”，只能使用Host给它的上下文。

（2）静态资源与动态资源

静态资源
URI在服务提供时已明确，例如某个日志文件、固定路径文档。

动态资源
通过URI Template（RFC 6570）定义，资源内容随参数变化：

logs://recent?timeframe={duration}

客户端只需填充参数即可构造具体资源URI。

（3）资源能力声明（Capabilities）

支持资源的MCP Server需要在初始化阶段声明能力，例如：

{
  "capabilities": {
    "resources": {
      "subscribe": true,
      "listChanged": true
    }
  }
}

• subscribe：是否支持订阅单个资源的变更
• listChanged：资源列表变化时是否主动通知客户端

（4）资源的设计定位

资源的设计目标是：为模型提供“事实背景”，而不是“执行能力”。如果你希望服务端主动驱动模型行为，那么应该使用Tools，而不是Resources。

2、Tools：模型可控的“执行能力”

工具（Tools）是MCP中唯一允许模型直接触发“动作”的原语。与资源不同，工具不是被读取，而是被调用（call）。

（1）Tool的核心定位

模型控制（Model-controlled），用于执行：

• API调用
• 数据更新
• 查询、计算
• 外部系统操作

需要特别注意的是：模型只是“决定是否调用工具”，真正的调用由客户端完成。这正是MCP所强调的：模型主控，客户端驱动（Model decides, Client executes）。

（2）Tool的定义结构

每个工具包含以下信息：

• name：唯一标识
• description：功能说明
• inputSchema：参数结构（JSON Schema）
• annotations（可选）：行为说明

（3）Tool的调用机制

在MCP中：

• 列出工具：tools/list
• 调用工具：tools/call
• 返回结果：标准JSON-RPC响应

整个过程完全协议化、可审计、可拦截。

3、Prompts：标准化的“提问模板”

在MCP中，Prompt是继Resources和Tools之后的第三个核心原语，但它关注的不是数据，也不是执行，而是——如何把用户意图组织成“模型更容易理解和执行”的输入结构。

Prompt本质上是由服务器端预先定义的一组可复用对话模板与交互流程。

（1）Prompt的设计理念

用户控制（User-controlled）
Prompt必须由用户或UI显式选择触发，协议不绑定交互方式，可以是Slash命令、菜单、按钮或表单。

强调结构化而非自由发挥

（2）Prompt的核心能力

• 参数化：支持动态输入（如时间范围、语言、主题）
• 资源整合：可嵌入资源作为上下文
• 多轮交互：适合诊断、教学、引导式任务
• 统一发现：通过prompts/list、prompts/get统一管理
• UI友好：天然适合产品化封装

典型Prompt定义结构如下：

{
  name: string;
  description: string;
  arguments: [{
    name: string;
    description: string;
    required: boolean;
  }];
}

（3）一个典型应用场景

例如在教学或企业知识场景中：

• 教学设计者在MCP Server中预置Prompt模板
• 教师通过自然语言或菜单选择Prompt
• 系统自动填参并引导多轮对话
• 即使非技术用户，也能“调动”智能体完成复杂任务

Prompt解决的是“经验如何被标准化复用”的问题。

4、三大原语的角色分工

最后用三句话总结MCP的核心原语设计：

• Prompt关注“如何提问”，让复杂任务变得可复用、可引导
• Resource提供“背景事实”，让模型有上下文可依
• Tool承担“执行动作”，让模型真正影响外部世界

这三者共同构成了MCP中安全、可控、可产品化的Agent能力体系。

MCP三个核心概念实战演示

以下分别对MCP的三个核心原语做了实战演示，代码已上传到GitHub，感兴趣的同学可以查看具体代码，代码是用Ja vaScript写的。

代码仓库：https://github.com/wangjoey2012-sudo/mcp-demos

1、Tools

2、Resources

3、Prompts

结语

本文深入介绍了MCP底层实现的一些框架及协议，也讲了Claude最近备受关注的Skills功能，希望能帮助大家更清楚地理解MCP和Skills各自的价值。

最后聊几句关于大模型Token的感想。

上次参加腾讯架构师同盟的沙龙，腾讯CodeBuddy的林强老师提到一个很实在的观点：大模型能力之所以还没渗透到生活各个场景，很大一个原因是Token成本太高。光看下边这张截图就知道——用claude-code安装pptx skills加上一些依赖，最后做一个简单的5页PPT文档，Token消耗就相当惊人。当前Token成本依然偏高，所以对个人来说，一些不重要的任务暂时还不适合用AI来解决。

这周尝试搭建一个企业价值投资分析的智能体，搭建过程中也一直在想：如果这个智能体后续需要自动运行，Token消耗又是一个必须正视的问题。