引言:AI 应用开发的“连接器”困境

在 AI 应用开发领域,一个长期存在的痛点日益凸显:如何让大语言模型(LLM)安全、高效地连接和使用外部工具、数据源与系统?

开发者们面临着两难选择:

  • 定制化开发:为每个新工具或数据源编写特定的集成代码,工作量大、维护成本高。
  • 通用化妥协:使用有限的预定义工具集,牺牲了灵活性和扩展性。

无论是调用数据库、操作文件系统、查询实时天气,还是控制智能家居,都需要为 LLM 设计一套复杂的“适配层”。这种重复劳动不仅效率低下,还带来了安全风险和兼容性问题。

正是在这样的背景下,Model Context Protocol(MCP) 应运而生,它正迅速成为连接 AI 模型与外部世界的新标准协议

什么是 MCP?核心定义

Model Context Protocol (MCP) 是一个由 Anthropic 公司主导设计并开源的开放协议。它的核心使命是:为大型语言模型(LLM)与任意工具、数据源和服务之间,建立一套标准化、安全、可扩展的“对话”机制。

你可以把它理解为:

  • AI 世界的“USB 协议”:就像 USB 标准让电脑可以即插即用各种外设一样,MCP 让 LLM 可以即插即用各种工具。
  • 模型的“操作系统接口”:为 LLM 提供了一套统一的系统调用(syscall)规范,使其能安全地请求外部资源。
  • 工具生态的“通用插座”:任何符合 MCP 协议的工具,都可以被任何支持 MCP 的 AI 应用或平台直接使用。

MCP 诞生的背景:解决“最后一公里”问题

1. 从封闭到开放

早期,每家 AI 公司(如 OpenAI、Anthropic)都构建了自己的工具调用框架(如 Function Calling)。这些框架互不兼容,开发者被锁定在特定生态中。MCP 旨在打破这种壁垒,建立一个中立的、厂商无关的标准。

2. 从复杂到简单

在没有标准之前,为一个 AI 应用添加新能力(如“读取公司内部 CRM 数据”)需要:

  1. 在应用后端编写数据接口。
  2. 设计专门的提示词(Prompt)来描述这个接口。
  3. 处理复杂的权限验证和错误处理。
  4. 担心数据泄露和滥用风险。

MCP 将这一过程标准化和简化了。

3. 安全性的迫切需求

让 LLM 直接操作数据库或发送邮件是危险的。MCP 在设计之初就将安全性置于核心,通过明确的权限模型和资源隔离,确保模型只能在受控的“沙箱”内使用工具。

MCP 的核心架构与工作原理

MCP 采用经典的客户端-服务器(Client-Server) 架构,通过清晰的职责分离,实现了模型与工具之间的安全、高效对话。其核心包含三个角色,并通过标准化的协议进行通信。

1. MCP 服务器 (Server):能力的提供者

MCP 服务器是一个独立的进程,充当工具、资源和提示词的“供应商”。它的核心职责是:

  • 暴露工具 (Tools):定义可执行的操作(如 search_webread_file),每个工具都有明确的输入参数和输出格式。
  • 提供资源 (Resources):定义可访问的数据源(如 file:///path/to/doc.md),客户端可以“订阅”以获取更新。
  • 管理提示词模板 (Prompts):提供预定义的提示词片段,帮助客户端更高效地与模型交互。

举例:一个“天气服务器”可能提供 get_weather 工具和 weather://{city} 资源。

深入解析

  • 独立性:服务器作为独立进程运行,与客户端(AI应用)隔离。这意味着即使服务器崩溃,通常也不会影响主应用。
  • 能力声明:服务器启动时,会向连接的客户端宣告自己提供了哪些工具、资源和提示词。这类似于插件系统的“能力发现”阶段。
  • 权限与沙箱:服务器运行在用户定义的安全上下文中。例如,一个文件系统服务器可以被配置为只能读取 ~/Documents 目录,而不能访问其他敏感区域。这种设计将安全策略的执行点从模型转移到了受用户控制的服务器进程。
  • 多语言支持:MCP 服务器可以用任何语言编写(官方提供了 Python、TypeScript/JavaScript SDK),只要遵循协议规范即可。

2. MCP 客户端 (Client):协议的消费者与协调者

MCP 客户端是集成在 AI 应用(如 Claude Desktop、Cursor IDE)中的组件,负责:

  1. 发现与连接:启动并连接到一个或多个 MCP 服务器。
  2. 能力发现:从服务器获取可用工具、资源和提示词列表。
  3. 请求代理:接收用户/模型的请求,通过 MCP 协议调用相应的服务器工具或读取资源。
  4. 结果返回:将服务器的执行结果返回给模型,并最终呈现给用户。

深入解析

  • 模型集成点:客户端是 LLM 与外部世界之间的“翻译官”。它将用户的自然语言请求、模型的决策转化为标准的 MCP 协议调用,并将结构化的结果转化回自然语言。
  • 多服务器管理:一个客户端可以同时连接多个服务器,聚合来自文件系统、数据库、网络搜索等不同来源的能力,为模型提供一个统一的能力视图。
  • 上下文管理:客户端负责维护会话上下文,确保在多次工具调用中保持状态的一致性(例如,记住之前读取过的文件内容)。

3. 通信协议:标准化对话的基石

MCP 的通信分为两层:

  • 传输层:通常使用 stdio(标准输入输出)SSE(Server-Sent Events),实现简单、跨平台的进程间通信。
  • 应用层:基于 JSON-RPC 2.0 协议,定义了 initializetools/listtools/callresources/read 等标准方法,确保消息格式的统一。

协议细节

  • 初始化 (initialize):连接建立后,客户端和服务器交换元数据(如名称、版本、能力)。
  • 列表方法 (tools/list, resources/list, prompts/list):客户端获取服务器提供的所有能力清单。
  • 调用方法 (tools/call):客户端请求服务器执行一个工具,并传递参数。服务器执行后返回结果或错误。
  • 读取方法 (resources/read):客户端请求读取一个资源(如文件、数据库记录)的内容。
  • 通知 (notifications):服务器可以主动向客户端推送事件,例如资源内容发生变化。

核心交互流程

一次完整的 MCP 交互通常遵循以下步骤:

外部世界 (数据库/API/文件等) MCP 服务器 大语言模型 (LLM) MCP 客户端 (如 Claude Desktop) 用户 外部世界 (数据库/API/文件等) MCP 服务器 大语言模型 (LLM) MCP 客户端 (如 Claude Desktop) 用户 1. 初始化与发现 2. 用户提出需求 3. 模型决策与调用 4. 结果呈现 连接 & 初始化 (initialize) 返回能力列表 (tools, resources, prompts) “帮我总结桌面上的 report.md” 传递用户请求及可用工具列表 决策需调用 read_file 工具 tools/call: read_file(path="~/Desktop/report.md") 执行操作:读取文件 返回文件内容 返回执行结果 传递文件内容 生成总结文本 展示总结结果

流程详解

  1. 连接与发现:客户端启动并连接到服务器,服务器宣告其提供的工具、资源和提示词。这一步建立了通信基础,客户端知道了“服务器能做什么”。

  2. 需求提出:用户通过客户端界面(如聊天框)提出自然语言请求。例如:“帮我总结桌面上的 report.md 文件”。

  3. 规划与调用

    • 客户端将用户请求和从所有已连接服务器获取的可用工具列表一起交给 LLM。
    • LLM(基于其理解能力和工具描述)进行规划,判断完成用户请求需要调用哪个工具(或读取哪个资源),并生成结构化的调用参数。例如,它可能决定调用 read_file 工具,并指定 path 参数为 "~/Desktop/report.md"
    • 客户端通过 MCP 协议(tools/call 方法)将结构化请求发送给正确的服务器。
  4. 执行与返回

    • 服务器收到调用请求后,在其安全沙箱内执行实际操作(如读取文件、查询数据库、调用 API)。
    • 服务器将执行结果(成功的数据或错误信息)封装成标准格式,通过协议返回给客户端。
  5. 合成与呈现

    • 客户端将服务器的原始结果(例如文件内容文本)交还给 LLM。
    • LLM 结合原始结果和对话历史,生成最终的自然语言回复(例如文件的摘要)。
    • 客户端将 LLM 的回复呈现给用户。

架构优势总结
这种架构将模型的理解与规划能力(在客户端/LLM端)与工具的安全执行能力(在服务器端)进行了清晰解耦。通过标准化的 JSON-RPC 协议连接,它带来了多重好处:

  • 安全性:工具在独立的、受控的进程中运行,与核心 AI 应用隔离。
  • 灵活性:可以动态添加、移除或更新服务器,无需修改客户端或模型。
  • 互操作性:任何符合 MCP 协议的客户端都可以使用任何符合 MCP 协议的服务器。
  • 可调试性:基于文本的 JSON-RPC 通信易于记录、检查和调试。

本质上,MCP 为 AI 应用定义了一套“外部函数接口(FFI)”,使得大语言模型能够安全、可靠地调用外部世界的能力,从而极大地扩展了其实际应用范围。

为什么说 MCP 是“游戏规则改变者”?

1. 生态互操作性:一次开发,处处运行

  • 工具开发者:只需编写一个符合 MCP 标准的服务器,所有支持 MCP 的客户端(Claude、Cursor 等)都能立即使用你的工具。
  • 应用开发者:无需为每个工具集成 SDK,只需实现 MCP 客户端协议,就能接入整个 MCP 生态的工具。

2. 用户主权与控制力

  • 自主配置:用户可以选择安装和管理自己信任的 MCP 服务器,决定 AI 助手能访问哪些数据和能力。
  • 安全边界:工具运行在用户控制的服务器进程中,与 AI 应用本身隔离,数据不会无故上传到云端。

3. 激发长尾工具创新

  • 降低了为 AI 开发工具的门槛。一个开发者可以快速创建一个 MCP 服务器来暴露其专业领域(如法律、医疗、金融)的数据或 API,并立刻被主流 AI 产品使用。
  • 形成了正向循环:更多工具吸引更多用户使用支持 MCP 的客户端,更大的用户基础又激励更多人开发工具。

4. 提升开发体验与效率

  • 标准化:统一的协议减少了重复的集成工作。
  • 可调试性:MCP 通信是透明的,便于开发者调试工具调用过程。
  • 动态性:工具可以动态加载、卸载,无需重启主应用。

MCP 与相关技术的对比

特性 Model Context Protocol (MCP) OpenAI Function Calling LangChain Tools
定位 跨平台、跨模型的开放协议 特定 API(OpenAI)的专有功能 Python 框架的组件
集成方式 客户端-服务器,进程隔离 通过 API 调用直接集成 通过代码库导入,在应用进程内运行
生态 开放、去中心化,任何人均可发布工具 封闭,由 OpenAI 控制 围绕 LangChain 框架的社区生态
安全性 ,工具在独立进程运行,权限清晰 中,依赖 API 层的权限控制 取决于具体工具实现
适用场景 需要安全、灵活连接多种外部能力的桌面/IDE AI 应用 基于 OpenAI API 的云端 AI 应用 使用 LangChain 框架构建的AI 应用后端

简单来说

  • OpenAI Function Calling 是“品牌家电的专用插座”。
  • LangChain Tools 是“一套好用的电工工具箱和标准件”。
  • MCP 是“国家颁布的通用插座和电器接口标准”。

实战:快速体验 MCP

场景:让 Claude Desktop 具备读取本地文件的能力

  1. 安装 Claude Desktop(一个内置了 MCP 客户端的应用)。
  2. 配置一个文件系统 MCP 服务器(例如官方示例 mcp-server-filesystem)。
    # 示例:通过 pip 安装一个文件服务器
    pip install mcp-server-filesystem
    
  3. 在 Claude Desktop 配置中添加服务器
    (修改配置文件,指定服务器命令和参数,授权其访问特定目录)
  4. 重启 Claude Desktop
  5. 直接对话:现在你可以对 Claude 说“请总结我桌面上的 report.md 文件”,Claude 会自动通过 MCP 调用文件服务器来读取文件内容,然后为你总结。

开发自己的 MCP 服务器(Python 示例)

创建一个简单的“时间查询”服务器:

# server.py
import asyncio
from datetime import datetime
from mcp.server import Server, NotificationOptions
from mcp.server.models import InitializationOptions
import mcp.server.stdio

# 创建服务器实例
server = Server("time-server")

# 注册一个工具:获取当前时间
@server.list_tools()
async def handle_list_tools():
    return [
        {
            "name": "get_current_time",
            "description": "获取当前的系统时间",
            "inputSchema": {
                "type": "object",
                "properties": {
                    "format": {
                        "type": "string",
                        "description": "时间格式,例如 '%Y-%m-%d %H:%M:%S'",
                        "default": "%Y-%m-%d %H:%M:%S"
                    }
                }
            }
        }
    ]

# 处理工具调用
@server.call_tool()
async def handle_call_tool(name: str, arguments: dict):
    if name == "get_current_time":
        fmt = arguments.get("format", "%Y-%m-%d %H:%M:%S")
        current_time = datetime.now().strftime(fmt)
        return {
            "content": [{"type": "text", "text": f"当前时间是: {current_time}"}]
        }
    raise ValueError(f"未知工具: {name}")

async def main():
    async with mcp.server.stdio.stdio_server() as (read_stream, write_stream):
        await server.run(
            read_stream,
            write_stream,
            InitializationOptions(
                server_name="time-server",
                server_version="0.1.0"
            )
        )

if __name__ == "__main__":
    asyncio.run(main())

运行此服务器,并在支持 MCP 的客户端中配置连接,AI 助手就获得了查询时间的能力。

MCP 的现状与未来展望

当前生态

  • 主流客户端支持:Anthropic Claude Desktop、Cursor IDE、Windsurf 等已原生集成。
  • 丰富的服务器库:官方和社区已提供了文件系统、数据库(SQLite, PostgreSQL)、浏览器、Git、日历、邮件等大量常用工具的服务器实现。
  • 开发工具成熟:提供了 Python、TypeScript/JavaScript 等语言的 SDK,方便快速开发。

面临的挑战

  1. 协议演进:MCP 仍处于快速发展期,协议本身可能还会变化。
  2. 安全最佳实践:如何安全地配置和管理众多第三方服务器,对用户是一大挑战。
  3. 性能考量:进程间通信(IPC)可能带来轻微开销,对于高性能场景需要优化。

未来趋势

  1. 成为事实标准:有望被更多 AI 应用、平台甚至操作系统原生支持。
  2. 云端集成:可能出现托管的 MCP 服务器市场,以及企业级的 MCP 网关。
  3. 更复杂的编排:支持服务器间的协作和管道操作(一个工具的输出作为另一个工具的输入)。
  4. 标准化提示词模板:通过 MCP 共享和组合高质量提示词,提升 AI 能力。

总结:你该如何看待与使用 MCP?

  • 对于普通用户:关注你使用的 AI 应用(如 IDE、桌面助手)是否支持 MCP。支持意味着你可以通过安装“插件”(MCP 服务器)来无限扩展其能力,同时牢牢掌控自己的数据安全。
  • 对于开发者
    • 使用工具:优先寻找 MCP 服务器来实现你需要的功能,避免重复造轮子。
    • 贡献工具:将你的服务或专业能力封装成 MCP 服务器,分享给社区。
    • 集成协议:在你开发的 AI 应用中考虑支持 MCP 客户端,让你的产品瞬间拥有强大的工具生态。
  • 对于企业:评估将内部系统(CRM、ERP、知识库)通过 MCP 安全地暴露给 AI 助手的可能性,提升员工效率。

MCP 的本质,是将 AI 模型与工具集成的权力,从少数平台公司手中,重新交还给开发者和用户。 它正在构建一个更开放、更安全、也更富创造力的 AI 工具生态。理解并拥抱这一协议,很可能是在 AI 时代保持竞争力的关键一步。

现在,你可以打开你的 AI 助手,问一句:“你支持 MCP 吗?” 这或许是你探索下一个 AI 新世界的开始。

Logo

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐