什么是模型上下文协议（MCP）？它是如何工作的？

信息技术数字 » 资源 » 什么是模型上下文协议（MCP）？它是如何工作的？

人工智能正凭借连接模型与现实世界的新方法取得巨大进步，其中最受关注的进展之一便是模型上下文协议（MCP）。如果您听说过人工智能代理、外部工具、红绿灯系统（RAG）或MCP服务器，并且觉得它们听起来像是“黑魔法”，请不要担心：它们可以通过逻辑和非常贴近现实的例子来理解。

接下来，您将详细了解 MCP 的定义、内部工作原理、解决的问题、组成组件以及最适合的应用场景。我们还将探讨其优势、当前局限性、实际应用案例（包括企业和金融科技领域的案例），并提供一些实用技巧，帮助您快速上手 MCP 服务器和客户端。

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

模型上下文协议 (MCP) 是一种开放的标准协议，它定义了人工智能模型如何与外部工具、服务和数据源进行通信。换句话说，它建立了一套通用规则，使得语言模型（例如 Claude、ChatGPT 或类似的语言学习模型）无需针对每种情况进行自定义集成，即可访问 API、数据库、文件、文档或企业应用程序。

实际上，MCP 就像人工智能模型和外部服务之间的一种“通用语言”。以往每个模型都使用自己的“方言”，每个工具也都有自己独特的 API，而 MCP 则充当了一座标准化的桥梁。模型使用 MCP，工具通过 MCP 对外开放，所有功能无缝衔接，无需为每个项目重复造轮子。

生命周期模型（LLM）的一个经典问题是，无论它们多么强大，它们都只能在训练框架内独立运行。除非有人构建特定的集成，否则它们无法访问您的电子邮件、客户关系管理系统（CRM）、企业资源计划系统（ERP）、订单数据库或内部文档。多级集成平台（MCP）的出现正是为了解决这一瓶颈：它为模型提供了一条安全且结构化的路径，使其能够查询实时数据并执行外部操作。

另一个关键方面是，MCP 是一个开放标准，最初由 Anthropic（Claude 的创建者）推动，旨在让任何供应商、公司或开发人员都能实现它。这促进了一个即插即用型 MCP 工具共享生态系统的出现，任何兼容的模型都可以利用该系统。

从概念上讲，MCP 并非代理框架，而是集成层。它并不决定使用哪个工具或何时使用；它只是提供了一种一致的方式，将工具和数据暴露给做出这些决策的代理或模型。

MCP 与 RAG 以及与传统 API 的比较

迄今为止，利用外部信息丰富模型最流行的方法之一是检索增强生成（RAG）方法。在RAG中，文档被转换为词嵌入并存储在向量数据库中；每次用户提出问题时，系统都会执行语义搜索以检索最相关的文本片段，然后将其添加到模型的上下文中。

使用 MCP，情况就不同了，因为它不需要预先索引信息或生成嵌入代码。相反，该模型直接从源头访问信息：API、数据库、文件系统、SaaS 工具、作为 MCP 服务器提供的文档等等。MCP 服务器负责提供这些功能并实时返回最新数据。

这带来了几个显著的好处：数据始终保持最新，信息重复减少，维护向量索引所需的计算量也降至最低。此外，从安全角度来看，这种方式更易于控制，因为无需将大量敏感数据导入外部数据库；而是按需提供。

与传统 API相比，区别在于理念。例如，REST API是为传统 IT 系统设计的，客户端可以精确地知道要调用哪个端点、发送哪些参数以及预期响应结构。而对于 LLM 来说，这种僵化的模式并不适用：模型需要根据对话上下文，发现可用的工具、理解它们的功能并决定何时使用它们。

类比：如何在不发疯的情况下想象MCP

为了更好地理解MCP的作用，我们可以借助一个形象的比喻。一个常见的类比是电路：人工智能模型相当于电机，数据源相当于各种发电厂，而MCP则相当于线路和配电盘，它决定了哪些能量通过哪根电缆、在什么时间以什么强度输送到电机。

同样，您可以将 MCP 想象成一个大型的、通用的 AI 模型 USB 接口。您将模型连接到 MCP“集线器”，然后将数据源、自动化工具、文件系统、CRM、第三方服务等等连接到该集线器。模型无需了解每个连接的具体细节；它只需要知道有哪些工具可用以及它们可以做什么。

在商业环境中，另一个有用的类比是将其视为交换机或上下文路由器。MCP 选择将哪些信息、从哪个来源以及何时注入到模型的上下文中。它过滤掉噪声，优先处理相关信息，并管理信息流，以避免LLM 的上下文窗口过载，因为上下文窗口始终是有限的。

MCP架构的关键要素

虽然这个概念听起来可能很复杂，但MCP 内部基于一个相当简单的客户端-服务器架构，具有三个主要的、区分明确的角色：

主机 MCP

MCP主机是AI模型或代理所在的应用程序。它可以是聊天机器人、编程IDE、企业级AI平台、企业虚拟助手，甚至是向最终用户提供智能功能的Web服务。

该主机集成了语言模型，并作为用户请求的入口点。MCP客户端从该主机初始化，配置要使用的 MCP 服务器，并控制一些行为：例如，每个上下文中可用的工具、加载的资源等。

MCP 客户端

MCP客户端通常驻留在主机内部，负责管理与MCP服务器的通信。它将模型的决策（例如，“使用这些参数调用工具X”）转换为对服务器的特定调用，并接收响应并将其转换为模型可以使用的格式。

可以将客户端视为模型和服务器之间的解释器或翻译器。此外，客户端还可以主动决定加载哪些资源、管理会话状态、对多个工具调用进行分组，以及处理超时和重试等问题。

MCP 服务器

MCP服务器是向模型公开特定功能的组件：文件访问、数据库查询、API 调用、业务操作、技术文档、第三方服务……每个 MCP 服务器通常专注于一组功能，就像一个专门的微服务一样。

在MCP服务器中，定义了几种类型的功能：

• 工具：模型可以调用的函数，例如 获取城市天气, 创建日历事件() o 检查产品库存(id).
• 资源：为模型提供静态或半静态上下文的信息片段，例如： 文档、政策、业务描述或使用规则.
• 提示服务器提供给模型的预定义文本模板，用于一致地解决重复性任务，并封装了 非常谨慎的提示 不需要每个客户手写。

这种方法的妙处在于，该模型可以动态发现每个 MCP 服务器提供的工具、资源和提示。无需“配置”特定的 API：只需按照标准公开即可，任何兼容的 MCP 主机/客户端都能使用它。

MCP 的工作原理详解

MCP 的典型工作流程在几乎所有场景下都类似。简而言之，当用户向模型发出请求时，可能会发生以下情况：

1. 用户提交查询或命令。 通过聊天、应用程序、IDE 等方式进行的交互会到达 LLM 所在的主机。
2. 该模型分析请求 并根据具体情况，判断其内部知识是否足够，或者是否需要其他知识。 查询外部数据或执行操作.
3. 如果您需要外界帮助， MCP客户端开始发挥作用检查哪些服务器已注册，它们有哪些可用工具，以及可以使用哪些资源/提示来获得支持。
4. MCP客户端 在相应的 MCP 服务器上调用相应的工具 （例如，一个工具查询数据库，另一个工具调用 GitHub API，另一个工具搜索文档等等）。
5. 服务器 执行该操作 （查询、操作、文档搜索、文件读取……）并以结构化格式将结果返回给 MCP 客户端。
6. MCP客户端 将这些信息注入到模型上下文中它将利用这些信息为用户生成更准确、更及时、更具可操作性的回复。

如果任务复杂，整个过程会迭代重复，甚至可以将多个工具串联起来使用。从用户的角度来看，人工智能助手似乎“知道如何做事”并能访问实时信息，而实际上，该模型只是将 MCP 用作集成层。

MCP 为开发人员和企业带来的主要好处

MCP 的采用开启了人工智能模型与现实世界系统集成方式的变革之门。其中最显著的优势包括：在技术和业务层面都具有重要意义的诸多方面。

减少整合工作

传统方法中，每个AI模型都必须手动连接到每个数据源。如果您有5个模型和10个系统，这会导致N×M的复杂集成，维护起来非常困难。而使用MCP，每个模型只需通过MCP进行通信，每个系统也只需提供一个MCP服务器。问题简化为N+M，管理起来更加容易。

这意味着开发团队可以节省时间和精力。他们无需为每个模型和服务组合构建自定义适配器，而是专注于正确实现单个 MCP 服务器，其他用户无需修改任何代码即可重用该服务器。

无需重新索引即可访问实时数据

借助 MCP，模型可以实时查询数据源。如果您更改数据库中的记录、更新文档或修改系统中的策略，模型将在下次调用时看到这些更改，而无需重新生成嵌入或重新索引。

这种方法特别适用于数据高度动态的环境：金融系统、物流、运营、实时支持、库存、物联网……在这些环境中，信息不断变化，静态索引很快就会过时。

更完善的数据安全和治理

另一个重要优势是，您无需将所有私人信息上传到外部基础设施供人工智能使用。MCP 服务器连接到数据存储的系统（本地、私有云、您控制的 SaaS），并且仅在必要时公开必要的信息。

这降低了数据泄露的风险，并有助于实施集中式安全和访问控制策略。您可以审核使用了哪些工具、拥有哪些权限、在什么上下文中使用以及针对哪些系统——这在银行、医疗保健、保险或公共管理等行业中尤为重要。

可扩展性和互操作性

由于 MCP 基于开放标准，因此能够促进不同供应商模型之间的互操作性。如果您明天决定更改 LLM 或合并多个 LLM，则无需重新构建所有集成；您可以继续使用相同的 MCP 服务器。

此外，模块化方法允许您逐步添加新服务：只需为该工具设置一个新的 MCP 服务器，并将其注册到所需的主机上即可。无需重写架构的其余部分或修改现有集成。

为用户和代理提供更好的体验

由于该模型能够随着时间的推移保持上下文并主动使用工具，因此可以构建更丰富的助手：项目规划器、编程助手、自动化复杂工作流程的代理，或者能够交叉引用来自各种系统的数据的业务助手，而用户无需了解底层技术框架。

MCP 的典型应用案例（包括金融科技领域）

MCP 的应用范围非常广泛，但在某些情况下，它尤其适用，因为需要协调访问许多数据源和工具，或者因为安全性至关重要。

商业虚拟助理

一个非常明显的例子是员工内部助手。想象一下，借助 MCP 技术，企业聊天机器人可以：

• 查阅客户数据库 查看历史记录、订单、事件或账单。
• 访问内部文档 （手册、流程、常见问题解答）用作 MCP 文档服务器。
• 与业务工具交互 创建工单、安排会议、发布报告或更新记录。

所有这些操作都不需要对模型和每个系统之间进行特定的连接器编程，因为MCP 提供了标准抽象。

与物联网和实时数据集成

例如，在物流或工业领域，代理商可以使用 MCP实时读取生产链的状态或货物的位置，并根据每秒更新一次的数据做出决策或建议。

推荐引擎和内容个性化

数字平台（流媒体、电子商务、在线学习等）可以利用 MCP 将模型与每个用户的历史记录和偏好连接起来，而无需从管理这些信息的系统中复制这些信息。

MCP 服务器可以公开一些工具，例如返回用户最后查看的内容、访问过的产品、与营销活动的互动等信息，从而使模型能够构建更加精细和具有上下文相关性的推荐。

在金融科技和金融领域的应用

在金融科技领域，多协议平台 (MCP) 非常适用，因为它兼具标准化、安全性和同时协调多个数据源的能力。一些典型示例包括：

• 财务助理 通过不同的 MCP 服务器查询账户、产品、交易和监管文件。
• 风险与合规分析 将模型与内部数据库、受监管的外部资源和评分系统连接起来。
• 财务工作流程自动化 （账户开立、信用申请、KYC验证）协调通过MCP提供的各种工具。

此外，MCP 提供统一且可审计的安全模型，这在可追溯性和监管合规性至关重要的行业中尤为重要。

如何在实践中构建 MCP 服务器

除了理论层面，MCP 已经拥有多种语言的实现和 SDK，使得创建 MCP 服务器和客户端相对容易。其基本思路始终如一：定义服务器将公开的工具、资源和提示，并注册将使用的传输类型。

例如，在 .NET/C# 环境中，可以使用ModelContextProtocol之类的包快速搭建 MCP 服务器。其典型结构如下：

• 设置一个 主持人 它注册 MCP 服务器、传输（例如，本地 stdio）以及从程序集中自动检测工具、资源和提示。
• 定义工具类 使用特定属性进行装饰（例如，注解）， McpServerToolType y McpServerTool）声明模型可以调用哪些函数。
• 创建资源 其中包括服务器向客户端提供的关键上下文（例如，使用条款、有效值列表、业务规则）。
• 注册提示 预定义用于封装高级提示逻辑，以便客户可以使用单个命令重复使用这些逻辑。

由此，诸如基于 Node 的 MCP 检查器或与VS Code、Claude、Cursor 或类似编辑器的集成等工具，允许您连接到本地或远程 MCP 服务器，列出其工具，并通过集成的聊天进行测试。

创建和使用 MCP 客户端

另一方面是MCP客户端，它也可以用不同的语言编写。它的主要职责是连接到MCP服务器，发现其功能，并代表模型协调对工具、资源和提示的调用。

典型的顾客通常：

• 配置传输方式（例如，使用 stdio 传输到本地二进制文件，或使用 HTTP 传输到远程服务器）。
• 调用方法 列出工具、提示和资源 服务器上可用。
• 使用适当的参数调用特定工具； 收集回复通常以文本块或更丰富的结构形式出现。

在实际场景中，MCP 客户端直接集成到 LLM 所在的宿主中（例如，VS Code 聊天或企业 Web 应用程序），模型本身会根据对话的上下文决定何时调用每个工具。

专用 MCP 服务器：文档案例

目前在生产环境中已经出现了一个非常有趣的案例，那就是从技术文档生成 MCP 服务器。文档平台可以自动在标准路径（例如/mcp）下设置 MCP 服务器，从而为整个文档提供搜索或查询工具。

因此，任何兼容的 MCP 客户端（例如 Claude、Cursor、某些 VS Code 插件等）都可以连接到该 MCP 服务器，并允许模型在响应用户时实时查阅文档。用户甚至无需说“请查阅文档”：LLM 可以自行判断此上下文来源是否相关，并在生成响应时使用它。

对于软件提供商而言，这意味着他们的用户可以将官方文档直接集成到他们的 AI 工具中，从而实现更准确的搜索、更新的上下文，并降低模型出现“幻觉”的风险。

MCP 目前的局限性和挑战

虽然 MCP 看起来很有前途，而且发展迅速，但它并非万能灵药，在孤注一掷之前，应该清楚地认识到它仍存在一些局限性。

一方面， MCP的普及程度仍然相对较低。MCP 于 2024 年底作为开放标准公开发布，尽管此后已经发布了数百个 MCP 服务器（包括官方和社区实现），但它最终是否会成为 LLM ↔ 工具通信的事实标准，还有待观察。

另一个关键点是，在许多现有实现中，MCP 服务器运行在应用机器本地，这虽然简化了安全性，但却会使大型分布式环境中的可扩展性和部署变得复杂。将 MCP 应用于多租户环境仍然是一个技术难题。

此外，模型本身也存在固有的局限性。虽然 MCP 服务器可以承载许多工具，但 LLM 受限于其上下文窗口以及对持久内存的管理方式。您不能同时向模型导入数百个工具和资源而不失控或产生噪声；您必须精心设计哪些工具和资源在何时以何种优先级公开。

最后，一些 AI 客户端或扩展程序仍然没有充分利用 MCP 的功能（例如，有些工具会忽略预定义的资源或服务器提示），这意味着您始终需要考虑服务器端的安全措施，以便关键逻辑不会仅仅依赖于客户端的操作。

总的来说，MCP 已经是构建真正智能软件的一个非常有前途的组件，但要保证在生产环境中部署它，还需要生态系统的成熟度和良好的实践。

种种迹象表明，随着语言模型成为真正智能体经济的引擎，以及越来越多的公司采用 MCP 协议实现集成标准化，我们将看到智能体能够以分布式方式发现、协调和重用工具的环境的出现。对于任何致力于设计面向未来的 AI 解决方案的人来说，深入了解 MCP 协议并开始尝试使用 MCP 服务器和客户端都至关重要，因为它很可能成为我们日常使用的许多智能应用的底层基础。