MCP 架构：附图完整技术详解

MCP 架构是实现 MCP（Model Context Protocol，模型上下文协议）的一组基础组件和通信规则。MCP 是一项开源标准，而 MCP 架构则是其运行所依托的底层基础设施。

任何 MCP 架构都包含并围绕三个核心组件构建：主机（host）、客户端（client）和服务器（server）。MCP 的通信框架通常被描述为由数据层和传输层组成。数据层是规定消息格式的一组规则（MCP 请求以 JSON-RPC 2.0 格式发送）。传输层负责承载这些消息，对外部连接使用 Streaming HTTP。

MCP 架构是一种实现 Model Context Protocol 的服务器框架。Model Context Protocol 是一项开放标准，用于将 AI 模型连接到工具、数据库等资源，以及扩展输入上下文的提示词。这些统称为“原语”（primitives）。归根结底，MCP 架构让 LLM 能够发现有哪些可用工具并执行工作流，而无需在客户端频繁更新。

MCP 架构示意图：AI 应用与 MCP 服务器交换请求，MCP 服务器提供工具、资源和提示词。

自 Anthropic 推出以来，MCP 架构已在 AI 工作流中得到广泛应用。这在很大程度上是因为它取代了维护负担更重的系统（例如围绕多个 API 连接构建的系统），同时又不牺牲性能。由于所有可用功能都位于 MCP 服务器之后，因此只需一个连接，而且更新和新增的功能会立即对客户端应用可用。

MCP 为 LLM 提供了一种途径，使其能够发现并调用可用的工具、提示词和资源，这些内容既可以位于主机应用的本地系统上，也可以来自外部提供方。

对于提供外部功能访问的工具而言，发现是指主机向 MCP 服务器发出 tools/list 调用，以查找有哪些可用工具。随后，LLM（在某些情况下是主机）可以读取可用工具的描述，并根据需要请求这些工具。提示词和资源的使用过程与此类似。

MCP 架构组件示意图：包含 LLM、编排器和客户端的主机分两步连接到 MCP 服务器，先进行发现，再发出请求；MCP 服务器对外提供工具、资源和提示词。

这与软件开发中一直以来的常规做法——定制的基于 API 的架构——形成了鲜明对比。在那种架构中，应用之外的功能必须通过专用连接、以格式严格的请求来调用。

主机应用是核心编排平台，并与 LLM 相连。Perplexity 和 Claude Desktop 等知名工具都可以在 MCP 系统中充当主机。

在一个简单的工作流中，用户通过聊天界面提出问题。随后，主机的编排器组件会为问题添加上下文，告诉 LLM 有哪些可用的 MCP 原语，并附上其功能描述。

客户端是 AI 应用中的一个软件组件。MCP 为客户端提供了一个标准接口，使其能够根据主机或 LLM 的指令与内部和外部 MCP 服务器通信。它的任务是建立连接、格式化 JSON-RPC 消息、发送请求并接收响应。

“MCP 主机”和“MCP 客户端”这两个术语有时会被混用。然而，二者的区分很有意义，因为像 Perplexity 这样的主机可能会同时编排多个 MCP 客户端。一个复杂的 AI 工作流可能需要访问数十个甚至数百个独立的 MCP 服务器，而每个服务器都会使用单独的连接。

MCP 主机（例如 Perplexity）编排三个 MCP 客户端的示意图，每个客户端都连接到各自的 MCP 服务器，例如数据库、文件或外部 API。

服务器对外提供该 AI 工具可以使用的所有工具。从架构角度来看，MCP 服务器负责解析传入的请求，并在需要时连接到所请求的原语。

MCP 服务器可以提供对三类原语的访问：

工具：这些本质上是外部软件功能。以传统的基于 API 的方法为例，网站分析应用可能会通过向外部服务器发送格式化请求来获取数据。在 MCP 架构中，来自某个提供方的所有第三方功能都可以通过单一连接使用，并且请求按照标准格式规则创建。
资源：资源是提供只读上下文的数据源，数据库架构（schema）就是一个很好的例子。MCP 服务器会向主机公开其可用的各种信息源。如果主机查询数据库（例如通过 LLM 生成的 SQL 搜索），则视为工具请求。
提示词：这些是可复用的提示词模板，可帮助 LLM 执行特定任务。用户或主机之所以调用提示词而非工具，是因为完成任务需要现成的指令。主机应用中的预设任务（例如“审查代码”或“分析数据”选项）通常以提示词的形式存储，供用户选择。

另外值得注意的是，MCP 和 API 并不是互斥的技术。MCP 服务器可以公开 API 调用，以响应发现请求。关键在于，维护这些调用的是 MCP 提供方，而不是客户端。

MCP 架构中的数据层是一组规则，用于定义请求、响应和通知的格式。消息的标准语言是 JSON-RPC。

所有 MCP 架构都遵循一个基本流程：（1）主机进行初始化和发现，（2）MCP 服务器作出响应，（3）主机发起调用（有时由 LLM 决定），每个阶段都对应一条单独的 JSON 消息。

MCP 数据层示意图：用户向主机应用发送提示词，LLM 在主机应用中与 MCP 客户端协同工作；客户端向 MCP 服务器（工具、资源、提示词）发送请求并接收结果，然后主机向用户返回响应。

下面通过两个示例来看看工具发现是如何运作的（这些示例同样适用于资源或提示词）：

在 LLM 生成前发现工具：主机启动 MCP 客户端，由客户端发送 tools/list 请求（即获取 MCP 服务器的可用工具列表）。LLM 会在生成过程中查看该列表，并判断是否需要某个特定的工具、资源或提示词。
为 LLM 提供运行搜索的选项：在智能体系统中，主机会向上下文输入添加一个发现选项，例如 search-tools， LLM 便可在需要时请求搜索。

工具大体上是外部应用功能，通常由 LLM 或主机选择。资源和提示词则通常应用户要求或由主机请求。

下面是一个虚构的笔记应用向 MCP 服务器发送 tools/list 请求的示例：

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

在此示例中，“id”:101 使用 ID 标识该请求，以便客户端匹配响应；“params” 字段则包含有关客户端的附加信息，例如客户端名称（notes-app-client）和功能。

作为响应，MCP 服务器会返回工具定义，其中包括可用工具的名称及相关详细信息。例如，列表中可能包含一个 add-task 工具，让笔记应用能够在已连接的任务管理或日历应用中创建任务，并为每个任务分配标题和优先级。

请求可能如下所示：

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

“method” 字段告诉 MCP 服务器这是一次工具调用，“name” 指定要调用的工具，“arguments” 则提供所需的输入。

如果说数据层决定了客户端与 MCP 服务器之间的连接“传什么”，那么传输层决定的就是“怎么传”。它定义了消息的传输方式：具体的通道，以及规定请求和响应如何传递的规则。

MCP 有两种传输方式：

标准输入/输出：当 MCP 服务器与主机应用运行在同一本地环境中时使用此方式。客户端将 JSON 请求写入服务器的标准输入。服务器读取请求，执行所请求的操作，然后将响应写入标准输出。
Streamable HTTP：当 MCP 服务器在主机应用外部运行时，MCP 客户端使用 HTTP POST 向服务器发送请求。服务器会以单条 JSON 消息或 Server-Sent Events (SSE) 流进行响应。SSE 流是一种持久的“监听”通道，使服务器能够随时间推移返回多条消息。

MCP 多租户架构是一种可以同时为多个用户（租户）提供服务的实现方式。

这里的租户可以是个人、一群人或一个组织。实现方式可以是为每个租户运行单独的 MCP 服务器、提供对单个共享服务器的访问，或者将一组服务器置于中央网关之后。使用网关时，网关会根据用户身份或请求性质将请求路由到正确的端点。

它的基本原理与标准 MCP 架构相同，但每个用户的请求都在各自的工作空间中运行（即使这意味着共享资源），并单独进行身份验证。这种架构在企业场景中很常见，而且通常更倾向于共享资源，因为运行多个 MCP 服务器会带来不必要的成本。

一个端到端的 MCP 请求在实际中是什么样的？它包含八个核心阶段，每个阶段都涉及一个不同的架构组件。

端到端 MCP 请求的八步流程图：工具发现、用户输入、模型处理、工具选择、请求、工具执行、结果和答案生成。

下面沿用前面那个连接到任务管理服务的笔记应用示例，来看看 MCP 工具调用在实际中是什么样的：

工具发现：笔记应用（主机）使用其 MCP 客户端，通过 tools/list 请求获取服务器的可用工具。服务器会返回这些工具的名称、描述和预期输入，其中包括 add-task 工具的相关信息。这一步可能在你提交提示词之前就已完成。
用户输入：你通过应用内聊天机器人向这款基于 LLM 的笔记应用提交请求，例如：“在我的日历中创建一个任务，审阅我的新草稿，优先级为中。”
模型处理：主机将你的请求和相关工具定义发送给 LLM。
工具选择：LLM 生成结构化的工具请求，指定工具及其输入：add-task，其中 title: 审阅草稿，priority: 中。主机检查该操作是否获得许可，然后将请求传递给 MCP 客户端，由客户端发送 JSON-RPC 消息。
请求：MCP 客户端向其 MCP 服务器发送 tools/call 请求。
工具执行：MCP 服务器调用任务管理应用的 API，按照指定的标题和优先级创建新任务。
结果返回：服务器将结果发回 MCP 客户端，客户端再将其传递给主机。主机将结果添加到提供给 LLM 的信息中。
答案生成：LLM 利用该结果为用户生成答案，例如：“我已创建一个审阅草稿的任务，优先级为中。”

MCP 和传统 API 架构经常被混为一谈，但它们其实是互补的技术。MCP 专为基于 AI 的应用而设计，解决了实现和管理多个硬编码 API 连接所带来的高昂维护负担。

MCP 为主机应用的每个功能提供方或内部资源只提供一个连接，从而有助于解决上下文输入臃肿（列出所有 API）或基于 API 的应用脚本能力受限的问题。

相反，MCP 可以将 API（更确切地说，是调用 API 的功能）作为其工具列表的一部分公开。每当提供方更新其应用并推出新的 API，或者文档发生变化时，只需更新 MCP 服务器即可，主机应用一侧无需更改任何代码。

自推出以来，MCP 的安全性一直备受争议。尽管它通常被认为是一项安全的技术，但仍存在若干安全风险，其中许多风险在复杂的架构实现中更为突出。

MCP 架构存在以下潜在弱点：

提示词注入：用户将恶意提示词插入外部数据中，AI 模型误将其解读为指令。
权限过度：MCP 服务器可能会向 AI 模型公开大量工具，从而增加引发安全问题的可能性（即扩大“爆炸半径”）。
意外数据泄露：配置不当的实现可能会导致 API 密钥或数据库凭据等敏感信息被传递给 LLM。
本地系统操纵：与其他任何应用一样，本地 MCP 服务器同样容易受到恶意脚本等本地系统问题的影响，而且还存在一个额外问题：它们可能会对智能体 AI 系统造成下游危害。

这些问题都并非无法克服。通常，只需采取成熟的措施就足以确保系统安全。让人工参与决策环节（human in the loop）、对敏感数据实施严格管控以及防范服务器攻击等措施都是常见做法。

MCP 已被证明是一项对开发者实用且广受欢迎的开放标准。它解决了基于 LLM 的应用中硬编码 API 的诸多问题，并大幅减轻了开发者的编码负担。

展望未来，MCP 底层的主机和服务器架构几乎肯定会保持不变。未来的创新将集中在跨多步骤工作流的高级智能体能力上。

此外，随着这些智能体功能的落地，需要更强有力的安全防护措施；同时，随着 AI 系统变得更加庞大和复杂，也需要可扩展的架构，尤其是在传输层。

什么是 MCP 架构？

MCP 架构组件：主机、客户端和服务器

主机

客户端

服务器

MCP 架构中的数据层是什么？

MCP 架构中的传输层是什么？

什么是 MCP 多租户架构？

MCP 架构图：分步详解

MCP 架构与传统 API 架构有何不同？

MCP 架构安全吗？

MCP 架构的未来发展方向是什么？