—1—
何为MCP
模型上下文协议（ModelContextProtocol）是一个开源协议，由Anthropic（Claude开发公司）在2024年11月25日发布[1]，旨在让大型语言模型（LLM）能够以标准化的方式连接到外部数据源和工具。它就像AI应用的通用接口，帮助开发者构建更灵活、更具上下文感知能力的AI应用，而无需为每个AI模型和外部系统组合进行定制集成。MCP被设计为一个通用接口，类似于USB-C端口，允许LLM应用以一致的方式连接到各种数据源和工具，如文件、数据库、API等。
—2—
为何MCP“突然”火了
MCP去年就提出了，为什么直到最近突然火了呢?笔者认为主要有三点原因：
首先是科技巨头的战略推动示范作用强大。2025年3月，OpenAI对其Agents SDK进行了重大更新，支持了对手Anthropic推出的MCP服务协议。随后，微软、阿里、百度等巨头纷纷表态“押注”MCP。这种从竞争到协作的范式转变，显然是对MCP最好的背书。
其次，MCP的出现及火热有其历史必然性，大模型如火如荼，由此衍生的AI Agent大爆发，催生出生态层面的基础设施需求。MCP天然的“一次开发，多模型兼容”特性，使其踩上了AI应用新范式的历史进程。
最后，MCP开源生态与工具链的日趋完善，为AI应用的寒武纪大爆发带来可能。自去年11月Anthropic 将 MCP 开源后，社区贡献呈指数级增长，MCP服务器从初始的数十个激增至 2025 年 2 月的 1000 + 个，覆盖数据库、云服务、机器人等领域。
—3—
MCP架构体系
根据Anthropic官方的介绍[2]，MCP 的核心采用客户端 - 服务器架构，支持主机应用程序连接多个服务器：
MCP 主机（MCP Hosts）：指需要通过 MCP 访问数据的程序，例如 Claude 桌面版、集成开发环境（IDEs）或 AI 工具。
MCP 客户端（MCP Clients）：协议客户端，与服务器保持一对一连接，负责传递主机的访问请求。
MCP 服务器（MCP Servers）：轻量级程序，通过标准化的 模型上下文协议（Model Context Protocol）暴露特定功能（如文件读取、API 调用等）。
本地数据源（Local Data Sources）：算机本地的文件、数据库及服务（如本地 MySQL 数据库、Excel 文件），可被 MCP 服务器安全访问。
远程服务（Remote Services）：互联网上的外部系统（如通过 API 提供的天气服务、云存储等），MCP 服务器可通过网络连接调用其功能。
—4—
MCP和Function Calling 之间的区别
从上一节的架构图中，最直观的感受是可能是MCP架构本质是一个代理？大模型（Host）直接调用本地数据源，或者远程服务不也行么，这不就是Function Calling已经在干的活儿么？
Function Calling是单一大模型的功能插件机制，一般由大模型厂商定义，不同大模型厂商之间在接口定义和开发文档上存在差异；需要开发者预先为特定模型定义可调用函数，依赖模型自身的上下文理解和结构化输出能力。
MCP 是面向智能体生态的基础设施层协议，类似于“AI 领域的USB-C 接口”，定义了LLM 与外部工具/ 数据源的通信格式，但不绑定任何特定模型或厂商，将复杂的函数调用抽象为客户端-服务器架构。
—5—
MCP的运作机制
让我们以一个实际的例子，来直观的感受MCP的运行机制与Function Calling的不同[3]。
当你提出一个问题时：比如现在几点了？
客户端将你的问题发送给 Claude大模型；
Claude 分析可用工具并决定使用哪些工具(一个或多个)；
客户端通过 MCP 服务器执行所选工具；
结果被发送回 Claude；
Claude 生成自然语言回复；
回复展示给你！
—6—
MCP的本质是提示词
上面的例子涉及到了MCP的灵魂，大模型是如何分析可用工具并决定使用哪些工具的？
根据官方提供的示例[4]，我们可以发现大模型是通过prompt来分析可用工具并决定使用哪些工具的。具体地：
通过提示词，向LLM解释了什么是MCP，并对每个MCP Server做了详细描述，包括传参格式；
将用户的问题和MCP结构化的提示词一起输入给LLM；
LLM得到用户的问题和MCP的一大堆信息后开始推理，最后选择了可以解决用户问题最合适的MCP Server，并将MCP Sever返回的结果整合成自然语言反馈给用户。
由于MCP的选择是基于prompt的，所以任何大模型其实都适配MCP，只要提供对应的工具描述，并做好训练。MCP不像传统的协议定义，它没有一个确定的数据结构，本质上还是基于提示词的协议。
—7—
从设计模式的角度看MCP的收益
MCP的出现恰好印证了软件行业那句颠覆不破的真理：
任何软件工程遇到的问题都可以通过增加一个中间层来解决。
从设计模式的角度看，MCP本质上是一个代理，带来如下好处：
标准化：MCP标准化了LLM访问外部服务的方式，简化了不同数据源和工具的集成。
模块化：MCP促进了模块化设计，允许独立开发和维护不同组件。
可扩展性：MCP使得添加新数据源或工具变得简单，做到了对扩展开放，对修改关闭。
—8—
MCP的挑战
如果在同一个上下文里挂载了很多MCP服务，模型很可能出现“幻觉”，选择了错误的工具，该如何解决？这个问题的本质是模型对上下文描述的理解能力到底有多高，可行的辅助工作包括在应用侧控制暴露工具的范围和数量。此外，可以选择创建帮大模型“筛选”工具调用的MCP Server，已解决上述问题。
此外，如果要接入一个第三方的MCP Server，在安全保障上，应该做哪些工作？目前，MCP对这方面的支持还处于起步阶段，并没有形成完备的方案。无论是协议层面的安全还是应用层面细粒度的授权、认证、控制，都需要进一步补强。
—9—
快速上手MCP的正确姿势
除了使用官网提供的快速上手例子[5]，更为推荐的方式是把 MCP 的相关文档和 SDK 代码复制进一个 AI 模型，比如DeepSeek 里，告诉它“帮我写个 MCP 服务器，支持某个功能”，它一般会给出一个可行的初始版本。然后你再手动做一些修改就行。
—10—
A2A协议是MCP的黄金搭档？
A2A（Agent2Agent）如同智能体间的“通用语言”，专注于解决多智能体协作问题。它通过标准化通信机制（如JSON格式的“智能体名片”），让不同开发者、供应商的AI能相互发现、对话与分工，例如在招聘场景中，主智能体可自动协调面试官、简历分析等专业智能体，高效完成复杂任务。而MCP（模型上下文协议）则像智能体的“工具百宝箱”，统一了AI与外部工具、数据源的交互接口。
二者的结合堪称“黄金搭档”：A2A管协作，MCP管工具。在AI智能体从“单兵作战”迈向“群体协作”的进程中，谷歌A2A协议与Anthropic MCP协议的互补组合，正成为打通AI生态协作壁垒的关键钥匙！
