One Person Unicorn

返回文章列表

权力协议:MCP与A2A——2025年企业主导地位战略分析

CodingoAI

引言:协议即权力

在软件时代,谁控制了协议,谁就控制了市场。这不是隐喻,而是经济现实。HTTP使万维网民主化,但也为谷歌和Facebook创造了数万亿美元的价值。TCP/IP实现了互联网,但思科因销售路由器而繁荣。SMTP使电子邮件成为可能,但Gmail主导了收件箱。

2025年,一场新的协议战争正在AI领域展开。这次的战场是代理间通信,而武器是两个新兴标准:Anthropic的模型上下文协议(MCP)和Google的代理到代理(A2A)协议

这不仅仅是关于技术优势的问题。这关乎谁将定义AI代理未来十年的互操作方式——以及由此产生的万亿美元生态系统。本报告为企业战略家和创始人剖析了这场协议战争,揭示了其影响、策略以及如何利用这场转变的方法。

第一部分:协议战争的简史——前车之鉴

案例研究1:VHS vs. Betamax——质量无关紧要

20世纪70年代末的录像机大战是关于网络效应和战略联盟的经典案例,而非技术优势。Betamax技术上更优越(更好的图像质量、更小的磁带)。但VHS获胜是因为:

  • 授权策略:JVC将VHS授权给任何愿意制造的公司。索尼对Betamax保持专有控制。
  • 内容为王:VHS磁带更长(120分钟 vs. 60分钟),这意味着一盘磁带可以录制整部电影。这吸引了电影制片厂,建立了更大的内容库。
  • 价格战:多个制造商意味着竞争和更低的价格。

教训:在协议战争中,生态系统 > 技术。让更多人采用”足够好”的标准比拥有封闭、优越的标准更有价值。

案例研究2:微软如何用拥抱、扩展、消灭策略赢得浏览器战争

20世纪90年代,网景的Navigator占据了约80%的浏览器市场份额。微软几乎从零开始,用Internet Explorer(IE)粉碎了它。如何做到的?

  • 拥抱:微软采用了现有的网络标准(HTTP、HTML)。
  • 扩展:他们添加了专有的ActiveX控件、VBScript和DirectX集成——只在IE中有效的功能——迫使开发者针对IE进行优化。
  • 消灭:通过与Windows捆绑IE并使其免费,他们切断了网景的氧气供应(网景销售其浏览器)。到2002年,IE拥有95%的市场份额。

教训:在协议战争中,分销 > 功能。控制分销渠道(微软拥有桌面操作系统)意味着你可以将你的标准强加给市场,即使它不是”最好的”。

案例研究3:开放的胜利——开放标准如何击败围墙花园

虽然专有标准可以赢得战斗,但历史表明开放标准往往赢得战争——至少在足够长的时间线上。

  • **Wi-Fi(IEEE 802.11)**击败了专有的无线标准,因为设备制造商不必向单一供应商支付许可费。
  • Linux和开源软件慢慢侵蚀了专有Unix和Windows服务器的主导地位,为云计算奠定了基础。
  • USB成为通用标准,因为它是跨行业联盟创建的,而不是被单一公司控制。

教训:开放标准降低了进入壁垒,加速了采用,但需要时间才能成熟。专有标准可以快速移动并在早期货币化,但随着生态系统变得更加复杂,面临着被更灵活、社区驱动的替代方案颠覆的风险。

元教训:协议战争不是通过技术赢得的

从这些历史案例中,一个模式变得清晰:

协议战争不是通过拥有最好的技术赢得的。它们是通过以下方式赢得的:

  • 网络效应:首先达到临界质量。
  • 生态系统策略:谁拥有开发者、制造商和内容创作者。
  • 分销权力:控制用户的访问点。
  • 授权模式:开放 vs. 专有,以及这如何影响增长。

MCP和A2A战争将遵循这些相同的动态。技术能力只是战场。真正的战争是关于生态系统控制。

第二部分:竞争者——MCP vs. A2A

模型上下文协议(MCP):Anthropic的标准化赌注

MCP是什么:Anthropic于2024年11月推出的MCP是一个开放协议,标准化AI应用程序如何与外部数据源和工具连接。它创建了一个统一的接口,用于将LLM连接到数据库、API、文件系统等,而无需为每个集成使用自定义代码。

核心架构:

  • 主机:AI应用程序(例如,Claude桌面、IDE、AI代理)
  • 客户端:在主机内运行的MCP客户端
  • 服务器:为特定数据源或工具提供标准化接口的MCP服务器
  • 通信:使用JSON-RPC 2.0,支持多种传输(stdio、HTTP + SSE)

它解决的问题:

没有MCP,集成LLM是一个噩梦。每个数据源(Slack、Google Drive、SQL数据库)都需要自定义连接器。每次AI应用程序想要添加新功能时,开发者必须从头开始构建集成。

MCP解决了这个M x N问题。以前,如果你有M个AI应用程序和N个数据源,你需要M*N个自定义集成。使用MCP,你只需要M + N(M个MCP客户端 + N个MCP服务器)。这大大降低了集成成本。

核心功能:

  • 资源:MCP服务器公开LLM可以读取的数据(文件、数据库记录、API响应)。LLM可以使用资源URI请求特定数据,服务器返回它。
  • 提示:服务器可以为用户公开可重用的提示模板,帮助标准化常见任务。
  • 工具:LLM可以调用MCP服务器公开的函数(例如,发送电子邮件、查询数据库、运行Python脚本)。
  • 采样:服务器可以请求LLM代表它们生成完成——一种”反向LLM调用”模式。

Anthropic的策略——“开放”赌注:

  • 完全开源:MIT许可。任何人都可以实现MCP服务器或客户端。
  • 早期生态系统投资:Anthropic通过预构建集成(Slack、GitHub、Google Drive)、SDK(Python、TypeScript)和详细文档来引导社区。
  • Claude优先,但不限于:虽然MCP在Claude桌面中原生集成,但该协议被设计为模型无关。Anthropic希望它成为一个跨平台标准。

在野外的MCP: 截至2025年,已经有数十个开源MCP服务器可用(用于Postgres、GitHub、Puppeteer等),并且该协议已集成到Zed、Replit、Codeium等开发工具中。

代理到代理(A2A)协议:谷歌对代理互联网的愿景

A2A是什么: 谷歌于2024年12月通过论文和开源参考实现宣布的A2A,是一个用于AI代理之间直接通信和协作的协议。虽然MCP是关于连接代理到工具和数据,但A2A是关于代理到代理的交互——构建一个代理的”网络”。

核心架构:

  • 发现:代理如何找到彼此(通过中央注册表或分布式发现机制)。
  • 消息传递:定义了代理之间通信的结构化消息格式(任务请求、结果、能力声明)。
  • 治理:包括信任、声誉和安全性的框架(代理如何验证彼此的能力和意图)。

它解决的问题:

今天的AI代理是孤立的。它们在自己的环境中运行,无法合作解决需要多个专业的复杂任务。例如,一个旅行规划代理可能需要与航班预订代理、酒店代理和天气代理对话才能构建完整的行程。没有标准化的方式让这些代理相互协商任务和交换信息。

A2A将代理生态系统设想为一个市场,其中:

  • 代理宣传他们的能力(例如,“我可以预订航班到欧洲”)。
  • 其他代理可以发现并将任务外包给它们(例如,“旅行代理”雇用”航班代理”)。
  • 协作通过标准化协议进行协商和执行。

核心功能:

  • 能力声明:代理发布他们可以执行哪些任务的机器可读描述。
  • 任务委托:代理可以向具有必要技能的其他代理发送任务请求。
  • 结果验证:定义代理如何报告结果以及如何验证结果。
  • 信任和声誉(路线图):虽然仍在开发中,但A2A的愿景包括代理评估彼此可靠性的机制,可能基于过去的表现或声誉评分。

谷歌的策略——“控制网络”:

  • 开源,但有影响力:与MCP一样,A2A是开源的。但谷歌的战略是将自己定位为协议演变的主要贡献者和管理者。
  • 利用现有优势:谷歌拥有强大的云基础设施(GCP)、现有的开发者关系以及可以成为A2A注册表或发现中心的平台。
  • AI代理即服务的愿景:谷歌希望A2A能够实现一个去中心化的AI代理市场——类似于应用商店,但针对自主代理。这为谷歌托管、索引和货币化这个生态系统创造了机会。

在野外的A2A:A2A比MCP更新。截至2025年初,它主要处于研究和早期实验阶段,具有谷歌的参考实现和一些学术项目。它还没有达到MCP的生产采用水平,但这是快速移动的领域。

直接比较:MCP vs. A2A

维度MCP (Anthropic)A2A (谷歌)
核心目的将AI应用连接到数据/工具实现AI代理间通信
主要用例工具使用、RAG、数据访问代理协作、任务委托
架构客户端-服务器(主机 ↔ MCP服务器)点对点 / 市场(代理 ↔ 代理)
成熟度(2025年初)生产就绪,增长的生态系统早期阶段,主要是研究
治理模型开源(社区驱动)开源(谷歌影响力)
网络效应潜力高(更多服务器 = 更有用的协议)非常高(更多代理 = 指数级实用性)
战略控制点Claude作为旗舰实现谷歌可以托管注册表/基础设施
竞争对手OpenAI的插件(现在已弃用),LangChain工具尚不清楚,但潜在的专有代理网络

第三部分:战略影响——谁赢了意味着什么

场景1:MCP成为事实标准

含义:

  • AI应用层价值增加:如果MCP成为连接工具和数据的标准,那么价值就会累积到使用MCP的AI应用层(Claude、其他AI助手、AI IDEs)。Anthropic成为”连接器经济”的默认平台。
  • 数据提供商的商品化:如果每个数据源都必须有一个MCP服务器才能相关,那么数据提供商就会失去议价能力。他们必须支持MCP或变得不可见。
  • 谷歌的回应:谷歌可以采用MCP(类似于微软最终在Edge中采用Chromium),但以扩展的方式(例如,添加谷歌特定的功能),或者他们可能会促进A2A作为竞争标准,创建分裂。

赢家:

  • Anthropic(生态系统控制)
  • MCP原生AI应用和工具
  • 开发者(标准化降低集成成本)

输家:

  • 试图建立专有连接器护城河的AI公司
  • 不采用的数据/工具提供商

场景2:A2A成为代理互联网的主干

含义:

  • AI代理经济爆炸:A2A为专业化AI代理市场创造了基础设施——每个代理都做一件事并做得很好,但可以与他人无缝协作。这解锁了复杂的多代理工作流程,单个供应商无法单独构建。
  • 谷歌作为基础设施提供商:即使A2A是开放的,谷歌也可以通过托管中央代理注册表、提供代理托管基础设施(在GCP上)或成为代理身份验证和信任的提供者来货币化。
  • 对MCP的威胁:如果代理到代理的通信变得比代理到工具的连接更有价值,那么A2A变得更加关键,而MCP成为商品(或成为A2A生态系统内的较小层)。

赢家:

  • 谷歌(如果他们控制关键基础设施)
  • 专业代理开发者(新的商业模式)
  • 企业(可以编排多个供应商的代理)

输家:

  • 单片AI平台(试图在内部做所有事情)
  • 不采用标准的代理
  • 如果谷歌变得过于占主导地位,消费者和监管机构可能会担心

场景3:碎片化——两个标准共存(或更多)

含义:

这是”最坏情况”场景——行业在不兼容的标准周围分裂。一些工具支持MCP。一些代理使用A2A。一些公司构建专有系统。

  • 开发者痛苦:构建者必须支持多个协议才能达到所有用户。
  • 创新放缓:缺乏单一标准意味着网络效应被稀释。生态系统增长变慢。
  • 整合机会:像LangChain、Microsoft(通过Semantic Kernel)或新兴的初创公司这样的中间件层可以提供跨MCP、A2A和其他系统的抽象,并捕获价值作为”翻译”层。

赢家:

  • 中间件/抽象层提供商
  • 拥有资源支持多个标准的大型企业

输家:

  • 小型开发者和初创公司
  • 最终用户(由于缺乏互操作性而获得更差的体验)
  • 整个AI生态系统(由于碎片化而增长缓慢)

第四部分:创始人和企业的行动手册

对于AI产品创始人:你应该下注哪个?

推荐:对冲你的赌注,但向MCP倾斜(短期)

原因:

  • MCP更成熟:它现在在生产中,有一个增长的生态系统,并有明确的文档。构建MCP集成的时间成本很低。
  • 即时价值:如果你正在构建AI应用程序,支持MCP意味着你可以立即插入Slack、GitHub等,而无需构建自定义集成。
  • A2A是一个押注未来:A2A更具推测性,但如果你正在构建代理,了解它并为未来采用做好准备。

可操作步骤:

  1. 如果你正在构建AI应用:立即添加MCP客户端支持。使用Anthropic的SDK。为你的用户可能需要的前5-10个数据源(Notion、Google Drive等)启用MCP服务器。
  2. 如果你正在构建专业AI代理:设计你的代理架构时考虑到A2A。即使你还没有实现完整的A2A,也要确保你的代理可以通过定义良好的API公开其功能,以便将来兼容A2A。
  3. 如果你正在构建工具/数据产品:发布MCP服务器。这将使AI应用程序很容易集成你的产品,从而增加你的分销。
  4. 监控标准:协议战争移动很快。订阅Anthropic和谷歌的开发者博客。加入Discord/Slack社区,了解采用情况。

对于企业战略家:定位你的组织

推荐:投资于两个协议,但要有策略

原因:

企业应该是标准无关的,但为主导标准做好准备。最大的风险不是选择错误的标准,而是根本不采用,并被更灵活的竞争对手超越。

可操作步骤:

  1. 审核你当前的AI工具栈:确定哪些供应商支持MCP或A2A,哪些不支持。询问不支持的供应商他们的路线图。
  2. 构建内部MCP服务器用于专有数据:不要等待供应商。如果你有关键的内部系统(CRM、ERP、知识库),构建MCP服务器以使你的AI代理可以访问它们。
  3. 试点多代理工作流程:即使A2A还不完全成熟,也开始试验多代理系统(例如,用于客户服务、供应链优化)。当A2A或类似标准变得生产就绪时,你会有经验。
  4. 参与治理:如果你是一家大公司,请考虑加入或赞助塑造这些标准的开源项目和行业联盟。拥有一席之地意味着你可以影响协议演变以支持你的用例。

对于投资者:资助什么

推荐:注意协议战争不是二元的

投资论点:

投资者不应该只是押注MCP或A2A获胜。真正的价值在于这些协议启用的生态系统层。

可操作步骤:

  1. 押注中间件和工具:投资于构建在这些协议之上的公司(例如,为MCP服务器的公司、代理编排工具、跨协议抽象层)。
  2. 寻找协议原生初创公司:识别从第一天开始就被设计为”MCP优先”或”A2A原生”的初创公司,因为它们将比将遗留系统改造为支持这些标准的公司拥有架构优势。
  3. 关注垂直整合:专注于特定用例(例如,用于法律的多代理AI,用于财务研究的工具)并对该垂直深度集成MCP/A2A的公司可能比通用平台玩家拥有更强的护城河。

第五部分:更深层次的游戏——权力与控制

谁真正从协议战争中受益?

MCP和A2A都是”开放”的,但开放≠中立。这两个协议的主要推动者是巨头公司,有明确的议程。

Anthropic的MCP战略:防御护城河

Anthropic推动MCP不仅仅是为了互操作性。它是一种防御策略,旨在将Claude定位为AI应用层的默认基础。

逻辑:

  • 如果MCP成为标准,那么Claude(MCP的旗舰实现)自动成为任何想要插入广泛工具和数据生态系统的AI应用程序的首选。
  • 即使OpenAI、谷歌和Meta采用MCP(这是开源的好处),Anthropic仍然受益,因为他们已经建立了最大的MCP服务器生态系统。他们将成为事实上的参考实现。
  • 这降低了被OpenAI或谷歌颠覆的风险,他们可能会试图将客户锁定在专有的工具生态系统中。通过使工具连接开放和标准化,Anthropic使模型层(他们擅长的地方)更具竞争力。

谷歌的A2A战略:控制下一个平台

谷歌推动A2A是一场平台游戏。他们从错过移动应用程序生态系统(iOS / Android应用商店)中吸取了教训,现在正试图控制代理生态系统的基础设施。

逻辑:

  • 如果A2A成为标准,那么用于发现、信任和编排代理的基础设施就变得至关重要。谷歌可以通过托管中央代理注册表(类似于Google Play用于应用程序)、提供身份/身份验证服务或代理托管(在GCP上)来货币化。
  • 即使谷歌不直接向代理收费,控制基础设施也意味着他们可以通过广告、数据访问和优先位置来货币化(类似于Google搜索如何货币化网络,即使网络是”开放的”)。
  • 这抵消了OpenAI/Anthropic的模型主导地位。如果代理之间的通信比单个模型的智能更有价值,那么谷歌就不需要拥有”最好”的LLM。他们只需要拥有代理相互对话的网络。

元游戏:协议作为护城河

底线是:

协议本身成为竞争优势

拥有”最佳”AI模型是不够的(模型很快就会商品化)。拥有”最佳”应用程序是不够的(应用程序可以被复制)。但是控制协议——定义AI系统如何相互通信的标准——创造了一个几乎不可能被颠覆的护城河。

这就是为什么微软、Anthropic和谷歌都如此激烈地争夺协议主导地位,即使他们将协议作为”开源”发布。真正的奖品不是许可费,而是生态系统控制。

结论:为什么这对独角兽创始人很重要

如果你正在构建一家AI公司,你不能忽视协议战争。以下是原因:

  1. 你的架构选择锁定了你的未来:如果你今天在专有系统上构建,而MCP或A2A成为标准,你将被迫进行代价高昂的重构或面临不相关的风险。
  2. 协议启用网络效应:率先采用正确的协议意味着当生态系统增长时,你将自动变得更有价值(你将兼容更多的工具、代理和数据源)。
  3. 分销来自互操作性:如果你构建MCP或A2A原生,其他平台将更容易集成你,从而放大你的分销。
  4. 标准是防御性护城河:通过采用开放标准,你可以避免被锁定在单一供应商(OpenAI、谷歌)中,并保留未来的灵活性。

最终建议:站在巨人的肩膀上,但不要被绑住

  • 对于2025年:在MCP上大力投入(这是现在生产就绪的)。构建MCP服务器(如果你提供数据/工具)或MCP客户端(如果你正在构建AI应用程序)。
  • 对于2026年及以后:为A2A的兴起做好准备。将你的代理架构设计为模块化和可互操作的。参与A2A社区。
  • 长期:不要将你的整个业务押注在任何一个协议上。构建抽象层,允许你在标准之间切换。你的核心价值应该是你独特的数据、AI模型或用户体验,而不是你使用哪个协议。

协议战争不仅仅是关于技术。它们是关于权力、控制和塑造未来十年的AI生态系统。理解这场战争——以及如何定位自己——可能是建立一个被颠覆的产品和建立一个价值数十亿美元的平台之间的区别。

欢迎来到AI时代的协议战争。明智地选择你的阵营。

来源

  • anthropic.com
  • modelcontextprotocol.io
  • github.com
  • langchain.com
  • arstechnica.com
  • reddit.com
  • google.github.io
  • arxiv.org
  • venturebeat.com
  • techcrunch.com
  • zdnet.com
  • youtube.com
  • openai.com
  • infoq.com
  • semanticscholar.org
  • en.wikipedia.org
  • britannica.com
  • history.com