是时候去问CTO了，咱的AI产品要不要封装MCP？_风闻

原创：杨荟博士（Istari企业智能创始人），亲爱的数据（谭婧）

第一节，当下是智能体蛮荒时期，

为什么MCP协议火了？

大家对智能体的好感，

被Manus这种操作电脑的智能体，

加了一把柴火。

还有深度研究（DeepResearch），

这种擅长信息检索、汇总、推理、

定性定量分析的智能体产品，

也带了好头，

好产品起到示范作用，带动智能体概念。

进而带动MCP讨论热度。

当然，反对的声音也很大，

观点1.

两个月后就有更好的模型出现，

我们不应该在“脚手架”上花更多时间精力。

观点2.

现在的模型已经能读懂API文档了，

能生成调用API的代码了，

为啥还要出来个MCP？

观点3.

人来操作API都有信息安全问题，

何况智能体？

观点4.

MCP出来大半年了，

大的服务商没有几个真的为它适配。

对待垃圾产品应该一致吐槽，

真正有价值的东西，

表面看似吐槽，本质是辩论：

为什么MCP如此重要？

先讲个好理解的，

都知道，数据对大模型非常重要，

除了已经“喂给”模型的数据，

推理时，访问到外部的数据也非常重要，

但唯一是“喂进去训练”这个形式吗？

肯定不是。

但是外面接入数据哪里那么容易。

且不只数据，文件，工具，

往大了说某个系统的能力，

都可以“接入”给大模型。

“接入”的本质是“集成”，

当下有关AI的集成高度碎片化，

这是一件极为糟糕的事情。

各界人士只要想让AI有个好发展，好前程，

都想让局面有个根本型的改变。

MCP应运而出，

而且会在这个方向上迅速迭代。

任何开放协议之类的东西天然受到开源社区欢迎，

后面我们还会介绍。

Anthropic公司推出MCP，

确实为模型发展“计深远”，

OpenAI紧跟而上，

也显示了其胸怀。

北美AI模型的两架马车，

均拿出了态度和行动。

现在真有点，

且看下回分解的味道了。

我回想起了汉尼拔的那句名言：

“要么我找到路，要么我开辟路。”

前面4个观点后文均有反驳。

还有一个有趣的问题，

谁在研究MCP？

第一波人铁定是程序员，

程序员是API最直接的“消费者”，

而第二波关心的MCP人才更关键——

创业公司创始人，产品负责人，技术负责人。

因为他们得决定一件事——

“我的AI产品要不要也用MCP？”

第二节：MCP是啥？

MCP，全称Model Context Protocol。

模型上下文协议，

热门词汇，

不能慢一步。

吃瓜最前线，

若想挖得深，

“USB插头”“桥梁”，

这种比喻就潦草了。

“MCP是啥”这个问题，

我也问了GPT，千问，豆包不少问题，

MCP这个话题，

幻觉程度前所未有，高达50%。

看来对于互联网上还没有形成定论的新兴事物，

大模型也似懂非懂。

最好理解两样东西：

1.API

2.智能体

在MCP出现之前，

早期的技术协议已经做了类似的工作，

本质上，协议解决了软件之间的连接。

API定义了软件之间如何通信，

智能体想“看”地图，

不用再造一套地图服务，

人家高德导航做得已经很好了：

1路线规划与导航

2实时交通信息

3位置搜索

4地点详情查询

5公共交通查询

6打车服务对接

7停车场查询与导航

8天气与环境信息

9吃喝玩乐推荐

10周边公共交通工具推荐

那想“调用”高德导航里某种服务怎么办？

以前是APP之间调用，

比如：滴滴打车可用高德实时交通信息优化路线，

只是一个比方，其实滴滴并不舍得这笔费用，

滴滴有自己的地图部门，

我认识他们部门的算法小哥哥，

怎么说呢，滴滴地图的服务一言难尽……

话说回来，

对开发者来说，高德是一套功能。

对智能体来说，高德里的信息，功能，它都需要，

高德是智能体的“工具”，

也是MCP Server，

MCP官网说了，

有三种MCP Server。

第三节，API为何不够用，非要MCP？

从某个角度讲，

虽然MCP是Anthropic公司推出的，

近期也得到了OpenAI公司的支持，

但要成为行业通行的标准，

它还需要赢得多方支持：

终端用户，开发者，传统软件工具，线上服务平台。

每个利益相关方都有自己的诉求，

比如，开发者希望减少开发工作量，

MCP的设计天然考虑了开发者的诉求。

有请杨荟博士给“观点2”一个硬核反驳：

最大的原因是，如果让模型自己读API的话，

理解和执行的能力千差万别。

因为API写的人，写的方式也千差万别。

用MCP的方式能让智能体更容易的理解API怎么调用。降低了工作难度，降低了出错的可能性，提高了可靠性。

智能体需要调用APP的功能，

但是APP的类型太多了，

诉求也各不相同。

有些是偏纯工具，希望被使用。

比如高德。

值得注意，

这时候，高德和智能体比起来，

高德“权力”更大。

是高德允许智能体查路线、算距离，

是高德允许智能体使用它的API功能，

兼容MCP是高德“做出”动作配合AI，

把这些功能“变成一种MCP服务“，发布出去，

这样，智能体才能来“调用”。

我们称高德为MCP Server，

能被智能体调用。

此刻，你会问，不就是新的API吗？

有啥好吹？

关键在于，智能体比较以前的软件，

多了个脑子，

脑子是个好东西，

希望你有，我有，大家有。

没脑子的软件，给它一套工具，

“选用哪个”全凭代码。

拿API来说，10个功能对应10个API，

开发者手动添加10次URL。

而智能体能自己选，

甚至给它一个工具箱入口就够了，

因为它能判断工具箱里10个工具用哪个合适。

工具列表里有系列说明性文字，

比如，工具信息，工具描述，

是一种智能体所需要的“背景信息”。

比如，

杨荟博士和谭老师打算，

“从上海到杭州吃西湖醋鱼。”

大模型有上海到杭州的常识——不远，

但是为了精确，

它会从高德里“查”一下距离，

这也是一种“背景信息”。

第四节，为什么Uber还不支持MCP？

并不是在技术上有难度，

实话说，MCP没啥技术挑战。

而是，用户入口有可能不掌握在自己手里了。

人家才不愿意这样做。

假如，美团接入MCP协议，

某个智能体就能帮着点外卖。

且这个智能体很热门，用户超级多，

美团可能就扛不住了，

你现在是不是也理解为什么美团要搞基础模型了，

你看，AI面前，王兴也焦虑。

美团基础模型的名字很好玩，叫LongCat。

当然，美团也可以选择抵抗，就不接入。

再讲一个例子，

网页解析器是一种服务，

能读取和分析网页内容。

例子：假设你想在所有电商平台里比价，

以确保买到最便宜商品，

那得知道多个电商平台该商品的价格变化，

手动比价很费事。

但是，智能体有调用网页解析器服务的能力，

让智能体“看”网页上的价格信息，

并定期通知你价格的变化。

淘宝，京东，PDD自动比价。

你觉得，电商平台会允许这种全平台比价智能体，

拿到真实且实时的价格吗？

价格，多敏感的商业信息，

很可能成立专门的团队，

“阻止”任何组织或个人成批量“拿走价格”，

别问我怎么知道的。

你不愿意支持，但有人愿意支持。

当这些互联网门户级APP，

考虑要不要做MCP Server的时候，

他们担心的是：

这么多年砸钱无数积攒下来的用户入口地位，

把用户入口让给了调用这个服务的厂商，

那要问一句，

凭什么让给你？

愿意支持MCP的 APP，

往往是开放接口吸引更多用户，

推动标准化并构建生态系统的公司。

不愿意支持MCP的APP，

则是那些核心竞争力依赖数据敏感性，

用户入口是核心资产，

或倾向于封闭生态的公司。

这种差异反映了不同企业，

在面对技术变革时的战略选择，

也揭示了技术标准推广过程中不可避免的博弈。

第五节，“入口大战”又来了？

MCP是技术话题，也是商业话题。

原本由平台APP掌控的“商业模式设计权”，

现在有可能转移到智能体开发者手中。

平台必须重新思考如何适应这种变化，

否则可能被淘汰。

表面上，MCP的出现是为了提升效率和开放性，

但实际上它触及了商业深层逻辑：

数据控制权、

生态系统主导权、

商业模式设计权，

以及行业规则制定权。

谁能主导MCP或者类似协议的发展，

谁就能在未来商业版图中占据有利位置。

只要智能体做大了，

谁不兼容这款“智能助理”，

谁就损失销售机会。

MCP这个事情的成败，

取决于智能体繁不繁荣了。

然而，这是一个鸡生蛋，

蛋生鸡的问题。

首先，智能体要能切实给用户解决真正的问题，

生活方便，上班简便。

也有人管智能体叫“数字助理”“数字劳动力”。

智能体想有用户，想普及，

就得能干很多活，

但是反过来，

而人类大部分的需求：

出行（滴滴），

购物（淘宝），

点外卖（美团），

都有大型APP占据，

远看星辰大海，近看全是红海，

看上去智能体想找份“体面工作”，

就业机会不多，

智能体若是没有工作机会，自然没有用户。

这是什么局面？

有点像早期互联网，

网页少的时候给，搜索引擎的价值小，

有海量网页的时候，搜索引擎才有江湖地位，

网页创作者也会主动优化内容，

以迎合搜索引擎的规则。

当智能体没有什么用户的时候，头部APP不理，

当智能体很火爆，

倒逼着APP厂商加入。

这是一个典型的“先有鸡还是先有蛋”的问题，

也就是，技术生态的启动困境和网络效应。

有智能体，MCP类似的协议才有存在的可能。

好比，城市道路四通八达了，

到交通法才有实施的意义。

如果某个小地方只有一条10米的路，

交通法的意义也体现不出来。

当下，是智能体的市场教育时期。

杨荟博士认为：距离企业级智能体需求爆发，

还有些时日，但来日不远。

第六节，哪种软件最适合封装成MCP？

看上去，你跟一个工具（MCP Server）说话，

它不会“思考”，只会干它会做，且有限的几件事。

而智能体要复杂得多，

擅长理解，记忆，逻辑推理，

这个视角下，

大部分工具（MCP Server）像一个电饭锅，

而智能体像厨师团队。

要我说，电饭锅（MCP Server），功能稳定，

只要按键就工作，

不记得你之前让它干啥，

也不会主动去想你下一步要做什么。

而厨师团队能力强，也不好管。

这种最适合封装的“工具（MCP Server）”，

其实是那种本身不需要智能的工具，

或者说，不需要智能决策和判断的工具。

像订机票，订酒店，

所以，当下，而大多数工具（MCP Server），

都是“轻量型”的，

如何托管，如何设计这样一整个“厨师团队”，

不是谁都有的能力，

这是智能体创业团队的机会。

第七节，哪种软件系统拥抱MCP最积极？

答案是，数据库。

这是杨荟博士的观察，

我们对“Awesome MCP Servers”集合网站有所观察。（在github搜索awesome-mcp-servers），

拥抱MCP的软件（服务商）的数量还在快速增加，那么问题来了，

为什么数据库拥抱MCP最积极？

写这节的时候，

“亲爱的数据”读者群有个群友问：

是数据库拥抱MCP，

还是MCP拥抱数据库？

这不是文字游戏，

在MCP面前，

MCP是一种协议或标准，本身是中立的，

它并不会主动去“拥抱”某个具体的技术或系统。

相反，软件（如数据库、工具、应用），

需要根据MCP的规范进行改造，以实现兼容性。

好比，MCP是一种语言，假如是“英语”。

英语来了，不是用“英语”把数据库重写一遍，

而是，数据库“适配”英语，

好比，增加一个会说英语的接口，

套用这个比方，

数据库了增加会讲“MCP语言”的“服务窗口”，

数据库不直接和消费者互动，

没有用户入口丢失的担心。

数据库希望被使用得多越多好，

拥抱MCP当然积极。

杨荟博士还补充了一个观点，

智能体有一个刚需——

长短期记忆，

加上数据库就相当于扩展了智能体的记忆容量，

所以，智能体想做大，

可以没有美团的MCP，

可以没有阿里天猫的MCP，

但不能没有数据库，

按说，大的数据库的厂商动作还没有这么快，

不过，不包括Clickhouse，

人家原厂已发布MCP Server。

第八节，

目前工具（MCPServer）里面没有智能体。

是杨荟博士的一个观察。

好遗憾，它们在等啥，

为何还没把智能体放进去。

因为“工具”易于计费、易于控制。

但智能体是行为复杂，

成本不易控，结果不确定的实体。

这正是体现技术团队价值之所在之处。

那些没有智能体的工具凑在一起，像什么？

像API商店：

而不是“智能体服务市场”。

为什么？

智能体玩的是，我有一群助理，

能一起帮你想事、做事、配合安排。

就好比，大模型外挂智能体，

智能体在外挂智能体，

禁止俄罗斯套娃梗。

不过，万事都有开头。

在“大模型只输出想法”的前提下，

智能体作为“行动层”，

真正做事的那一层，

它要靠什么爆发？

我们认为：

智能体的蓬勃发展取决于，

它是否拥有，

“通用行动能力+

高质量工具生态+

可组合的系统结构”

——这三者共同形成，

“AI动作系统”的地基。

杨荟博士说，当下看来，

第一波的影响力作用于APP。

第二波的影响力才作用于AI产品。

为什这么说？

美团可能不愿意兼容MCP，

宁愿自己造智能体。

这是天然的阻碍。

怎么办呢？

我们认为，这可能就会形成“摆渡车”模式。

好比，你进风景去游玩的时候，

公共交通不会带你直达景点核心地带，

比如，公交车会停在八达岭长城烽火台门口吗？

多数大景点都有“摆渡车”，

一般来说，干一件大事哪怕里面有好几件小事，

虽然美团这类平台不支持MCP，

但是可能会积极支持，

“智能体对智能体协议”，

例如谷歌刚刚发布的Agent to Agent（A2A）。

这就好比，

当智能体A进入美团，

先遇见一个美团前台，

其实是智能体B。

后续，关于点外卖的一切相关事宜，

美团前台，

也就是智能体B，

接手了。

这时候，MCP没用了，

请用智能体和智能体的“语言体系”来沟通。

于是，智能体对智能体的协议，

会日显重要，

市场的情况，要过数月才能清楚，

不过我们引入了一个新概念。

A2A。

这是另外一套协议。

第九节，我们认为：A2A更重要，为什么？

因为MCP协议本身有些局限性，

接入这套协议的有两个角色：

智能体的生产厂商和外部工具开发商。

他们并不总是有动力将自己的工具封装成MCP。

为什么？

因为它们更希望将自己的“接入能力”控制在手中。

比如，智能体厂商希望工具封装成MCP，

美团滴滴携程去哪儿这种APP

越多接入越好。

尤其是APP平台。

例如，美团、滴滴、携程，

这些平台越多外部工具接入，

它们就越能获得更多的流量，

但它们又不希望自己的核心能力，

被第三方工具取代。

智能体的生产商往往不愿意把自己的智能体，

封装成MCP，

尤其是当它们的智能体已有用户群体时。

可以说，它们更愿意选择MCP+A2A双重封装，

相当于同时拥有两种接入方式。

也就是说，

它们希望“工具”能够主动入局，

但并不是所有的“工具”都有动力去接入MCP，

尤其是那些头部的APP，

智能体的崛起也可能会削弱APP平台的控制力。

APP确实很强势，

若被智能体绕过了入口，

麻烦很大。

假如全世界的大小餐厅老板手机里就有智能体，

可以提供点餐，下单，

吃货评价，外卖等多个服务功能；

全世界的吃货，

也都有手机智能体，

这吃货们的手机智能体对接大量餐厅智能体，

还需要美团干嘛？

美团情何以堪？

再总结一下，

如果终端用户（消费者）拥有的智能体和商品/服务真正提供方的智能体能用A2A协议直连，那么它们就绕过了APP平台。因此，A2A协议可能成为智能体冲破发展障碍的关键。

第十节，阿里云拿什么样的动力拥抱MCP？

要我说，动力可太多了，

国内头部云计算厂商里旗帜鲜明地支持MCP的，

确实只有阿里云了。

国内其他厂商都没玩MCP。

这符合他们AI这一轮的开源策略。

智能体在当前的AI产品生态中，

占据了一个非常重要的地位，

不仅是新技术，

更是一种全新的产品形态。

对阿里云来说，

任何有利于智能体生态发展的事，

都应该多做。

这样就有了先发优势。

这波阿里云吃亏只有一种可能：

万一智能体完全是个泡沫

我认为，其他厂商现在没呐喊支持，

一部分是因为资源有限，

或者，还在考虑怎么支持，如何支持。

阿里云现有动作：

一是百炼开了智能体商城，

二是无影云电脑搞了个智能体的运行环境，

名叫AgentBay。

它俩是什么关系呢？

一个是智能体商城（百炼），

一个是商城里的旗舰店（AgentBay）。

旧逻辑里，云厂商的价值就是让IT更简单，

新逻辑还在形成，

我观察，无影是阿里云原厂原装的云电脑，

既然智能体需要操作一个“电脑”，

那么无影肯定争先恐后，

也就是说，就有很多事情可以做。

AgentBay这个产品，

是带电脑操作系统界面的虚拟机服务。

当你在这个虚拟机环境里让智能体操作电脑。

不就是一个“操作间”吗，

有操作环境，且能在这里面加装备。

阿里云就是开发环境和装备的厂商。

现在智能体作坊，

明日智能体工厂。

智能体有这么强的刚需吗？

有时候，一般的本地设备（办公电脑），

难以支撑高并发，

高算力需求的智能体，

还有时候，任务执行时，

会占用本地计算资源和操作权限，

也就是一种“我的电脑”，

被智能体“霸占”的即视感。

严谨地说，阿里云的目标是，

让开发者无需自己搭建和配置虚拟机，

而是直接用阿里的虚拟机环境来开发智能体。

省流版说法：

WeWork办公区，

谁用谁留，用完就走。

以无影云电脑为例，对比一下，

如果不使用MCP协议，

智能体仍然可调用无影的虚拟操作间服务，

但前提是，

智能体开发者需要阅读虚拟操作间的API文档，

并手动代码调用这些服务。

也就是说，

开发者需要在代码中明确“告诉”智能体，

该如何操作以及各种细节。

而如果使用MCP协议，

智能体则能自动读取，

MCP协议中的相关操作指南，

智能体自行决定如何调用。

像Manus这样操作电脑的产品，

云上“包间”做得好，

高效和安全就都有了。

这件事对云厂商有多重要呢？

如果云厂商不做好，

会有人替你干好。

那就是大模型厂商，

干得好，且取得垄断地位后，

就能绕开了云厂商。

所以，对智能体，

云计算厂商都会不遗余力，

而且，要我说，一举两得，

云平台按需计费的模式，

为智能体开发者提供弹性计算资源，

从而增加收入。

此外，可从调用阿里云别的服务的API中收费。

比如，智能体用了阿里云PolarDB数据库，

阿里数据库部门就可以赚到钱，

其他云厂商也一样。

不仅能够赚钱，取得规模效应后，

有机会成为“智能体商店”的所有者，

就看阿里云有没有实力运营智能体时代的淘宝。

第十一节，有MCP，为什么谷歌还出A2A？

阿里现在支持MCP，

日后也会支持A2A吗？

这是个好问题。

谷歌A2A博客说，

它和MCP的关系是补充关系，

但不够本质，

A2A协议意味着，

智能体服务里的两个角色都是智能体，

智能体A和智能体B，

甚至就可以人类自然语言交流，

还需要MCP协议吗？

为了干活的目标，

智能体B在理解了智能体A的意图之后，

智能体B自己决定的如何提供服务。

B提供给A服务，B服务A，

这里用甲乙方的比喻比较贴切。

苹果会推出自己的协议和谷歌的竞争吗？

有可能，因为在端入口，

智能手机厂商话语权最大，

硬件控制软件，这是房东和租客的关系，

手机厂商对APP厂商始终有降维打击的能力。

我们畅想日后，

人形机器人的数量超过了手机的数量，

机器人厂商就是房东了。

杨荟博士和我讨论时谈到，

悲观的专家也在发声，智能体泡沫太大。

智能体的瓶颈没有暴露出来，

有个观点是，智能体也许没有瓶颈，

因为只有智能体大量被用户使用，

积累真实的使用数据后，

智能体改进的过程中，

才能看清天花板到底在哪。

A2A协议还得再新开一篇，

欢迎专家前来交流。

第十二节，举个西湖醋鱼的例子，

体会MCP的方便之处，

尤其体会，

智能体在没有人插手（规定格式，选择工具）的情况下，就有工具可用，且知道怎么用。

以前：手动查高德和美团，

以后：智能体，

这时候，

我想再聊聊MCP里的字母C是什么？

是Context，直接翻译是“上下文”，

那到底什么是上下文？

智能体需要理解的，

为了达成用户的（杨荟博士和谭老师）目标，

用户虽然没说，智能体也应该知道的信息。

MCP协议通过标准化的数据结构和接口，

将“上下文”传递给智能体。

智能体的常识里有：

1.知道杭州离上海不远；

2.西湖醋鱼是杭帮菜；

智能体“调用”高德，“上下文”里有：

第一，城市地区，

出行看天气，出发和到达城市天气；

第二，推荐餐厅，

地点在杭州西湖景区，

第三，口味，

杭帮菜。

第四，选择出行方式，

比如开车、骑车、步行。

再次确认杭州到上海精确距离182公里，

开车大约三小时可到达，

但只有约1/10000的用户喜欢骑车去，

几乎没有人喜欢从走路去。

所以，智能体会帮杨荟博士和谭老师，

挑选自驾的方式。

接下来，

智能体“调用”美团，

第五，选择“楼外楼”（孤山店）餐厅；

解释一下，

这是美团内部评分排序算法得出的结果，

到底智能体能获取前三名，还是前五名，

这取决于美团写MCP协议的时候，

至于返回几个最佳上榜餐厅，

至于是取前三强，

或者前五强，

由美团决定；

也就是说，

MCP协议只规定格式，

格式里的细节由美团决定，

由美团的工程师在开发MCP工具时考虑。

还可以调用Agentbay里的浏览器能力，

搜索下小红书相关话题下面的口碑评价，

添点笑料，

最后，西湖醋鱼上桌。

最后的最后，

作为一个杭州人，

谭老师告诉杨荟博士，

如果你觉得西湖醋鱼难吃，

那一定不正宗，

因为正宗的更难吃。

（完）