想象一下，你的AI助手不仅能和你聊天，还能直接操作你的音乐软件切换歌曲、在Photoshop中调整图片、从Notion里查找笔记，甚至控制你的智能家居。这不再是科幻场景，而正通过一个名为MCP（Model Context Protocol） 的协议变为现实。它正是打通AI与现实世界工具的“万能钥匙”。

一、什么是MCP

MCP是由Anthropic公司提出并开源的一项开放标准，旨在解决为AI模型安全、高效地接入实时、结构化外部信息的核心挑战。它通过在大型语言模型（LLM）与外部工具、数据源或服务之间，建立一套安全、标准化且模块化的通信桥梁，来达成这一使命，在保障安全与隐私的前提下，实现了两者间无缝且灵活的交互。

您可以将其理解为AI世界的 “USB-C” 。

• 在USB-C出现之前，每个外设（如打印机、鼠标）都需要特定的驱动和接口，混乱且低效。

MCP正是为了解决AI与工具连接的类似困境而生。它旨在将大模型从“孤立的聊天机器人”升级为能够调用万千工具的“全能型Agent”。

二、为什么需要MCP？—— AI的“手脚”之困

在没有MCP之前，AI模型虽然拥有强大的“大脑”（推理和生成能力），但它缺少“手脚”和“感官”。它要与现实世界交互，主要面临两大困境：

1. 集成复杂：每个工具（如数据库、API、软件）都有自己独特的接口和认证方式。为AI适配每一个工具都需要大量的定制化开发工作，成本极高。

2. 安全风险：直接授予AI模型过高的系统权限（如执行Shell命令）是极其危险的，一个错误的指令就可能导致系统崩溃或数据泄露。

MCP的核心功能是允许LLM请求外部工具协助回答查询或完成任务。MCP通过提供一个标准化的中间层，完美地解决了这些问题。它让工具开发者可以一次性地为AI世界“编写驱动”，而AI应用开发者则可以轻松地“即插即用”这些工具。

在大模型中，MCP是否必须的？LLM是否能自学使用API吗？如果能自学API,MCP还在存在的价值吗？从理论上来讲，答案或许是肯定的。比如每个API的描述都极为详实，我们可以尝试将这些描述+API提供给LLM，使其能够掌握达成目标所需的步骤。那实际中没有采取此种策略的原因又是什么呢？根本原因还是效率与体验。一般让LLM来掌握API的调用效率较低下，会显著延长并复杂会LLM交互流程，牺牲用户的交互体验。因此目前业界优选MCP。

MCP有哪些特性呢？

• 上下文管理与记忆：持有当前会话的上下文、历史对话和工具输出，支持长对话中的信息追踪与回溯。
• 减少LLM幻觉：LLM 本质上可能会编造事实，或生成看似合理但实则错误的信息（产生幻觉），因为其回答基于训练数据而非实时信息。MCP 提供清晰路径，使 LLM 能访问外部可靠数据源，从而提高回答的真实性并减少幻觉。
• 工具/连接器编排：能调用外部工具或连接器（如数据源、计算服务、文件存储等），并按设定的顺序与条件进行编排。
• 会话隔离与多租房：为不同用户或会话提供独立且隔离的上下文空间，确保数据和操作的边界与安全。
• 权限与安全控制：基于作用域的访问控制、输入输出过滤、风险评估与合规性约束，防止越权使用。
• 错误处理与容错机制：具备错误捕获、重试策略、降级与回退，以提升鲁棒性。
• 可观测性与日志追踪：记录调用链、连接器使用、数据访问等，便于审计、性能分析与故障排查。
• 上下文窗口与预算管理：对可用上下文长度设定上限、进行摘要/压缩以保留关键信息，避免过度膨胀。

简而言之，需要MCP的原因有以下几点：

• Developers: MCP reduces development time and complexity when building, or integrating with, an AI application or agent.
• AI applications or agents: MCP provides access to an ecosystem of data sources, tools and apps which will enhance capabilities and improve the end-user experience.
• End-users: MCP results in more capable AI applications or agents which can access your data and take actions on your behalf when necessary.

三、MCP的技术架构：三层核心组件

MCP是一种有状态、能够保持上下文的框架，旨在促进人类与AI Agent之间开展智能且多步骤的交互。与传统API调用有所不同，MCP融入了一个持久、动态发展的上下语言层级，使AI系统能够保留记忆、持续学习，并随时间推移自主采取行动。

MCP遵循CS架构清晰地将AI应用、工具和协议本身分离开来，主要由三部分构成：

1. MCP 客户端（Client）：

   • 角色：通常是AI应用或平台，如Claude桌面端、Cursor、或其他AI Agent框架。

   • 职责：向服务器发出请求，例如“请查询数据库X”、“请执行操作Y”。

2. MCP 服务器（Server）：

   • 角色：特定工具或数据源的封装器。每个工具（如PostgreSQL数据库、文件系统、JSF）都可以拥有自己的MCP服务器。

   • 职责：定义并提供一系列该工具可被调用的“功能”（如query_database, call_jsf），并执行客户端的请求。

3. MCP 协议（Protocol）：

   • 角色：连接客户端与服务器的通信规则和标准。它规定了双方如何握手、如何传输数据（使用JSON-RPC 2.0作为通信协议）、以及消息的格式。

   • 核心概念：

     • 资源（Resources）：为AI应用提供上下文信息的数据源（例如文件内容、数据库记录、API响应）

     • 工具（Tools）：AI-apps可以调用以执行作（如文件作、API调用、数据库查询）的可执行函数

     • 提示（Prompts）：可重复使用的模板，帮助结构化与语言模型的交互（例如，系统提示、少数样本示例）

举个具体例子，考虑这样一个MCP服务器——提供数据库的上下文。它可以暴露用于查询数据库的工具、包含数据库模式的资源，以及包含少数样本示例的提示，用于与工具交互。

更详细的内容可参考：https://modelcontextprotocol.io/docs/learn/architecture

四、MCP工作原理

MCP采一个动态上下文窗口，该窗口随每次交互而扩展，用于存储用户偏好、会话记录以及环境数据。为了避免数据过载，他在保留关键细节的同时，将非关键信息压缩成嵌入形式。

MCP vs. 传统API直接调用

特性	传统API直接调用	MCP协议
记忆	无状态、无记忆	跨会话持久上下文
集成方式	硬编码，紧耦合，每对接一个工具都需要写特定代码。	标准化，松耦合，通过协议发现和调用，即插即用。
安全性	依赖应用自身实现，风险较高，密钥可能暴露给模型。	架构级安全，服务器独立权限，客户端（AI）无法接触敏感信息。
可扩展性	差，新增工具需要修改应用代码。	极佳，新增工具只需启动新的MCP服务器，客户端自动发现。
生态	割裂，各自为政。	统一开放，工具一次开发，处处可用。

MCP与RAG都通过外部信息来增强LLM，但方式不同，目的各异。RAG 用于查找和使用信息以生成文本，而 MCP 是一个更广泛的交互与操作系统。

功能	RAG	MCP
主要目标	在生成回答之前，从权威知识库中检索相关信息，以增强 LLM 的回答。	标准化 LLM 的双向通信，使其能够访问并与外部工具、数据源和服务交互，从而在检索信息的同时执行操作。
机制	包含一个信息检索组件，用于根据用户查询从知识库或数据源中拉取信息。然后，检索到的信息将增强 LLM 的提示内容。	定义了用于 LLM 应用调用外部函数或从专用服务器请求结构化数据的标准化协议，从而实现操作和动态上下文集成。
输出类型	LLM 根据其训练数据生成回答，该数据已通过外部文档中与查询相关的文本进行增强。通常重点关注事实准确性。	使 LLM 能够生成结构化调用以调用工具、接收结果，并根据这些结果和操作生成可供人类阅读的文本。也可以涉及实时数据和函数。
互动	主要用于被动检索信息，为文本生成提供依据；通常不用于在外部系统中执行操作。	专为主动交互和在外部系统中执行任务而设计，为 LLM“使用”外部功能提供“语法”。
标准化	这是一种用于改进 LLM 的技术或框架，但并非适用于不同供应商或系统之间工具交互的通用协议。	这是一种开放标准，规范 AI 应用为 LLM 提供上下文的方式，从而实现集成标准化并减少对自定义 API 的依赖。
使用场景	问答系统、能提供最新事实信息的聊天机器人、文档摘要功能，以及降低文本生成中幻觉内容的出现。	AI 智能体可执行任务（例如预订航班、更新 CRM、运行代码）、提取实时数据，并实现高级集成。

MCP vs. 大模型原生Function Calling

大模型原生的Function Calling是一种描述能力，它告诉模型“你可以调用哪些函数以及这些函数的格式是什么”。但它不关心这些函数具体如何实现、在哪里执行、以及如何安全地执行。

MCP是Function Calling的“运行时和后勤保障系统”。

• Function Calling 是“菜谱”：它告诉AI厨师可以做“宫保鸡丁”这道菜。

• MCP 是“整个厨房”：它提供了灶具、锅铲、食材（MCP服务器），并确保了厨师在安全、规范的环境下烹饪。

连接的生命周期

1. 初始化：AI应用（客户端）启动一个或多个MCP服务器进程。

2. 握手：客户端与服务器通过交换initialize和initialization消息建立连接，协商协议版本。

3. 资源/工具列表：客户端向服务器请求可用的资源（resources/list）和工具（tools/list）列表。

4. 工作循环：

   • 用户提问：用户在AI应用中提出问题。

   • AI决策：AI模型根据问题和可用工具列表，决定调用哪个工具，并生成调用参数。

   • 调用执行：客户端向服务器发送tools/call请求。

   • 返回结果：服务器执行工具（如查询数据库），并将结果返回给客户端。

   • 呈现用户：客户端将结果提供给AI模型，模型生成最终的自然语言回答给用户。

5. 关闭：会话结束，客户端与服务器断开连接。

五、MCP的安全性

MCP使用OAuth 2.1(https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-13)实施安全授权，以保护敏感资源与操作。

• 权限隔离：每个MCP服务器运行在独立的、受限制的权限环境中。一个文件服务器只能访问指定文件夹，一个数据库服务器只有只读权限。即使服务器被恶意利用，危害也被限制在最小范围。授权机制用于保障对MCP服务器所暴露敏感资源与操作的安全访问。当您的MCP服务器涉及处理用户数据或管理操作时，授权机制能确保只有获许可的用户可以访问其端点。

• 沙箱化运行：服务器通常以沙箱模式运行，无法访问主机的核心系统资源。

• 无需传递密钥：AI模型本身永远不会接触到API密钥或系统密码，这些凭据仅由MCP服务器持有。

虽然MCP服务器的授权是可选的，但强烈建议在以下情况下进行：

• 你的服务器访问的是用户特定的数据（电子邮件、文档、数据库）
• 你需要审计谁做了哪些操作
• 你的服务器授予需要用户同意的API访问权限
• 你是在为企业环境构建，且有严格的访问控制
• 你需要实现流量限制或按用户追踪使用量

结语

MCP远不止是一个技术协议，它更是一个生态的蓝图。它通过解耦AI应用与具体工具，为AI智能体的发展铺平了道路。随着支持MCP的工具和服务越来越多，我们将迎来一个AI真正成为个人和工作助手的时代，一个“万物皆可AI调用”的时代。

而这把通往未来的“万能钥匙”，现在已经握在了我们手中。

参考文献：

https://modelcontextprotocol.io/docs/getting-started/intro