图解「模型上下文协议（MCP）」：从与传统 API 的比较入手
图解「模型上下文协议（MCP）」：从与传统 API 的比较入手
模型上下文协议（MCP）是近期热议的AI技术话题。它通过标准化通信协议，让AI应用与外部工具、数据的交互如同USB-C接口一般高效且灵活，彻底改变传统API架构的僵化限制。本文将从技术角度深入解析MCP的核心架构和能力交换机制。
最近，关于模型上下文协议（MCP）的讨论非常热烈。你一定听说过它。
今天，让我们一起来了解一下模型上下文协议（MCP）。
直观地说，MCP就像AI应用的USB-C接口。正如USB-C为设备连接各种配件提供了标准化方案，MCP也将AI应用连接到不同数据源和工具的方式标准化了。
接下来从技术角度进行深入探讨。
MCP的核心遵循客户端-服务器（client-server）架构，Host应用程序可以连接到多个Server。
它包含三个主要组件：
- Host
- Client
- Server
在我们进行深入探讨之前，先来了解一下整体架构👇
Host代表任何提供AI交互环境、访问外部工具和数据源并运行MCP Client的AI应用（如Claude桌面版、Cursor）。
MCP Client在Host内运行，实现与MCP Servers的通信。
MCP Server对外开放特定能力，并提供对数据源的访问权限，包括：
- Tools：使大语言模型能够通过你的Server执行操作。
- Resources：将Server上的数据和内容开放给大语言模型。
- Prompts：创建可复用的提示词模板和工作流程。
要构建属于你自己的MCP系统，理解客户端-服务器通信机制是必不可少的。
现在我们来解析客户端与服务器的通信流程。
本文将对该过程进行逐步拆解，请看下方这张示意图…
首先进行Capability Exchange（译者注：Capability Exchange（能力交换）是一种动态服务发现与适配机制，是MCP连接建立的必经步骤，类似于“握手协议”。），流程如下：
- 客户端发送初始请求，获取服务器能力信息
- 服务器返回其能力信息详情
- 例如当天气API服务器被调用时，它可以返回可用的“tools”、“prompts templates”及其他资源供客户端使用
交换完成后，客户端确认连接成功，然后继续交换消息。
这种机制非常强大，原因如下：
在传统的API架构中：
- 如果你的API最初需要两个参数（例如，天气服务的location参数（译者注：地理位置）和date参数（译者注：日期）），用户需严格按此参数结构构建应用。
- 之后，如果你决定为该API添加第三个必选参数（例如，unit参数（译者注：温度单位）），将API“契约”进行变更。
- 这意味着该API的所有用户都必须更新代码，增加对新参数的支持，如果未及时更新，他们的请求可能会失败、报错或提供不完整的结果。
MCP的设计解决了这个问题，具体方法如下：
- MCP引入了一种动态、灵活的方法，与传统API形成鲜明对比。
- 当Client（例如Claude Desktop这类AI应用）连接MCP Server（例如天气服务）时，会发送初始请求，以便了解Server的能力。
- Server的响应包含可用的tools、resources、prompts以及相关参数的详细信息。例如，若天气API最初仅支持location和date参数，服务器会通过能力交换告知这些信息。
- 当新增unit参数时，MCP Server可在下次进行能力交换时动态更新能力描述。Client无需硬编码或预定义参数，只需查询Server的最新能力并自动适配。
- 这样，Client就能使用更新后的新功能（例如在其请求中包含unit参数），实时调整行为，而无需重写或重新部署代码。
希望本文能阐明MCP的作用。
后续我们将探索如何创建自定义的MCP servers并围绕它们构建实践演示，敬请期待！