大模型上下文协议(MCP):标准化接口驱动AI货币化新机遇

MCP通过标准化接口赋能AI应用,简化集成,加速货币化。如同AI领域的USB-C接口,或将重塑AI生态。

原文标题:大模型上下文协议 MCP 带来了哪些货币化机会

原文作者:阿里云开发者

冷月清谈:

本文深入探讨了大模型上下文协议(MCP)兴起的原因及其带来的变革性影响。MCP通过标准化的方式简化了大模型与外部数据、API和系统的集成,解决了传统集成方式的碎片化问题,实现了从N x N到One for All的演进。文章对比了MCP与Function Calling,指出MCP在跨平台和标准化工具集成方面更具优势,而Function Calling在模型主导的动态决策和实时任务执行中仍然不可替代。MCP的成熟不仅改变了AI Agent服务的供应端,更深刻地影响了消费端用户的使用体验,推动了AI编程从辅助工具向程序员代理的质变,并实现了从“被动应答”到“主动共创”的转变。此外,文章还分析了MCP如何加速大模型的货币化,并探讨了在MCP生态系统中,网关和可观测的重要性,最后对MCP的未来进行了展望。

怜星夜思:

1、文章提到MCP类似于AI领域的USB-C接口,但国内大模型厂商尚未大规模跟进,你觉得MCP最终能否像USB-C一样成为事实标准?如果不能,可能的阻碍是什么?
2、文章提到Higress和Nacos等开源项目在MCP生态中的作用,你认为云原生技术在推动AI Agent发展中扮演了什么角色?除了文章提到的,还有哪些云原生技术可以赋能AI Agent?
3、文章提到MCP加速了大模型的货币化,你认为对于开发者来说,参与MCP生态建设的最佳切入点是什么?

原文内容

打开这篇文章的读者,都有一致的观察,2月中旬开始,MCP 火了。我们来看看反映开源项目热度的两个关键指标,GitHub Star 和搜索指数。

Star 从2月开始,加速增长:

微信指数,从2月开始,出现流量突增:

从社群的交流看,预计4月,国内会集中出现一批 MCP 中间件提供商,包括 Server、Client、Server hosting、Registy、Marketplace 等,在各自原有的优势领域进行延展。本文旨在进一步厘清一些易混淆的概念,并分享看到的一些货币化机会,以及我们在 MCP 上的计划和进展。 

一、为什么 MCP 火了?

MCP 在大模型和第三方数据、API、系统的交互过程中,用单一的标准协议取代碎片化的集成方式[1],是 N x N 向 One for All 的演进,能以更简单、更可靠的方式让人工智能系统获取所需数据。

MCP 是去年11月发布,迅速获得市场的第一波关注;今年2月,Cursur、Winsurf、Cline 均开始引入 MCP,不同于前期已经接入的上千家被调用方,AI 编程引入 MCP,可以认为是吹响了大模型生态效应的号角,将 AI 编程工具端的大量开发者引向被调用方,以唤醒规模巨大的存量应用和系统。

从产业链的视角看,这不仅能解决 AI 应用和海量经典在线应用孤岛化、碎片化的现状,也能大幅提升 AI 编程工具的使用深度、扩大使用群体,还给 AI 应用带来了足够大的货币化空间,以及给经典在线应用引入更多的流量,甚至还能催生自然语言使用专业软件的市场,举个例子,Blender MCP 将 AI 连接到 Blender,就可以通过简单的文本提示来创建、修改和增强 3D 模型。

在这个生态内,MCP、AI 类应用、AI 编程工具、经典在线应用都是受益方 ,谁先接入谁先获益。OpenAI 宣布支持 MCP,将加速 MCP 成为 AI 原生应用的核心基础设施。P.S. 由于国内大模型还未在大模型上下文协议有所动作,MCP 最终能否成为事实标准,在国内依然存在不确定性。

从关键生产力程序员的视角看,程序员现在无须切换到 Supabase 来检查数据库状态,而是可以使用 Postgres MCP 服务器执行只读 SQL 命令,使用 Redis MCP 服务器直接从 IDE 直接和 Redis 键值存储进行交互。在迭代代码时,还可以利用 Browsertools MCP 让编码代理访问实时环境以进行反馈和调试。这个并不新鲜,程序员使用云产品的时候,也会更倾向于使用 API 方式来调用云产品的能力,而非在多个云产品的控制台上之间跳转。

程序员往往是新技术的早期采用者,随着 MCP 的成熟,普通消费者也可以通过自然语言,助推 MCP 产业链的繁荣。

二、MCP 越成熟,Function Calling 越无用武之地?

首先,MCP 和 Function Calling 都是大模型调用外部数据、应用和系统的技术实现方式。MCP 由 Anthropic 在2024年11月底推出,Function Calling 由 OpenAI 在2023年6月首次提出(即创建一个外部函数作为中介,一边传递大模型的请求,另一边调用外部工具,其他大模型大多也采用这类技术方案)。但是他俩在定位、开发成本等方面有着较明显的差异。

定位不同:

  • MCP 是通用协议层的标准,类似于 “AI 领域的 USB-C 接口”,定义了 LLM 与外部工具 / 数据源的通信格式,但不绑定任何特定模型或厂商,将复杂的函数调用抽象为客户端-服务器架构。
  • Function Calling 是大模型厂商提供的专有能力,由大模型厂商定义,不同大模型厂商之间在接口定义和开发文档上存在差异;允许模型直接生成调用函数,触发外部 API,依赖模型自身的上下文理解和结构化输出能力。

开发成本不同:

  • Function Calling 的技术实现过程,以 OpenAI 为例,需要为每个外部函数编写一个 JSON Schema 格式的功能说明,精心设计一个提示词模版,才能提高 Function Calling 响应的准确率,如果一个需求涉及到几十个外部系统,那设计成本是巨大,产品化成本极高。

  • MCP 把大模型运行环境称作 MCP Client,同时,把外部函数运行环境称作 MCP Server,统一 MCP 客户端和服务器的运行规范,并且要求 MCP 客户端和服务器之间,也统一按照某个既定的提示词模板进行通信,这样就能通过 MCP Server 加强全球开发者的协作,复用全球的开发成果。

交互方式不同:

  • MCP 通过标准化的客户端 - 服务器架构实现双向通信,需开发者预先配置服务器并定义接口。
  • Function Calling 由模型主动触发,模型在生成文本时直接插入调用请求(如 JSON Schema 格式),宿主应用解析后执行并返回结果。

与模型能力的深度耦合:

  • Function Calling 通常与模型的上下文理解深度绑定。例如,GPT-4 的 Function Calling 可利用模型的推理能力优化调用参数,或根据返回结果调整后续生成内容。

  • MCP 作为通用协议,需通过标准化接口传递信息,可能牺牲部分与特定模型的协同优化空间。

实时性与低延迟需求:

  • Function Calling 的调用逻辑直接嵌入模型响应流程,适用于对实时性要求高的场景(如在线支付、实时数据分析)。
  • MCP 需通过 MCP 服务器中转,可能增加延迟,尤其在跨网络调用时。

总的来看,MCP 的全面适配会减少对 Function Calling 的依赖,尤其是在跨平台、标准化工具集成场景中。但是 Function Calling 仍将在特定场景中不可替代,例如模型主导的动态决策、实时任务执行、专有生态集成等,并且在一些轻量化的调用场景中,Function Calling 在实效性方面更具优势。未来,两者可以形成互补,MCP 成为基础协议层,Function Calling 作为模型增强层,共同推动 AI 与外部世界的无缝交互。

三、MCP 改变的是供应端,变革的却是消费端

不同人对供应端和消费端的理解有所不同,我们对供应端和消费端在本文中做一个定义:

  • 供应端:提供 AI Agent 服务的产业链,包括云厂商、大模型、AI 应用(包含 AI Agent)、经典在线应用、各类 AI 中间件服务商等。

  • 消费端:使用 AI Agent 的终端用户。

首先不得不提 Devin 和 Manus。

Devin 的出现,是 AI 编程从编程辅助工具向程序员代理的质变,不再仅仅是代码补全和辅助生成,而是能覆盖从需求分析→代码编写→测试→部署→Bug修复全程,独立处理完整任务的,Devin 变革的是程序员群体(国内用户使用程序员代理,推荐灵码);Manus 变革的则是广大普通的互联网用户,用户和 AI 的交互,不再仅仅是一问一答的对话机器人服务模式,而是能调动 AI 应用以外的互联网在线服务,自主、完整地实施用户想法的通用 AI 代理,实现了从“被动应答”到“主动共创”的质变。

结果越是智能,过程越是复杂。“认知负荷是工程效能的核心阻碍”这一观点,在 AI Agent 上表现更甚。因此 AI Agent 对高效的开发和工程范式需求更加强烈。

不同于经典互联网,AI Agent 的产品化和工程化更加复杂。电商应用满足了用户不出门就能购物的需求,聊天应用满足了用户不出门就能社交的需求,是一种体力替代,AI Agent 则是一种脑力和心力替代,帮助用户完成从基础生存到高阶创造的全链条活动。若仅依赖于 Function Calling 来调用外部应用,显然不是一种高效的开发范式。MCP 才能让开发者可以更加便捷的手搓下一个 Manus。他好比是互联网世界的 HTTP 协议,让所有客户端和网站,均基于同一个规范进行通信,并由此推动全球开发者共同协作,加速 AGI 的到来。

四、MCP 加速了大模型的货币化?

从我们的观察来看,确实如此。

以 Firecrawl 为例,这个开源项目提供:

  • 全面抓取数据网站数据:自动爬取整个网站的所有可访问子页面,无需依赖站点地图。

  • 数据清洗与格式化:将爬取的网页内容自动转换为干净的 Markdown 或结构化数据 ,去除广告、导航栏等无关信息,丢弃页面噪音。

  • 处理调取数据、无须再加工:既可无缝对接模型,直接输出 LLM-ready 的格式,还能被各类 AI 编程框架集成,加速数据预处理流程。

在支持 MCP 之前,Firecrawl 已具备全自动网页爬取能力,但依赖传统技术实现,用户需通过 REST API 或 SDK 手动调用 Firecrawl 服务,无法直接与大模型无缝集成。Firecrawl 今年1月通过与 Cline 平台的集成,正式引入了 MCP 协议,开发者可通过 MCP 服务器调用 Firecrawl 的爬取能力,实现“AI模型直接控制网页抓取”的自动化流程。更重要的是,用户不担心协议绑定影响可扩展性,毕竟要实现更丰富的大模型能力,需要依赖多个类似 Firecrawl 的大模型中间件供应商。因此,MCP 是打开了大模型中间件供应商们的网络效应,加速了这类玩家的变现能力。

a16z Infra 团队绘制了一张 MCP Market Map[2] 。这个图涵盖了 MCP 生态当今最活跃的领域,尽管仍有许多空白,但对国内的创新会带来诸多启发。

随着 MCP 的采用率不断提高,基础设施和工具将在 MCP 生态系统的可扩展性、可靠性和可访问性方面发挥关键作用。由此带来一个可能会完全不同于经典互联网产业链的结果:to B 领域的机会将比 to C,更加丰富。

  • MCP Client:作为调用方,是用户与 MCP 生态的交互入口,聚焦终端功能的实现。例如,聊天应用类(如 Claude),提供自然语言交互服务,让用户通过对话调用 AI 能力;编码工具类(如 Cline、Cursor),AI 编程场景,在 IDE 里调用外部应用和系统的能力;任务自动化类:帮用户自动化执行重复性任务,如数据处理、流程调度,以提升效率。Manus 就是典型的 MCP Client。

  • MCP Server:作为被调用方,提供后端服务支撑,包括各类核心功能模块。例如,数据库类(如 ClickHouse、Supabase)负责数据存储、查询与管理;设计类(如 Figma、Blender),支撑设计创作、文件协作等功能;生产力工具类(如 Notion、Obsidian),提供笔记管理、知识整理等办公协作服务;支付类(如 Stripe),处理在线支付交易,支持商业场景的资金流转。

  • MCP Marketplace:扮演生态枢纽角色,聚合与分发 MCP 相关工具,类似 “应用商店”。一方面,开发者可在此发布 MCP 客户端、服务器工具;另一方面,用户能便捷发现和使用各类 MCP 工具(如 MCP.so、Glama),促进生态内资源的流通与共享。

  • Server Generation&Curation:聚焦 MCP 服务器的开发与维护。提供工具或框架(如 Mintlify、Stainless)辅助服务器开发,简化搭建流程;优化服务器配置、功能迭代,确保服务器性能稳定,适配不同业务场景需求。

  • Connection Management:协调 MCP 生态中各组件的交互。管理客户端与服务器、服务器与服务器之间的连接,确保数据传输高效;优化连接稳定性,处理网络协议适配、请求路由等,保障生态内交互流畅。

  • Server Hosting:为 MCP 服务器提供运行环境支持。借助云计算等基础设施(如 Cloudflare、Smithery),托管服务器代码与数据;负责服务器的运维、扩容、安全防护,保障服务器持续稳定运行。

近日,Higress 作为 AI 原生的 API 网关,开源 Remote MCP Server 托管方案,实现存量 API 到 MCP 的无缝转换。该方案已经被 Anthropic 官方采纳,并发布至 MCP GitHub 介绍页。

此外,Nacos 发布 MCP Registry,实现存量应用接口“0改动”升级到 MCP 协议。作为 MCP Registry,Nacos 扮演控制面的角色,提供存量的服务管理和动态的服务信息定义,帮助业务在存量接口不改动的情况下,通过 Nacos 的服务管理动态生效 Higress 网关所生成的 MCP Server 协议。

Nacos + Higress 的组合,再加上 Apache RoceketM、OTel 等开源方案,正最大化复用云原生的存量技术组件,极大降低经典互联网应用构建 AI Agent 的构建成本。

阿里云资深技术专家李艳林(彦林)绘制

五、MCP 生态越繁荣,越依赖网关和可观测?

MCP Server 是功能服务的封装,其本质是通过 MCP 协议提供标准化接口的服务端。但凡涉及跨网访问,就需要身份验证、授权、数据加解密、防攻击机制等。此时,便需要一个面向 MCP Server 管控的 MCP 网关了。

与 API 网关类似,MCP 网关将强制执行访问控制、将请求路由到正确的 MCP 服务器、处理负载平衡并缓存响应以提高效率。这对于多租户环境尤其重要,因为不同的用户和代理需要不同的权限。标准化的网关将简化客户端与服务器之间的交互、提高安全性并提供更好的可观测性,从而使 MCP 部署更具可扩展性和可管理性。

  • 身份验证:验证用户、设备或服务的身份,防止未授权实体接入生态。例如,用户登录 MCP 客户端(如 Claude)时,通过账号密码、令牌等方式验证身份,避免恶意攻击或非法访问。

  • 授权:提供权限精细化的控制,在身份验证通过后,决定用户或服务可执行的操作范围。例如,普通用户仅能使用基础 MCP 服务器功能,而高级用户或特定服务可获得数据库读写、敏感工具调用等更高权限。

  • 流量管控:实现请求过滤、速率限制、协议转换等功能。例如,对高并发请求限流,拦截非法请求,统一处理加密传输,提升生态整体安全性与稳定性。

以上能力,已在 Higress Remote MCP Server 托管方案实现。

在 MCP 生态中,由于调用关系更加复杂和多样,可观测也是不容忽视的基础设施:

  • 故障排查与问题诊断通过日志收集记录生态中各个组件(如 MCP 客户端、服务器 )运行时的离散事件,在出现问题时,开发和运维人员能依据这些记录追溯系统行为,快速定位故障点。链路追踪则可分析请求在不同组件间的调用路径,判断哪一部分出现错误、阻塞,以及输入输出是否符合预期,帮助排查跨组件交互时产生的问题。此外,还可以通过调用链对调用情况进行分析。

  • 性能优化聚合度量对系统资源使用情况(如 CPU、内存占用)、响应时间、吞吐量等关键指标进行统计分析,找出性能瓶颈,为优化系统配置、调整架构提供依据。比如发现某 MCP 服务器在高并发下响应缓慢,就可以针对性地优化代码或增加硬件资源。

  • 服务质量监控实时监测 MCP 生态内服务的运行状态和可用性,及时发现服务中断、延迟过高等影响用户体验的问题,并触发相应的预警机制,以便运维人员快速响应处理,保障服务稳定可靠。

作为标准化的地图服务能力平台,高德已率先推出其 MCP Server,提供12大核心功能,助力企业级智能体应用开发。我们预计,国内将快速诞生一大波 MCP Servers 和 MCP 中间件,加速 AI Agent 的产品化和工程化。

[1] https://mp.weixin.qq.com/s/zYgQEpdUC5C6WSpMXY8cxw

[2] https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

[3] https://github.com/alibaba/higress/tree/main/plugins/wasm-go/mcp-servers


个人认为,MCP要成为国内的事实标准,需要解决以下几个问题:一是各大厂商的利益博弈,如何让他们愿意放弃一部分控制权,拥抱通用标准?二是技术上的适配难度,毕竟各家大模型的底层架构和API接口都不一样。三是市场推广的力度,如何让更多的开发者了解和使用MCP,形成规模效应?如果这些问题解决不了,MCP在国内的普及之路可能会比较坎坷。

云原生这套东西,本质上就是为了解决大规模分布式应用的管理和运维问题。AI Agent 要想真正落地,肯定离不开云原生的支撑。比如,AI Agent 需要大量的计算资源,云原生提供的弹性伸缩能力就能很好地满足这个需求;AI Agent 的各个组件之间需要频繁通信,云原生提供的服务发现和负载均衡能力就能保证通信的效率和稳定性。至于其他的云原生技术,我觉得像事件驱动架构、serverless computing等,都能在特定场景下发挥作用。

云原生技术在AI Agent发展中扮演着至关重要的角色。首先,容器化技术(如Docker)和容器编排系统(如Kubernetes)为AI Agent提供了轻量级、可移植和可扩展的运行环境。其次,服务网格(如Istio)简化了AI Agent之间的通信和管理,提高了系统的可靠性和可观测性。此外,无服务器计算(如AWS Lambda)使开发者能够专注于AI Agent的业务逻辑,而无需关心底层基础设施的运维。除了文章提到的,还有像云原生数据库、消息队列、API网关等都可以赋能AI Agent。

从技术角度看,MCP的优势在于通用性和解耦,降低了集成的复杂度和成本。但国内大模型厂商在商业考量上可能会有所不同,他们可能更倾向于构建自己的生态系统,以便更好地控制数据和用户。因此,MCP要成为事实标准,需要克服生态竞争和技术兼容性等方面的挑战。

云原生技术就是AI Agent的“基建”,没有这些基础设施,AI Agent很难规模化。我觉得像微服务架构、DevOps、GitOps这些理念,对于AI Agent的开发、部署和运维都很有帮助。此外,像Service Mesh这种服务网格技术,可以帮助AI Agent实现更精细化的流量控制和安全管理。总而言之,云原生技术为AI Agent提供了一个可靠、高效、可扩展的运行平台。

我觉得这事儿挺难说的。USB-C能成,很大程度是硬件接口的标准化需求非常刚性,不用就没法充电、传输数据。但AI这块,各家大模型都有自己的生态和技术路线,短期内可能还是会优先考虑自家体系内的兼容性。而且,即便都支持MCP,各家在具体实现上可能也会有一些差异,导致互操作性受限。除非出现一个强有力的推动者,比如国家层面的标准制定,否则很难统一。

我感觉从Server Generation & Curation这个方向入手比较有潜力。现在MCP Server的开发还比较复杂,如果能提供一些工具或者框架,简化MCP Server的开发流程,肯定会受到开发者的欢迎。就像Spring Boot之于Java开发一样,如果能有一个类似的框架来简化MCP Server的开发,那市场前景肯定非常广阔。

对于开发者来说,参与MCP生态建设的最佳切入点取决于自身的技能和兴趣。如果擅长后端开发,可以考虑开发MCP Server,提供各种有用的功能和服务;如果擅长前端开发,可以考虑开发MCP Client,让用户更方便地使用AI Agent;如果对数据处理和中间件比较熟悉,可以考虑开发MCP Marketplace,帮助用户发现和使用各种MCP工具。总之,选择自己擅长的领域,并结合市场需求,才能在MCP生态中找到自己的位置。

我觉得最好的切入点是解决实际问题。可以先调研一下,看看现在有哪些AI应用或者行业痛点可以用MCP的方式来解决。比如,可以尝试开发一个基于MCP的智能客服系统,或者一个基于MCP的自动化数据分析工具。通过解决实际问题,不仅能快速积累经验,还能更容易获得用户认可和商业机会。