从 LangChain 创始人Twitter激辩 MCP，到 Manus 项目火爆出圈，以及OpenAI & Google纷纷下场兼容MCP，这场由Anthropic发起的技术变革正引发全球科技圈的关注。作为国内首批接入MCP生态的企业级平台和开源社区，阿里云百炼与ModelScope社区深度拥抱MCP全套生态工具并提供大量深度应用实践，并收获到大家的热烈反馈。在各类宣传稿中，MCP似乎无所不能，那么它真的是技术上的万能灵药么？我们将从技术祛魅与生态重构的双重视角，和大家深度讨论下MCP的现状与对未来的展望。

本文分为三部分。大约7000字，完整阅读需要5-10分钟。核心内容如下：

观点1: MCP技术本身不是灵丹妙药，我们推动MCP Bench项目希望各生态参与者一起更冷静地看待MCP的实际效果，目前来讲并不存在生产力的显著改观。（章节1）

观点2：MCP协议有希望解决Assistant API、Langchain等平台/社区DevOps方案无法弥合的应用迭代困境与分工错配。MCP通过对不同大模型生态位之间的巧妙权责分配，让模型、DevOps平台、工具方、应用构建者的工作充分解耦合，并且有意愿做好相应的优化与协作。（章节2）

观点3：MCP生态的持续发展需要各生态位的共同努力，模型参与者持续推进具备通用交互的深度思考模型，DevOps平台提供更好的服务管理与上下文环境，工具开发者让业务系统更加透明（Transparency）和声明式（Declarative）。（章节3）

1. 热度节节攀升的背后，并没有生产力的大幅提升

1.1. 什么是MCP？

作为一切讨论的前提，先简单解释一下什么是Model Context Protocol（MCP）协议。MCP是2024年11月份Anthropic发布的开放协议，用于连接 AI Assistant 与各类工具和数据源，如Github仓库、Google Drive、Slack、业务工具和开发环境等。

简单来说，MCP标准化了工具的发起并回传工具结果的指令，并允许通过通讯协议（如HTTP、SSE等）方式完成远程调用。对照大家熟悉的插件或本地函数（Function），MCP Server可以视作下述2种情况的集合：

• 远程部署的MCP：类似百炼 / COZE 平台中智能体启用的官方插件。

• 本地部署的MCP：类比于本地函数，但 MCP 封装了 “调用 - 执行 - 返回” 的底层逻辑。开发者无需自行编写 “解析函数名 - 等待结果 - 提交结果恢复流程” 的控制代码，只需遵循统一协议即可。

1.2. Wrappers or Elixir：打造MCP Bench进行技术祛魅

如果以这个视角来看，MCP似乎没做什么，只是一个接口协议层面上的封装（wrappers）。为了一探究竟，我们近期做了一项面向开源社区的MCP Bench工作，设计了一组针对Web Search场景的调用效果对比，使用了包含中英文，最新新闻等源头的300条问题构造的问答对，由模型连接MCP进行问答，对回答的精度采用模型打分。我们对比了Github和多个MCP市场上的高频使用的web search相关的MCP，在给定同一个LLM，同样的Prompt的情况下，观察调用不同MCP达到的精度，以及其效率。实验结果显示：

1. 效果差异性很大，从有效样本的准确率上看，最高的Bing web search(64%) 和最低的DuckDuckGo(10%)相差了54pt。

2. 效率差异性更大，从有效样本的平均时间消耗上看，最快的bing web search和Brave search仅需要15秒以内，而最慢的Exa search需要231秒（注意有效样本都是非超时的正常返回的情况，所以这个值不会被超时的样本影响）。

3. Token消耗量接近，从有效样本的输出token数目上看，基本都是在150-250tokens，说明模型总是会精炼地回答，而不相关于其使用的MCP。

1.3. No Pain No Gain：简单封装去拥抱MCP并未提升工具调用实际性能

为了进一步揭示简单封装MCP是否会带来效果上的帮助，我们引入了两个对照组，对照组1使用Function call的方式使用Qwen-max模型调用搜索引擎（即图中的Qwen web search)，对照组2使用调用夸克搜索作为tool，可以看到对照组1达到了55%的精度，跟Firecrawl search接近，甚至比Brave Search等有名的MCP效果(43-45%)还要好。而对照组2也跟Brave Search的精度接近。从此观察可以看出，从效果上function call的方式跟现在的MCP相比仍有一战之力，甚至比很多MCP方案都要好。更多的讨论，详见MCP Bench社区的持续迭代：https://github.com/modelscope/MCPBench

2. 生产关系的剧变：MCP引发的蝴蝶效应

基于MCPBench的结果，我们可能会发出疑问：一个在工具调用效果上没有显著效果提升的协议为何会受到社区和大厂的拥抱和青睐？在这里，我们从大模型应用开发生态的视角来讨论下MCP究竟做对了什么，解决了什么问题？

首先，我们介绍下构建大模型应用的过程中，通常涉及四个关键角色，它们各司其职又相互配合：

1. 模型厂商（如OpenAI、Qwen）：提供底层大模型能力、负责模型的训练和维护、定期更新迭代基础模型；

2. DevOps应用平台厂商（如Langchain，百炼、Dify）：提供开发框架和工具、简化应用开发流程、处理模型调用、工具集成等复杂性；

3. 工具提供者和业务系统（如Bing Search，高德地图，淘宝业务中台）：提供专业领域的业务能力、封装核心业务接口、维护业务系统的稳定运行；

4. 大模型应用构建者：基于前三方的能力构建实际应用、专注于大模型应用的逻辑设计、实现大模型应用的快速迭代；

接下来，我们来聊一聊应用构建者在MCP协议前后的应用开发范式上的转变。

2.1. MCP前的AI应用困境：搭建容易上线难，上线容易迭代难

轻松搭建AI + 工具应用：以"淘宝智能问答助手"为例，借助Assistant API的强大架构，开发团队仅需约50行代码，就能打造出一个能接收用户查询、智能分析需求、精准调用搜索接口并友好呈现结果的完整应用。在这个流程中，平台悄然处理了复杂的模型调用与工具协调工作，让开发者得以专注于业务逻辑设计，实现了开发效率的质的飞跃。

痛苦的维护与迭代：然而，这种开发便捷的架构在实际应用中却面临严峻挑战。在阿里云服务上百家AI业务伙伴的过程中，我们发现大量协作问题主要源于模型和业务系统的动态变化，静态设计与动态环境之间的矛盾日益凸显。

1. 模型更新困境：应用开发者通常会针对特定版本的大模型优化工具调用方式和结果解析逻辑。当模型厂商推出新版本时，这些优化往往会被过时或出现效果下降。例如，GPT-3.5到GPT-4的升级可能导致原先精心设计的提示词和解析逻辑完全无法适配。这使得业务系统被迫继续使用旧版模型或基于新版本重新开发，无法直接受益于新模型带来的能力提升。

2. 工具变更痛点：在复杂业务场景中，工具接口几乎不可避免地需要迭代更新。当淘宝搜索接口参数结构、返回格式或业务逻辑发生变化时，工具提供方必须联系应用开发者重新配置Assistant，甚至重写部分代码。这种紧耦合关系导致每次微小变更都可能引发跨团队协作，大大增加了沟通成本和出错风险。

3. 维护责任模糊：当系统出现问题时，究竟是模型能力不足、工具接口异常还是应用逻辑缺陷？在多方协作的架构下，问题定位和责任划分变得异常复杂。四个角色之间的依赖关系形成了一个脆弱的平衡，任何一方的变动都可能打破这种平衡。

结论：大模型应用开发已逐渐实现从"低代码"到"零代码"的跨越，极大提升了开发效率。然而，模型厂商、应用平台、工具提供者、应用构建者这四大角色的紧密耦合，在面对模型迭代和业务变更时暴露出维护成本高、责任边界模糊等问题，亟需更灵活的架构设计。

2.2. 溯源应用开发跑起来就不协调的根本原因：分工上的错配问题

这个现象往深了讲，其实我们会发现在Assistant API这类中心化的大模型应用开发范式下，有三个比较难解决的错配问题。

错配1：思考与执行的结构性失衡

在 Assistant API 开发框架下，基础模型的原生能力与工具执行体系存在显著的逻辑断层。作为通用智能系统，大模型的设计初衷是构建开放域问题解决框架，其核心优势在于通过上下文理解、逻辑推理和知识整合形成通用决策路径，这与人类基于认知框架进行问题拆解的思维模式具有本质相似性。然而在工具调用场景中，模型面临双重适配挑战：

1. 工具语义理解偏差：模型对 API 接口的参数定义、返回格式及业务约束的学习效率显著低于通用知识获取，易出现参数配置失当、异常处理缺失等问题。

2. 环境依赖性断裂：训练环境与生产环境的工具调用上下文存在差异，模型在脱离训练时的特定 API 组合场景后，难以动态适配实时变化的业务规则。这种能力断层本质上是通用智能系统与专用工具执行体系的解耦需求未被有效满足。

3. 失去的数据飞轮效应：大模型应用相当多的价值在随着数据积累越来越好用上，这需要应用数据持续回流进入模型训练过程中。强执行细节的数据随业务更新会出现广泛实效现象，使得数据层面的飞轮难以为继。

错配2：中心化开发范式下模型和业务系统变更时的工作权责不明

在模型优化和业务系统动态变化的环境下，中心化的大模型应用开发范式往往面临任何一方变更带来的高昂成本。

1. 应用迭代无法直接受益于模型更新：深度耦合的大模型应用开发范式，导致大量的业务逻辑绑定特定模型版本进行深度优化，通用基座模型的优化和更新，无法直接受益下游应用。

2. 业务系统 & 工具变更痛点：复杂业务系统下的参数更新、接口扩展、以及返回格式的变化，都需要应用开发者重新进行应用开发和迭代，任何工具方变更通知的不及时，都会导致下游应用的服务稳定性缺少保障。

错配3：人才知识结构与分工体系的适配性挑战

大模型应用开发的第三重错配，本质是难以单点优化带来的跨领域能力需求与传统专业分工的结构性矛盾。大模型应用要求开发团队同时具备算法、工程和业务能力，这与传统的单一技能专精模式形成冲突。核心矛盾和现实困境如下：

1. 能力复合化与分工专业化的断层：开发人员需要掌握大模型算法、工程实现和业务逻辑，但传统团队中算法、工程和业务岗位之间存在知识壁垒，导致跨团队协作时出现“语义鸿沟”。

2. 人才供需失衡与协作成本高企：具备算法、工程和业务三维能力的复合型人才市场稀缺（薪酬溢价达60%-80%），且各团队“背靠背”开发时需耗费40%以上研发周期进行需求对齐，系统稳健性过度依赖少数核心成员，违背工程化可扩展性原则。

2.3. MCP煽动的蝴蝶效应：通过Owner的转移，实现生态位间的解耦合

看完2024年在大模型应用构建以及应用全生命周期所出现的种种问题，我们来看看MCP重构了一个怎样的新生产关系。

大模型应用开发常牵扯到模型、DevOps平台、工具方、应用构建者这4方面的深度协作。而在跨团队的协作中，Owner的归属大致会遵循以下两大原则，MCP协议也恰好成为大模型应用开发践行这两大原则的关键钥匙。

原则1：谁有能力做优化，应该归谁

1. 对于大模型效果，基础模型团队有能力基于数据提升其基础能力；

2. 对于应用实现搭建，模型应用团队有能力设计如Prompt、工作流等实现执行逻辑；

3. 对于工具与业务系统的有效性，工具提供商与业务系统团队有能力持续迭代优化其内部效果和效率。

MCP的关键创新在于允许业务系统（MCP Server）与模型应用端（MCP Client）分离：

1. Server端：以高德为例，没有人比高德更熟悉自身的业务逻辑，为了扩大本Server影响力，高德自身有能力和驱动力做Server端的优化。

2. Client端：以OpenAI发布的Agent SDK支持MCP为例，模型厂商最有能力根据自家的Function Calling协议，定制优化MCP的调用效果，而不是依赖简单的Prompt工程。

原则2：谁有动机做优化（和业务的利益最相关），应该归谁

1. 在没有MCP之前：

2. 业务系统方缺乏优化动力：以去年封闭协议的插件市场为例，商业闭环尚未形成，维护成本与开发周期均较高；

3. 模型团队缺乏优化动力：其更聚焦通用能力提升，而通用能力提升难直接转化为业务落地效果；

4. 开发者缺乏优化动力：未建立合理商业分佣模型，多平台插件开发模式难以持续，且封闭生态导致应用落地依赖单一平台。

5. 有了MCP后，以MCP Bench为例，可以清晰的衡量模型能力和MCP的能力边界，使得双方均有极强的动机进行提升各自性能，因为自己的能力提升可以实打实地为其他模块贡献价值，并逐渐形成彼此独立且解耦的模型市场和MCP市场。

1. 回顾上一章节提到的基于Assistant API中心化开发范式的种种错配问题，基于MCP新范式，模型优化和业务系统优化变得相对独立，大家的迭代优化是在去中心框架下自发有序形成的。应用开发者不再需要苦于在中心化的框架下，同时关注模型更新、业务逻辑和服务生命周期的种种问题，让对的人真正做对的事情，从而实现整个行业和领域的加速发展。

结论：MCP协议通过接口设计重构了大模型应用生态关系，解决了中心化框架下的错配问题，让各参与方能够去中心化地专注于优势领域并有动力做持续优化，实现"专业的人做专业的事"。

3. MCP时代我们应该做什么：新生产关系下的发展建议

当然，我们也要冷静的看待，目前版本下的MCP，还只是简单的一层HTTP封装，并没有凭空解决掉刚才我们提到的种种问题。但是MCP在生产关系层面所掀起的蝴蝶效应，让我们也看到了MCP生态正在逐渐形成一个大模型应用生态的新协作范式，能够让生态中的各类参与者，都能在这么一个比较一致预期的愿景下，做出各司其职的优化。

3.1. 模型厂商：通用推理-交互能力的不断进阶

持续推动通用推理模型（General Reasoning Model）的演进和持续优化。以Manus项目引爆的Super Agent市场，我们看到MCP正在加速整个领域的发展周期，其本质是解决大模型与外部世界的交互问题。除了通讯协议的建设，更需要模型参与者不断提升基础模型的理解能力、思考能力，与环境的通用交互能力。例如复杂任务场景的优化往往需要基础模型具备对多个MCP工具的理解、规划和调度能力。以底层依赖的Function Calling能力为例，OpenAI O3 mini在GPT 4o的基础上进一步得到能力增强。今天我们看到的Cursor、OWL一类优秀的产品和开源项目，背后也是得益于基础模型能力的不断提升。在MCP时代，模型参与者可以更专注于通用性的提升，期待模型厂商在通用工具理解、复杂任务拆解、以及与物理世界的交互优化上，能够脱离于琐碎的交互环境细节，针对通用交互-思考迭代的工作模式（Reasoning Model with Unified Interaction Interfaces），做出基础技术的突破。

3.2. DevOps平台：生态共建、利益共享

MCP 协议重塑大模型应用开发的平台生态。以阿里云为例，其 MCP 服务已接入超过 50 款第三方工具（如高德地图、无影云电脑），开发者通过简单配置即可构建智能体（Agent）应用，开发效率提升 60% 以上。这种生态繁荣的背后，是 MCP 协议标准化接口（Standardized Interface）与利益分配机制的双重驱动：工具开发者通过开放 MCP Server 获取流量分成，平台方则通过协议层基础上的增量服务实现可持续收益，如服务的部署、安全认证、资源的弹性扩缩容，商业模式回归云厂商。

除了保障基础的生态管理，平台参与者还可以用以下方式进一步的帮助MCP的开发和使用：

• 更好的鉴权和密钥管理：MCP涉及大量工具的密钥，比如Brave search的Key，Github 的token等等，这些密钥在MCP部署启动时需要明文使用，而其运行环境却并不一定安全，所以平台参与者可以构建更加安全的密钥管理，存储以及传输机制，以提高MCP服务的安全性

• 更好的资源管理：MCP的运行也需要CPU，存储等资源，甚至一部分嵌入了LLM的MCP还需要使用GPU资源，这些资源如果分散在各处不仅不利于管理，并且利用率不高，平台参与者可以设计更加弹性的资源分析机制，并使用弹性的计算容器，提高MCP的资源使用率

• 更好的利益共享：目前市面上大部分MCP都是免费的，一部分需要通过Key来收费，这种现状也是由于头部效应所产生，即少量高质量的MCP被广泛应用，而长尾的的MCP却无人问津。但长尾的MCP未必等于低质量，所以平台可以设计更好的利益共享和分配机制，帮助长尾的MCP获得一定的流量或者收益，使得整个平台的MCP的多样性得以保证。

3.3. 工具提供者与业务系统：业务透明化与声明式接口

工具提供者与业务系统在 MCP 协议下的核心使命，是通过透明化业务变更（Transparency of Business Changes）降低开发门槛。MCP协议进一步扩展了自然语言交互的边界，这种能力的实现依赖于 MCP 协议的声明式接口（Declarative Interface）—— 开发者无需编写复杂的 API 调用代码，只需定义业务逻辑的声明式描述（如 "输入：自然语言查询；输出：结构化数据"），MCP 协议会自动完成接口适配与数据流转。

让我们以数据库工具为例，来看这个声明式接口如何帮助工具参与者对MCP优化，以及优化能带来怎样的升级和改变。数据库查询场景有很多官方和社区维护的MCP，比如PostgreSQL MCP，MySQL MCP Server。这些工具都实现了一个很简单的对数据库连接的封装，在配置好数据库账号密码等信息之后，这些MCP会建立一个跟数据库的长连接，然后暴露一个execute_sql的工具接口。在调用这个工具时，模型需要构造一个query参数，其内容需要是可执行的SQL。这个简单的封装虽然是一个MCP，但把这个过程里面最有难度的一个部分（构造SQL查询语句）留给了LLM，整个工具调用的成功与否实际上非常依赖LLM的SQL构造能力。

我们在一个开源测试集SQL-eval上测试了一下官方的PostgreSQL-mcp-server的精度，结果如下表所示。

不同搭建方式的数据库查询MCP的执行效率（Test by MCP-Bench）

那如何用声明式接口来优化这个MCP呢？一个直接的思路是，我们能不能让这个MCP本身再智能些，让LLM调用MCP的时候更简单一些，比如降低参数构造的难度。在实验中，我们构造了一个实验组（析言MCP xiyan-mcp-server），将这个execute_sql工具替换为一个get_data工具，其参数不再是SQL，而改为对LLM更友好的自然语言的形式，从而大大降低LLM调用的难度。关于析言项目的介绍，详见https://github.com/XGenerationLab/XiYan-SQL。

Xiyan 声明式接口设计（declarative interface）方案

接口一旦确定了，我们在原官方mcp的实现上作如下改动：在MCP内部先调用一个text-to-sql的在多个榜单上sota模型XiyanSQL-qwencoder-32B，来将自然语言转为SQL，再去执行。这个改变也就给原来的MySQL-mcp-server装上了一个大脑。从实验上看，在xiyan-mcp-server可以达到80%的精度，比原来的postgreSQL-mcp-server提高了近22pt。按这个方式，我们也在MySQL-mcp-server上做了这个实验，也带来了5pt的提升。因此，声明式接口改造可以给未来MCP透明化开发带来新生产力。

4. 结语

MCP通过协议层标准化设计重构大模型应用生产关系，虽当前技术实现尚未突破效果瓶颈，但其解耦协作框架已明确划分模型、平台、工具三方权责——模型聚焦通用推理迭代，DevOps平台构建MCP效果管理体系，工具通过更透明的声明式接口释放价值。

阿里云百炼与ModelScope作为国内首批支持平台，将持续深耕MCP生态建设，赋能AI应用落地。行业需以务实态度看待技术演进：既不夸大短期效能，也不忽视长期生态价值。MCP的产业实践刚刚起步，这不是技术概念的狂欢，而是新生产关系所将产生价值重构，让我们一起期待MCP为大模型应用开发带来的种种新可能。

---

参考链接

MCPBench开源项目：https://github.com/modelscope/MCPBench

MCPBench评估报告：https://github.com/modelscope/MCPBench/blob/main/mcpbench.pdf