详解AI Agent系列 | 一文读懂Model Context Protocol（模型上下文协议）

最新推荐文章于 2025-07-14 16:44:04 发布

原创最新推荐文章于 2025-07-14 16:44:04 发布 · 1k 阅读

20 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能

AI Agent 专栏收录该内容

2 篇文章

订阅专栏

一、引言

AI Agent 生态割裂之痛与 MCP 协议破局之道 —— 一场关于 AI 协作标准的革命

自 2023 年大模型技术突破以来，全球 AI 生态呈现爆炸式增长：OpenAI 的 GPT-Store 聚集了超 300 万开发者，Anthropic 的 Claude 系列在长文本处理领域独占鳌头，Google 的 Gemini 在代码生成领域持续领跑，而国内的 Coze、Dify 等平台也在快速构建 AI Agent 开发框架。这种繁荣背后却暗藏危机 —— 各平台间数据格式互不兼容、API 接口各有定义，每个体系都相对于另一个体系形成不兼容、孤立的格局，这就导致了开发者每接入一个新平台，都可能需要重构整套交互逻辑。

MCP 协议：打破 AI 生态巴别塔的通用语

对于目前的各家自己维护生态，各家孤立的状态，肯定有很多的个人以及公司开始思考——如何才能以相对“无痛”的方式将各家生态的强项集合起来？

Anthropic在2024年11月发布的一篇关于模型上下文协议(Model Context Protocol，MCP协议)帮助推动了数据源、AI、AI驱动工具之间建立连接。

本文就以下三个角度，来分析MCP到底是什么，以及它对现有局面的影响力。

什么是 MCP？
为什么需要 MCP？
作为用户，我们如何使用/开发 MCP？

二、什么是模型上下文协议（MCP）

从高维度理解MCP到底能干什么

MCP （Model Context Protocol，模型上下文协议）定义了应用程序和 AI 模型之间交换上下文信息的方式。这使得开发者能够以一致的方式将各种数据源、工具和功能连接到 AI 模型（一个中间协议层），就像 USB-C 让不同设备能够通过相同的接口连接一样。

MCP 的目标是创建一个通用标准，使 AI 应用程序的开发和集成变得更加简单和统一。

用一句话理解：MCP 就是以更标准的方式让 LLM Chat 使用不同工具。

这样就不用让开发者在开发Claude基础的Agent时开发一套使用逻辑，而开发GPT基础的Agent时再开发另一套使用逻辑。

更简单的可视化如下图所示，这样你应该更容易理解“中间协议层”的概念了。

三、为什么需要MCP?

3.1 MCP解决了什么问题？

目前AI Agent三大基石：

1. 基础模型（进行思考、推理、计划）

2. 数据源

3. 可调用的工具

随着AI Agent的发展，我们希望其数据来源并不停滞在基础模型完成训练的时间节点，而是扩展到更加事实、更加动态、更加领域专注；同时，我们也希望扩展其能力，将其能力扩展到不仅是输入输出文字，而是可以直接控制屏幕，调用命令等等。

为了推动AI Agent的能力边界，许多 LLM 平台（如 OpenAI、Google）引入了 function call 功能。这一机制允许模型在需要时调用预定义的函数/工具等来获取数据或执行操作，显著提升了自动化水平。

但是 function call 也有其局限性， function call 平台依赖性强，不同 LLM 平台的 function call API 实现差异较大。例如，OpenAI 的函数调用方式与 Google 的不兼容，开发者在切换模型时需要重写代码，增加了适配成本。除此之外，还有安全性，交互性等问题，例如专有的、敏感的数据库无法上传至云端推理的问题。

3.2 MCP通过什么方式解决这些问题？

数据与工具本身是客观存在的，只不过我们希望将数据连接到模型的这个环节可以更智能更统一。Anthropic 基于这样的痛点设计了 MCP，充当 AI 模型的"万能转接头"，让 LLM 能轻松的获取数据或者调用工具。更具体的说 MCP 的优势在于：

生态 - MCP 提供很多现成的插件，你的 AI 可以直接使用。
统一性 - 不限制于特定的 AI 模型，任何支持 MCP 的模型都可以灵活切换。
数据安全 - 你的敏感数据留在自己的电脑上，不必全部上传。（因为我们可以自行设计接口确定传输哪些数据）

为了实现这一协议，Anthropic将MCP 分成三个主要组件：

MCP Host：Host是嵌入 LLM 的应用程序，例如聊天机器人、虚拟助手、Claude Desktop等。Host负责确定何时需要从外部系统获取信息或执行操作，并将这些请求委托给 MCP client。简单来说，Host是 LLM 应用程序的载体，它利用 LLM 的能力，并通过 MCP 与外部世界进行交互。
MCP Client：客户端是位于宿主内部的组件，负责维护与 MCP 服务器的连接，并处理 MCP 协议的通信细节。客户端将宿主的请求转换为符合 MCP 协议的消息，并发送给相应的 MCP 服务器。同时，它还接收来自 MCP 服务器的响应，并将这些响应转换成宿主可以理解的格式。客户端可以看作是宿主与 MCP 服务器之间的桥梁。
MCP Server：服务器是独立的程序，负责提供对特定数据源或工具的访问。每个服务器都实现了 MCP 协议，并对外暴露一组定义好的功能。例如，一个数据库服务器可以提供查询数据库的功能，一个文件系统服务器可以提供读写文件的功能，一个 Web API 服务器可以提供访问特定 Web API 的功能。服务器抽象化了底层数据源和工具的复杂性，为客户端提供了一个统一的访问接口。

让我们通过一个实际场景来理解这些组件如何协同工作：

假设你正在使用 Claude Desktop (Host) 询问："请帮我整理xx文件夹下的文档"

Host：Claude Desktop 作为 Host，负责接收你的提问并与 Claude 模型交互。
Client：当 Claude 模型决定需要访问你的文件系统时，Host 中内置的 MCP Client 会被激活。这个 Client 负责与适当的 MCP Server 建立连接。
Server：在这个例子中，文件系统 MCP Server 会被调用。它负责执行实际的文件扫描操作，访问你的桌面目录，并返回找到的文档列表，并进行下一步整理。

已经加入的server：

https://github.com/modelcontextprotocol/servers

https://github.com/punkpeye/awesome-mcp-servers/blob/main/README-zh.md

整个流程是这样的：你的问题 → Claude Desktop(Host) → Claude 模型 → 需要文件信息 → MCP Client 连接 → 文件系统 MCP Server → 执行操作 → 返回结果 → Claude 生成回答 → 显示在 Claude Desktop 上。

这种架构设计使得 Claude 可以在不同场景下灵活调用各种工具和数据源，而开发者只需专注于开发对应的 MCP Server，无需关心 Host 和 Client 的实现细节。

原理：模型是如何确定工具的选用的？

当用户提出一个问题时：

客户端（Claude Desktop / Cursor）将你的问题发送给 Claude；
Claude 分析可用的工具，并决定使用哪一个（或多个）；

（模型是通过 prompt 来确定当前有哪些工具；通过将工具的具体使用描述以文本的形式传递给模型，供模型了解有哪些工具以及结合实时情况进行选择）

客户端通过 MCP Server 执行所选的工具；
工具的执行结果被送回给 Claude；
Claude 结合执行结果构造最终的 prompt 并生成自然语言的回应；
回应最终展示给用户

3.3 MCP 的技术实现

3.3.1 MCP 协议

MCP 的核心在于其定义的通信协议，该协议规定了客户端和服务器之间如何交换消息、如何调用工具、如何获取资源等。

消息格式：MCP 协议采用 JSON-RPC 2.0 作为其消息格式。JSON-RPC 2.0 是一种轻量级的远程过程调用 (RPC) 协议，它使用 JSON (JavaScript Object Notation) 作为数据交换格式。JSON 是一种易于阅读和编写的文本格式，同时也易于被机器解析和生成。

一个典型的 MCP 请求消息包含以下字段：

jsonrpc: 指定 JSON-RPC 协议的版本，固定为 "2.0"。
method: 指定要调用的工具或要执行的操作的名称。
params: 指定调用工具所需的参数，可以是一个数组或一个对象。
id: 指定请求的唯一标识符，用于匹配请求和响应。

{
  "jsonrpc": "2.0",
  "method": "query_database",
  "params": {
    "sql": "SELECT * FROM users WHERE id = 1"
  },
  "id": 1
}

一个典型的 MCP 响应消息包含以下字段：

jsonrpc: 指定 JSON-RPC 协议的版本，固定为 "2.0"。
result: 指定工具执行的结果，如果执行成功。
error: 指定工具执行的错误信息，如果执行失败。
id: 指定与哪个请求对应的响应，与请求消息中的 id 字段相同。

{
  "jsonrpc": "2.0",
  "result": [
    {
      "id": 1,
      "name": "John Doe",
      "email": "john.doe@example.com"
    }
  ],
  "id": 1
}

3.3.2 MCP 的传输协议

MCP 协议可以在多种传输协议之上实现，例如：

HTTP: 客户端和服务器之间通过 HTTP 请求和响应进行通信。
WebSocket: 客户端和服务器之间建立持久的双向连接，可以实现实时的消息传递。
标准输入/输出 (stdin/stdout): 客户端和服务器之间通过操作系统的标准输入和输出流进行通信，通常用于本地进程间的通信。

选择哪种传输协议取决于具体的应用场景和需求。HTTP 适用于简单的请求-响应模式，WebSocket 适用于需要实时通信的场景，stdin/stdout 适用于本地进程间的通信。

四、MCP对目前格局的变革

MCP 有潜力成为一个通用接口，可以将其视为 AI 领域的虚拟/软件版 USB-C。

它能够在 LLM/AI Agent 与外部资源之间实现无缝、安全且可扩展的数据交换。

MCP 采用客户端-服务器架构，其中 MCP 主机（AI 应用）与 MCP 服务器（数据/工具提供方）进行通信。

开发者可以使用 MCP 构建可复用、模块化的连接器，并利用针对主流平台的预构建服务器，从而打造一个由社区驱动的生态系统。

MCP 的开源特性鼓励创新，允许开发者扩展其功能，同时通过精细化权限控制等特性确保安全性。