1.2 MCP 为何与众不同

在 1.1 小节中详细介绍了什么是 MCP（Model Context Protocol，模型上下文协议），以及 MCP 协议出现的背景和解决的问题。

MCP 协议的核心在于 C，也就是 Context，重点描述如何通过主机应用、MCP 客户端、MCP 服务器三者之间的协作，为大模型补充上下文信息。

而给大模型补充上下文这件事情，在 MCP 协议出现之前，有过不少解法，比如：

记忆存储。把对话的历史消息存储起来，在用户提出新问题时，应用读取历史消息，作为上下文信息补充给大模型
RAG。应用把用户提问发送给大模型之前，先从本地知识库或者互联网上检索信息，再把检索结果作为上下文信息补充给大模型
Function Calling。应用定义一堆工具，分别对接不同的外部数据源。接到用户提问时，把工具列表和用户提问一起发送给大模型，由大模型进行调度，返回合适的工具和调用参数，应用通过工具调用得到外挂数据，再作为上下文信息补充给大模型

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

1.2.1 MCP 与 Function Calling 的关系

Function Calling 是一种交互范式。

Function Calling 定义了三个角色：应用、资源方、大模型。交互过程涉及两个核心步骤：Pick Tool 和 Call Tool。

Pick Tool：应用把工具列表和用户提问发送给大模型，大模型识别用户意图，挑选最适合的工具来满足用户需求
Call Tool：应用通过大模型返回的工具名和参数，调用资源方获取外挂数据

MCP 协议是一套交互标准。

MCP 协议定义了三个角色：主机应用、客户端、服务器。跟 Function Calling 相比，MCP 协议相当于是把”客户端-服务器”作为一个黑盒。

从整体视角看，MCP 协议有四个角色：应用、黑盒（客户端-服务器）、资源方、大模型。

交互流程为：

应用把用户提问发送给黑盒中的客户端
黑盒中的客户端请求黑盒中的服务器，获取服务器定义的工具列表
应用把工具列表和用户提问发给大模型，由大模型进行 Pick Tool
应用根据大模型返回的工具名和参数，通过黑盒中的客户端，发起 Call Tool 请求到黑盒中的服务器
黑盒中的服务器请求资源方得到外部数据
应用得到黑盒返回的外部数据，作为上下文信息补充给大模型，回答用户的初始问题

Function Calling 机制中，工具是在应用内部直接定义的，与外部资源的对接，是由应用直接完成的。

而 MCP 协议中，工具是在外部 MCP 服务器中定义的，应用添加了 MCP 服务器，就能获得 MCP 服务器定义的工具列表。应用不直接跟资源打交道，应用对接 MCP 客户端，资源由 MCP 服务器对接。MCP 协议通过服务外包的方式，减轻了应用侧的实现负担。

Function Calling 的核心在于 Pick Tool 环节，依赖大模型的推理能力。我们平时说的某大模型支持 Function Calling 能力，正确的理解应该是此模型在 Pick Tool 任务场景做了专门的训练优化(函数描述嵌入、特殊格式训练与指令微调)。支持 Function Calling 的模型，在接到应用传递的 Tools 列表，需要从中选择最匹配的 Tool，解析出参数时会有更高的准确度。

而不支持 Function Calling 的模型，比如 gpt-3.5-turbo，也可以通过设置系统提示词的方式，实现 Pick Tool 的操作。只是匹配准确度没有支持 Function Calling 的模型高而已。

MCP 协议是基于 Function Calling 机制之上的应用层协议，本质是为应用给大模型提供上下文服务的，MCP 协议跟大模型本身没有关系。

因此，MCP 不需要大模型支持，不支持 Function Calling 的大模型依然可以使用 MCP。

1.2.2 MCP 受到了 LSP 的启发

从 MCP 官方的访谈播客得知，MCP 协议的设计受到了 LSP 的启发。

LSP（Language Server Protocol，语言服务器协议）是微软于 2016 年提出的一套用于编辑器/IDE 与语言服务器之间通信的协议方案。

LSP 协议建立了编辑器/IDE 与语言服务器之间的通信标准，将语言相关的智能功能（如代码补全、错误检查、定义跳转等）从编辑器中分离出来，由专门的语言服务器提供。

LSP 基于 JSON-RPC 协议，通过标准化的请求和响应格式，实现编辑器与语言服务器之间的通信。当开发者在编辑器中编写代码时，编辑器会向语言服务器发送请求，语言服务器分析代码后返回相应的信息。

LSP 的工作原理如图所示：

LSP 的主要优点：

编辑器中立性：开发者可以使用自己喜欢的编辑器，同时享受语言服务提供的智能功能
避免重复工作：每种语言只需实现一次语言服务器，然后可用于所有支持 LSP 的编辑器
扩展性好：轻松为新语言添加支持，无需为每个编辑器单独开发插件

参考 LSP 协议的设计，MCP 协议也实现了类似的流程，我们在 1.2.1 中已经聊到过，MCP 协议在应用层面定义了三个角色：主机、客户端、服务器。

主机指的是大模型客户端应用，其内部可以创建多个 MCP 客户端，跟应用外部的 MCP 服务器对接。从整体来说，我们可以把 MCP 协议中的主机+客户端，看做是 LSP 协议中的编辑器/IDE，都是面向使用者直接提供服务的一方。
可以把 MCP 协议中的服务器看做是 LSP 协议中的语言服务器。主要作用是对接外部资源，面向 MCP 客户端提供数据或功能服务。

举个例子，基于 LSP 协议实现的一个 Go 语言服务器，主要提供 Go 代码的格式化、自动补全、函数跳转等功能。用户在 VS Code 编辑器中安装 Go 扩展，默认就启动了 Go 语言服务器。当用户在 VS Code 中编写 Go 程序时，VS Code 会把用户编写的代码发送到本地的 Go 语言服务器，进行 Go 代码的格式化、自动补全等操作。

用 MCP 协议 + AI 辅助编程再来举个例子：基于 MCP 协议实现了一个 Go 代码规范服务器，核心功能就一个，读取本地的团队编码规范文档并返回内容给 MCP 客户端。·用户在 Cursor 编辑器中使用 AI 辅助编程，交互流程：

在 Cursor 编辑器 AI 对话框中输入：帮我用 go 写个快速排序函数
Cursor 把请求发给大模型，告诉大模型用户需求，带上已经安装的 MCP 服务器列表
大模型响应给 Cursor，告诉 Cursor 应该先调用获取 Go 代码规范的工具
Cursor 通过 MCP 客户端请求 MCP 服务器调用工具，得到了 Go 代码规范
Cursor 带上 Go 代码规范和用户提问，请求大模型生成代码
大模型帮助用户生成目标代码，且代码风格符合用户所在团队的编码规范要求

交互流程如图所示：

如果用户后面加入了新的团队，团队有新的编码规范要求（比如原团队要求 Go 代码中常量全部大写，新团队要求常量使用驼峰式），那么用户只需要在启动本例的 MCP 服务器时，把对接的本地文件，更换成新团队的编码规范文档即可。使用 AI 辅助编程，就能生成符合新团队编码规范要求的代码。

通过对比分析，可以得知，MCP 协议吸收了 LSP 协议的诸多精华设计理念：

资源与应用解耦，通过外部服务器对接各种类型的功能服务或业务数据
外部服务器可以本地运行，客户端与服务器基于本地进程通信（stdio）
基于 JSON-RPC 协议格式交换数据
应用与服务器的实现，都是一次编码，随处运行，避免了重复工作

LSP 协议经过几年的发展，大大促进了代码编辑器领域的革命性创新和生态系统繁荣。它重塑了整个工具链的架构思维，将”协议驱动”的理念引入开发工具设计，最终实现了”一次实现，处处可用”的愿景，体现了软件工程中”关注点分离”的核心原则。

借鉴 LSP 设计思路的 MCP 协议，也必将大放异彩。而跟 LSP 有限的语言服务器数量相比，MCP 服务器的数量级要大很多，可以让 MCP 生态更加繁荣。

1.2.3 MCP 与 HTTP 协议的类比

MCP 协议发布之后，很多人觉得我们迎来了 AI 时代的 HTTP 协议，价值无可限量。

HTTP（HyperText Transfer Protocol，超文本传输协议）是万维网（World Wide Web）的基础协议。

它定义了客户端和服务器之间如何交换超文本文档，没有 HTTP，现代 Web 的信息交换方式将无法实现。

自 Tim Berners-Lee 博士和他的团队在 1989-1991 年间创造出它以来，HTTP 已经发生了太多的变化，在保持协议简单性的同时，不断扩展其灵活性。如今，HTTP 已经从一个只在实验室之间交换文件的早期协议进化到了可以传输图片，高分辨率视频和 3D 效果的现代复杂互联网协议。

30 几年以来，Web 技术与 HTTP 协议一直保持着共同演进的关系。Web 的发展需求推动了 HTTP 协议的不断进化(从 HTTP/0.9 到 HTTP/3)，而 HTTP 协议的增强又使 Web 应用的可能性大大扩展。

以用户在浏览器访问 https://mcp.so 这个网站举例，演示 HTTP 协议的工作原理，如图所示：

图：HTTP 协议工作原理

在这个例子中，浏览器是客户端，遵循 HTTP 协议的规则，跟 Web 服务器进行通信，拿到 Web 服务器返回的网页内容，展示给用户。

HTTP 协议使用的是互联网经典的 C/S（客户端/服务器）架构。

MCP 协议的设计与 HTTP 协议类似，也是 C/S 架构，只是额外引入了一个主机（Host）的概念。

主机：在 MCP 协议中指的是大模型应用，可以是一个对话客户端。
客户端：在 MCP 协议中是由主机应用创建的子进程，可以与服务器通信
服务器：在 MCP 协议中是一套独立的程序，可以在本地运行，或者在远程服务器运行，对接数据或服务，返回内容给客户端

以用户在大模型客户端查天气举例，演示一下 MCP 协议的主要工作原理，如图所示。

图：MCP 协议工作原理

在这个例子中，大模型客户端是主机应用，接到用户查天气的请求后，通过 MCP 客户端发起请求到 MCP 服务器，由 MCP 服务器完成查天气的功能，再返回天气信息给 MCP 客户端，最终由大模型客户端展示天气信息给用户。

关于 MCP 协议的设计细节和核心架构我们在第 2 章详细讲解。本节通过两个例子来演示了 HTTP 协议与 MCP 协议的基本工作流程。

我们可以对 MCP 协议与 HTTP 协议做一个简单的类比：

协议层次

HTTP 是应用层协议，建立在 TCP/IP 协议栈之上
MCP 也是应用层协议，可以建立在 HTTP 或其他传输协议之上

请求-响应模式

HTTP 采用请求-响应模式，客户端发送请求，服务器返回响应
MCP 同样采用请求-响应模式，MCP 客户端发送请求，MCP 服务器返回响应

生态系统

HTTP 催生了庞大的 Web 生态系统
MCP 正在构建 AI 时代的服务生态系统

正如 HTTP 协议在 30 年前开启了 Web 时代，让互联网真正走进千家万户，改变了人类获取信息和交流的方式。MCP 协议的出现，标志着 AI 时代进入了一个全新的阶段。通过 MCP 协议，我们可以预见一个全新的 AI 原生应用生态正在形成，这将带来比 Web 时代更加深远的信息变革。

1.2.4 MCP 与 A2A 协议的差异

MCP 协议在 2025 年 3 月份爆火的同时，谷歌于 2025 年 4 月 9 日发布了 A2A （Agent To Agent）协议。

A2A 也是一个开源通信协议，旨在为不同系统和平台中的智能体提供标准化的交互方式。智能体是能够执行特定任务的 AI 实体，A2A 确保这些智能体通过一致的标准进行通信和协作，实现跨平台协同工作。

A2A 的目标是使多个 AI Agent 能够共同完成任务，而不直接分享它们的内部记忆、思维或工具。

A2A 协议发布之后，有人开始唱衰 MCP，觉得谷歌出手发布 A2A，目的是为了取代 MCP，掌握 AI 智能体通信标准的制定权。

而仔细研究 A2A 协议之后，你会发现其与 MCP 协议还是存在着不少差异，A2A 协议并不是为了取代 MCP 协议而诞生。

MCP 和 A2A 都是为了解决 AI 智能体的通信问题。MCP 主要是解决应用与外部资源的通信问题，实现为大模型补充上下文的目的，而 A2A 是针对不同系统和平台中的智能体之间的通信。所以，他们并不是取代关系，而是互补与协作关系。

A2A 和 MCP 可以通过互补协作的方式来构建多智能体系统，利用大模型+专业工具+智能体来提供强大的复杂功能。

鉴于篇幅有限，我们暂不对 A2A 协议的设计原理、应用场景做具体的讲解，我们还是聚焦于 MCP 协议的价值宣传与实际应用。

但需要强调的是，A2A 协议的发布对于 AI 智能体的发展是好事，但是并不影响 MCP 协议的发展。我们期待看到，多个 AI 协议之间能够扬长避短，共同进步，加强协作，共同促进 AI 行业的整体进步与发展。

1.2.5 小结

本节内容详细探讨了 MCP 协议与其他相关技术的区别和联系，揭示了其独特价值：

与 Function Calling 的关系：

MCP 是在 Function Calling 基础上的升级和抽象
将工具定义从应用内部转移到外部 MCP 服务器
通过服务外包方式减轻应用侧实现负担

与 LSP 的渊源：

借鉴了 LSP 协议的设计理念
实现了资源与应用解耦
实现”一次编码，随处运行”

与 HTTP 的类比：

采用类似的 C/S 架构
正在构建 AI 时代的服务生态系统
有望像 HTTP 一样推动行业变革

与 A2A 的差异：

MCP 专注于应用与外部资源的通信，A2A 关注不同系统和平台中智能体间的通信
两者是互补而非替代关系
可以协作构建更强大的多智能体系统

MCP 协议通过创新的设计，为 AI 应用开发提供了标准化的上下文补充方案，有望成为 AI 时代的基础协议，推动整个 AI 生态系统的繁荣发展。