最近，关于模型上下文协议（MCP）的讨论非常热烈。你一定听说过它。
今天，让我们一起来了解一下模型上下文协议（MCP）。
直观地说，MCP 就像 AI 应用的 USB-C 接口。
正如 USB-C 为设备连接各种配件提供了标准化方案，MCP 也将 AI 应用连接到不同数据源和工具的方式标准化了。
1.gif
接下来从技术角度进行深入探讨。
MCP 的核心遵循客户端-服务器（client-server）架构，Host 应用程序可以连接到多个 Server。
它包含三个主要组件：
- Host
- Client
- Server
在我们进行深入探讨之前，先来了解一下整体架构👇
2.gif
Host 代表任何提供 AI 交互环境、访问外部工具和数据源并运行 MCP Client 的 AI 应用（如 Claude 桌面版、Cursor）。
MCP Client 在 Host 内运行，实现与 MCP Servers 的通信。
image.png
MCP Server 对外开放特定能力，并提供对数据源的访问权限，包括：
image.png
- Tools：使大语言模型能够通过你的 Server 执行操作。
- Resources：将 Server 上的数据和内容开放给大语言模型。
- Prompts：创建可复用的提示词模板和工作流程。
要构建属于你自己的 MCP 系统，理解客户端-服务器通信机制是必不可少的。
现在我们来解析客户端与服务器的通信流程。
本文将对该过程进行逐步拆解，请看下方这张示意图...
3.gif
首先进行 Capability Exchange（译者注：Capability Exchange（能力交换）是一种动态服务发现与适配机制，是MCP连接建立的必经步骤，类似于“握手协议”。），流程如下：
- 客户端发送初始请求，获取服务器能力信息
- 服务器返回其能力信息详情
- 例如当天气 API 服务器被调用时，它可以返回可用的“tools”、“prompts templates”及其他资源供客户端使用
交换完成后，客户端确认连接成功，然后继续交换消息。
这种机制非常强大，原因如下：
在传统的 API 架构中：
- 如果你的 API 最初需要两个参数（例如，天气服务的 location 参数（译者注：地理位置）和 date 参数（译者注：日期）），用户需严格按此参数结构构建应用。
image.png
- 之后，如果你决定为该 API 添加第三个必选参数（例如，unit参数（译者注：温度单位）），将API “契约”进行变更。
image.png
- 这意味着该 API 的所有用户都必须更新代码，增加对新参数的支持，如果未及时更新，他们的请求可能会失败、报错或提供不完整的结果。
image.png
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 并围绕它们构建实践演示，敬请期待！
Thanks for reading!
Hope you have enjoyed and learned new things from this blog!
