模型上下文协议 (MCP) 开启了许多扩展大型语言模型的可能性，但也引发了一些困惑。因此，我着手构建一个初学者指南，以可视化的方式（例如图表等）帮助理解 MCP 架构。

如果您是开发人员，您可能听说过 MCP 服务器如何在 Cursor、Windsurf 乃至 VS Code 的新代理工作流等代理模式软件开发中占据核心地位。然而，MCP 的应用远不止于软件领域。它还能提供无缝且丰富的最终用户 LLM 体验，因为它能在训练数据之外扩展模型的能力，并利用模型的推理能力驱动实际操作。

了解 MCP

LLM 本质上是一个压缩的知识库，包含了所有用于训练的数据。它借鉴了人类大脑的运作方式，通过类似神经网络的结构进行学习，这使得它们具备了推理能力，并能进行类似智能的重大逻辑跳跃。尽管大型语言模型令人印象深刻，但它们仍然受限于自身的数据。

MCP 是连接 LLM 与其掌握范围之外的知识和行动的桥梁。有人认为，在 OpenAI 不久前引入函数调用或工具调用功能时，这个概念就已经存在。但 MCP 继承了这一概念，并将其扩展为一个开放的通信标准。它奠定了结构化接口的基础，实现了分布式和动态的工具部署与发现。稍后我们将详细讨论 MCP 与函数调用的区别。

MCP 主机、MCP 客户端和 MCP 服务器

概述了 MCP 的目的后，我们可以进一步剖析 MCP 的构成要素。MCP 本质上包含三个实体：

• MCP 主机：这是集成了 MCP 功能的 AI 驱动应用程序。实际示例包括 Claude Desktop、Cursor、Windsurf、VS Code、DeepChat 等。这些应用程序通过实现 MCP 客户端来集成 MCP。
• MCP 客户端：MCP 客户端是基础实现层，通常托管在功能丰富的 AI 应用程序、代理框架及其他类似应用中。它是与 MCP 服务器通信的接口。
• MCP 服务器：MCP 服务器是提供“世界”功能的部分。例如，LLM 无法直接访问您的本地文件，对吧？但如果 MCP 服务器提供了文件访问工具，LLM 就可以列出、读取和操作这些文件。MCP 服务器实现了 LLM 现在可以访问的这些扩展功能、知识和操作。

注意：您可能会看到 MCP 主机有时也被称为 MCP 客户端，因为这个术语被上移了一层，意指 MCP 客户端实际上就是 AI 驱动的应用程序本身。

函数调用和工具简介

MCP 服务器最常见的做法是向 MCP 客户端提供工具。工具的示例包括“读取文件”或“列出远程 git 存储库的所有分支”。

它们是如何实现的？MCP 服务器会告知 LLM：“嘿，这是我为你提供的工具，其中一个叫做 read_file”。然后，LLM 可以通过模型上下文协议专门触发这个工具。该协议又映射到 MCP 服务器代码中的实际函数实现：

但工具本身并非新概念。工具调用（或称函数调用）是由 OpenAI 于 2023 年末推出的。随后，函数调用在每个 AI 应用程序中实现，并且必须由应用程序专门为 LLM 进行编排。更重要的是，并非所有模型都原生支持函数调用。

我们稍后会讨论 MCP 如何为函数调用提供更优的整体解决方案。

MCP 服务器传输类型：STDIO 与 HTTP

MCP 服务器最初可能给人一种实际基于网络服务的印象，但 MCP 的精妙之处在于它可以通过标准输入/输出（STDIO）传输与本地运行的进程进行通信。

什么是 STDIO？

STDIO（标准输入、标准输出、标准错误）是系统进程之间基于文本的基本通信机制。这实际上是指命令或程序，例如在命令提示符中运行的 git。

程序执行时，操作系统会建立三个默认通道：stdin 用于接收输入（通常来自键盘或其他程序的输出），stdout 用于正常输出（通常显示在终端或写入文件），stderr 用于错误和诊断消息（通常也显示在终端，但通常与 stdout 分开）。

简而言之，STDIO 允许程序与操作系统或其他程序交互。例如，您可以将一个命令的输出（其 stdout）通过管道（|）作为另一个命令的输入（stdin）。同样，您可以将程序的 stdout 或 stderr 重定向（>）到文件以便记录或后续检查。许多命令行工具严重依赖 STDIO 进行数据处理管道和基本交互。

在具有客户端-服务器架构的系统（如 MCP）中，STDIO 提供了一种直接的方法：MCP 服务器作为一个进程运行，接收来自 MCP 客户端的请求（通过 stdin），并将其作为文本响应（通过 stdout）发送回去。

本地 STDIO MCP 服务器

将 MCP 服务器扩展到云端

最终，随着 HTTP 传输类型在 Cursor 和 Claude Desktop 等 AI 应用程序中得到广泛应用，以及 Vercel 和 Cloudflare 等云基础设施对托管 MCP 服务器的支持，MCP 服务器的潜力得以真正释放。

最初，MCP 规范引入了一种基于网络的 HTTP 传输机制，依赖名为 SSE（服务器发送事件）的机制来同步和协调 LLM 与 MCP 服务器之间的消息。然而，与 Websockets 类似，SSE 需要长时间运行的服务器连接，这在 Vercel Functions 或 AWS Lambdas 等现代无服务器部署平台上难以实现。因此，一种新的可流式 HTTP (Streamable HTTP) 规范应运而生，为 MCP 服务器实现了无服务器 HTTP 支持。

基于 HTTP 的 MCP 服务器配置更简单，因为它们只需要远程主机地址，而无需复杂的命令行参数规范。它们还使 MCP 服务器更易于共享和访问，因为不再需要特定的开发环境在本地设置和运行。

例如，Cursor 期望通过 HTTP 的远程 MCP 服务器定义如下：

MCP 架构——整合

现在我们已经概述了 MCP 的构建模块（如 MCP 客户端、MCP 服务器、它们用于通信的传输类型以及每种类型的实际示例），我们可以更好地理解部署模型和 MCP 的整体架构。

MCP 架构同时支持本地和远程部署，实现了多种配置和部署策略。例如，您可以构建一个完全在本地运行的、支持 MCP 的 AI 应用程序生态系统。具体操作如下：安装一个支持 MCP 的本地 AI 应用程序，例如 Raycast 生产力应用或 Cursor IDE。然后，通过 Ollama 为 Raycast 或 Cursor 提供本地运行的 LLM。Raycast 或 Cursor 应用程序运行本地 MCP 客户端，您可以为其配置本地运行的 MCP 服务器（例如 SQLite MCP 服务器），以浏览基于文件的数据库记录。

以上示例展示了一个完全在笔记本电脑本地环境中运行的人工智能应用设置，无需任何云服务或网络访问。

或者，您也可以混合搭配组件。您可以将 MCP 服务器部署到云基础设施，并通过 HTTP 传输使其可用。MCP 客户端和 MCP 服务器根据规范通过模型上下文协议进行通信，从而实现完全解耦。

更进一步说，虽然绝大多数 AI 应用程序已将 MCP 客户端的实现作为其自身的一部分，但这并非严格必要。MCP 客户端理论上也可以与 AI 应用程序分离。

MCP 与函数调用的比较以及为什么 MCP 不是 API 包装器

许多人将 MCP 描绘成“又一个 REST API 封装器”。这种看法既短视又低估了其价值。让我们探究一下为什么 MCP 更加细致入微，并且更契合 AI 应用的需求。

在讨论更广泛的 MCP 与 REST API 对比之前，一些开发人员希望更清晰地了解 MCP 与 OpenAI 及其 SDK 自 2023 年以来启用的原始函数调用有何不同以及为何不同。

MCP 与函数调用

使用函数调用时，AI 应用程序需要自行实现每一个工具。设想一下，如果像 Cursor 这样的 AI 应用程序需要实现一个“列出远程分支”的 git 工具。一个应用程序（例如 Cursor）可能会选择通过运行 git ls-remote 命令来实现，而另一个 AI 应用程序（例如 Windsurf）可能会决定依赖 GitHub API。这两种方法将导致完全不同的开发者体验、不同的错误处理机制等等。

这种函数调用能力的混乱和缺乏标准化，导致了不同 AI 应用程序之间不必要的代码和逻辑重复。

综上所述，MCP 相较于传统函数调用，具有以下差异化价值：

• 开箱即用的扩展性：函数调用 SDK 中的工具与 LLM 集成是硬编码的，因此本质上没有开箱即用的扩展能力。而使用 MCP，您可以独立部署 MCP 服务器，并将其功能正交地扩展到您的 AI 应用程序。
• 关注点分离：在传统函数调用中，工具的 AI 应用实现与其余 AI 应用逻辑之间没有清晰的界限。它们是耦合在一起的。虽然技术上可以在它们之间构建包装器和接口并通过 JSON-RPC 暴露，但这实际上是在重新创建 MCP。MCP 天然提供了这种分离，甚至更多。
• 用户扩展性：允许用户使用或操作 LLM 集成来扩展工具并不容易。由于函数调用的实现是 LLM 集成的一部分，因此它是硬编码的。如果要允许第三方工具扩展，您最终不得不重新发明 MCP 的机制。

传统函数调用的硬编码特性最初是为了定义工具而引入的，但也带来了安全隐患。工具需要实现的潜在危险和敏感操作是提供这些操作的 AI 应用程序本身的一部分。工具层面的不安全编码习惯或存在缺陷的安全实践可能会危及整个 AI 应用程序。

除了旨在解决的规范标准化问题之外，MCP 还提供了一种控制反转（IoC），将函数调用和扩展功能分离为独立的服务。

MCP 只是 REST API 包装器吗？

虽然有人可能将 MCP 简化为传统的 REST API，但这忽略了构建 AI 应用程序所涉及的复杂性。MCP 的许多属性确实与 REST API 类似：它通过 HTTP 通信，底层协议格式是 JSON-RPC，采用客户端-服务器模型。事实上，MCP 的目的类似于传统的 Web 应用程序——服务于客户端（浏览器或其他 API 使用者）。

然而，MCP 通常在比普通 REST API 更粗的粒度上运作，并且需要 REST API 所不具备的 AI 原生特性：

• MCP 驱动用例，而非操作：将 MCP 视为旨在解决特定问题的用例的赋能者。REST API 端点通常是实体及其属性的精细表示。MCP 最终会创建一个工具 x 端点（TxE）矩阵，其中一个公开的工具实现可能会映射到多个 REST API 端点。例如，一个为 Git 存储库公开“get_open_issues”工具的 MCP 服务器可能需要访问多个 REST API 端点：1) 列出所有未解决的问题；2) 获取每个未解决问题的所有数据和元数据（通过其 ID）。因此，MCP 服务器的粒度通常不如 RESTful API 精细。
• MCP 触发的操作超越了 Web 原生：虽然很容易将一切都视为与 Web 连接，但许多精彩的 MCP 演示都围绕着非 Web 和非 REST API 的交互。例如，流行的 Blender MCP 演示基于 Blender 的 Python API，使 Claude AI 应用程序能够创建完整的 3D 场景。通过语言原生 API 服务于 Blender 用例，可以更好地释放 LLM 的编码推理能力，从而获得更优的结果。
• MCP 原生利用 LLM，而 REST API 则不然：MCP 规范定义了一种称为 sampling 的功能，允许 MCP 服务器向 LLM 查询特定操作。这是一个在实际 MCP 中可行，但在现有 API 中难以实现的例子：以前面的 Git 工具为例，“获取对安全影响最大的未解决问题”。REST API 如何满足“对安全影响最大”的要求？如果问题上没有现成的安全过滤器或标签，就无法直接提取相关信息。但是，使用 MCP，工具实现可以先获取未解决问题列表，然后向 LLM 发出 sampling 请求，提示类似于“在以下未解决问题中，以 JSON 格式返回对安全影响最大的有序列表”。LLM 可以发挥其最擅长的分析能力，提供深入分析后的结果。MCP 将 LLM 作为其解决方案的一部分，而现有的 REST API 实现本身并不具备这种能力。sampling 和双向 LLM 通信不仅提供相似性或情感分析，还能满足 LLM 的多模态优势和迭代增强的需求。

MCP 安全问题

MCP 也带来了新的安全隐患。从根本上说，MCP 服务器的无处不在引发了类似软件供应链的安全隐患，例如：

• 恶意 MCP 服务器：如何确保 MCP 服务器的可信度？如果 MCP 服务器秘密执行并从本地或部署环境中窃取敏感信息，会导致什么后果？MCP 服务器可能存在后门吗？如何验证这些安全隐患？
• 易受攻击的 MCP 服务器：MCP 服务器可能行为符合预期，但这并不意味着它们没有安全漏洞或编码缺陷。MCP 服务器中不安全的编码实践可能会被攻击者利用，导致安全漏洞或数据泄露。

这些只是围绕 MCP 的一些突出安全隐患。