阿里云拥抱 MCP 这步棋,太多人都没有真正看懂

360影视 欧美动漫 2025-04-11 15:17 1

摘要:阿里云拥抱MCP(Model Context Protocol)的举措引发了广泛关注,但市场上存在诸多误解和非共识。本文将通过通俗易懂的方式,深入解析MCP的核心概念、与Function Calling的关系,以及阿里云百炼在MCP领域的战略布局。我们将探讨M

阿里云拥抱MCP(Model Context Protocol)的举措引发了广泛关注,但市场上存在诸多误解和非共识。本文将通过通俗易懂的方式,深入解析MCP的核心概念、与Function Calling的关系,以及阿里云百炼在MCP领域的战略布局。我们将探讨MCP如何通过标准化协议提升AI模型的工具调用效率,以及阿里云百炼如何通过支持MCP协议,弥补自身插件生态的不足,快速占领市场份额。

最近特工们兵分两路,一支受邀前往 Las Vegas 参加 Google Cloud Next 大会,一支前往北京郎园参加阿里云 AI 势能大会。前者 Google 发的东西有点多,还没消化完,改天我们详细说说。今天就先来聊聊阿里云百炼这边关于 MCP 的更新。

MCP 最近非常火,但也存在许多非共识和噪音,每个人对 MCP 的理解都有些参差,网上的各种分析也是眼花缭乱,读起来让人觉得知其然而不知其所以然。

MCP 具体干了个什么事?MCP 和 Function Calling 的关系是什么?MCP Market 和 Plugin Market 的区别是什么?百炼这么做的战略意义是什么?

我们尝试提出一个非常小白化的解释,来让没什么基础的读者也能搞明白以上所有问题,请允许我们娓娓道来。

一、MCP 的形象比喻

首先,用户让 LLM 调用工具,就好比我(特工少女,即 User)让男朋友(LLM)去小店(软件服务提供商)买东西(Data & Tool)并使用。如果模型接到的任务则可能需要多个工具调用(Tool Use),这就好比我跟男朋友讲的需求比较复杂,比如做从零做一道番茄炒蛋。

然后男朋友通过规划(Planning)决定去苏泊尔买个锅和铲,去菜场买个西红柿和鸡蛋,再去便利店买个糖和盐,以此来完成番茄炒蛋这道菜。但是在传统的 AI 应用开发过程中,男朋友(LLM)能去的小店(能使用的工具)都需要开发者预先定义线路(编写代码)。

但是,男朋友(LLM)每去一个新地方,都要造一条新路(编写代码),似乎不太方便。于是后来字节扣子、百度千帆、阿里云百炼等平台出现了,他们就好比是开了一个商超。商超跟各种小店说,我这里人气旺,你们直接按我们的要求来货架上架你们的商品就行,再跟我(User)说我这现成的商品多,以后让男朋友(LLM)来这买就行。

小店们觉得这事不错,便遵守平台一定的上架规范,开始把他们的商品(Tool)变成了插件(Plugin),我(User)提的好多需求,男朋友(LLM)在这些平台上就能一站式满足了,选几个插件直接用就行,方便了挺多。

但是,Anthropic 干了一个什么事情呢?他想搞电商!

他跟小店们说,不同平台的插件规范不太一样,你们去各个平台上架插件也挺累的。咱们搞个新玩法,能让天下的男朋友(LLM)都很容易的用到更多商品(调用更多工具)。你们呢按照我这个标准,把你们的商品都做一个数字化的标准信息处理(即变成了 MCP Server),我们再定义一个叫电商组件的东西(即 MCP Client),你们的 MCP Server 要跟电商组件有互动,只要遵守一个开放的规则,这部分就是 MCP 协议,即 Server 和 Client 的通信协议。

此外,Anthropic 基于这个电商平台(Client)的理念做了一个淘宝的外壳,这个淘宝就好比没有包含 LLM 的 Claude Desktop。在这基础上,如果再加上 Claude 的模型,就相当于让“男朋友刷淘宝”,这一整体就构成了 MCP Host。

MCP Server 只管提供各种工具,MCP Host 只管通过 MCP Client 获取并使用这些工具。然后淘宝上玲琅满目的商品很多,就形成了 MCP Market。

解释完了 MCP,那它跟 Function Calling 有什么关系和区别呢?为什么有人说它俩毫无关系,又有人说 MCP 是 Function Calling 封装了一层?到底谁是对的?

其实这两种说法都是对的,只是不同视角的解读。

为什么说 MCP 和 Function Calling 毫无关系呢?

从利用 MCP 进行工具调用流程来看,这里的 MCP 更多指的是协议本身(Client 和 Server 的连接),MCP 协议只关心商品在电商平台的上架情况,而 Function Calling 是模型调用工具的主流手段之一(纯靠系统提示词也可以),即男朋友怎么买怎么用这些商品,MCP 协议并不在乎这些,这是一条链路上的两个部分,所以没什么关系。

那为什么说 MCP 是 Function Calling 的封装呢?

这里的 MCP 更多指的是整个让模型调用工具的整体手段(即下图中下面这个红框)。无论是原先的 Function Calling(上红框),还是现在的 MCP,本质都是让男朋友买到商品并使用(让模型调用工具),因此核心目的相同。而至于为何认为是封装,是因为在当前 MCP 整体实现路径中,Host 里的 LLM 向 Client 调用工具时,大多仍然使用 Function Calling,所以可以理解成 MCP 封装了 Function Calling。

二、阿里云为何拥抱 MCP?

扯了这么多,主角终于登场了,阿里云百炼是个什么定位呢?

阿里云百炼可以形象的比喻为盒马。之前也是搞线下商超,但是吧,可能一方面觉得自己的商品供应商,以及来的顾客都不够多,其他家比如扣子好像更热闹一些;另一方面,可能觉得这个线上电商模式挺有前景的,于是也下场了。

百炼调整了自己的运营模式,支持 Anthropic 定义的那套标准协议,那些之前把自己商品打包成 MCP Server 的小店,现在百炼都能马上接过来,相当于也做起了电商平台,并且集 Server、Client、Market 于一体。就像盒马一样,既可以线下买,也可以网上买,这下销路就拓宽了。

百炼通过这种快速转型,弥补了之前可能略逊于扣子等的插件生态,因为现在得益于 MCP 工具变多了嘛。供给变多了,加之最近 MCP 很火热,市场热情不错,那么需求侧的开发者和企业会过来,本质上做的还是云的生意,通过这种方式在短期内占领市场份额。

百炼的眼光比较毒辣,跟进的比较快。但绝对不止百炼一家有这种想法,后面其他家也会陆续跟进,反正没什么坏处嘛,投入也不会特别大。

火山和扣子之所以没那么着急,我们认为是因为其实插件商店和 MCP 商店没什么本质区别。现在扣子平台的生态挺稳固的,很多客户需求都能基于扣子一站式实现了。

MCP 可能是多此一举,也可能是锦上添花,这取决于 MCP 的发展。以及,我们认为这些平台其实可以把 MCP 作为插件的补充,而不要直接暴露给用户,MCP 和插件的并列存在可能让用户感到迷惑。

三、可能存在的一些误区

很多人看到 MCP Server 觉得很牛逼,但其实真正牛逼的是小店里的商品本身,即工具能力本身,而不是 MCP。MCP 是个标准,不是个技术,核心还是得看 LLM 或者说 Agent 的能力。

比如 @AI 产品黄叔 前几天做了一个 Case,用 Winsurf + Claude 3.7 + 高德 MCP 实现找到两地之间的咖啡店。

但事实上这件事情在扣子上基于插件也能实现。

模型自己规划了,先找到了两地的经纬度坐标,计算了中间值,然后在这个中间值的经纬度找附近的咖啡馆。

然后一样能让扣子基于结果做一个前端样式展示。

另外黄叔引用的那位博主所说的“在地图上两个地点中间找位置的需求,过去十年都没有最佳解决方案”有失偏颇。Genspark 就可以口喷需求一键实现,效果也非常惊艳。

此外,大家做的很多 Case 也有为了 MCP 而 MCP 之嫌,可以说通过 MCP 能做到 xxx 功能,但不能说只有 MCP 才能做到 xxx。

以及,博主@赛博禅心 这里的表述也存在一些问题。

首先 Plugin 开发者和 MCP 开发者做的事情没什么区别,插件的开发和 MCP 的开发服务都有类似百炼这样的云平台来托管。

其次,“多次调度、多工具组合”的能力是来自于模型本身,跟选择的是 Plugin 还是 MCP 没任何关系。

另外,博主@AI 产品阿颖 就错的一塌糊涂了,他昨天的文章里写到,把阿里云百炼平台上高德的 MCP Server 拿到了 Cursor 里面用。但事实上拿的并不是百炼的,而是高德的,在 Cursor 里使用高德的 MCP,跟百炼没有一毛钱关系。

现在 MCP 确实是过誉了,很多博主明显错误的观点,但仍然阅读量很高且无人反驳的这一现象,足以说明现在市场的浮躁。虽然吐槽了许多,但实际上我们仍然非常看好 MCP 的理念和未来,只是希望在纷繁的信息洪流中保持一份清醒的思考。

以上只是我们在当下的拙见,若有错误,还请在评论区交流指正!

来源:人人都是产品经理

相关推荐