MCP全景调研：原理、生态与安全

摘 要

随着大语言模型从对话接口向自主智能体（Agent）演进，模型与外部数据及工具的集成成为核心瓶颈。模型上下文协议（MCP）作为一种新兴的开放标准，旨在通过标准化的架构消除集成碎片化，实现工具的即插即用与跨平台互操作。本文系统性地梳理了MCP的技术架构与实现细节，分析了其在工业界与开源社区的生态演进趋势，并深入探讨了协议在生命周期各阶段面临的安全挑战与隐私风险。研究发现，虽然MCP显著提升了智能体的协作效率，但其引入的间接提示词注入、工具链滥用及供应链安全等问题亟待建立体系化的防御方案。最后，本文对MCP未来的标准化路径与安全治理方向进行了展望。

一、引言

模型上下文协议（Model Context Protocol, MCP）是由Anthropic于2024年推出的开放标准，旨在为AI应用与外部数据源、工具之间建立统一的通信协议。MCP采用了宿主（Host）、客户端（Client）与服务端（Server）的三层架构，通过JSON-RPC协议实现了资源、工具与提示词模板的动态发现与双向调用，为LLM提供了标准化的外部增强能力。

自发布以来，MCP生态经历了爆发式增长。目前已形成以AI原生编辑器（如Cursor、Zed）为核心，向云平台（如Cloudflare）和多语言SDK（Python、TS等）扩散的多场景应用。开源注册表与第三方托管平台的涌现体现了MCP生态的自主治理，而随着MCP正式移交Linux基金会治理，该协议正从单一厂商提案演变为中立的工业标准。

在改变交互范式的同时，MCP也带来了全新的攻击面。由于协议缺乏内置的运行时隔离与细粒度权限控制，其面临着严重的供应链威胁（如安装程序欺骗）、逻辑层攻击（如间接提示词注入）以及运行时风险（如沙箱逃逸）。这些挑战不仅威胁到用户数据的私密性，更可能导致AI代理行为失控，成为系统级漏洞的放大器。

随着MCP逐渐成为大模型外部交互的事实标准，亟需对其底层逻辑与潜在风险进行深度剖析。本文旨在为开发者与研究者提供一份全景式的技术指引，以推动MCP生态在“安全稳健”的前提下实现可持续增长。

本文的综述方法如下：

1. Google Scholar检索文献
2. Arxiv检索预印本
3. 精读部分文献，略读剩余文献，梳理成文

二、背景

2.1 MCP核心概念

模型上下文协议（Model Context Protocol, MCP）是由Anthropic于2024年11月推出的开放标准，旨在为大语言模型与外部数据源或工具间的交互提供标准化的协议，解决现有协议碎片化的核心痛点[1]。MCP的设计灵感深受编程领域的语言服务器协议（Language Server Protocol, LSP）启发，正如LSP通过标准协议实现了N种编程语言与M种编辑器之间的解耦，MCP的目标是建立一套通用的通信契约，使得AI应用无需为每个数据源编写特定的集成代码。

2.2 需求与应用场景

随着大模型从单纯的对话机器人向智能体演进，业界对于实时数据感知与外部工具操控的需求呈现爆发式增长。然而，传统的集成方案面临着以下严峻的挑战。

1. 数据孤岛与信息碎片化。企业内部数据往往分散在SaaS应用、私有数据库和本地文件系统中。LLM若要发挥效能，必须能够安全、即时地访问这些上下文。传统的检索增强生成（RAG）模式在处理非结构化静态文档时表现优异，但在处理高度结构化或动态变化的系统（如ERP、CRM）时，缺乏标准化的交互协议，导致每增加一个数据源就需要进行繁琐的二次开发。
2. 工业级性能需求。在复杂任务流程中，智能体需要频繁调用外部API进行操作。MCP提供了一种“即插即用”的连接方式，使得智能体能够跨平台调度工具。例如，在软件开发场景中，一个支持MCP的IDE可以同时连接Git、Issue追踪系统和本地终端，通过标准协议获取上下文并执行修复建议。
3. 知识库的访问。隐私保护需求的提升促使更多用户倾向于本地处理敏感数据。MCP支持基于stdio的本地进程通信，允许LLM在不经过云端中转的情况下，直接与本地笔记软件（如Obsidian）或文件系统交互，满足了高隐私要求的个人数字化办公场景。

因此，业界迫切需要一个通用、完善的工具和数据调用协议。

2.3 LLM与外部交互方式的演进

LLM对外部工具的使用经历了从硬编码到标准化协议的四个重要阶段，这一演进过程反映了AI系统从封闭走向开放的趋势。

1. 静态提示词与RAG阶段（2020~2022）。Lewis等人提出的RAG框架首次为LLM提供了动态获取外部知识的能力，并支持知识更新而无需重新训练模型。RAG建立了"检索-增强"的基础范式，但其将检索和生成视为独立的批处理过程，未能定义LLM如何将检索到的内容转化为可执行的操作。Few-shot方法也被尝试使用。开发者在Prompt中手动描述工具的API格式，引导模型输出符合要求的文本，再通过正则表达式提取参数并调用。由于这种方式涉及到不可控的LLM输出，鲁棒性差，且易受长文本上下文干扰。
2. 函数调用与模型内行动阶段（2023年）。这一阶段的核心特征是将API调用能力直接嵌入到LLM的生成过程中。OpenAI推出的Function Calling使LLM能够在生成时输出格式化的JSON函数签名，统一了自然语言理解和动作调用[6]。Schick等人提出的Toolformer通过自监督掩码策略，在预训练阶段学习何时以及如何调用API，使模型能够自主决定工具使用时机[5]。Yao等人的ReAct框架则提出了推理与行动交替执行的模式，使模型能够基于中间观察结果动态调整后续行动[4]。而OpenAI的Webgpt则首次赋予LLM联网搜索的能力[3]。这些创新显著提升了agent的自主性和灵活性，但所有能力都局限于单一模型内部，依赖静态工具注册表，缺乏跨平台、跨模型的标准化接口。
3. 开放协议与互操作性阶段（2024-2025年）。这一阶段的核心转变是从模型层面的能力增强转向协议层面的标准化互操作。Anthropic推出的Model Context Protocol（MCP）通过JSON-RPC客户端-服务器接口标准化了LLM与外部工具的集成，提供了Resources、Tools、Prompts和Sampling四大原语。IBM的Agent Communication Protocol（ACP）采用RESTful HTTP接口，提供了模型无关的通信层。Google的Agent-to-Agent Protocol（A2A）通过Agent Card实现基于能力的发现。Agent Network Protocol（ANP）则采用去中心化架构，支持开放互联网上的跨平台Agent协作。这些标准化协议简化了LLM与外部交互的流程，为可扩展的多Agent生态系统奠定了基础[8]。

2.4 MCP的优势

相比于之前的集成方案，MCP在技术架构与生态治理上展现出显著优势[8]：

• 互操作性与可扩展性：开发者只需为一个工具编写一次MCP Server，即可让所有支持MCP协议的模型（如Claude、GPT、Gemini）直接调用。这种“一次编写，到处运行”的特性极大地降低了生态建设的门槛。
• 上下文感知的深度集成：与传统的API调用不同，MCP的“资源（Resources）”概念允许Server向Host推送动态更新的上下文。模型不再是盲目地发出请求，而是在丰富的实时环境信息中进行决策，显著提升了Agent的执行成功率。
• 安全设计：MCP将执行权保留在Client端或Server端， Host应用可以作为安全网关，对所有进出的JSON-RPC请求进行拦截、审计和人类确认（Human-in-the-loop）。这为解决提示词注入攻击和过度授权问题提供了底层制度保障。
• 降低上下文窗口消耗：通过MCP的按需检索与采样（Sampling）机制，Host无需将所有文档塞进Prompt，而是由模型根据需要动态请求特定片段，有效地缓解了长上下文导致的模型注意力涣散和显存溢出问题。

三、设计与实现

3.1 架构设计

MCP架构采用典型的客户端-服务器（Client-Server）模型，包含三个核心组件：

1. MCP宿主（Host）：运行LLM的端侧应用，如AI驱动的集成开发环境（IDE）、桌面工作站或智能助手客户端。
2. MCP客户端（Client）：集成在Host内部，负责发起与Server的连接、管理权限并维护协议握手及会话生命周期。
3. MCP服务端（Server）：轻量级程序，负责将特定的原始数据（如SQL数据库、GitHub代码库、本地文件系统）或API功能封装为协议定义的标准格式，通过JSON-RPC 2.0接口暴露给Client。

在MCP体系中，信息交换被抽象为三类核心原语[2]，即服务端能提供三种服务：

• 资源（Resources）：只读数据流，如日志或文档
• 工具（Tools）：可执行的函数或动作
• 提示词（Prompts）：预定义的高级指令模板

此外，还有Roots原语用于控制对目录的访问权限，Sampling原语用于服务端反向调用LLM生成内容。这种抽象不仅实现了模型与环境的解耦，更为后续的安全审计与权限控制提供了标准化的切入点[2]。

3.2 工作流

MCP的基础通信协议构建于JSON-RPC 2.0规范之上[2]。选择JSON-RPC而非RESTful架构的主要考量在于其轻量化的消息结构以及对双向异步通信的良好支持。协议规范定义了三类基础消息类型：请求（Requests）、响应（Responses）以及通知（Notifications）。

协议的生命周期管理起始于初始化握手（Initialization Handshake）。在该阶段，客户端发起 initialize 请求，携带其支持的协议版本、能力集合以及客户端信息。服务端回执其协议版本及能力清单。这一过程不仅是技术对齐，更是权限协商。只有在双方完成版本匹配后，客户端才会发出 initialized 通知，标志着会话正式开启。在整个会话期间，任何一方均可通过发送 ping 请求来检测连接存续性。

此外，协议引入了能力协商机制。服务端可以声明其是否支持资源列表（Resources）、工具调用（Tools）或提示词模板（Prompts）。这种细粒度的能力声明机制使得 Host 能够根据当前任务的需求，动态加载最相关的服务端模块，从而优化了 LLM 的推理上下文空间[8]。

3.3 技术细节

3.3.1 传输方式

MCP在传输层实现了灵活的适配机制，目前主流的实现方案包括标准输入输出（stdio）、服务器发送事件（SSE）以及演进后的流式HTTP传输（Streamable HTTP）。

1. stdio 传输方式：这是目前本地集成最常用的方式。在这种模式下，客户端通过子进程管理（Child Process Management）启动服务端程序。两者通过标准的 stdin 和 stdout 流进行双向通信。该方式的优势在于零网络延迟和天然的安全性，因为所有数据流仅在同一物理机内部流动，极大降低了中间人攻击的风险。
2. SSE（Server-Sent Events）传输方式：主要用于远程服务端场景。由于传统的 HTTP 协议是无状态且请求响应式的，SSE 为其提供了单向长连接能力。服务端通过 SSE 实时向客户端推送状态更新（如日志或长任务进度），而客户端通过标准的 HTTP POST 请求向服务端发送指令。这种混合模式解决了跨网络调用中的实时性问题 [13]。
3. Streamable HTTP 传输方式：作为 SSE 的现代化替代方案，它利用了 HTTP/2 或更高版本中对于流式处理的优化支持。相比于 SSE 的单向推送，流式 HTTP 支持更为复杂的双向数据交换，且在负载均衡和代理服务器的兼容性上表现更佳。该方式通常被应用于云原生环境下的 MCP Server 部署 [14]。

3.3.2 资源管理

在MCP中，资源（Resources）被定义为可被模型读取但不可被直接执行的上下文信息。其管理核心基于 URI 体系。

1. 资源发现与定位：服务端通过 resources/list 接口公开其可供访问的资源树。每个资源通过一个全局唯一的 URI（如 file:///logs/error.log 或 db://customers/profiles）进行标识。这种基于 URI 的定位方式允许 Host 使用统一的模式处理来自不同 Server 的异构数据。
2. 动态资源模板：为了应对海量且动态的数据（如数据库中的特定行），MCP 支持 URI 模板（URI Templates）。服务端定义参数化的路径，模型可以根据推理需要，填充特定参数（如用户 ID）来请求精准的上下文片段。这种按需加载机制显著减少了冗余信息的输入。

3.3.3 状态管理

由于 LLM 的交互通常是多轮对话，MCP 必须具备处理会话状态的能力，尽管底层的传输协议（如 HTTP）可能是无状态的。

1. 会话生命周期绑定：在 stdio 模式下，状态与子进程的生命周期直接绑定；而在 SSE 或 HTTP 模式下，协议通过在 header 或请求参数中携带唯一的 Session ID 来维持逻辑上的长链接。
2. 服务端状态更新：当服务端的数据发生变更（例如监控的文件被修改），它会主动发送 notifications/resources/list_changed 通知。客户端收到通知后，会提示 Host 重新索引相关资源。这种主动更新机制确保了模型始终基于“最新”的上下文进行推理，避免了陈旧数据导致的逻辑错误。

3.3.4 错误处理

为了确保系统的健壮性，MCP 定义了一套严密的错误处理逻辑。除沿用 JSON-RPC 2.0 的标准错误代码（如 -32700 解析错误、-32601 找不到方法）外，MCP 还扩展了特定的业务级错误码。

1. 执行级异常处理：当工具执行失败时，服务端返回 code 为 -32000 的错误，并携带详细的 data 字段说明故障原因（如权限不足或第三方服务超时）。客户端收到错误响应后，可以将错误信息回传给模型，由模型判断是否需要重试或调整参数。
2. 协议层防御：若客户端发送了服务端未声明支持的能力请求（例如在不支持资源的 Server 上调用 read），服务端必须返回特定的错误响应，而非保持静默。这种显式的反馈机制是实现自动发现与自我修复系统的基础。

四、MCP生态

4.1 生态发展现状

自Anthropic在2024年底发布Model Context Protocol（MCP）以来，该协议在短短一年内经历了从单一厂商提案到工业界通用标准的跨越式演进。

4.1.1 生态规模

根据2025年底的统计数据，MCP在开源社区的表现极具爆发性，其核心仓库在不到八个月的时间内获得了超过3.7万个GitHub星标，成为年度增长最快的人工智能基础设施项目之一 [18]。生态的繁荣直接体现在服务端（Server）数量的指数级增长上。在2025年9月推出官方注册表预览版时，入驻的服务端仅为数百个，而截止到2025年11月，活跃的MCP服务端已接近2,000个，月增长率超过400% [19]。

学界也对MCP生态的规模进行了测绘和实证研究。Guo等人提出了MCPCrawler系统测量框架，可以收集和归一化来自六个主要市场的数据；在14天的活动中，汇总了8401个有效项目，然而其中显示，超过一半的上市项目无效或低价值[13]。Wu等人提出的MCPZoo则提供了从多个公共来源收集的最大、最全面的MCP服务器数据集，包括129,059台服务器，并且提供了可交互的接口以支持基于MCP的系统和安全分析的研究[14]。

4.1.2 评估体系

随着生态规模的扩大，如何科学评估MCP集成的效能成为了学术界关注的重点。2025年出现的 MCPGauge 和 MCPVerse 等基准测试体系填补了这一空白。

• MCPGauge通过“主动性、合规性、有效性、开销”四个维度量化了LLM对MCP工具的使用效率。研究发现，虽然大部分模型在标准指令下表现良好，但在处理大规模候选工具集时，模型性能会出现明显的衰减。
• MCPVerse 提出了一个包含数千个真实MCP Server的测评环境，挑战模型在动态、非模拟环境下的工具编排能力。该基准测试结果显示，顶级模型（如Claude-4或GPT-5预览版）能够利用MCP的资源订阅机制，将推理延迟降低25%以上。

4.2 应用场景

MCP生态的成熟不仅体现在服务端的丰富度上，更体现在主流开发工具和生产力平台作为“宿主（Host）”的深度集成。目前，MCP已形成了以智能集成开发环境（AI-native IDE）为核心，向桌面工作站和企业级中间件扩散的集成矩阵。

在开发工具领域，Cursor、Zed以及Windsurf等新一代编辑器率先实现了MCP原生支持。这些工具利用MCP将模型的能力从单纯的代码补全扩展到了对整个开发环境的感知，例如通过MCP Server直接读取Git历史、执行本地测试脚本或检索第三方库文档。JetBrains系列产品也在2025年末在其AI Assistant中引入了MCP支持，允许开发者通过简单的命令行指令或图形化界面动态加载MCP服务端[17]。此外，微软的Copilot Studio和IBM的BeeAI也相继宣布支持MCP，旨在为企业用户提供跨厂商的智能体协调能力。这种广泛的宿主支持确保了MCP Server开发者只需编写一次代码，即可在多个主流AI交互界面中被调用，彻底解决了由于IDE碎片化带来的适配成本问题。

4.3 生态治理

4.3.1 中心化注册表

为了解决MCP服务端的发现与分发难题，生态内涌现出了多种治理模式。官方MCP注册表（Official MCP Registry）充当了权威的索引角色，通过严格的版本规范确保了协议的一致性。与此同时，第三方分发平台如 Smithery.ai 通过提供托管服务和自动化的OAuth身份验证UI，进一步简化了非技术用户的使用流程。Smithery 等平台不仅提供服务端的搜索与发现，还引入了“即插即用”的连接机制，开发者可以通过唯一的URL直接将远程Server挂载到自己的客户端中，无需手动管理复杂的环境变量和密钥[12]。

4.3.2 分发机制

除了中心化注册表，社区还通过诸如 mcp-get 等包管理工具，实现了类似于NPM或PyPI的服务端安装体验。这种分层级的分发体系——即“官方索引提供规范、第三方平台提供托管、开源工具提供本地管理”——构成了MCP生态长期稳定运行的物理基础。此外，AWS等云服务商也开始在其Serverless架构（如Amazon Bedrock）中集成MCP转发能力，允许企业以更低的延迟和更高的并发量运行其私有的MCP服务端 [22]。

4.4 中立化

MCP的治理结构在2025年末发生了标志性的转变，其核心标志是MCP正式加入Linux基金会（The Linux Foundation）。这一举措标志着该协议从Anthropic主导的单一厂商项目向由全球协作驱动的开放标准迈进。在Linux基金会的治理框架下，MCP设立了由开发者、云厂商（如AWS、Google）和模型提供商共同参与的指导委员会，以确保护协议的长远规划不受单一商业利益的裹挟[9]。

这种中立化治理策略的核心在于通过RFC（Request for Comments）机制推动协议规范的演进。例如，在2025年11月的版本更新中，社区通过协作引入了“人类确认（Elicitations）”机制，专门解决复杂任务中模型反向请求人类输入时的交互标准化问题 [19]。这种由需求驱动的、开放且透明的治理模式，增强了企业对于采用MCP作为长期架构底层方案的信心。同时，为了防止协议由于各厂商自定义扩展而导致的分裂（Fragmentation），委员会推出了SDK分级体系，根据对核心规范的遵循程度对第三方库进行认证。这种“共建共享、严控核心、放开边缘”的治理哲学，是MCP能够在中期维持其生命力并最终向ISO或IETF等更高级别标准演进的关键保障[11]。

五、安全与隐私

针对模型上下文协议（MCP）生态系统的安全分析是当前生成式人工智能基础设施研究的重难点。根据Hou等人（2025）的系统性分类，MCP的威胁模型涵盖了从服务器创建、部署到运维的全生命周期。Yang等人（2025）通过MCPSecBench评估发现，目前主流MCP提供方（如Claude、OpenAI、Cursor）在核心漏洞面前普遍存在脆弱性，超过85%的已知攻击类型可成功实施，凸显了协议层与实现层安全机制的滞后[19]。此外，Hasan等人（2025）对1,899个开源MCP服务器的实证研究显示，约7.2%的服务器存在通用漏洞，5.5%展现出特定于MCP的工具中毒迹象，证明了该生态系统初期治理的严峻性[12]。

5.1供应侧威胁

恶意开发者在供应侧通过多种手段干预MCP生态的健康。首先，名称空间劫持与工具名称冲突是初级的身份冒充手段。Hou等人指出，攻击者注册与知名服务器相似的名称可以诱导模型误调用恶意实例。Wang等人（2025）进一步提出了偏好操纵攻击（MPMA），其中直接操纵（DPMA）通过在描述中植入诱导词，在多项测试中达到了100%的攻击成功率；而基于遗传算法的隐蔽策略（GAPMA）则利用广告心理学特征，在不引起用户警觉的情况下劫持模型选择偏好[22]。

此外，Shuli Zhao等人（2025）揭示了更为隐蔽的寄生工具链攻击（Parasitic Toolchain Attacks），利用MCP缺乏上下文隔离的缺陷，在无需受害者直接交互的情况下，通过嵌入恶意指令使合法工具组合成违规工作流[21]。Bhatt等人（2025）针对此类风险提出了增强型工具定义接口（ETDI），试图通过OAuth身份验证和策略控制来减缓此类劫持风险[22]。

不仅如此，Zhao等人的研究指出，攻击者可以轻易制作大量恶意MCP服务器，且难以检测[21]。Fang等人进行了一系列试点实验，证明MCP驱动的代理系统的安全风险是真正的威胁，其防御并非微不足道，呼吁业界重视恶意第三方提供者问题[27]。

5.2注入与伪造威胁

外部攻击者的威胁主要聚焦于数据的动态流入环节。

间接提示词注入（Indirect Prompt Injection）是MCP面临的结构性挑战，外部恶意数据源（如GitHub议题、网页评论）携带的指令在被MCP工具检索后直接进入模型上下文，使模型转化为攻击者的“受困代理”。Hou等人的案例展示了攻击者如何通过受污染的外部数据诱导模型读取私密仓库并外泄。

此外，安装程序欺骗在2025年呈现高发态势。由于 MCP 服务器通常需要复杂的本地环境配置，这为非技术用户制造了技术门槛 。为了提升易用性，社区涌现了如 Smithery-CLI、mcp-get 和 mcp-installer 等自动安装工具 。非官方的自动安装程序由于代码签名和完整性校验，可能分发含有后门或指令监听能力的恶意服务器二进制文件[23]。

5.3 运行时安全问题

在运行时环境中，敏感信息的静态存储与动态调用均存在泄露风险。Hou等人分析发现，许多MCP本地部署将API密钥明文存储在已知路径的JSON文件中，易导致凭证窃取。沙箱逃逸则是更深层的威胁，Radosevich与Halloran的安全审计表明，缺乏运行时隔离的MCP工作流允许恶意指令修改系统配置（如篡改.bashrc文件）以建立后门[24]。Zhao等人提到的寄生工具链则进一步演示了如何在获取隐私数据后利用模型自主决策能力，链式调用外发工具实现数据的自动化外泄[21]。由于MCP目前高度依赖宿主应用的权限体系，缺乏细粒度的最小权限原则实施，导致一个受损的工具往往能波及整个系统的资源边界。

5.4 长期维护问题

技术实现层面的不成熟进一步放大了安全风险。Hasan等人（2025）指出，MCP服务器的维护质量参差不齐，66%的代码存在“异味”，14.4%含有逻辑缺陷，这种低质量的实现为攻击者提供了现成的利用点[12]。Hou等人提到的配置漂移（Configuration Drift）也是云端多租户部署的一大难题，随着版本迭代，初始的安全 baseline 可能在手动调整或部分更新中失效。此外，更新后的权限持久化（Privilege Persistence）使得已吊销的凭证在某些实现中仍能通过缓存维持有效会话，构成了长期的潜在安全隐患。

5.5 防御体系的探索

针对MCP全生命周期的风险，学术界与工业界正尝试构建多层防御体系。Xing等人（2025）开发了分层防御架构MCP-Guard，将静态特征扫描与深度神经网络威胁检测相结合[28]。Kumar等人（2025）则提出了防御深度层MCP Guardian，重点加强了通信层的防火墙集成、速率限制与日志分析[29]。Ntousatis等人提出了统一路由MCP会话的网关，实现信息流保护与审计[30]。Jing等人则提出了模型上下文完整性协议（MCIP），一个解决MCP中缺失的安全机制的MCP改进版本，根据精细的分类法捕捉MCP应用场景中的不安全行为[31]。

Hou等人强调，未来的安全实践必须包括元数据自动化验证、强制性的运行时沙箱隔离以及基于人类参与（Human-in-the-loop）的敏感意图审核。只有建立起跨厂商、跨层级 的信任治理链条，MCP才能在实现跨系统互操作性的同时，确保AI代理行为的安全可信[8]。

六、未来发展趋势

随着智能体的不断普及与发展，MCP和以其为代表的智能体交互和增强协议前景广阔。未来的发展趋势将集中在安全集成、自适应服务发现、本地化、标准化等方面。

• 安全集成：针对目前存在的间接提示词注入和权限过载风险，未来的安全防御将从外部拦截转向协议层面的内生安全。MCP Server将集成更细粒度的身份验证（如基于硬件安全模块的私钥签名），实现无验证不执行。利用可信执行环境（TEE）对敏感工具调用进行封装，确保模型在处理私有数据时，数据流向在协议层透明且可审计。
• 自适应服务发现：未来的交互将不再局限于预定义的工具集，而是转向动态工具发现模式。模型将具备在运行时根据任务语义，在数以万计的MCP Server注册表中自动检索、评估并挂载相关服务端的能力，实现跨软件、跨平台的自动化闭环。
• 本地化：随着移动端大模型（On-device LLM）的普及，MCP将称为连接本地设备和云端算力的重要桥梁。未来的AI原生的操作系统可以将MCP作为内核级的通信协议，允许本地文件系统、传感器数据通过 stdio 等极低延迟的传输方式直接服务于模型。
• 标准化：MCP有望从单一厂商发起的草案演进为类似 HTTP 或 TCP/IP 的互联网基础协议。随着 Linux 基金会等中立机构的深度参与，未来的交互标准将超越文本指令，向多模态上下文（如流式音视频、三维空间状态）的标准交换迈进。

七、结语

本综述系统性地梳理了MCP的架构设计、演进历程及生态现状。研究表明，MCP不仅提升了工具调用的互操作性，更通过资源（Resources）和采样（Sampling）等原语，为智能体（Agent）提供了感知物理世界状态的标准化途径。然而，随着协议的普及，供应侧的恶意行为、运行时的安全逃逸以及维护阶段的配置偏移，构成了制约其大规模工业化应用的主要壁垒。

MCP的出现标志着大语言模型应用开发从插件式硬编码向通用协议化的重大范式转移，成功地在异构的模型能力、碎片化的数据源以及多样化的交互终端之间建立了一层标准化的语义层，将大模型打造成更通用的智能体。尽管安全挑战依然严峻，但标准化带来的生态复利将不可逆转地重塑人机协作的底层逻辑。未来，模型与外部世界的边界将进一步模糊，协议将成为连接数字逻辑与物理现实的核心纽带。

参考文献

[1] Anthropic. 2024. Introducing the Model Context Protocol. [Online]. Available: https://www.anthropic.com/news/model-context-protocol. [2] Anthropic. 2024. MCP Specification: Core Primitives and JSON-RPC structure. [Online]. Available: https://modelcontextprotocol.io [3] Nakano R, Hilton J, Balaji S, et al. Webgpt: Browser-assisted question-answering with human feedback[J]. arXiv preprint arXiv:2112.09332, 2021. [4] Yao S, Zhao J, Yu D, et al. React: Synergizing reasoning and acting in language models[C]//The eleventh international conference on learning representations. 2022. [5] Schick T, Dwivedi-Yu J, Dessì R, et al. Toolformer: Language models can teach themselves to use tools[J]. Advances in Neural Information Processing Systems, 2023, 36: 68539-68551. [6] OpenAI. (2023). Function Calling and Other API Updates. OpenAI Blog. [Online] [7] Ehtesham A, Singh A, Gupta G K, et al. A survey of agent interoperability protocols: Model context protocol (mcp), agent communication protocol (acp), agent-to-agent protocol (a2a), and agent network protocol (anp)[J]. arXiv preprint arXiv:2505.02279, 2025. [8] Hou X, Zhao Y, Wang S, et al. Model context protocol (mcp): Landscape, security threats, and future research directions[J]. arXiv preprint arXiv:2503.23278, 2025. [9] GitHub Blog. (2025). MCP joins the Linux Foundation: What this means for developers building the next era of AI tools and agents. [Online]. [10] Anthropic. (2025). One Year of MCP: November 2025 Spec Release and Anniversary Report. [Online]. Available: https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/ [11] AWS Open Source Blog. (2025). Shaping the future of MCP: AWS's commitment and vision. [12] Hasan M M, Li H, Fallahzadeh E, et al. Model context protocol (mcp) at first glance: Studying the security and maintainability of mcp servers[J]. arXiv preprint arXiv:2506.13538, 2025. [13] Guo H, Hao Y, Zhang Y, et al. A Measurement Study of Model Context Protocol Ecosystem[J]. arXiv preprint arXiv:2509.25292, 2025.= [14] Wu M, Chen P, Hong G, et al. MCPZoo: A Large-Scale Dataset of Runnable Model Context Protocol Servers for AI Agent[J]. arXiv preprint arXiv:2512.15144, 2025. [15] Song W, Zhong H, Ding Z, et al. Help or Hurdle? Rethinking Model Context Protocol-Augmented Large Language Models[J]. arXiv preprint arXiv:2508.12566, 2025. [16] Lei F, Yang Y, Sun W, et al. MCPVerse: An Expansive, Real-World Benchmark for Agentic Tool Use[J]. arXiv preprint arXiv:2508.16260, 2025. [17] JetBrains. (2025). AI Assistant Documentation: Connecting to MCP Servers. [18] Song H, Shen Y, Luo W, et al. Beyond the protocol: Unveiling attack vectors in the model context protocol ecosystem[J]. arXiv preprint arXiv:2506.02040, 2025. [19] Yang Y, Wu D, Chen Y. Mcpsecbench: A systematic security benchmark and playground for testing model context protocols[J]. arXiv preprint arXiv:2508.13220, 2025. [20] Guo Y, Liu P, Ma W, et al. Systematic analysis of mcp security[J]. arXiv preprint arXiv:2508.12538, 2025. [21] Zhao S, Hou Q, Zhan Z, et al. Mind your server: A systematic study of parasitic toolchain attacks on the mcp ecosystem[J]. arXiv preprint arXiv:2509.06572, 2025. [22] Wang Z, Zhang R, Liu Y, et al. Mpma: Preference manipulation attack against model context protocol[J]. arXiv preprint arXiv:2505.11154, 2025. [23] Lee Y, Choi W, Nam D. Supply Chain Threats in the MCP Ecosystem: Attack Vectors and Mitigation Strategies[C]//International Workshop on Security. Singapore: Springer Nature Singapore, 2025: 329-349. [24] Radosevich B, Halloran J. Mcp safety audit: Llms with the model context protocol allow major security exploits[J]. arXiv preprint arXiv:2504.03767, 2025. [25] Bhatt M, Narajala V S, Habler I. Etdi: Mitigating tool squatting and rug pull attacks in model context protocol (mcp) by using oauth-enhanced tool definitions and policy-based access control[J]. arXiv preprint arXiv:2506.01333, 2025. [26] Zhao W, Liu J, Ruan B, et al. When mcp servers attack: Taxonomy, feasibility, and mitigation[J]. arXiv preprint arXiv:2509.24272, 2025. [27] Fang J, Yao Z, Wang R, et al. We Should Identify and Mitigate Third-Party Safety Risks in MCP-Powered Agent Systems[J]. arXiv preprint arXiv:2506.13666, 2025. [28] Xing W, Qi Z, Qin Y, et al. Mcp-guard: A defense framework for model context protocol integrity in large language model applications[J]. arXiv preprint arXiv:2508.10991, 2025. [29] Kumar S, Girdhar A, Patil R, et al. Mcp guardian: A security-first layer for safeguarding mcp-based ai system[J]. arXiv preprint arXiv:2504.12757, 2025. [30] Ntousakis G, Stephen J J, Le M V, et al. Securing mcp-based agent workflows[C]//Proceedings of the 4th Workshop on Practical Adoption Challenges of ML for Systems. 2025: 50-55. [31] Jing H, Li H, Hu W, et al. Mcip: Protecting mcp safety via model contextual integrity protocol[C]//Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing. 2025: 1177-1194.