深入MCP Remote模式：两大基础协议及工作原理，一步步教你弄懂

原创最新推荐文章于 2026-11-02 09:37:22 发布 3.5k 阅读 AI写同款

Python_金钱豹

1万+粉丝2841篇原创

关注

MCP协议 MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 推出的一种开放标准，旨在统一大型语言模型（LLM）与外部数据源和工具之间的通信协议。MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题，MCP 使得 AI 应用能够安全地访问和操作本地及远程数据，为 AI 应用提供了连接万物的接口。阅读详情

AI摘要

本文深入剖析MCP远程模式原理及官方标准最新变化。介绍了消息协议JSON - RPC 2.0，其具有语言无关、简单易用等优点；分析了HTTP Post传输方式的不足，引出SSE传输协议；阐述了基于SSE的Remote模式工作流程；还提及最新的Streamable HTTP标准调整。此外，还分享了大模型AI学习资料和阶段规划。

MCP（模型上下文协议）的集成架构是一种典型的客户端（AI应用）与服务器（MCP Server）架构。相对于本地模式中的进程间通信，跨越机器边界的远程模式则体现出更多的复杂性：传输协议、状态维持、并发处理等，都是棘手的问题，这也导致其Remote模式的标准一直还在不断完善中。

本文为大家一步步来剖析MCP远程模式的原理，并了解官方标准的一些最新变化：

消息协议：JSON-RPC 2.0
基于JSON-RPC 2.0的MCP模拟
传输协议：为什么需要SSE
基于SSE的Remote模式
最新变化：Streamable HTTP

消息协议：JSON-RPC 2.0

既然是用来简化集成、提高互操作性的标准，首当其中的是消息协议。这就像一个国际交流会议，大家说相同的”语言“，效率才会更高。

在MCP中规定了唯一的标准消息格式，就是JSON-RPC 2.0。JSON-RPC 2.0是一种轻量级的、用于远程过程调用（RPC）的消息交换协议，使用JSON作为数据格式。

注意：它不是一个底层通信协议，只是一个应用层的消息格式标准。形象的说，就像两个人需要交换包裹，它规定了包裹应该如何打包、内部如何分区、如何贴标签等，但它不规定包裹如何运送。

比如，你需要调用MCP Server上的一个计算器来计算“5+3”，这就是一次远程过程调用。那么JSON-RPC2.0就约束了你给Server的消息必须遵循以下格式：

{
    "jsonrpc": "2.0", // 协议版本，固定为 "2.0"
    "method": "calculate", // 要调用的方法名
    "params": { // 方法参数，可以是对象或数组
        "expression": "5+3"
    },
    "id": 1                  // 请求标识符，用于匹配响应
}

而当MCP Server处理完成，JSON-RPC又约束了回复的消息必须长这样：

{
    "jsonrpc": "2.0", // 协议版本
    "result": 8,         // 调用结果
    "id": 1                  // 对应请求的标识符
}

这样两边就非常和谐的完成了一次请求处理。在实际的JSON-RPC 2.0规范中，还规定了通知类消息的格式、异常时的标准错误代码等。

所以，你可以很容易看出这种消息协议的好处：

*语言无关***：**还有语言不支持JSON吗？
*简单易用*：结构简单，天然可读，易于调试。
*轻量灵活*：可以适配各种传输方式（不规定怎么运输“包裹”）。

基于JSON-RPC 2.0的MCP模拟

规定了消息的标准，再选择一种传输方式，就可以简单模拟出MCP的远程方法调用过程。你肯定会首先想到简单又好用的HTTP协议，比如我们写一个简单的服务端来处理上面的请求：

...

app = FastAPI()

#可调用的工具
def safe_calculate(expression: str) -> float:
   ...省略...

@app.post('/jsonrpc')
async def jsonrpc_endpoint(request: Request):
    """处理所有JSON-RPC请求的FastAPI端点"""
    try:
        content = await request.json()

        method_name = content.get("method")
        params = content.get("params", {})
        request_id = content.get("id", None)
        
        if method_name == "calculate":   #暂时hard coding
            try:
                expression = params.get("expression", "")
                result = safe_calculate(expression)
                response = {"jsonrpc": "2.0","result": result,"id": request_id}
            except ValueError as ve:
                response = {
                    "jsonrpc": "2.0",
                    "error": {"code": -32603,"message": str(ve)},
                    "id": request_id
                }
        else:
            .....其他错误处理...
        return JSONResponse(content=response)
    
    except Exception as e:
#处理其他异常
        ...

再写一个客户端来测试调用这个Server：

#模拟一个MCP客户端，基于简单的HTTP Post
......
class MCPClient:
    ......
    def call(self, method, params=None, timeout=10):
        """调用远程方法"""
        payload = { 
            "jsonrpc": "2.0", 
            "method": method, 
            "params": params if params is not None else {}, 
            "id": self.request_id 
        }
        self.request_id += 1
        
        headers = {'Content-Type': 'application/json'} 

        try:
            response = requests.post(
                self.server_url, 
                data=json.dumps(payload), 
                headers=headers, 
                timeout=timeout
            ) 
            response.raise_for_status()
            return response.json()
        
        except Exception as e:
             ...
...client.call("caculate",{"expression":"3+5"})

这样，我们就模拟了一个基于JSON-RPC2.0的MCP通信的"雏形"：

客户端构造符合JSON-RPC2.0规范的请求消息
通过HTTP Post发送请求到服务端
服务端接收并解析请求，比如需要调用的方法（‘caculate’）
服务端根据请求参数调用对应逻辑(caculate函数)
获得结果，构造并返回JSON-RPC2.0标准的响应

传输协议：为什么需要SSE

MCP Server的其他功能（Resource等）当然也可以采用相同的方式实现。既然这种方式简单易用，为什么MCP的通信标准并不是简单的HTTP Post呢？

如果你采用FastMCP开发MCP Server，可能无法感知到这一点，因为FastMCP是在低层MCP SDK上封装的简易框架，隐藏了细节。

【单一的HTTP Post方式存在的不足】

用下图表示基于简单HTTP Post的请求-响应模式：

考虑到AI应用场景的实际特点，存在着一些可以想象的局限性：

同步阻塞模式：不适应长时间任务需求

单一的请求/响应模式下，客户端必须等待服务端处理完成，这适合快速响应的API，但不擅长应对长时间运行的任务。比如，你可能会把一个复杂工作流发布成MCP Server的工具。那么这种模式就会带来客户端阻塞甚至超时的问题。
无法服务端推送：缺乏双向通信的能力

服务端不能主动向客户端推送消息，数据流动必须由客户端触发。但正如上面的场景，如果你的MCP Server运行一个长时间的任务，你可能需要定期的向客户端报告处理进度或者中间结果，而简单HTTP Post无法做到。

在MCP Server的功能规范中，也存在部分服务端发起的能力，这也依赖于服务端主动推送的能力。
短连接：无法应对对话式会话的需求

在实际应用场景中，你的客户端AI应用可能会在一次会话中多次频繁地与MCP Server对话，来访问其中的资源或工具。这种对话式的交互需要保持会话状态和连接，这需要建立长连接的会话。
流式输出的需求

AI Agent的应用场景中，有时候也需要工具调用做流式的输出，这也需要MCP Server的支持。

基于这样一些原因，MCP采用了带有SSE（Server-Sent Events）的HTTP协议作为Remote模式下的传输方式。

基于SSE的Remote模式

现在我们来了解这种“HTTP with SSE”的传输方式。

【什么是SSE】

SSE（服务器发送事件） 是一种基于HTTP协议的单向通信技术，允许服务器主动实时向客户端推送消息，客户端只需建立一次连接即可持续接收消息。它的特点是：

单向（仅服务器→客户端）
基于HTTP协议，一般借助一次HTTP Get请求建立连接
适合实时消息推送场景（如进度更新、实时数据流等）

其基本通信过程如下：

【MCP的HTTP with SSE模式】

由于SSE是一种单向通信的模式，所以它需要配合HTTP Post来实现客户端与服务端的双向通信。严格的说，这是一种HTTP Post（客户端->服务端） + HTTP SSE（服务端->客户端）的伪双工通信模式。

为什么是伪双工？因为它不是在一个通道上完成双向通信，WebSocket才是。

这种传输模式下：

一个HTTP Post通道，用于客户端发送请求。比如调用MCP Server中的Tools并传递参数。注意，此时服务端会立即返回。

一个HTTP SSE通道，用于服务端推送数据，比如返回调用结果或更新进度。

两个通道通过session_id来关联，而请求与响应则通过消息中的id来对应。

一次完整的会话过程用下图表示：

详细描述如下：

连接建立：客户端首先请求建立 SSE 连接，服务端“同意”，然后生成并推送唯一的Session ID。
请求发送：客户端通过 HTTP POST 发送 JSON-RPC2.0 请求（请求中会带有Session ID 和Request ID信息）。
请求接收确认：服务端接收请求后立即返回 202 (Accepted) 状态码，表示已接受请求。
异步处理：服务端应用框架会自动处理请求，根据请求中的参数，决定调用某个工具或资源。
结果推送：处理完成后，服务端通过 SSE 通道推送 JSON-RPC2.0 响应，其中带有对应的Request ID。
结果匹配：客户端的SSE连接侦听接收到数据流后，会根据Request ID 将接收到的响应与之前的请求匹配。
**重复处理：**循环2-6这个过程。这里面包含一个MCP的初始化过程。
**连接断开：**在客户端完成所有请求后，可以选择断开SSE连接，会话结束。

以上就是MCP远程模式下的HTTP with SSE的传输工作模式。简单总结：通过HTTP Post发送请求，但通过SSE的长连接异步获得服务端的响应结果。

现在，你应该可以理解，如果使用官方的低层SDK来开发MCP Server，为什么Server启动代码大概长这样：

这里服务端的两个端点，/sse是用于会话的开始建立SSE连接，/messages/则用于后续的客户端Post请求处理。

如果你愿意，你甚至可以直接使用最基础的HTTP代码与服务端通信（比如小编），以验证这个交互过程。

最新变化：Streamable HTTP

尽管HTTP with SSE的模式带来了很多优点，但也引入了复杂性。所以在最新的MCP标准（2025-03-26版）中，对目前的传输方式做了调整，改名为Streamable HTTP。

其主要变动在于允许在MCP Server端根据自身需要来选择：你可以选择简单的无状态模式，也可以按需选择支持目前的HTTP with SSE模式。这给予了开发者更大的选择权，具体包括：

移除了专门的/sse端点，所有通信都通过单一/message端点进行。
任何 HTTP POST 请求都可被服务器按需升级为 SSE 流（不再强制）；客户端也可通过GET 请求初始化 SSE 流（目前模式）。
服务器支持完全无状态部署。

当然，最终的协议版本与SDK以官方的正式发布为准。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述