当前位置：首页 > news >正文

MCP（模型上下文协议）——AI生态的“万能插座”

news 来源：原创 2025/6/14 16:25:59

关于上一篇分词的相关算法以及实践，得稍等等去更新了，这两天在折腾组装主机。因此将这篇在公司内技术分享的内容，分享出来，偷个懒。

引子：当AI遇见“万能接口”——MCP的诞生与使命在数字世界的洪流中，人工智能模型如同一艘艘孤舟，面对浩瀚的数据海洋与工具群岛，却始终缺乏一根可靠的“锚链”。直到2024年11月，Anthropic推出了模型上下文协议 （MCP）——一个被誉为“AI世界的USB-C端口”的开放标准。
今天，我们将从以下三方面来一探MCP！

是什么（what）？概念、定义
为什么（why）？为什么要
怎么样（how）？现在发展趋势、怎么使用/编写、现在存在的问题

是什么（What）？

——重新定义AI与世界的连接方式

“打破数据孤岛：MCP如何成为AI的‘神经中枢’？”

MCP介绍

MCP （Model Context Protocol，模型上下文协议）

2024年末，Anthropic推出了模型上下文协议(MCP)，这是一个标准化人工智能工具交互的通用协议。 MCP受到语言服务器协议(LSP)(Gunasinghe and Marcus, 2021)的启发，为人工智能应用程序提供了一个灵活的框架，可以动态地与外部工具进行通信。 MCP允许人工智能代理根据任务上下文自主地发现、选择和协调工具，而不是依赖于预定义的工具映射。它还支持人机交互机制，使用户能够根据需要注入数据或批准操作。通过统一接口，MCP简化了人工智能应用程序的开发，并提高了其处理复杂工作流程的灵活性。自发布以来，MCP已迅速从一个利基协议发展成为人工智能原生应用程序开发的关键基础。（目的就是为了解决 AI 模型与外部数据源、工具交互的难题。）

MCP通过提供标准化协议来简化此过程，该协议使AI智能体能够通过统一的接口无缝地调用、交互和链接多个工具。这减少了手动配置并增强了任务灵活性，使智能体能够执行复杂的操作而无需大量的自定义集成。
在这里插入图片描述

它就像是一个 “通用插头” 或者 “USB 接口”，制定了统一的规范，不管是连接数据库、第三方 API，还是本地文件等各种外部资源，都可以通过这个 “通用接口” 来完成，让 AI 模型与外部工具或数据源之间的交互更加标准化、可复用。

MCP架构

在这里插入图片描述

MCP-通信机制

服务器推送事件 (Server-Sent Events,SSE)
标准输入输出 (STDIO)

MCP -Core Components

HOST：主机代表任何提供 AI 交互环境、访问工具和数据、并运行 MCP 客户端的 AI 应用（如 Claude 桌面、Cursor）
- 初始化和管理多个客户端。
  
  客户端-服务器生命周期管理。
  
  处理用户授权决策。
  
  管理跨客户端的上下文聚合。
MCP Client：MCP 客户端在主机中运行，以实现与 MCP 服务器的通信
- 专用连接：每个客户端与单个服务器保持一对一的有状态连接。这种专注的关系确保了清晰的通信边界和安全隔离。
  
  消息路由：客户端处理所有双向通信，高效地在宿主和其连接的服务器之间路由请求、响应和通知。我们将在 Cursor IDE 与Linear 和 Slack 的示例中看到一个简单的例子。
  
  功能管理：客户端通过维护有关可用工具、资源（上下文数据）和提示模板的信息，来监控其连接的服务器的功能。
  
  协议协商：在初始化期间，客户端协商协议版本和功能，确保宿主和服务器之间的兼容性。
  
  订阅管理：客户端维护对服务器资源的订阅，并在这些资源发生更改时处理通知事件。
MCP Server：服务器公开了特定功能并提供对以下数据的访问
- Tools：服务器启用 LLMs 执行操作，使服务器能够向客户端暴露可执行的功能。通过工具，LLM 可以与外部系统交互、执行计算并在现实世界中采取行动。
- Resources：将服务器上的数据和内容暴露给 LLMs
- Prompts：创建可重用的提示模板和工作流程

Tools:

MCP 中的工具允许服务器暴露可执行的函数，这些函数可以被客户端调用并被 LLM 用来执行操作。工具的关键方面包括：

发现：客户端可以通过 tools/list 端点列出可用工具
调用：工具通过 tools/call 端点调用，服务器执行请求的操作并返回结果
灵活性：工具可以从简单的计算到复杂的 API 交互

Resources:

资源是模型上下文协议(MCP)中的一个核心原语，允许服务器暴露数据和内容，这些内容可以被客户端读取并用作 LLM 交互的上下文。

Prompt：

提示词使服务器能够定义可重用的提示词模板和工作流,客户端可以轻松地将其呈现给用户和 LLM。它们提供了一种强大的方式来标准化和共享常见的 LLM 交互。

为什么（Why）？

——MCP为何成为AI生态的基石？

背景

在 MCP 引入之前，AI 应用依赖于各种方法，例如手动 API 连接、基于插件的接口和代理框架，来与外部工具交互。
在这里插入图片描述

Function Call

本身LLM是经过预训练的，真实场景中的数据没有进入模型参数中（比如本地文件，数据库，一些网络实时信息等），llm是落后与数据更新的过程中。因此2023年，OpenAI 推出**函数调用（Function Call）**加速了这一进程，这使得语言模型能够以结构化的方式调用外部 API。这项进步扩展了大型语言模型 (LLM) 的能力，使其能够检索实时数据、执行计算以及与外部系统交互。随着函数调用的普及，围绕它形成了一个生态系统。

Function Call（函数调用）本质上就是提供了大模型与外部系统交互的能力，类似于给大模型安装一个 “外挂工具箱”。当大模型遇到自己无法直接回答的问题时，它会主动调用预设的函数（如查询天气、计算数据、访问数据库等），获取实时或精准信息后再生成回答。

比如：Coze、dify中的插件，其实都是基于Function Call实现封装的。

OPEN AI 最开始提出这项技术的时候，并没有想让它成为一项标准，所以虽然后续很多模型也支持了 Function Call 的调用，但是各自实现的方式都不太一样。
这也就意味着，如果我们要发开一个 Function Call 工具，需要对不同的模型进行适配，比如参数格式、触发逻辑、返回结构等等，这个成本是非常高的。
工具集成仍然支离破碎。开发人员必须手动定义接口、管理身份验证并处理每个服务的执行逻辑。跨平台的函数调用机制各不相同，需要冗余实现。此外，当前的方法依赖于预定义的工作流程，限制了 Agent 动态发现和协调工具的灵活性。

这些方法需要将每个外部服务与特定的 API 集成，从而导致复杂性增加和可扩展性有限。

在这里插入图片描述

Function Call工作流程

将用户的自然语言输入与已有函数的描述作为输入参数传给 LLM
LLM 结合输入参数，决定调用哪些函数，并指明必要参数（如函数的入参），进行格式化（如 JSON、XML 格式）的输出
用户端接收到 LLM 格式化的函数调用后，对本地的函数进行调用，得到结果
将得到的函数结果传给 LLM，使得 LLM 有了所需的上下文信息

MCP

MCP 通过提供一个标准化协议来解决这些挑战，该协议能够与多个工具进行无缝且灵活的交互。

MCP是一种标准化通信协议，类似于AI领域的"USB-C接口"。它通过JSON-RPC 2.0规范定义上下文传递规则，要求所有接入系统遵循统一的数据结构和通信流程。

MCP 工作流程

客户端（Claude Desktop / Cursor）将问题发送给 LLM
LLM 分析可用的工具，并决定使用哪一个（或多个）
客户端通过 MCP Server 执行所选的工具
工具的执行结果被送回给 LLM
LLM 结合执行结果，归纳总结后生成自然语言展示给用户

Function Call侧重于模型想要做什么，而 MCP 侧重于如何使工具可被发现和可消费，尤其是在多个Agent、模型或平台之间。

标准化: 统一的接口和协议，简化开发
高效性: 优化的上下文管理，增强模型交互
可扩展性: 灵活的架构支持自定义扩展
易用性: 简单直观的 API，较低的使用门槛

统一集成：一个用于连接任何 LLM 和任何工具的通用协议。

缩短开发时间：用于资源访问和工具执行的标准模式。

清晰的职责分离：数据访问（资源）和计算（工具）被清晰地分离。

一致的发现机制：用于查找可用功能（工具、资源、提示词、根目录、采样）的统一机制。

跨平台兼容性：为一个系统构建的工具可以与其他系统协同工作。

Function Call VS MCP

维度	Function Calling	MCP
协议统一性	各模型厂商自定义	标准化协议（JSON-RPC 2.0）
数据结构	应 LLM 提供商而有所不同	规范的 JSON-RPC
调用方式	同进程函数或API	Studio/SSE
主要职责	解析用户意图并选择合适的函数调用，并进行格式化输出	规范化函数的具体执行过程，即规范 LLM 应用与外部系统的交互
集成复杂度	M×N（模型数量×工具数量）	M+N（模型数量+工具数量）
扩展成本	高（每新增模型或工具需重新适配）	低（遵循协议即可接入，工具热插拔）
适用场景	简单任务（单次函数调用）	复杂流程(多工具协同 + 数据交互)

在这里插入图片描述

怎么样（How）？

——趋势、应用与挑战

MCP如何工作

在一个典型的工作流程中，用户向MCP客户端发送提示，客户端分析意图，通过MCP服务器选择合适的工具，并调用外部API来检索和处理所需信息，然后通知用户结果。

在这里插入图片描述

MCP-生命周期

在这里插入图片描述

案例实现——查询天气

async def fetch_weather(city: str) -> dict[str, Any] | None:"""从 OpenWeather API 获取天气信息。:param city: 城市名称（需使用英文，如 Beijing）:return: 天气数据字典；若出错返回包含 error 信息的字典"""params = {"q": city,"appid": API_KEY,"units": "metric","lang": "zh_cn"}headers = {"User-Agent": USER_AGENT}async with httpx.AsyncClient() as client:try:response = await client.get(OPENWEATHER_API_BASE, params=params, headers=headers, timeout=30.0)response.raise_for_status()return response.json()  # 返回字典类型except   httpx.HTTPStatusError as e:return {"error": f"HTTP 错误:   {e.response.status_code}"}except   Exception as e:return {"error": f"请求失败:   {str(e)}"}def format_weather(data: dict[str, Any] | str) -> str:"""将天气数据格式化为易读文本。:param data: 天气数据（可以是字典或 JSON 字符串）:return: 格式化后的天气信息字符串"""# 如果传入的是字符串，则先转换为字典if isinstance(data, str):try:data = json.loads(data)except   Exception as e:return f"无法解析天气数据:   {e}"# 如果数据中包含错误信息，直接返回错误提示if "error" in data:return f"⚠️   {data['error']}"# 提取数据时做容错处理city = data.get("name", "未知")country = data.get("sys", {}).get("country", "未知")temp = data.get("main", {}).get("temp", "N/A")humidity = data.get("main", {}).get("humidity", "N/A")wind_speed = data.get("wind", {}).get("speed", "N/A")# weather 可能为空列表，因此用 [0] 前先提供默认字典weather_list = data.get("weather", [{}])description = weather_list[0].get("description", "未知")return (f"🌍   {city},   {country}\n"f"🌡 温度:   {temp}°C\n"f"💧 湿度:   {humidity}%\n"f"🌬 风速:   {wind_speed}   m/s\n"f"🌤 天气:   {description}\n")

执行

@mcp.tool()
async def query_weather(city: str) -> str:"""输入指定城市的英文名称，返回今日天气查询结果。:param city: 城市名称（需使用英文）:return: 格式化后的天气信息"""data = await  fetch_weather(city)return format_weather(data)if __name__ == "__main__":# 以标准 I/O 方式运行 MCP 服务器mcp.run(transport='stdio')

发展现状

尽管MCP被迅速采用，但其生态系统仍处于早期阶段，安全、工具可发现性和远程部署等关键领域缺乏全面的解决方案。

4月以来，阿里云、谷歌、腾讯等企业的高调支持成为行业焦点。

阿里云百炼平台上线业界首个全生命周期MCP服务，首批集成高德、无影等50余款工具；
谷歌宣布为Gemini模型添加MCP支持，称其“正成为AIAgent时代的开放标准”；
腾讯云则升级大模型知识引擎，支持调用MCP插件。巨头的技术整合能力显著扩大了MCP的应用场景。

挑战

概念性

缺乏集中式安全监督。 由于MCP服务器由独立的开发人员和贡献者管理，因此没有集中平台来审核、执行或验证安全标准。这种分散的模式增加了安全实践不一致的可能性，使得难以确保所有MCP服务器都遵守安全的开发原则。
身份验证和授权漏洞。 MCP目前缺乏一个标准化的框架来管理不同客户端和服务器之间的身份验证和授权。没有统一的机制来验证身份和规范访问权限，就难以执行细粒度的权限，尤其是在多租户环境中，多个用户和代理可能与同一MCP服务器交互。缺乏强大的身份验证协议增加了未经授权的工具调用的风险，并将敏感数据暴露给恶意行为者。此外，不同的MCP客户端处理用户凭据的方式不一致，进一步加剧了这些安全挑战，使得难以在不同部署中维护一致的访问控制策略。
调试和监控机制不足。 MCP缺乏全面的调试和监控机制，这使得开发人员难以诊断错误、跟踪工具交互以及在工具调用期间评估系统行为。由于MCP客户端和服务器独立运行，错误处理和日志记录中的不一致性可能会掩盖关键的安全事件或操作故障。如果没有强大的监控框架和标准化的日志记录机制，识别异常、防止系统故障和减轻潜在的安全事件将变得具有挑战性，从而阻碍了更具弹性的MCP生态系统的开发。

缺陷——被攻击

MCP就像是一个 “通用插头” 或者 “USB 接口”，制定了统一的规范，不管是连接数据库、第三方 API，还是本地文件等各种外部资源，都可以通过这个 “通用接口” 来完成，让 AI 模型与外部工具或数据源之间的交互更加标准化、可复用。

当前，MCP 已逐步确立其作为 AI Agent 连接外部工具的标准协议地位。但 MCP 设计的初衷为简化 AI 和外部工具之间的交互流程，在安全上并没有过多考虑。

MCP 在设计上确实存在一些天然的安全缺陷，在使用了 MCP 的 LLM 应用中更容易构造安全攻击，目前市面上的 MCP Clinet 本身在设计上也没有为安全过多考虑，所以风险还是非常大的，无论是作为 MCP 的开发者，还是使用者，安全都是不容忽视的一个问题。

类别	名称	描述
MCP Server恶意投毒
	工具投毒（提示词投毒）	工具中毒是一种专门针对 LLM 的攻击方式，与传统漏洞利用代码执行缺陷不同，它通过篡改工具定义中的元数据（如描述、参数说明），直接影响 LLM 的决策逻辑。在 MCP 生态中，LLM 依赖外部工具访问敏感系统和数据，这种攻击模式因此具备高度隐蔽性和破坏性。攻击者可以在一段正常功能的提示词里嵌入恶意攻击的提示词，从而达到在用户不知情的情况下欺诈、窃取用户信息等恶意操作。这种攻击主要影响 Cursor、Claude for Desktop 等 MCP 客户端用户。工具投毒攻击的核心机制在于，攻击者可以在 MCP 代码注释中的工具描述里嵌入恶意指令，这些指令对用户不直接可见但对 AI 模型可见。
	窃取用户数据	攻击者通过各种恶意的方式（比如监听工具的整个交互内容、读取本地某些文件等等）获取到了用户相关的某些内容，然后通过 API 将这些内容发送到远程服务器。
	执行恶意命令	攻击者通过一些系统命令 API，在用户不知情的情况下调用系统命令，进行比如在本机安装恶意软件、篡改系统配置文件、窃取敏感数据、创建后门账户、发起网络攻击等恶意操作，此类命令脱离 MCP 本身要提供的功能。
	非法目录读取	攻击者通过文件读取 API，在用户不知情的情况下读取本机的某些敏感文件，，比如~/.ssh/id_rsa等私钥文件、系统配置文件（如/etc/passwd、/etc/shadow）、数据库配置文件（含账号密码的.ini或.conf文件）以及用户个人隐私数据（如聊天记录、财务报表文档等）。
MCP Server 实现缺陷		通常是 MCP Server 在实现过程中本身缺乏安全考虑，实现出了一些含有漏洞的代码，一些攻击者在使用到这个 MCP Server 时，通过利用漏洞来达成攻击效果。
	提示词注入	提示词注入漏洞主要利用了 LLM 无法有效区分系统指令和用户输入的特性。当应用程序未对用户输入进行适当验证和清洗时，攻击者可以在输入中嵌入特殊指令，这些指令会被模型解释并执行，从而绕过应用程序设定的安全边界。
	命令注入	当用户可控的输入未经有效清理或验证，直接嵌入系统命令时，即引发命令注入漏洞。
	代码注入	用户可控的输入被 MCP Server 动态地作为代码执行，这使得攻击者可以注入任意代码并执行。
	DOS 风险	恶意输入可能导致 MCP Server 过度使用资源（如内存、CPU、磁盘），从而使系统性能下降甚至崩溃。
	权限校验缺陷	MCP Server 允许根据用户提供的标识符访问内部对象/资源，而未进行适当的授权检查。