阿里云MCP更新背后：这场工具调用的革命，你真的看懂了吗？
最近，我们团队兵分两路，一支前往拉斯维加斯参加 Google Cloud Next，另一支在北京郎园参与阿里云 AI 势能大会。谷歌那边发布了不少内容，后续再详细解读。今天先集中精力，聊聊阿里云百炼在 MCP 方面的这波更新及其战略意图。
MCP 近来确实热度极高，但随之而来也有不少争议和误解。每个人对它的理解不尽相同，网上虽有不少分析文章，但总让人觉得“知其然，不知其所以然”。MCP 究竟做了什么？它和 Function Calling 之间到底是什么关系？MCP Market 与 Plugin Market 又有什么差异？阿里云百炼这样做的战略意义何在？我们尝试用一个非常通俗的框架，让哪怕是零基础的读者也能彻底弄清这些问题。
先从“男朋友买番茄炒蛋”讲起
用户让大模型调用工具，好比让男朋友去小店买东西。如果任务复杂，需要多个工具协同——比如从零做一道番茄炒蛋——男朋友就得规划一下：先去苏泊尔买个锅和铲，再去菜场买西红柿和鸡蛋，最后到便利店买糖和盐。在传统的 AI 应用开发中，男朋友（LLM）每去一个新地方，开发者都必须提前为这条路“铺好代码”，非常麻烦。
后来，像字节扣子、百度千帆、阿里云百炼这类平台出现了。它们相当于开了一个大型商超，跟各类小店说：“来我这上架商品吧，顾客多，按照我的标准来就行。”小店们觉得不错，就遵守平台的上架规范，把工具变成了插件。用户（我）提的需求，男朋友（LLM）在商超里就能一站式解决——选几个插件直接使用，方便多了。
但 Anthropic 又往前推了一步——他想搞电商。他跟小店们说：“每个平台的上架规范都不一样，你们去各家上架也挺累的。不如我们定义一套统一标准，让天下的男朋友（LLM）都能更轻松地使用更多工具。你们按我这个标准，把工具打包成 MCP Server；我们再定义一个‘电商组件’，也就是 MCP Client；双方通过一套开放协议通信——这就是 MCP 协议。在此基础上，Anthropic 还做了一个‘淘宝外壳’（Claude Desktop），里面不直接包含 Claude 模型，但加上模型之后，就成了 MCP Host。MCP Server 提供工具，MCP Host 通过 MCP Client 获取并使用这些工具。淘宝上商品多了，就形成了 MCP Market。”
MCP 和 Function Calling 到底是什么关系？
这个问题挺有意思。有人说它俩毫无关系，有人说 MCP 是 Function Calling 的封装——到底谁对？其实都对，只是视角不同。
说毫无关系，是因为从工具调用流程来看，“MCP 协议”本身只关心 Client 和 Server 的连接，只关注商品怎么上架到电商平台。而 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 只是一个标准，不是一门技术，核心还是得看大模型或 Agent 的能力。比如有博主用 Windsurf + Claude 3.7 + 高德 MCP 找两地之间的咖啡店，但这件事在扣子上基于插件同样能实现——模型自己规划，先找到两地经纬度坐标，计算中间值，再找附近咖啡馆，然后让扣子做前端样式展示。而那位博主说的“在地图上两个地点中间找位置的需求，过去十年都没有最佳解决方案”也有失偏颇，Genspark 就能通过口喷需求一键实现，效果很棒。
现在很多案例都有“为 MCP 而 MCP”的嫌疑。可以说“通过 MCP 能做到 xxx”，但不能说“只有 MCP 才能做到 xxx”。另外，有博主把 Plugin 开发者和 MCP 开发者的工作说得天差地别，实际上没什么本质区别——插件的开发和 MCP 的服务开发都有类似百炼这样的云平台来托管。至于“多次调度、多工具组合”的能力，那是模型本身的能力，跟选择 Plugin 还是 MCP 没有任何关系。
更离谱的是，有博主在文章里写，从阿里云百炼平台上把高德的 MCP Server 拿到了 Cursor 里用。但事实上，他拿的是高德的 MCP，跟百炼平台没有一毛钱关系。
坦率地说，MCP 确实有些被“过度神化”了。很多博主明显错误的观点，阅读量却很高，且无人反驳——这种现象本身就说明市场有些浮躁。虽然吐槽了不少，但我们仍然非常看好 MCP 的理念和未来。只是希望在纷繁的信息洪流中，保持一份清醒的思考。