MCP：它真的值得大肆宣传吗？

序言

MCP （模型上下文协议） 是技术界热议的话题，它由 Claude 的创始人Anthropic开发，并于 2024 年 11 月开源，解决了将 AI 模型连接到各种工具和数据集的复杂性。虽然去年它还默默无闻，但最近发展势头强劲，越来越多的开发者、平台和企业开始加入。

那么，

MCP 是一种开放协议，可让 AI 系统和代理无缝连接到外部工具和资源。
可以将 MCP 想象成AI 工具的USB 端口------它允许您连接所需的所有不同数据源。当然，当您在 AI 编码平台上从零开始启动项目时，一切都会顺利进行。但是，如果您需要从 GitHub 上的旧项目中提取代码、从 Google Drive 获取文档，并随时掌握 QA 团队在 Slack 中发布的更新，该怎么办？使用 MCP，您只需将 Github-Slack-Drive 连接到正在使用的 AI 编码代理，即可确保您的工作流程不出现任何问题。
在 MCP 之前，每个工具都需要自定义编码。

虽然 MCP 和大型语言模型 (LLM) 都是 AI 开发不可或缺的一部分，但它们的用途却截然不同：

LLM ：这些是先进的人工智能模型，经过海量数据集训练，能够理解并生成类似人类的文本。它们在语言翻译、内容创作和摘要等任务上表现出色。

MCP：这是一种促进 LLM 与外部应用程序之间通信的协议，允许 AI 系统执行文本生成以外的任务，例如与数据库交互、执行功能以及在不同工具之间保持上下文感知。

本质上，LLM 提供认知能力，而 MCP 则使他们能够有效地与外部世界互动。

现在我们已经弄清楚了 MCP、API 和 LLM 之间的区别，让我们深入了解 MCP 的实际工作原理。

从高层次来看，MCP 遵循客户端-服务器架构：

客户端无需对自定义集成进行硬编码，只需向服务器发送结构化的 MCP 请求，服务器再与工具通信并返回结构化的 MCP 响应。

其核心组件 包括协议层、传输层和消息处理系统。

协议层负责高级通信逻辑，处理消息框架、请求-响应链接以及客户端和服务器之间的通知管理。

该协议的功能包括：

在代码层面，MCP 通过 Protocol 类公开此功能，该类包含 setRequestHandler、setNotificationHandler、request 和 notification 等关键方法。这些抽象确保开发人员能够使用简洁、可预测的通信模式。

传输层负责处理客户端和服务器之间 MCP 消息的传输。MCP 根据部署场景支持多种传输机制：

Stdio Transport使用标准输入/输出进行通信，非常适合进程间本地、同机通信。它轻量级且易于管理。
带有服务器发送事件 (SSE) 传输的 HTTP专为远程通信而设计，使用 HTTP POST 发送客户端到服务器的消息，并使用 SSE 发送服务器到客户端的流式消息。这使其能够集成到基于云的架构或 Web 友好的环境中。

无论传输方式如何，MCP 消息都使用 JSON-RPC 2.0 进行交换，确保跨不同平台和编程语言的结构一致性和兼容性。

MCP 中的通信主要由四种主要消息类型构成：

MCP 连接经历几个阶段：

初始化

消息交换

终止

MCP 确实名副其实。它让 AI 模型与工具的连接变得超级简单，省去了所有繁琐的自定义工作。如果您想构建更智能、更灵活的 AI 应用，又不想再为这些繁琐的流程头疼，MCP 将彻底改变游戏规则。那么你认为呢？最后我之前总结了一些学习MCP的资源想学习的可以收藏一下：传送门