MCP 的工作原理：完整的请求流程

六部分系列文章之第三部分 —— MCP 系列文章

← 第二部分：MCP 是什么：AI 智能体如何连接真实系统

从本质上讲，MCP 是人工智能与外部系统之间的一种结构化对话。人工智能询问有哪些功能可用，系统则以双方都能理解的格式作出回应。人工智能提出所需请求，系统返回结果。

这就是本文后续内容所采用的心智模型。

第二部分解释了 MCP 是什么：包括其组成部分（宿主、客户端、服务器）、三大基本要素（工具、资源、提示）以及管理它们的控制平面。本文将展示这些组件之间实际是如何通信的——首先以系统架构图形式呈现，然后是消息流，最后是线缆级协议消息。

端到端请求流程

一旦各组件就位，当用户提出一个需要调用外部系统的问题时，就会发生以下过程。

图中为每条消息单独编号。以下六个步骤将这些消息归纳为更高层次的阶段：

1. 用户 → 宿主。客户提问：“订单 #4521 的状态是什么？”
2. 宿主 → 大语言模型（LLM）。宿主将问题连同上下文一起传递给大语言模型。
3. 大语言模型（LLM）→ 宿主。模型判断需要使用 check_order_status 功能。它不会直接调用该工具，而是告诉宿主要调用哪个工具以及使用哪些参数。
4. 宿主 → MCP 客户端 → MCP 服务器。宿主将请求通过相应的 MCP 客户端路由，该客户端向封装了订单数据库的 MCP 服务器发送一条 JSON-RPC 请求。
5. MCP 服务器 → 真实系统 → MCP 服务器。服务器将请求转换为原生数据库查询或 API 调用，获取结果，并将其重新格式化为 MCP 响应结构。
6. MCP 服务器 → MCP 客户端 → 宿主 → 大语言模型（LLM）→ 用户。响应沿原路径逐级返回。大语言模型利用该结果生成自然语言回答：“订单 #4521 已于昨日发货，预计周四送达。”

关键在于关注点分离。大语言模型从不直接接触数据库，服务器从不进行语言推理，客户端也从不决定使用哪个工具。每一层只做一件事，而协议则确保它们协同工作。

JSON-RPC 基础知识——仅需了解足以阅读线缆数据的内容

每条 MCP 消息都遵循 JSON-RPC 2.0 规范。要读懂本文后续内容，你只需了解以下三种消息类型：

• 请求（Request）——包含一个 id，并期望收到响应。
• 响应（Response）——使用相同的 id，并携带结果或错误信息。
• 通知（Notification）——没有 id，也不期望收到响应。