我要投稿

深入解析模型上下文协议（MCP）

发布日期：2025-03-19 04:54:28 浏览次数： 1514 来源：异度部落格

概述

随着 Cursor 等智能编程工具的崛起、Manus 产品的推出，以及 Claude Sonnet 等大语言模型在编程领域能力的显著提升，MCP 逐渐引起了技术社区的广泛关注与重视。本文将深入浅出地介绍 MCP 的核心概念，并结合具体场景探讨其实际应用价值。

什么是 MCP？

MCP（The Model Context Protocol，模型上下文协议）是一个开放协议，由 Anthropic 在 2024 年 11 月提出。MCP 能够实现 LLM 应用与外部数据源和工具之间的无缝集成。无论是在构建一个 AI 驱动的 IDE、增强聊天界面，还是创建自定义 AI 工作流，MCP 都提供了一种标准化的方式，将 LLM 与所需的上下文连接起来。 可以把 MCP 理解为 Agent 世界的转接头。

MCP 整体架构

MCP 遵循 client-server 架构，对于一个 Agent 而言可以连接多个 MCP Server。整体架构包含 4 部分：

MCP Host：通过 MCP 访问数据的 AI 工具的程序，如 Claude Desktop、集成开发环境（IDE）或 Agent 等
MCP Client：与 MCP Server 保持 1:1 连接的协议客户端
MCP Server：轻量级程序，通过标准化的 MCP 暴露特定功能，包括工具（Tools）、外部资源（Resources）和提示词模版（Prompts）等。
MCP Protocols：定义 MCP Client 和 MCP Server 之间的通信方式

MCP Host

MCP Host 可以是任何需要访问外部数据的 LLM 应用/Agent。它们负责：

初始化和管理多个 MCP Client。
MCP Client-MCP Server 生命周期管理。
处理用户授权。
管理跨 MCP Client 的上下文聚合。

MCP Client

每个 MCP Client 负责：

专用连接：每个 MCP Client 与 MCP Server 保持一对一的有状态连接。这种专用连接模式确保了通信界限清晰，并实现安全隔离。
消息路由：MCP Client 负责处理所有双向通信，高效地在 MCP Host 和所连接 MCP Server 之间传递请求、响应和通知。
能力管理：MCP Client 通过维护服务器的可用工具、资源（上下文数据）以及提示模板等信息，监控并管理所连接 MCP Server 的能力。
协议协商：在初始化阶段，MCP Client 会与 MCP Server 协商协议版本和相关能力，以确保 MCP Host 与 MCP Server 之间的兼容性。
订阅管理：MCP Client 维护对 MCP Server 资源的订阅关系，当这些资源发生变化时，负责处理并分发相应的通知事件。

MCP Server

MCP Server 是为 LLM 提供外部数据和上下文的基础构建单元。MCP Server 的关键组成包括：

工具（Tools）：工具是可执行的函数，使得大语言模型能够与外部应用进行交互，其作用方式类似于传统 LLM 调用中的函数。例如，一个名为 LIST_FILES 的工具，接收目录名称作为参数，执行后会获取该目录下的文件，并将结果返回给客户端。此外，工具也可以是对外部服务的 API 调用，例如 Gmail、Slack 和 Notion 等。
资源（Resources）：资源包括文本文件、日志文件、数据库结构定义、文件内容以及 Git 历史记录等，可以为 LLM 提供额外的上下文信息。
提示模板（Prompt Templates）：预定义的模板或指令，用于指导 LLM 的互动行为。

工具由模型自主控制，而资源和提示模板则由用户进行控制。模型能够根据给定的上下文自动发现并调用所需工具。

MCP Protocols

所有的 MCP Protocol 必须遵循 JSON-RPC 2.0。目前协议定义的类型有：

Requests：执行操作的消息，必须包含唯一的 ID 和方法名。
Responses：返回的消息，必须包括 Request 中的 ID。
Notifications：单向消息无需返回，必须不包含 ID。

关于协议的更多内容可以参考：https://spec.modelcontextprotocol.io/specification/2024-11-05/

Function Calling vs MCP

主要区别如下：

Function Calling 由特定的大模型服务提供商（如 OpenAI 的 GPT-4）引入的功能。它允许模型根据输入，生成特定格式的函数调用请求。应用程序接收到该请求后，执行相应的操作，并将结果返回给模型。这种机制使模型能够主动请求外部功能的执行，但并不强制要求使用特定的通信协议或格式。

MCP 是在 OpenAI 的 Function call 和 GPTs 之后提出的，可以说 Function call 为 MCP 提供了灵感和基础功能。MCP 是一种开放协议，旨在通过标准化的接口，实现大型语言模型与外部数据源及工具的无缝集成。它规定了上下文与请求的结构化传递方式，确保消息传递的标准化和一致性。MCP 的设计初衷是通过本地运行服务器来确保用户数据的安全性，避免将敏感信息直接发送给 LLM。

主要区别：

层级定位：Function Calling 更侧重于模型的具体实现和特性，是特定大模型厂商提供的独特功能。而 MCP 则是一个更底层、更通用的标准，相当于为所有人提供的“公共基础设施”。
通信方式：Function Calling 的通信格式并不固定，可能根据不同厂商的实现而有所不同。而 MCP 要求通信格式遵循 JSON-RPC 2.0 标准，确保消息传递的标准化和一致性。
依赖关系：两者并不互相包含，也没有谁必须依赖谁。应用可以选择在 MCP 之上通过特定机制（包括 Function Calling）与模型交互，也可以在 MCP 范式下使用其他不基于 Function Calling 的方式与模型或数据源交互。