MCP 与 Skills：协议、原语与使用方式

前记：最近Claude的Skills大家都在热议，很多人认为Skills是不是可以替换掉MCP，基于这个背景，笔者深入了解了下MCP，以及简单使用了下Skills，最终的结论是，MCP和Skills不是替代关系，是相互协作的关系。

—、Skills介绍及使用

1、Skills介绍

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

与一次性 Prompt 不同，Skills 更像是给大模型配置的“专家级操作手册 / 标准作业流程（SOP）”，其核心目标是让模型在特定场景下稳定、一致、可控地输出高质量结果。

核心特征

模块化封装：将复杂任务的知识、步骤和输出规范固化为独立 Skill，便于复用和维护

自动触发：Claude 会根据上下文语义自动发现并调用合适的 Skill，而非依赖用户显式指令

结构化约束：通过明确的输入假设、执行步骤和输出格式，显著降低模型“自由发挥”的不确定性

轻量可扩展：Skill 可仅包含指令，也可附带模板、示例或脚本资源

2、Skills的使用

a、macos 安装claude-code

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

b、安装pptx skill 

c、用pptx skill 写一个ppt

写完这个ppt，claude-code自动帮我安装了需要使用的其他skills如下：

二、Skills和MCP区别

Anthropics官方对这两个概念进行了定义，简单来说，

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（Model Context Protocol）中，并不是所有能力都通过“工具调用”来完成。为了清晰地划分 谁来控制、谁来决策、谁来执行，MCP 将 Agent 可用的能力抽象为三类核心原语：

Prompt 负责“如何提问”

Resource 负责“提供背景”

Tool 负责“执行操作”

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

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

资源（Resources） 是 MCP 中用于向 LLM 暴露上下文数据的核心原语之一。

它的本质不是“能力”，而是可被读取的背景信息。

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

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

（1）资源的核心特征

URI 唯一标识

每个资源都通过 URI 定位，例如：

file:///home/user/docs/report.pdfpostgres://db.example.com/customers/schemascreen://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，有需要的同学可以查看具体代码，代码是claude code用javascripts写的。

代码仓库：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消耗也是一个必须要考虑的问题。