MCP是什么？MCP很好，但它不是万灵药

什么是MCP？

MCP是一种开放的技术协议，旨在标准化大型语言模型（LLM）与外部工具和服务的交互方式。你可以把MCP理解成是一个AI世界的通用翻译官，让AI模型能够与各种各样的外部工具“对话”。

为什么需要MCP？

在MCP出现之前，AI工具调用面临两大痛点：

第一是接口碎片化。每个LLM使用不同的指令格式，每个工具API也有独特的数据结构。不同模型调用相同功能API接口时，需要重新实现一次。

如：百度地图发布的大模型工具调用接口，和高德地图发布接口，可能完全不一样。没有统一的市场和生态，只能各自为战，各自找开发者接各自的大模型。

各家厂商训练出的智能体大模型，任务编排能力参差不齐，标准不一致

第二是开发低效。开发者需要为每个组合编写定制化代码；这种为每种模型进行定制化的API接口，不仅成本高昂且难以扩展。

如果有使用过各大模型（如：DeepSeek、元宝、千问等）API接口就知道，各类大模型的参数和返回值都存在较大差距。

如：面对相同的函数和工具，每个开发者都需要重新从头造轮子，按照自己想要的模型回复格式重新撰写、调试提示词。

而MCP则采用了一种通用语言格式（JSON - RPC），一次学习就能与所有支持这种协议的工具进行交流。不管什么LLM，用上它就能使用工具/数据了。

MCP的整个过程

图片来源：ailydoseofds

首先需要在主机上自动或手动配置 MCP 服务，当用户输入问题时， MCP 客户端让 大语言模型选择 MCP 工具，大模型选择好 MCP 工具以后， MCP 客户端寻求用户同意（很多产品支持配置自动同意），MCP 客户端请求 MCP 服务器， MCP 服务调用工具并将工具的结果返回给 MCP 客户端， MCP 客户端将模型调用结果和用户的查询发送给大语言模型，大语言模型组织答案给用户。

MCP的工作原理

MCP的技术架构可以简单理解为一个由三个核心部分组成的系统：MCP Host、MCP Client和MCP Server。这三部分共同工作，让AI模型能够顺畅地调用所有支持这种协议的工具。

大模型（如Claude或GPT）理解用户指令，规划任务步骤，判断何时需要使用哪些外部服务，并最终整合信息为用户提供答案。大模型，例如DeepSeek，如果不能联网、不能操作外部工具，只能是聊天机器人。除了聊天没什么可做的。

Agent系统（框架），就像是大模型的手和脚，执行大模型的指令，去执行各项任务。包括MCP Host和MCP Client。

MCP则是Agent使用的标准化通信协议，它不做决策，只负责按照Agent的指示，以统一的格式和协议与各种服务提供商通信（MCP Server）。

AI Agent（人工智能体）又是什么？简单来说AI Agent就是大模型+Agent系统+MCP。

是一个能够感知环境、进行分析、决策，并执行动作以实现特定目标的智能系统。能够主动完成一项复杂的任务。

而一旦大语言模型能操作工具，例如：联网/地图/查天气/函数/插件/API接口/代码解释器/机械臂/灵巧手，它就升级成为智能体Agent，能更好地帮助人类。今年爆火的Manus就是这样的智能体。

所以，AI Agent不只是模型，还有规划、工具使用这些能力。

其实严格来说，AI Agent =  大模型(AI)+Agent（MCP是Agent的一部分，是Agent与外部通信的统一、标准化的协议，把MCP单独拎出来是方便对MCP进行说明）。

大模型（AI）是理解用户意图、规划任务、拆解步骤，同时决策什么时候执行什么工具，已达到预期的目标。

Agent是一个执行体，它负责执行AI下达的明确的、单一功能的指令，如执行计算机工具进行数学计算。

而MCP是一种技术框架，其中最核心的就是MCP Client和MCP Server的协议转换，以使Agent能够使用统一、标准的协议调用所有支持这种协议的工具。而无需重复开发工具，让Agent能通过配置化方式集成各种需要的工具。

MCP的技术架构由三个核心组件构成：

MCP Host （执行环境） 是程序的运行空间。它提供了服务程序的连接、启动、停止等进程的管理工作，即管理 MCP Server 的生命周期（启动、连接、关闭）。

在实际应用中，Claude Desktop、Cursor这类AI应用就是典型的Host，它们提供了用户与AI交互的界面和环境，同时也为Agent和MCP Client提供了运行空间。

通常定义一个MCPServerManager类，管理多个MCP server。而每个server类，又创建对应的MCP client与对应的MCP server 建立连接。

class MCPServer:
    """Represents a single MCP server instance."""

    def __init__(self, config: MCPServerConfig):
        self.config = config
        self.client: Optional[MCPClient] = None
        self.status: str = "stopped"
        self.tools: List[MCPTool] = []
        self.pid: Optional[int] = None
class MCPServerManager:
    """Manages multiple MCP servers."""

    def __init__(self, server_configs: Dict[str, MCPServerConfig]):
        self.servers: Dict[str, MCPServer] = {}

        for server_name, config in server_configs.items():
            self.servers[server_name] = MCPServer(config)

MCP Client （通信枢纽） ，通过标准化的MCP协议，获取并调用MCP server工具。它不参与决策，不理解任务本质，只负责按照Agent的指示，以正确的参数格式和协议与各种服务提供商通信。MCP Client是一个纯技术组件，处理通信协议、数据格式转换和连接管理等底层问题。实现 MCP Client 与 MCP Server 的通信（支持 stdio 和 SSE）。

class MCPClient:
    """Client for communicating with MCP servers."""

    def __init__(self, transport: Transport):
        self.transport = transport  # 协议传输 支持 stdio 和 SSE
        self.initialized = False
        self._message_id = 0

MCP Server （服务终端） 类似外部服务提供商，每一个服务供应商都负责特定类型的服务。有的提供数据分析，有的提供信息检索，还有的提供内容生成。在MCP架构中，每个Server提供特定类型的功能：工具、资源或提示。

在MCP出现之前，当用户需要完成某项任务时，必须自行思考完成这项任务需要使用哪些工具，以及如何使用这些工具，需要熟悉各个工具的使用。例如，预订会议室需要登录内部系统A，获取财报需要使用系统B，订餐则需要拨打餐厅电话。开发者则需要为每个工具单独编写代码，效率低下且难以维护。

在MCP之后，用户只需使用一个统一的方式，就能以相同的方式获取所有的服务。开发者也只需实现一次MCP接口，就能让AI系统与所有支持该协议的工具进行交互。

MCP不是Function Call的替代，而是基于Function Call的工具箱

很多人认为，MCP是对传统Function Call的一种替代。

而实际上，两者并非替代关系，而是紧密合作的关系。

Function Call是大型语言模型（LLM）与外部工具或API交互的核心机制。它是大模型的一个基础能力，就是识别什么时候要工具，可能需要啥类型的工具的能力。它是大模型的一个基础能力。

而MCP则是工具分类的箱子。因此MCP不是要取代Function Call，而是要在Function Call基础上，联合Agent一起去完成复杂任务。

如果把整个工具调用的流程剖析开来，实际是“Function Call + Agent + MCP系统的组合。”用一句话说清楚：大模型通过FunctionCall表达，我要调用什么工具，Agent遵循指令执行工具的调用，而MCP则是提供了一种统一的工具调用规范。

不过在过去，有人会把这一整套Function Call+ Agent +API的模式叫作一个Function Calling，所以会引起混淆。

通过区分Function Call和MCP，我们可以清晰地看出，MCP并不负责决定使用哪个工具，也不进行任务规划或理解用户意图。这些是大模型层面的工作。MCP只是提供了一个统一的工具接口，成为产业内认可的工具调用标准协议。

MCP的开发难题与市场乱局

今年2月以来，AI开发社区掀起了一场“MCP淘金热”。在没有官方应用商店的情况下，目前发现全球MCP Servers有3万多个工具自发接入MCP协议。

但是，现在市面上的MCP可用性太低。MCP市场正经历着典型的技术炒作周期。

如今几万个MCP工具中，真正具备实用价值的不足二成。腾讯开发者victorhuang的观察一针见血：“很多MCP，实际上都没有真的做MCP。”

我真实的体验也是一样，试用Cursor和TREA等AI编程工具，自己开发AI智能体（其实也不能算是真正的AI智能体，而是采用Langgraph的工作流）。很多所谓的MCP Servers存在严重问题，从简单的配置错误到完全无法使用的情况不等。这些工具有的是因急于上线而未经充分测试，有的则是开发者实验性质的产物，从未打算投入实际使用。

反正我还没有真正的使用过一个有用的MCP Server，都是自己从新开发的。

而更严重的问题是，其中大部分MCP可能市场根本就不需要。大家发现MCP有市场，就做了一个简单封装，但它本来没有什么特别的用。

比如说，现在MCP提供的搜索服务可能就有数十家之多。而在“Evaluation Report on MCP Servers”论文中，作者对此类服务做了一些评测，发现水平差异非常大。其中像Exa Search内容关联又不准，时间相关性又差。

而且，现在MCP Server也缺乏评价体系。这导致Agent无法依靠可靠的指标来选择最适合的工具，只能通过反复尝试或基于模糊的描述做出决策。这种低效的选择过程不仅浪费计算资源，还延长了任务完成时间，降低了用户体验。

我个人在使用Tavily MCP Server时也是存在类似的问题，搜索的准确性和时效性有待提升。而且需要反复的尝试和调优，浪费大量的时间和token，效率较低，为了达到搜索质量的效果，反复调试参数。

市面上也存在大量参差不齐，参数和返回值、tools命名各异的Tavily MCP Server。让我对MCP的实际能力提出了怀疑，并没有市场所说的那样万能。

因此，那些最成功的AI应用往往采取了相反的路径—它们不是提供更多的工具，而是提供更精准的工具。比如Manus，在MCP已经存在的情况下，其实根本没有采用这一协议，而是选择内建应用。因为它只有几十种工具，为了提高调用准确度和稳定性，不如自己去单独写。

而Cursor这样的代码编辑器已经内置了最常用的开发功能，使得大多数外部MCP工具显得多余。在作者使用Cursor时，虽然开启了几十个MCP，但真正能用到的凤毛麟角。

所以，在使用Cursor和TREA时，我也很少使用其他MCP Server，内置的工具基本能完成所有任务。

但MCP市场当前的混乱状态并非失败的标志，而是任何新兴技术生态系统必经的成长阶段。

MCP很好，但它不是万灵药

很多人期待MCP能够一劳永逸的自动改善AI系统的决策能力，或者提升任务规划的效率。但这种诉求实际上是在错误地将工具与工匠混为一谈。

因此，当前对MCP的批评存在一个根本性的认知错位—人们期待一个通信协议能完成智能系统的全部工作。

Agent调用工具的效果受到诸多因素制约—工具选择能力、任务规划能力、上下文理解能力—而这些能力的培养与提升，都不在MCP的职责范围内。MCP只承诺提供统一的工具接口，而不承诺这些工具将被如何选择和组合。

在技术演进的长河中，我们总是倾向于寻找一劳永逸的解决方案，一种可以解决所有问题的银弹。但如同软件工程中著名的“没有银弹”论断，AI工具调用领域同样不存在万能的解决方案。

一个真正强大的AI系统需要多个精心设计的组件协同工作：大语言模型提供基础理解和生成能力，Agent框架负责任务执行逻辑，而MCP则专注于提供统一的工具调用接口。

零基础入门AI大模型必看

陆陆续续也整理了不少资源，希望能帮大家少走一些弯路！

无论是学业还是事业，都希望你顺顺利利 ！

1️⃣ 大模型入门学习路线图（附学习资源）

2️⃣ 大模型方向必读书籍PDF版

3️⃣ 大模型面试题库

4️⃣ 大模型项目源码

5️⃣ 超详细海量大模型LLM实战项目

6️⃣ Langchain/RAG/Agent学习资源

7️⃣ LLM大模型系统0到1入门学习教程

8️⃣ 吴恩达最新大模型视频+课件

以上大模型资料包的内容都整理在了我的gzh里，【小灰熊大模型】回复【6】自动掉落，都是🈚️尝分享，可以自取~