当前位置：首页 > news >正文

MCP 大模型的扩展坞

news 2025/8/17 7:45:41

前言

随着 ChatGPT 的爆火，大语言模型（LLM）的能力已经被大家认可。现在的大模型，不仅可以帮你撰写文档，生成诗歌文章，理科生的活儿它也做的同样优秀。从文学创作到数学推导，大语言模型正以惊人的适应性突破传统认知边界。

然而，大语言模型虽然强大，却也有它的局限性。

大模型是通过历史数据进行训练的，这些数据在训练时就已经固定。模型训练完成后，其知识就停留在训练时的状态，无法自动获取训练之后的新信息。例如你问它今天杭州的天气怎么样，大模型是没有这些数据的，其回答结果无非两种：要么无法回答，要么胡编乱造。

由此可见，大模型的知识库和日益发展的现实世界是断层的，是相互矛盾的。

大模型的数据获取问题

为了解决这个矛盾，行业内探索出了两种主要的方案，让大模型可以基于更多的信息来推理。

一、模型微调

模型微调，是在预训练好的大模型的基础上，使用新的数据集进行额外的训练。模型的基本架构保持不变，只调整部分参数，从而使模型学习新的知识或适应特定任务。

可见，模型微调仍然是一个“先训练后部署”的方案，虽然在解决某些专业领域问题时补充了新知识，但不适用于对时效性要求高的场景，比如获取实时新闻、天气信息等。

二、上下文补充

上下文补充，是为大模型提供外部知识库或信息源的技术方案，旨在让大模型突破知识的时效性限制，能够访问专业领域信息，从而提高回答的准确性、时效性和可靠性。

上下文补充不需要重新训练模型，而是在模型生成回答时实时提供相关信息作为输入上下文，让模型能够基于这些最新的信息进行推理，弥补静态知识与动态世界之间的鸿沟。

模型上下文补充

MCP 就是模型上下文补充的一种实现方案。不过在 MCP 出现之前，行业内就已经存在几种补充上下文的方案：

1、记忆存储

客户端会将用户与大模型的每轮对话内容记录下来，并设定一定的记忆容量。当用户提出新问题时，系统会从记忆库中提取与当前对话相关的信息，作为补充上下文提供给大模型，从而使模型的回答更加连贯，就像赋予了模型“记忆”能力。

不过，它受限于模型支持的上下文长度。

2、RAG

RAG（retrieval-augmented generation，检索增强生成）工作原理：当用户发出提问时，AI应用通过向量检索、关键词匹配等方式，从外部知识库检索相关信息，再把检索到的信息作为上下文提供给大模型，让大模型基于补充的信息进行回答。

3、函数调用

函数调用（function calling）工作原理：当用户发出提问时，AI应用会将集成的函数列表作为上下文发送给大模型。大模型根据用户输入判断具体调用的函数，并生成相应的调用参数。随后，AI应用执行该函数并将结果发送给大模型，作为补充信息供其生成最终的总结或回答。

4、MCP

MCP 是在函数调用的基础上做了进一步的升级和抽象，目的是让AI应用更加简单、高效、安全地对接外部资源，更好地为大模型补充上下文信息。

什么是MCP？

MCP 是一个标准化的协议，它的作用是解决大模型和外部系统之间集成的难题。

在这个大模型和外部系统均百花齐放的时代，如果没有一个统一的标准，要实现上面这个目标简直是天方夜谭。假设大模型厂商有M个，要集成大模型的外部系统有N个，集成二者的工作量就是 M*N 的关系。

所以，MCP 设计的出发点，就是为解决大模型和外部系统集成设计一个通用的标准协议。

MCP 是 Model Context Protocol 的缩写，中文译为“模型上下文协议”。

MCP 约定了 AI 应用如何规范地集成外部工具，实现为大模型（Large Language Model）补充上下文（Context）的目的，其本质是应用层协议（Protocol），好比似 HTTP 协议。

协议即标准。标准的制定，是为了推动行业形成一种共识。共识一旦形成，不仅能降低重复开发的成本，更能推动整个生态系统有序、快速地发展。

MCP = MCP主机 + MCP客户端 + MCP服务器

MCP主机

MCP的中心枢纽，它既是用户与大模型直接交互的终端，又是协调外部资源的调度中心。

作为终端：接收用户输入并请求大模型生成回答。所有支持MCP的AI应用，都可以看作主机。
作为调度中心：主机创建并管理多个客户端实例。在请求大模型生成回答的过程中，主机创建客户端实例请求外挂的服务器获取额外的数据或者执行特定的任务。再把外挂的服务器返回的数据，作为上下文补充给大模型，让大模型具备外挂能力。

MCP服务器

主要负责对接外部数据或服务，并通过标准的数据格式将响应内容发送给MCP客户端。

比如，我们开发一个【天气MCP服务】，对外提供“获取城市天气”等能力。

MCP客户端

是MCP主机与MCP服务器之间的桥梁。客户端“寄生”于主机中，由主机创建并进行调度，客户端与服务器进行连接，从而实现与外部数据或服务的交互。

有一个比喻很形象，说AI应用就像一台只有有限接口的电脑，无法直接访问外部数据或服务。MCP则扮演了“扩展坞”的角色，通过标准化的协议接口，为AI应用提供连接各种外部系统的能力。

MCP交互形式

MCP 由主机、客户端、服务器组成。所有支持MCP的AI应用，都可以看作是主机，MCP 客户端寄生在主机内，由主机负责创建和调度。

交互形式大致流程：用户提出问题，MCP 主机创建 MCP 客户端和 MCP 服务器建立连接，然后客户端询问服务器具备哪些能力，比如列举服务器支持的所有工具 Tools。然后主机把用户问题和MCP服务器支持的能力列表喂给大模型，大模型识别用户的意图，判断应该调用哪个工具，参数是什么，然后MCP客户端发起工具调用，MCP服务器处理请求并返回结果，主机再将MCP服务器返回的信息一并喂给大模型，这一步就是在补充模型的上下文信息，让模型具备获取外部知识的能力。最后，大模型基于所有获得的信息，进行推理和回答。

能力协商机制

MCP采用能力协商机制，在初始化阶段，客户端与服务器分别通过 capabilities 字段声明自身支持的能力。这些声明决定了双方在整个会话期间的交互方式与能力边界。

例如，服务器可以声明支持提示词、资源、工具等能力；客户端则可能声明支持根（节点）、采样等能力。

{"jsonrpc": "2.0","id": 1,"method": "initialize","params": {"protocolVersion": "2025-03-26","capabilities": {"roots": {"listChanged": true},"sampling": {}},"clientInfo": {"name": "McpClient","version": "1.0.0"}}
}

JSON-RPC

MCP 使用 JSON-RPC 作为客户端与服务器的通信基础。它是一种基于JSON的轻量级RPC协议。

主要特点包括：

使用JSON作为消息格式；
支持标准的请求-响应通信模式；
简单易用，语言无关，易于跨平台实现；
可以通过HTTP/HTTPS或其他传输协议进行传输；
标准的JSON-RPC请求结构包括方法名、参数和请求ID；响应则包含结果或错误消息，以及与请求相匹配的ID。当前，JSON-RPC的最新版本是2.0。

JSON-RPC 请求对象字段：

jsonrpc，字符串，指定JSON-RPC协议的版本，必须为2.0；
method，字符串，表示要调用的方法名；
params（可选），对象或数组，包含传递给方法的参数；
id，字符串、数字或null，用于将请求与对应的响应关联起来。

JSON-RPC 响应对象字段：

jsonrpc，字符串，指定JSON-RPC协议的版本，必须精确地为2.0；
result，响应成功时必须包含此成员，且包含方法调用的结果；
error，响应失败时必须包含此成员，且包含错误消息；
id，必须包含此成员，且必须与请求对象中的id值相同。

连接声明周期

MCP定义了一个严格的生命周期（lifecycle），用于客户端-服务器连接，确保了通信双方能进行适当的状态管理和能力协商。

建立连接

客户端发送

{ "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2024-11-05", "capabilities": { "roots": { "listChanged": true }, "sampling": {}}, "clientInfo": { "name": "ExampleClient", "version": "1.0.0" } } 
}

服务端响应

{ "jsonrpc": "2.0", "id": 1, "result": { "protocolVersion": "2024-11-05", "capabilities": { "logging": {}, "prompts": { "listChanged": true }, "resources": { "subscribe": true, "listChanged": true }, "tools": { "listChanged": true } }, "serverInfo": { "name": "ExampleServer", "version": "1.0.0" }, "instructions": "Optional instructions for the client" } 
}

客户端确认

{ "jsonrpc": "2.0", "method": "notifications/initialized" 
}

和 TCP 三次握手很像。

操作阶段

比如，客户端想知道服务端支持哪些工具

{ "jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": { "cursor": "optional-cursor-value" } 
}

服务端响应

{ "jsonrpc": "2.0", "id": 1, "result": { "tools": [ { "name": "get_weather", "description": "Get current weather information for a location","inputSchema": { "type": "object", "properties": { "location": { "type": "string", "description": "City name or zip code" } }, "required": ["location"] } } ], "nextCursor": "next-page-cursor" } 
}

客户端想调用某个工具，就发送

{ "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "get_weather", "arguments": { "location": "New York" } } 
}

服务端响应

{ "jsonrpc": "2.0", "id": 2, "result": { "content": [ { "type": "text", "text": "Current weather in New York:\nTemperature: 72°F\nConditions: 
Partly cloudy" } ], "isError": false } 
}