MCP is all you need

上周六，我受邀参加了由 TGO 鲲鹏会 举办的全球科技领导力大会（GTLC），回到了熟悉的深圳，做了一场题为《MCP 的发展与未来》的分享。

活动举办很成功，现场观众很热烈，我想把分享内容，整理成文字，与你共享。

我与 MCP

为什么讲 MCP？

1.MCP 最近三个月热度持续上涨，已经是 AI 行业实际意义上的通信标准，充当了 AI 应用与外部扩展之间 连接器 的角色。

2.MCP 虽然发布才半年，却已形成行业共识，现在各行各业都在积极接入 MCP，包括知名的大模型客户端、AI 应用，以及通过 API 开放能力的各类服务商、数据平台等。

3.MCP 是 AI 高速发展近三年以来，第一个，也是最大的一个平台型机会，发展潜力无限。

为什么是我来讲 MCP？

1.我在 MCP 发布之初，就坚定看好，熟读了 MCP 的设计文档，在社交平台发表多篇对 MCP 的解读和对其未来发展的预判，算是一个 MCP 布道者 的角色。

2.我基于 MCP 开发过服务器、客户端、智能体，设计过 MCP 传输机制，做过 MCP 应用市场和 MCP 云端部署。是实战经验极丰富的 MCP 开发者。

3.我做的 MCP.so 是收录 MCP 服务器数量最多的 MCP 应用市场，谷歌搜索 MCP 关键词多次排名第一，月访问量超百万，被 a16z 市场报告引用。

因此，当 GTLC 主办方邀请我来分享时，我很快答应了下来，我希望在聊 AI 的专业场合，让更多的朋友了解 MCP，积极拥抱 MCP。

MCP 是怎么火起来的

很多人知道 MCP 最近很火，但不知道 MCP 为什么会火，不知道 MCP 是怎么火起来的。

其实，MCP 从发布到爆火的过程，是有迹可循的，主要经历了三个阶段。

1. 发布（2024/11）

MCP 是在 2024 年 11 月 25 日发布的，可以说是横空出世。MCP 发布的当天，国内外媒体争相报道，用"震惊，炸裂"来形容 MCP 的诞生，声称 AI 行业马上要“变天”了。

MCP 发布之初，官方实现了十几个经典的 MCP 服务器，包括网页内容抓取、时间处理、数据查询等类别，并在 Claude 桌面版实现了对 MCP 服务器的接入。

MCP 在发布后的两个月时间内，处于相对沉寂的状态，偶尔有一些新的 MCP 服务器发布和 AI 应用宣布支持 MCP，但整体讨论热度不高。

2. 起势（2025/01）

直到 2025 年 1 月底，MCP才开始出现热度上升的势头，主要跟几个知名的 AI 产品的功能迭代有关。包括 Cursor、Windsurf 等 AI 编辑器作为客户端支持了 MCP，Perplexity、Figma 等厂商发布 MCP 服务器开放了部分能力。

3. 爆火（2025/03）

MCP 真正爆发是在 2025 年 3 月，引爆点是 Manus 的发布。

Manus 于 2025 年 3 月 6 日发布，这一通用智能体产品，可以模拟用户操作浏览器的行为，通过 AI 执行各类自动化任务。一经发布迅速火遍全网，成为继 DeepSeek 之后又一个 AI 标杆。

Manus 火了之后，开始有人分析 Manus 的实现原理，推测其实现过程中用到了大量的 MCP 服务器。比如 Manus 的联网搜索、浏览器操作、文件创建、命令行调用等工具，跟 MCP 服务器的行为模式高度吻合。虽然据我所知，Manus 最初的功能实现，并没有用到 MCP 服务器。但 Manus 的出圈让 MCP 迅速火了起来，推动了 MCP 生态的发展。

通过谷歌搜索趋势分析，可以印证上述 MCP 发展的三个阶段。“MCP Server”关键词的搜索量超过“GPTs”是在 3.6 号，正是 Manus 发布的日期。

底层逻辑

深入剖析 MCP 从发布到爆火的三个阶段，我们可以归纳其中的底层逻辑：

MCP 从发布到流行的过程完美诠释了双边市场的发展规律：初期面临典型的“鸡蛋悖论”——缺乏应用支持导致服务器开发意愿不足，缺乏服务器又让应用缺乏接入动机。然而，明星效应 的介入打破了这一僵局，头部 AI 应用的率先支持产生了示范作用，启动了双边效应，使得应用端和服务器端开始相互促进。随着生态参与者增多，网络效应 逐渐显现，每个新加入者都为整个网络增值，最终形成了正向循环，推动 MCP 生态实现爆发式增长。

MCP 有哪些应用场景？

talk is cheap. MCP 光讲概念行不通，还是要回到实际应用价值。不管是作为企业，还是独立开发者，都需要知道 MCP 可以怎么用，在哪些场景下用。

MCP 落地场景

1. 企业 AI 工作台

AI 行业在高速发展，很多企业在积极拥抱 AI。举个例子，比如你的公司需要开发一个 AI 工作台，以对话的方式，对接内部各个 OA 系统，包括 HR 招聘系统、CRM 客户管理系统、ERP 采购系统等。

按照我们熟知的开发流程，在开发 AI 工作台时，你需要去跟各个 OA 系统的负责部门对接，让他们开放 API，或者 RPC 接口，然后你按照接口文档接入。这个过程有很高的沟通成本，接入效率低下。

如果基于 MCP 去实现这个 AI 工作台，流程就简单多了：各个 OA 系统以 MCP 服务器的形式开放功能，AI 工作台作为 MCP 客户端，通过配置接入功能。你不需要再去请求哪个部门开放 API，而是由别人主动发布 MCP 服务器，接入到你做的 AI 工作台。用一个经典的词来理解，叫做：控制反转。

2. 个人 AI 助手

使用过 Spotlight 类应用的朋友应该知道，此类定位是个人助手的产品，需要支持插件扩展各种类型的功能。比如我在用的 uTools 就允许用户安装插件，这些插件可能是 uTools 官方开发的，也可能是第三方开发者开发的。

而面向个人的 AI 助手，基本逻辑类似，只是应用本身和接入的插件，都集成了 AI 能力。如果每个 AI 助手都定义一套标准，让开发者按照这套标准去写插件，毫无疑问，有很多的重复开发工作。

MCP 天然适合这种需要通过 插件扩展 功能的场景，个人 AI 助手可以接入 MCP 成为客户端，把 MCP 服务器作为要扩展的插件，这样就可以快速集成大量的功能，用户的使用频次就上去了。

3. 开放平台 / 智能体 / AI Coding

理论上，任何做开放平台的、做智能体的、做 AI Coding 产品的企业或个人，都可以基于 MCP 开放自身的数据或服务，或者通过 MCP 服务器扩展自身的功能。在过去一段时间，我们看到了很多典型的例子，比如：

• 供应：高德地图 / MiniMax / Perplexity
• 路由：Zapier / Apifox
• 托管：Cloudflare / 阿里云
• 使用：Same / 扣子空间

通过 a16z 发布的 MCP 市场地图，我们也看到很多产品，在各个领域和场景，正在积极地拥抱 MCP。

从宏观层面了解了 MCP 的发展路径和应用场景之后，接下来我们以科普的形式，再介绍一下 MCP 的诞生背景和工作原理。

什么是 MCP？

MCP 全称 Model Context Protocal，中文译作 模型上下文协议

从字面意义上理解，MCP 面向的对象是大模型（Model），主要目的是给大模型传递上下文（Context）。

MCP 的本质是应用层协议（Protocal），跟我们熟知的 TCP/IP，HTTP 协议类似。

为什么要给大模型传递上下文

众所周知，大模型是通过历史数据进行训练的，这些数据在训练时就已经固定。模型训练完成后，其知识就停留在训练时的状态，无法自动获取训练之后的新信息。也就是说，大模型的“静态知识”与动态世界的“实时需求”之间存在根本性矛盾。

为了解决大模型获取实时信息的问题，一般需要应用给大模型传递上下文。

围绕“如何给大模型传递上下文”这一问题，诞生了几种主流的解决方案：

1. 记忆存储

记忆存储通常由大模型客户端实现。客户端会将用户与大模型的每轮对话内容记录下来，并设定一定的记忆容量。当用户提出新问题时，系统会从记忆库中提取与当前对话相关的信息，作为补充上下文提供给大模型，从而使模型的回答更加连贯，就像赋予了模型“记忆”能力。

2. RAG

RAG （Retrieval-Augmented Generation，检索增强生成）是一种让大模型获取实时信息的重要技术。其工作原理是：当用户发出提问时，AI 应用通过向量检索、关键词匹配等方式，从外部知识库或数据源中搜索相关信息，再把检索到的信息作为上下文提供给大模型，让大模型基于补充的信息进行回答。

3. Function Calling

Function Calling 是一种让大模型执行特定任务的机制，它允许大模型将自然语言请求转换为具体的函数调用，由应用调用外部工具，并返回结果。 其工作原理是：当用户发出提问时，应用会将集成的函数列表作为上下文发送给大模型。大模型根据用户输入判断应调用的函数，并生成相应的调用参数。随后，应用执行该函数并将结果发送给大模型，作为补充信息供其生成最终的总结或回答。

4. MCP

我们可以认为，MCP 是在 Function Calling 的基础上做了进一步的升级和抽象，目的是让应用更加简单、高效、安全地对接外部资源，更好地为大模型补充上下文信息。

用一张图来快速感受一下，给大模型传递上下文这件事的重要性。

在 ChatMCP 网页版对话框问“深圳明天下雨吗”，大模型因为无法获取实时的天气信息，不能回答这个问题。而在挂载高德地图 MCP 服务器之后，通过调用其提供的天气查询工具，查询到了实时天气，作为上下文信息补充给大模型，大模型就能回答这个问题了。

理解 Function Calling

Function Calling 是 MCP 的基础，工作原理包含两个基本步骤，分别是：

1. 工具选择 Pick tool
2. 工具调用 Call tool

Function Calling 最早由 OpenAI 提出，后来成为了 AI 应用集成外部扩展的一种标准。

OpenAI 官方文档给出的 Function Calling 的交互流程如下：

可以看到，这个例子跟我们前面演示询问“深圳明天下雨吗”的例子类似。

也许有人会问：

既然有了 Function Calling 为什么还需要 MCP？

MCP 跟 Function Calling 有什么区别？

为什么需要 MCP？

Function Calling 一定程度上解决了给大模型传递上下文的问题，但也存在着不小的局限性。在解释 Function Calling 局限性的同时，我们可以跟 MCP 做一个简单的类比。

1. Function Calling 只是交互范式，MCP 是协议标准

Function Calling 只定义了 AI 应用、函数工具、大模型三者之间的基本交互流程，并没有规定具体的交互细节，也没有约定工具调用的输入输出参数。

而 MCP 作为协议标准，有更高级别的定义与约束，为 AI 应用集成外部工具定义了统一的接口规范、参数格式和通信契约。

2. Function Calling 只能定义工具，MCP 能定位更丰富的特性

Function Calling 只能在 AI 应用内定义函数工具，通过工具调用执行操作或获取外部数据。

而 MCP 除了可以在 AI 应用外的 MCP 服务器定义函数工具，还支持提示词、资源特性，允许 AI 应用通过 MCP 服务器外挂更多的数据或服务。

3. Function Calling 实现无约束，MCP 功能可复用

AI 应用基于 Function Calling 集成外部扩展，主要靠 AI 应用编码实现，实现方式无约束，不同的 AI 应用有不同的实现方案，无法复用。

而 MCP 可以让对接双方都可复用功能。MCP 服务器只需实现一次，就可以被任意的 AI 应用集成。AI 应用只需接入一次 MCP，就可以集成任意的 MCP 服务器。

用一张图来直观感受一下，使用 MCP 可以显著降低 AI 应用集成外部扩展的复杂度。

我们也可以通过 LSP 协议来类比。

LSP 遵循了软件工程中"关注点分离"的原则，并实现了"一次实现，处处可用"的工程愿景，成功推动了编辑器生态的标准化和可扩展性。MCP 则延续并拓展了“协议驱动”的理念，跟 LSP 有限的语言服务器数量相比，MCP 服务器的规模要大很多，将为 AI 应用构建出更繁荣、更开放的服务生态。

快速理解 MCP

可以参考笔记本电脑的 扩展坞 来快速理解 MCP。

AI 应用就像一台只有有限接口的笔记本电脑，无法直接访问外部数据或服务。MCP 则扮演着"扩展坞"的角色，通过标准化的协议接口，为 AI 应用提供连接各种外部系统的能力。

通过 MCP，AI 应用不再受限于大模型的能力边界，而是能够像连接了扩展坞的笔记本电脑一样，灵活地接入各种外部系统，实现更强大的功能。

这是一个三方受益的方案。

1. 用户。按需配置各种类型的 MCP 服务器，实现各种需求
2. 开发者。只需开发一次 MCP 服务器，被用于各种场景
3. 厂商。以 MCP 服务器开放服务，获得更多的接入量，增加 ToB 收入

MCP 诞生的意义

我们可以用“秦始皇统一六国”的例子来简单类比 MCP 诞生的意义。战国时期，七国各自为政，使用不同的文字、货币和度量衡，不同小国之间交流困难，经济、文化、科技发展缓慢。秦始皇统一六国后，为了方便管理，统一了文字、货币和度量衡。从此，各国之间交流变得方便，经济、文化、科技发展迅速。

MCP 一定程度上也可以理解为 AI 时代的 HTTP 协议。

正如 HTTP 协议在 30 多年前开启了 Web 时代，让互联网日后真正走进了千家万户，改变了人类获取信息和交流的方式。我们可以预见，MCP的出现标志着一个全新的 AI 原生应用生态正在形成，由此引发的信息变革将比 Web 时代带来的更加深远。

了解完 MCP 的诞生背景和时代意义之后，我们再从技术的角度学习一下 MCP 的核心架构和设计哲学。

MCP 核心架构

MCP 并不复杂，这个协议的核心是定义了三个角色并明确了它们之间的协作模式。

MCP 的本质是计算机领域常见的 C/S （客户端/服务器）架构。引入了主机的概念，组成了其核心的“主机-服务器-客户端”架构。

• 主机

主机是 MCP 的中心枢纽，它既是用户与大模型直接交互的终端，又是协调外部资源的调度中心。

• 服务器

服务器是 MCP 的核心组件，主要负责对接外部数据或服务，并通过标准的数据格式将响应内容发送给客户端。

我们可以将服务器理解为外部数据或服务的一个代理网关，所有的数据交互都通过该代理进行。

• 客户端

客户端是主机与服务器之间的桥梁。客户端“寄生”于主机中，由主机创建并进行调度，客户端与服务器进行连接，从而实现与外部数据或服务的交互。

MCP 应用举例

通过一个简单的例子来理解 MCP 的架构。

在 Claude 桌面版写入两个 MCP 服务器配置：

然后通过 Claude 对话框发送：“我想从广州开车去武汉看樱花，请帮我规划一下路线，把行程计划保存到我的笔记”

可以看到，Claude 通过调用 MCP 服务器内部的工具获取了地理信息，输出了行程规划路线，最后把内容保存到了 Flomo 笔记。

在这个例子中，Claude 是 MCP 主机，在启动的时候，就创建了两个 MCP 客户端，分别与配置的两个 MCP 服务器保持连接，并在后续的过程中向两个 MCP 服务器发起了工具调用。

MCP 连接生命周期

理解 MCP 连接生命周期可以帮助我们更好地开发 MCP 服务器和 AI 应用。

MCP 连接生命周期跟 TCP 的三次握手、四次挥手有点类似，也要经历建立连接、交换消息、断开连接等阶段。

MCP 基于 JSON-RPC 2.0 实现消息传输，MCP 的传输机制是可插拔的，支持 stdio、websocket、HTTP 等方式，你也可以自定义传输机制。

MCP 服务器特性

MCP 服务器支持三大特性：提示词、资源、工具。

1. 提示词

你可以把常用的提示词封装进 MCP 服务器，在任意接入了 MCP 的 AI 应用中使用，比如在 AI 应用对话框中，输入 @ 符号，快速插入在 MCP 服务器导出的提示词。

2. 资源

你可以在 MCP 服务器内置文档、数据表结构等资源，在任意接入了 MCP 的 AI 应用中，通过下拉选择等方式，快速导入 MCP 服务器中的资源。

3. 工具

你可以在 MCP 服务器定义工具，执行特定任务并返回内容，在任意接入了 MCP 的 AI 应用中，通过工具调用的方式，外挂数据或服务。

MCP 生态

MCP 已经成为行业共识，生态也在迅速发展。

结合已有的产品形态和发展趋势，我畅想了一下 MCP 未来的生态，应该会是这个样子：

MCP 生态的核心组成包括以下几部分：

1. 服务器：MCP Servers

MCP 服务器正在以非常快的速度增长，就跟当前互联网存在海量 API 一样，未来 MCP 服务器应该也是海量的，每个服务器对接不同类型的数据或服务，提供各式各样的功能。

2. 应用市场：MCP Marketplace

为了更好地收集、分类和分发 MCP 服务器，我们需要一个 MCP 应用市场。

MCP 应用市场存在的意义和价值，是提供一个中心化的渠道，让 MCP 服务器与使用者之间可以更好地连接。在一定程度上，可以将其类比为 App Store 和 Google Play 在移动应用生态中的定位。

比如 MCP.so 就是这样的 MCP 应用市场，其核心功能包括 MCP 服务器的收录、分类、搜索，提供云端部署、调试、对话等服务。

3. 服务路由平台：mcprouter

MCP 是分布式、去中心化的。用户当前使用 MCP 服务器的主要方式，是把代码拉到电脑本地运行。对用户而言，这种方式的使用成本较高（需要安装环境、配置、运行）。 因此，建立一个中心化的 MCP 路由平台很有必要。

MCP 路由平台的核心功能是对接 MCP 应用市场上的高质量 MCP 服务器，通过云端部署的方式，对 MCP 服务器进行托管，再对外提供统一的接入方式，所有原来需要发给 MCP 服务器的请求都通过 MCP 路由平台进行代理转发。

MCP 服务路由平台的核心价值，包括：

• 云端部署，并发 + 多租户
• API 网关，统一鉴权
• 供应链整合，统一计费

一定程度上可以类比硅基流动、OpenRouter 等大模型路由平台。

跟 OpenRouter 对接有限的大模型不同， MCP路由平台对接的 MCP 服务器的数量级更大，且每个 MCP 服务器一般都内置多个工具。如果把每个工具作为一项原子能力，MCP 路由平台将会是一个能力工厂，可以作为 Agent 基础设施，让 Agent 开发像搭积木一样简单。

4. 消费终端： chatmcp / ai agents

所有接入 MCP 路由平台的 AI 应用，都可以作为 MCP 生态的消费终端。包括 AI 编辑器、对话客户端、智能体等。

5. 命令行工具：omcp

大模型领域有一个知名的命令行工具：ollama，为用户提供了便捷的大模型本地部署与管理能力，使得用户能够在本地环境中快速下载、运行和切换多种开源大模型，极大地降低了大模型的使用门槛。

参考 ollama，我们也可以实现一个 MCP 命令行工具，比如叫做：omcp，帮助用户在本地管理 MCP 服务器，实现 MCP 服务器的安装、配置、运行等操作，降低 MCP 服务器的使用门槛。同时，MCP 命令行工具也可以连接云端的 MCP 路由平台，实现用户免安装使用 MCP 服务器的需求。

总结

本篇文章系统性介绍了 MCP 的诞生背景、工作原理、协议架构和生态系统，希望能帮助各位建立一个全局观，祛魅 MCP，知其然、知其所以然。

MCP 的发布，加速了 AI 行业的发展，以智能体为代表的 AI 应用也将迎来大爆发。对于创业者而言，有很多的机会，唯有躬身入局，扬帆启航，方能不辜负这个时代。

MCP is all you need. 祝福每一位拥抱 AI 的同行者。

文章来自于“艾逗笔”，作者“idoubi”。