华为大咖说丨AI界爆火的MCP（模型上下文协议）是什么？前景如何？

全文约4192字，阅读约需7分钟

---

MCP（模型上下文协议），Model Context Protocol，“AI 应用的 USB-C 接口”，通过提供标准化的交互方式，使AI模型能连接多种外部应用程序和服务。自2024年面世以来，受到全球多家模型、应用公司关注，但生态仍待完善。面向未来，在技术发展演进阶段，其有长期存在价值；从商业视角看，MCP 在 To C 业务中应用场景广阔，而 To B 业务中价值有待发掘。

01 黑盒视角看MCP

 在人工智能快速发展的当下，大型语言模型（LLM）展现出理解人类意图并生成连贯文本的强大能力。然而，人们期望 LLM 不仅能“回答问题”，更能够“解决问题”，即通过调用各类工具或 API 来完成实际任务。这背后带来两个问题，一个问题是“如何让LLM更易于调用工具（API）？”，另一个是“如何让LLM更准确的调用工具（API）？”。

MCP（Model Context Protocol）应运而生，其核心目标是解决第一个问题——工具调用的便捷性：MCP 受 LSP（Language Server Protocol，语言服务器协议，是对开发工具与语言服务器进程之间交换的消息进行标准化的产物 ）启发，于 2024 年 7 月由 Anthropic 的 David 和 Justin 创建，旨在标准化 AI 应用与扩展间的通信。在 MCP 框架下，工具可以类比为各种便携机外设，有耳机、U盘、投影仪、键鼠等，而 MCP 则像是便携机的拓展坞，为 LLM 提供统一接口，使其能够轻松连接并调用各种工具或服务，无需关心底层通信协议和消息格式差异。

02 白盒视角看MCP架构

 把 MCP 打开，我们先看其通用架构：

从架构上来看，MCP 包括 Host、Client 和 Server 三大核心组件。

◆ Host 是基于 LLM 的应用，它作为中枢，负责管理 Client 实例、调度模型与工具交互，以及处理用户界面逻辑。

◆ Client作为“通信代理” 嵌入 Host 中，和 Server 是 1:1 对应关系。

◆ Server则是轻量级程序，用来暴露服务。

MCP 通过定义 Client 与 Server 之间的标准化通信协议，将 LLM 与工具的交互转化为统一的 client - server 模式，其传输层基于 JSON - RPC 2.0 消息格式，涵盖本地和远程两类通信方式。

可见，Client – Server的交互是MCP的核心，如下图：

MCP Client 和 MCP Server 有着明确分工。MCP Client 负责调用工具、查询资源以及处理提示词。MCP Server 则是把工具、资源和提示词暴露出来。其中，工具由模型控制调用，像检索、发送消息、更新数据库记录等；资源由应用控制，包括文件、数据库记录、API 响应等数据；提示词是用户控制的，像文档问答、文本摘要等预定义模板，方便 LLM 学习和使用。这种关系使得能力（工具）和资源相互独立，LLM 掌握能力，应用掌控数据 。

 

03 MCP如何构建？

 在构建阶段，MCP 需要完成 Host 与工具的连接。也就是让Host要知道可以调用哪些工具可供调用。

 我们可以把Host理解成一个我们正在用的应用软件APP，他是包含LLM的AI Agent，已经预置了一些能力，实现了这些能力的“开箱即用”。据网上搜索，数千甚至更多的公开能力已经通过github等平台发布。这种能力，是静态的。一般是面向高频使用的、核心的工具。如果只有这种方式，MCP就失去意义了，因为预置的，可以由该应用软件APP厂家自己完成集成，完全可以适配各种消息格式、通信协议等。（备注：Longchain CEO观点：MCP定位面向非开发者，为不可控的Agent提供工具接入能力。）

 所以，还有一种“动态”新能力动态上线机制。由工具（Server）发起，通过注册中心（Registry，需要单独部署）动态声明自身能力，Host 实时发现并创建对应的 Client，实现能力的动态扩展。这样，对于APP的用户来说就实现了按需、快速扩展能力，甚至千人千面。这一过程中，server将工具、资源、相关Prompt传递给client，然后通过client让LLM分析并掌握如何调用工具。

 通过这两种方式，MCP 框架既能保证基础能力的稳定性，又能灵活扩展新功能，实现 “核心能力可控，长尾能力无限” 的架构目标。

 

04 MCP如何运行？

 在运行阶段，也就是这个应用程序APP在用户的使用过程中，如何完成闭环。

这个时序图很清晰地描述了整个过程。核心是LLM，它作为大脑，承担工具选择、流程编排和结果整合的核心职责，包括：

• 语义理解能力，精准解析用户意图，比如将 “生成一张猫的图片并发送到邮箱” 拆解为 “图像生成” 和 “邮件发送” 两个工具需求；
• 动态推理能力，能结合历史对话、工具反馈等上下文，灵活调整调用策略，如遇失败自动重试或替换工具；
• 目标导向编排能力，将复杂任务拆解为工具调用序列，例如 “生成报告” 任务，优先调用数据查询工具获取数据，再利用文档生成工具输出结果。

 此外，目标导向编排能力也至关重要，LLM 要能够将复杂任务分解为一系列工具调用步骤，并按照合理顺序执行。基于这些能力，MCP 的工具选择与编排采用动静结合的模式：

1.静态编排通过可视化界面或声明式 DSL 预定义工具调用流程，适用于重复性强、流程固定的任务。

2.动态编排则依赖 LLM 根据用户查询、工具注册表和上下文实时生成执行计划，适用于复杂多变的场景。

05 MCP的未来

截至目前，MCP 已赢得众多行业玩家的青睐与支持。公开数据显示，MCP 平台、Smithery、PulseMCP、Glama 及 GitHub 等生态发布的 Server 工具总量超万款。国内众多头部企业也已接入 MCP 协议并提供服务。

5.1  协议优化维度 

面向规模化商用，MCP 生态还需在多维度持续打磨：

1.  部署轻量化：当下多数 MCP Server 需本地运行或手动配置服务器环境。未来要简化部署链路，推动 Web 化一键启动和 Serverless 化改造，降低开发者门槛，尤其助力中小团队快速集成。
2.  多租户架构：要构建标准化多租户体系，实现控制面与数据面分离，确保租户间数据隔离；借助负载均衡共享计算资源，提升高并发场景下的服务稳定性。
3.  全链路认证体系：现有应用多用于本地测试或非敏感场景，商用需强化认证机制，涵盖 Client 端接入授权、工具端来源可信、租户级权限控制和资源隔离等
4.  智能网关建设：搭建统一入口，实现身份权限校验、动态路由选择及高频响应缓存，提高调用效率与流量治理能力。

5.2  未来发展视角 

 技术视角

MCP 聚焦于解决 “LLM 调用工具便捷性” 问题，但 “LLM 调用工具准确性” 同样关键。从技术理论上看：

✦ LLM能力进阶：随着大模型持续进化，LLM 将更精准地筛选、调用和编排 API，若其能灵活适配不同应用 API 的协议与格式，完成调用闭环，MCP 作为中间件的必要性将大大降低。也就是说，当便携机的接口能灵活的变化、扩展的时候，就不需要统一的Type-C 拓展坞了。

✦ API演变趋势：API 正向面向 LLM 大模型转变：

✔ 一方面，API颗粒度从原子级的、海量而冗余（在长期代码开发中导致的问题）的，到应用级或者说业务级，实现API聚合。

✔ 另一方面，随着应用的主体的智能化提升，其所暴露的API形态，将会从传统面向结构化数据的，向支撑非结构化数据、类自然语言接口转变。

也就是说，未来API分为两类：

✔ 一类是面向结构化数据的、进行了聚合的业务级API，也是ADN说描绘的意图API，这类API主要是基于基础网络数据所聚合的。

✔ 另一类是面向非结构化数据的类自然语言的接口，这类API主要是基于“人”的多样化、具有不确定性的诉求的。两类API结合起来，能极大简化LLM调用的复杂度，并提升调用的准确性。

综上，技术目标态下MCP或将失去存在价值。但在面向目标态的持续演进过程中，MCP 能显著提升 LLM 调用工具的便捷性，将长期发挥作用。

 商业视角

站在商业角度，MCP协议存在性来看，主要机会在面向To C的业务中，面向To B的业务可能面临较大挑战。

 To C 业务机遇：

在To C领域，我们可以把相关的产品分成高频交互类和低频操作类两种类型进行分析。

1.高频交互类产品

从硬件角度看，便携机、手机、智能手表、智能电视等属于高频交互类产品。高频交互的特性使得这类产品对计算能力、迭代升级速度以及开放生态构建有更高要求。运行在这些硬件上的系统软件，如Windows、鸿蒙、安卓、iOS等，本身具备提供MCP Host能力的优势。通过预集成，这些系统软件可以与工具类应用（如HarmonyOS NEXT的小艺集成导航、订票等功能）实现联动。此外，考虑到To C市场用户需求的多样性和自主性，部分社交平台、即时通信工具以及LLM（Large Language Model）应用等也具备构建和提供MCP Host的潜力。

从软件视角来看，构建MCP Host能力并主动集成更广泛的工具，能够更大程度地实现用户意图的闭环。这一过程不仅能提升用户体验，还能抢占未来智能时代的用户入口，从而为企业带来竞争优势。

2.低频操作类产品

低频操作类产品包括智能冰箱、智能音箱、扫地机器人等硬件，以及订餐、购物、新闻、导航、邮件等软件应用。这些产品工具属性强，应用范围明确，更新迭代速度相对较慢，且用户对其更新的感知度较低。为了增加销量和用户基数，这些产品一直在探索新的功能和卖点。例如，智能冰箱可以实现自动下单购物，导航软件可以提供酒店预订等功能。通过支持MCP协议，这些产品能够更加主动地被调用，从而成为增加卖点的有效手段。如今，许多家电产品宣传其智联能力（如通过手机APP操控）也是基于类似的逻辑。

综合来看，无论是高频交互类产品还是低频操作类产品，主动拥抱MCP协议都是面向智能时代增加用户基数、提升销量和增强用户粘性的有效方案。

To B 业务挑战

在To B领域，情况则有所不同。To B产品通常具有较高的门槛，企业用户的选择范围相对有限。因此，产品和解决方案提供商更倾向于成为企业用户的入口，而不是沦为工具被调用。即使难以成为企业用户的主入口，他们也会努力成为二级入口，以避免被其他系统调用。基于此，笔者认为MCP在To B市场的应用前景较为有限，其推广和应用必将面临诸多困难。

我们以通信运营商市场为例：
先看乙方。一类是面向运营商作业流的BOSS系统提供商，因为其产品平台与运营商的业务流程强绑定，他们会主动拥抱AI大模型，巩固天然所具备的用户入口优势地位。另一类是通信设备提供商，出于守护通信设备格局、增加用户粘性的目的，他们主观上也必将进行解决方案的智能化升级，力求与BOSS系统更平等的、而不是“Host-工具”的被动定位。此外，这两类乙方的数量规模并不大，也就是说“不确定的工具”很少甚至没有。因而他们之间通过MCP进行调用的必要性和可能性都不大。至于厂商系统内部，通信设备提供商的系统基本与自己的通信设备硬件绑定，其调用过程是确定性的，如自家设备、工具软件等，这些集成调用通过已有API开发、升级就行，不需要MCP。

再看甲方通信运营商，其核心诉求是通过其所提供的通信服务的智能升级，实现其面向最终用户的商业闭环。至于乙方的系统之间是否采用MCP并不是核心诉求，所以也并不会进行过多的强制条款约束。从目前运营商的关注度来看，他们对A2A、LMOS、ANP等协议更为关注，这些协议都是更加对等的智能体之间的互通，而不是智能体与工具的调用。

综合来看，在ToB领域，MCP的应用前景可能并不大。

 写在最后，MCP 现已初步赢得行业认可，但从生态成熟度、开发者采纳及标准化竞争等维度看，仍面临诸多挑战，其未来发展需在技术优化、商业拓展等方面持续发力，以稳固并拓展自身在 AI 生态中的地位。