MCP：AI大模型的万能插座-CSDN博客

本文链接：https://blog.csdn.net/jennycisp/article/details/147645230

最近一直在做数据+AI方向的工作，前两天无意中看到一个MCP的技术，经过详细的学习之后，了解到这个可能不仅仅应用在大模型，而更多是数据和模型之间的桥梁，最近就一直在考虑对于多模态数据如何才能实打实的和应用模型结合起来的事情，MCP无疑是提供了某种思路，下面是关于MCP的一些介绍，部分内容是参考的社区文档。

MCP（Model Context Protocol）是一种开放协议，它标准化了应用向设备提供上下文的方式。可以将 MCP 想象成 AI 应用的 USB-C 端口。正如 USB-C 提供了一种标准化的方式将您的设备连接到各种外围设备和配件一样，MCP 也提供了一种标准化的方式将 AI 模型连接到不同的数据源和工具。

首先来说说为什么会有MCP，随着AI大模型和人工智能助手的快速发展，很多企业都在往AI方向转型，定制和自身业务相关联的AI应用，投入巨资在模型的推理和训练上，然而，即便是再厉害的大模型、即便是再强大的预训练模型，也会因为和业务数据隔离而受到限制，等于模型和数据是被困在各自的信息孤岛中。

如果我们要接入企业内部的数据源，则需要单独来定制实现数据源的连接，这对于很多企业有大量不同数据源的系统来说，工作量非常大，二者对于整个系统后续都难以扩展。

所以，MCP提供了一项开放标准，使开发者能够在数据源和AI驱动的工具之间建立安全的双向连接。MCP的架构简单易懂，开发者可以通过MCP服务器来公开访问，也可以构建连接到这些服务器的AI应用中（也就是MCP的客户端）。

下面来看看一个关于MCP的使用示意图：

假如我们有M个不同的AI应用（例如聊天问答、RAG知识库等等）和N个不同的服务系统（内部数据库、聊天数据等等），那么可能需要构建M*N个不同的API来集成，这会导致维护复杂度很高，以及团队之间的重复工作。

MCP其实就是希望将M*N的问题，转换为M+N的问题，我们需要构建N个MCP的Server端，然后应用程序客户端构建M个MCP 客户端，MCP是一个Client/Server的架构，有如下几个角色说明：

Hosts：与用户交互的应用程序（例如，Claude Desktop、类似 Cursor 的 IDE、自定义代理）。
Clients：位于主机应用程序中，管理与特定 MCP 服务器的连接。保持 1:1 的连接。
Servers：通过客户端通过标准 API 向 AI 模型公开工具、资源和提示的外部程序。

其中，MCP Server端的组件包括：

Tools（模型控制）：这些是可以调用来执行特定操作的函数（工具），例如天气 API，基本上是函数调用
Resources（应用控制）：这些是可以访问的数据源，类似于 REST API 中的 GET 端点。资源提供数据时无需执行大量计算，不会产生任何副作用。上下文/请求的一部分
提示（用户控制）：这些是预定义的模板，用于以最佳方式使用工具或资源。在运行推理可以进行选择

MCP是怎么运行的？

MCP 采用前面描述的客户端-服务器模型运行。以下是简化的流程：

Initialization（初始化）: 当主机应用程序启动时，它会创建 N 个 MCP 客户端，它们通过握手交换有关功能和协议版本的信息。
Discovery（发现）: 客户端请求服务器提供哪些功能（工具、资源、提示）。服务器返回列表和描述。
Context Provision（提供上下文）: 主机应用现在可以向用户提供资源和提示，或将工具解析为兼容格式，例如 JSON 函数调用
Invocation（调用）: 如果确定需要使用工具（例如，根据用户请求“‘X’ 存储库中有哪些未解决的问题？”），主机会指示客户端向相应的服务器发送调用请求。
Execution（执行）: 服务器接收请求（例如，使用 repo ‘X’ 的 fetch_github_issues），执行底层逻辑（调用 GitHub API），并获取结果。
Response（响应）: 服务器将结果发送回客户端。
Completion（完成）: 客户端将结果中继到主机，主机将其合并到LLM的上下文中，从而允许LLM根据最新的外部信息为用户生成最终响应。

MCP 是一个标准框架，它定义了 AI 系统如何与外部工具、服务和数据源交互。MCP 无需为每个服务创建自定义集成，而是定义了这些服务如何互操作、请求如何构建、哪些功能可用以及如何发现这些功能等基本概念。它使开发者能够轻松可靠地在 AI 工具与外部数据源、应用和其他服务之间构建安全可靠的双向连接。

MCP Server是 MCP 世界与外部系统特定功能（例如 API、数据库、本地文件等）之间的桥梁/API。它们本质上是根据 MCP 规范暴露这些外部功能的包装器。

只要服务器能够通过支持的传输协议进行通信，就可以使用各种语言（Python、TypeScript、Java、Rust 等）构建服务器。服务器主要通过两种方式与客户端通信：

stdio（标准输入/输出）：当客户端和服务器在同一台机器上运行时使用。这对于本地集成（例如访问本地文件或运行本地脚本）来说简单有效。
通过 SSE（服务器发送事件）的 HTTP：客户端通过 HTTP 连接到服务器。初始设置后，服务器可以使用 SSE 标准通过长连接向客户端推送消息（事件）。

MCP 解决的什么问题？

人工智能工具的实用性取决于它们能够访问的数据和能够采取的行动。

AI人工智能将来应用到实际中场景中的时候，更多的特征还是取决于它们能够访问的数据以及针对访问到的数据所作出的行动。

对于通用性的能力，LLM的预训练数据就足够了，但是，牵扯到让AI了解公司内部的业务数据，例如销售额与上季度相比变化，竞争对手的营销策略如何根据市场状况做出调整。

如果希望AI利用这些信息执行某些操作的话，我们就需要一种方式让它与这些应用程序进行交互，MCP就是这样一种程序，通过提供标准化的方式来发现和调用外部系统中的操作，简化了这一过程。它弥合了理解与执行之间的差距，因此 AI 不仅仅是提供洞察，还能积极地完成任务。

以前，这意味着你需要为每个想要获取洞察或采取行动的应用构建自定义集成。而 MCP 则为 AI 工具如何与任何数据源交互提供了标准化解决方案。任何支持 MCP 的应用都能够提供一套结构化的工具或操作，供 AI 助手或代理使用。当你要求 AI 执行某项操作时，它可以检查可用的工具并采取适当的操作——灵活性大大提升。

通过使用安全协议标准化 AI 模型与外部数据源之间的通信，MCP 使开发人员能够更快、更轻松地与关键工具构建安全集成，并且也使开发人员能够更轻松地在不同工具之间切换。例如，两个不同的文件存储应用应该具有类似的 MCP 服务器实现，而无需编写全新的集成代码。

MCP 和 AI Agent的区别

AI Agent是由人工智能驱动的工具，能够自主行动。举个简单的例子， ChatGPT、 DeepSeek 能够根据我们的查询决定执行哪些网络搜索以及访问哪些网站，我们可以告诉它想要什么，但它决定如何为我们提供服务。

MCP 能够实现Agent行为。通过允许开发者将应用程序和数据源连接到 AI 助手，他们可以构建能够自主决策并在其他应用程序中采取行动的 AI 工具。但 MCP 并非构建 AI 代理的唯一方法，使用 MCP 也不会自动将任何 AI 驱动的工具变成 AI Agent。它只是将 AI 连接到另一个工具的一种方式。

MCP 主要面向构建自定义集成和 AI 应用程序的开发者，尤其适合拥有技术资源、需要在自己的应用程序或工作流程中构建专用 AI 功能的团队。

。它只是将 AI 连接到另一个工具的一种方式。

MCP 主要面向构建自定义集成和 AI 应用程序的开发者，尤其适合拥有技术资源、需要在自己的应用程序或工作流程中构建专用 AI 功能的团队。

这两种方法在生态系统中都有其地位：MCP 为开发人员提供了更深层次的控制和自定义实现的灵活性，而无代码工具则为没有大量开发资源的业务用户或团队提供了可访问性和速度。