在 AI 领域，MCP（模型上下文协议）和 plugin（插件）是两个热门概念，但它们之间存在本质区别。本文将深入探讨 MCP 协议的定义、功能和使用方法，对比其与 plugin 的差异，并结合实际案例展示如何通过阿里云百炼平台使用 MCP 服务。

最近AI领域的最热门的应该可以说得MCP协议了，从年初到现在，我的媒介矩阵已经被MCP这个话题包围了，从抖音到知乎，所有的技术博主都在谈论MCP协议，虽然起初我真的很想把它叫做买彩票（MCP，没别的意思）。

从Google trend来看，最近24个月内，尤其是在2025年之后，有关MCP的话题搜索量几乎直线上升，名副其实的话题之王。

不过，从区域来看，在全球搜索国家来看，我国地区是关注MCP协议人数最多的，完胜其他国家和地区，单从下方这个图标来看，我几乎感觉不到其他国家有在研究这玩意，这会把Google整成百度来用了。

一、MCP是什么？

那言归正传，什么是MCP协议呢？

MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 提出并于 2024 年 11 月开源的一种通信协议，旨在解决大型语言模型（LLM）与外部数据源及工具之间无缝集成的需求。

它通过标准化 AI 系统与数据源的交互方式，帮助模型获取更丰富的上下文信息，从而生成更准确、更相关的响应。

通俗来说，MCP 协议就像是设备之间沟通的 “语言规则”，规定了不同设备或程序之间如何 “听懂” 对方的话、如何传递信息。比如你和朋友聊天，需要用同一种语言（比如中文），还要遵守一定的表达顺序（比如先说你好，再说事情），这样才能互相理解。

如何定义B端产品及B端产品经理方法论

相较于C端产品，B端产品最大的特点是：面向特定领域用户，且数量少得多，但更注重对用户专业领域操作流程的深度挖掘——也就是专业性更强，与业务的结合更紧密。

查看详情 >

MCP 协议就是给机器、软件、设备定下的一套类似的 “沟通规则”，让它们能按照统一的方式发送和接收信息，避免 “鸡同鸭讲”。

这样说你可能还是不懂，于是我们就再举一个例子，来加深一下理解

假设你家有一个 智能灯泡 和一个控制它的 手机 APP，它们之间需要通信才能实现 “用手机开关灯” 的功能。

没有协议时：

手机想让灯泡开灯，可能会发一条消息：“喂，开一下！” 但灯泡可能听不懂，因为它不知道 “喂” 是不是开头、“开一下” 具体是什么指令，也不知道该怎么回复手机 “我已经开了”。就像你对一个只会说英语的人说中文，对方完全懵圈。

有了 MCP 协议后：

MCP 协议提前规定好了：

• 消息格式：必须以 “[指令]” 开头，比如 “[开灯]”“[关灯]”，后面跟着设备编号（比如 “灯 – 001”）。
• 回应规则：灯泡收到指令后，必须回复 “[状态] + 结果”，比如 “[已执行] 灯 – 001 已打开”。
• 错误处理：如果灯泡没电了，要回复 “[错误] 电量不足”，让手机知道哪里出了问题。

这样一来，手机和灯泡就像用同一种 “语言” 对话，每一条消息都符合 MCP 协议的规则，双方都能准确理解对方的意思，不会出错。

二、基于MCP可以做什么？

读到这的用户可能会有一些疑惑，这不就是plugin吗？

是，但又不是

说它不是，是因为它和plugin有着本质的区别

MCP本质是模型与工具的通用交互标准。以高德地图为例，MCP 将高德的 API（如地点搜索、路径规划）封装为符合 MCP 协议的服务，通过统一的 JSON Schema 定义输入输出格式。这种标准化设计使得：

跨模型兼容：无论是通义千问、Claude 还是 GPT，只要支持 MCP 协议，均可直接调用高德的 MCP 服务，无需单独适配。

多步任务调度：MCP 支持复杂任务链的自动执行。例如，用户只需输入 “规划从杭州西湖到灵隐寺的骑行路线并预估时间”，MCP 服务会自动完成地点解析、路径规划、实时路况查询等多步操作，而无需手动拆分任务。

动态上下文管理：MCP 服务在调用过程中可携带上下文信息（如用户的历史搜索记录），提升任务连贯性。例如，用户连续查询 “附近的咖啡馆” 和 “推荐其中评分最高的”，MCP 服务能自动关联两次请求的上下文。

而plugin本质是：

厂商为特定模型设计的专有接口，例如高德为通义千问开发的插件。主要核心特点是：

• 模型绑定：插件通常仅支持特定模型（如通义千问），无法直接在其他模型中复用。例如，高德的插件需要在通义千问的生态中通过 API Key 认证才能使用。
• 单次调用逻辑：插件的功能通常以单次函数调用的形式实现。例如，用户需要分别触发 “搜索地点” 和 “规划路线” 两个插件，而无法通过一个请求完成多步任务。
• 静态配置依赖：插件的参数和功能通常在开发时固定，难以动态调整。例如，插件可能无法自动适配不同城市的交通规则变化

总结起来说

你要是用MCP，你可以更加开放、更加丰富、更加简单，但是plugin不会，它是暂时、封闭和复杂的

比如，以开发成本来说，传统plugin想要开发的话，需针对特定模型编写代码。例如，高德的插件需使用通义千问的 SDK，实现插件的注册、参数解析和结果返回等逻辑。而且通常需要处理模型的认证和授权等等。

但是前者MCP，却是低代码几乎是零代码就能使用，比如，阿里云百炼这两刚发布的MCP服务，用户只需通过简单配置即可接入高德的 MCP 服务，无需编写代码。例如，用户可在百炼广场直接开通高德的 MCP 服务，并通过拖拽操作将其集成到 Agent 流程中，而且，MCP 服务由平台托管，开发者无需关心服务器部署、负载均衡等问题，省了不少麻烦。

这还只是从成本和效率来说，从跨模态和功能任务上还有更多的区别。

其实，AI一定会从成本和效率来打破僵局的，这里分享一句乔布斯的话，任何复杂的事物都不会永存。在AI时代，同样也是，你想一想以前我们想要让模型或者agent接入一个插件，其开发成本和维护成本先不谈，质量和稳定性更是一个难题，很多时候，插件几乎不能用，能用又不能适配模型

因此，这里面有一个潜在的需求又或者是趋势，不仅仅是现在的传统行业或者是互联网行业，哪怕是AI行业，太过于复杂的、低效率的产品都一定会被AI所替代。

比如视频剪辑、图片编辑，工厂流水线、包括有些工作流的编排等等，都有被代替的风险，因为它本质上是一种RPA，缺少足够的创意，还会耗费大量的时间和人力成本。

如果真的可以实现，我们人类可以把时间多花费在创造力上面，那将会很不同！

就功能变现和使用场景来说，它真的和plugin没什么区别，如果非要找不同的话，只能说确实很方便，很快，比如，

只需要一件部署就能使用MCP服务，包括一些国外的软件，像perplexity啥都可以用。

另外，如果没有自己想要的MCP，我们可以随意增加MCP服务，操作也不会太复杂，这里后文会讲到。

紧接着，我们需要上手试一下这一次阿里云发布的MCP协议服务，这应该是国内第一家发布的MCP服务，虽说没有MCP.so.com早，但是也还算及时，算是弥补了这一块缺陷，毕竟整天都都讲着理论不谈实操，肯定是没用的。

阿里自从开过年之后，在AI上面的进步真的有目共睹，感觉隔两天就是发布一个新模型或者一个新产品。前段时间，据传阿里所有部门都要AI化，这是打算从电商巨头转向AI公司了。

三、MCP如何用

话不多少，开始实操

首先，你需要打开阿里云，没有注册过的需要先注册一下，网址在这里：https://cn.aliyun.com/

当然你也可以直接打开阿里云百炼，都是一样的，我习惯用第一种方法。

在阿里云首页里，找到模型，然后找到AI应用构建–MCP服务，目前官方已经标识出来了，可以直接看到

不过这里阿里是把云百炼的模型和应用分开了，原因可能是以前放在一块的时候，功能太多，现在分为子母界面了，反而会更方便。

点击之后，可以直接进入MCP中心了，下面只要是你能看到的，都是接入服务的，这里我们还是直接使用高德地图，然后点击开通，然后就已经成功开通这个服务了。

但是，这里有一个问题，就是很多国外的软件它是需要API的，比如perplexity，你想要登录使用获取密钥的话，你就需要魔法，但是这一步得看缘分了

这里就引出了第一个问题，MCP服务应该更加丰富才行，否则就会很鸡肋，效果肯定不如插件好，你想想，如果你能的内存是256g的，但是你手机商店里面只有10个软件，其中还是一些外国的，你还用不了，这事你找谁说理去？

接着，目前很多MCP服务都是互相支持开通的，但是有些服务商不愿意接入的话，人家万一不愿意配合，那也很麻烦，所以后续的更新可能还需要不断的磨合，这里面也有非技术因素在影响。

然后，我们需要配置一个MCP服务了，阿里云是提供了两个选择，一个是应用支持，一个是工作流支持，之间用coze或者dify的用户，肯定都知道这是什么东西，不熟悉的话，他们也在文档里面给了操作步骤和使用手册，在云百炼的界面里面就能找到。

我这里就用了应用简单搭建一个MCP服务，这一大堆界面可以不用管，直接点击技能，里面的MCP，把刚才的高德接入进去就行

人设和回复逻辑，大家自行填写，我只是为了方便，其实你不写也完全没事，因为你MCP就使用了一个，模版的话我放在下面：

##你是一个路线规划助手

##技能

当用户问你路线问题的时候，你需要调用MCP服务来帮助解决问题

##限制

对于非路线或者地图的问题，不需要回复

这里有一个注意的点：

就是模型的选择是有限制的，第一，阿里云是提供了信任免费的额度的，很多模型基本上都是可以免费试用的

第二，要想使用MCP服务的话，就使用默认的模型，deepseek是不支持的，这里我用的是通义的max32k

然后这几件事弄好，你就可以使用了，我问了几个关于地图的问题，大概就是：

• q：帮我计划一下从杭州奥体到西湖的最佳路线
• q：帮我看看此刻西湖附近的交通情况
• q：哪种交通方式从奥体去西湖最佳？
• ………

首先从回答来看，其实还是不错的，基本上你问它一些的交通问题，它也都能回答上来，但是肯定不如你直接去使用高德效果好的。

另外，它好像不能完全实现实时的数据接入，比如，我问它现在的西湖交通情况如何，它回答不了，我一开始以为是我prompt不准确的问题，然后我又确定了一下时间，几时几分，但是它还是回答不出来

最后，你可以自己添加MCP服务，操作也不复杂，肯定要比plugin简单的多，就是下面几个步骤，然后想用别的服务的话，比如perplexity或者notion AI啥的，你需要调用API，就自行使用了

结论就是：现在的MCP服务基本上其实和plugin没有什么差别，甚至有些功能不如后者，虽然我不想泼冷水，但这也是没有办法的事情，它确实一个趋势，但是现在要想为其成为通用agent那种模式，可能还差得很远。

就比如，性能和延迟问题，实时应用（如自动驾驶）需毫秒级响应，而 MCP 调用远程 API 可能引入数百毫秒延迟。例如，车联网场景中，MCP 调用天气 API 的延迟可能影响路线规划的实时性。

又或者，在生态方面， 工具覆盖不全：现有 MCP 工具集中在通用领域（如天气、地图），垂直行业（如半导体制造设备控制）的专用工具较少。

写这篇文章的时候，Google也刚刚推出了A2A协议，一言以蔽之，是想让多个agent之间进行互相合作而诞生的一种协议，如果这么解释还不清楚，你可以简单的理解为，一群agent在开会。

而MCP解决的是，工具调用的问题，二者肯定有差别，但是方向是一样的，那就是，都是在朝着通用agent而前进，弥补现在agent单一、抽象、行动不足等的缺点。

但是，有总比没有好

一个优秀的作品往往都是从0开始，然后慢慢改进的，就像一篇文章一样，先写，写出来一坨垃圾，再慢慢改。