阿里云拥抱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 就可以口喷需求一键实现，效果也非常惊艳。

详情可以查看这个链接：https://www.genspark.ai/agents?id=98ec3208-5434-420b-9e8d-9e725ba7d685

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

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

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

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

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

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

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