深入浅出的聊下MCP

一、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 定位，例如：

代码语言：javascript

AI代码解释

ruby 复制代码

file:///home/user/docs/report.pdfpostgres://db.example.com/customers/schemascreen://localhost/display

应用控制（App-controlled）

资源由客户端应用决定：

何时暴露
暴露哪些
是否提供给模型作为上下文

换句话说：模型不能"主动索取资源"，只能使用 Host 给它的上下文。

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

静态资源

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

动态资源

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

代码语言：javascript

AI代码解释

ini 复制代码

logs://recent?timeframe={duration}

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

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

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

代码语言：javascript

AI代码解释

json 复制代码

{"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 定义结构如下：

代码语言：javascript

AI代码解释

css 复制代码

{  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三个核心概念实战演示

以下是github上大拿编写的测试Demo，代码是claude code用javascripts写的，有兴趣可以看下。代码仓库：github.com/wangjoey201...

1、Tools

2、Resources

3、Prompts

四、结语

本文深入浅出的介绍了MCP底层实现的一些框架及协议，希望对大家了解mcp有帮助。