AI Agent 协议战争:MCP vs A2A vs WebMCP,谁是下一个 TCP/IP

引言：一个创业公司定义了整个行业

2024 年 11 月，Anthropic 开源了一个协议。名字很朴素：Model Context Protocol，简称 MCP。

18 个月后的今天，OpenAI 采纳了它，Google 采纳了它，微软采纳了它，Amazon 采纳了它。MCP 的 SDK 月下载量突破 9700 万次，官方注册表中有超过 5800 个社区构建的 MCP Server。78% 的企业 AI 团队报告至少有一个基于 MCP 的 Agent 在生产环境运行。

一个创业公司定义了整个行业的基础协议——这在科技史上极其罕见。上一次发生类似的事，还是 1990 年代 Netscape 推动 HTTP 成为 Web 标准。

但 MCP 只解决了问题的三分之一。Agent 需要连接工具，也需要和其他 Agent 对话，还需要和浏览器中的网页交互。于是 Google 推出了 A2A，Chrome 146 发布了 WebMCP。三个协议，三层问题，正在拼出 Agent 时代的完整协议栈。

这篇文章拆解这三个协议各自解决什么问题、如何协同工作，以及对开发者意味着什么。

有意思的是，这三个协议背后的推动者——Anthropic、Google、W3C——并不是在竞争，而是在分工。它们解决的是同一个大问题的不同层面。理解这一点，是理解整个 Agent 协议格局的关键。

MCP：Agent 连接工具的"USB 接口"

问题：每个工具都要写一个适配器

在 MCP 出现之前，每个 AI 应用要连接外部工具，都得写定制化的集成代码。你的 Agent 要查数据库？写一个适配器。要调 GitHub API？再写一个。要读 Notion 文档？又一个。

一个 Agent 连接 12 个工具，就要维护 12 套集成代码。工具方更新了 API，你的适配器就坏了。换一个 AI 模型，所有适配器可能都要重写。

这就是 MCP 要解决的问题：用一个统一协议，替代无数个一次性的定制集成。

架构：Client-Server 模型

MCP 的设计极其简洁。整个协议只有三个核心概念：

Tools：Agent 可以调用的函数（数据库查询、文件写入、API 调用）
Resources：Agent 可以读取的数据（文件、Schema、配置）
Prompts：预定义的提示词模板

架构是标准的 Client-Server 模型。AI 应用（Claude、Cursor、VS Code）是 Client，外部工具通过 MCP Server 暴露能力。Client 连接 Server，Server 声明自己提供哪些 Tools 和 Resources，Agent 按需调用。

AI 应用 Claude/Cursor/IDE

三协议定位与成熟度对比

类比来说：MCP 就是 AI Agent 的 USB-C 接口。不管你是什么设备（手机、笔记本、显示器），只要有 USB-C 口，就能互相连接。不管你是什么 AI 模型（Claude、GPT、Gemini），只要支持 MCP，就能连接任何 MCP Server。

为什么 MCP 能赢

MCP 的胜出不是因为技术最先进，而是因为三个因素叠加：

先发优势。 2024 年 11 月开源时，市场上没有竞品。开发者开始围绕它构建生态，网络效应启动。

设计简洁。 三个核心概念，Client-Server 架构，JSON-RPC 2.0 通信。任何有 Web 开发经验的人都能在一天内写出一个 MCP Server。

治理中立。 2025 年 Anthropic 将 MCP 捐赠给 Linux Foundation。这消除了"被一家公司锁定"的顾虑，OpenAI 和 Google 才愿意采纳。

到 2026 年中，MCP 的 2026 Roadmap 已经聚焦在企业级需求：无状态协议核心、OAuth 认证对齐、Extensions 框架、Tasks 扩展。2026 年 7 月发布的 Release Candidate 是协议自发布以来最大的一次修订——引入了无状态核心（让协议能在普通 HTTP 基础设施上水平扩展）、MCP Apps（Server 端渲染 UI）、以及正式的废弃策略。协议正在从"开发者玩具"进化为"企业基础设施"。

MCP 的数字

几个数字帮助理解 MCP 的渗透速度：

9700 万：MCP SDK 月下载量（2026 年中）
5800+：官方注册表中的社区 MCP Server
1300+：生产环境中的 MCP Server 部署（Q2 2026）
78%：报告至少有一个 MCP Agent 在生产环境的企业 AI 团队比例
67%：将 MCP 列为 12 个月内默认 Agent 集成标准的 CTO 比例

作为对比，竞争协议的采纳率：A2A 23%、ACP 8%、UCP 4%。MCP 的领先不是微弱优势，而是数量级差距。

A2A：Agent 之间怎么对话

MCP 解决不了的问题

MCP 让 Agent 能连接工具。但如果你有多个 Agent，它们之间怎么协作？

设想一个场景：你让一个"旅行规划 Agent"帮你安排出差。它需要查航班、订酒店、安排地面交通、检查日程冲突。这些能力分散在不同的专业 Agent 中——航班 Agent 懂机票比价，酒店 Agent 懂房型推荐，日程 Agent 懂时间管理。

MCP 的模型是"Agent → 工具"。但这里需要的是"Agent → Agent"：一个协调者 Agent 把任务委托给多个专业 Agent，收集结果，整合方案。

这就是 A2A 要解决的问题。

Google 的答案：Agent2Agent Protocol

2025 年 4 月 9 日，Google 发布 A2A 协议，首批 50+ 合作伙伴包括 Atlassian、Salesforce、LangChain。2025 年 6 月捐赠给 Linux Foundation。2026 年 3 月 12 日，A2A 达到 v1.0.0 稳定版。到 2026 年 4 月，协议已有 150+ 支持组织、22000+ GitHub Stars，并在 Microsoft Azure AI Foundry、Amazon Bedrock AgentCore、Salesforce Agentforce 中投入生产。

A2A 的核心机制很小，但解决了关键问题：

Agent Card：能力发现。 每个 Agent 在 /.well-known/agent-card.json 发布自己的能力描述——"我能做什么、接受什么输入、产出什么结果"。其他 Agent 通过读取这个文件，就知道该不该把任务委托给它。

Task：任务生命周期。 通信以任务为单位。一个 Agent 向另一个 Agent 发送任务，任务经历 submitted → working → completed 的生命周期。支持同步返回、Server-Sent Events 流式返回、或回调 URL 异步通知。

Transport：标准通信。 JSON-RPC 2.0 over HTTPS，v0.3 起支持 gRPC。安全层兼容 OAuth 2.0 和 OpenID Connect。

用一句话概括 MCP 和 A2A 的区别：MCP 给你的 Agent 一双手（操作工具），A2A 给你的 Agent 一群同事（协作委托）。

A2A 的实际应用场景

Google Developers Blog 给出了一个供应链场景的完整示例：一个餐厅管理 Agent 通过 MCP 连接库存数据库检查食材余量，然后通过 A2A 将采购任务委托给供应商 Agent。供应商 Agent 有自己的 MCP 连接（批发价格数据库、物流系统），独立完成报价和下单，再通过 A2A 将结果返回给餐厅 Agent。

这个模式的关键在于：每个 Agent 是"不透明"的。餐厅 Agent 不需要知道供应商 Agent 内部用了什么模型、连接了哪些工具。它只需要知道对方的 Agent Card 声明了"我能报价"和"我能下单"。这种封装性让不同团队、不同公司构建的 Agent 能安全地协作，而不需要暴露内部实现。

A2A 的治理与成熟度

A2A 的发展速度值得关注。从 2025 年 4 月发布到 2026 年 3 月达到 v1.0，不到一年就完成了从概念到稳定版的跨越。Linux Foundation 的托管确保了治理中立性——和 MCP 一样，没有单一公司能控制协议方向。

但 A2A 的挑战也很明显：多 Agent 系统的调试极其困难。当一个任务在 5 个 Agent 之间传递，某一步出了错，追踪问题根源比单 Agent 系统复杂一个数量级。可观测性工具还在追赶协议的发展速度。

WebMCP：浏览器暴露结构化功能给 Agent

网站从"给人看"变成"给 Agent 用"

2026 年 2 月，Google 通过 Chrome 146 Canary 发布了 WebMCP。这是一个 W3C 标准提案，让网站可以声明自己提供哪些结构化操作，AI Agent 直接调用——不需要爬虫，不需要模拟点击。

想象一下当前 Agent 和网页交互的方式：打开浏览器 → 渲染页面 → 用视觉模型识别按钮位置 → 模拟鼠标点击。这就像让一个人蒙着眼睛，靠摸索来操作电脑。

WebMCP 的思路完全不同：网站主动告诉 Agent "我这里有哪些操作可以用"。Agent 不需要"看"页面，直接调用结构化的 API。

具体来说，网站通过 JavaScript 注册 Tools，或者在 HTML 表单元素上添加注解。Agent（浏览器内置的 LLM、扩展程序、或无头自动化脚本）发现这些 Tools 后直接调用。

// 网站声明自己提供的操作navigator.ai.tools.register({name:"search_products",description:"搜索商品目录",parameters: {query: { type:"string", description:"搜索关键词" },category: { type:"string", enum: ["electronics", "books", "clothing"] } },handler:async (params) => {returnawaitsearchAPI(params.query, params.category); }});

这个转变的意义类似于 Web 早期从"纯展示页面"到"提供 API"的演进。当年 REST API 让机器能读懂网站数据，WebMCP 让 Agent 能直接操作网站功能。

WebMCP 的现状

Chrome 146 和 Edge 已支持 WebMCP（flag-gated preview）。Cloudflare 的 Browser Run 产品已集成 WebMCP 支持。W3C Web Machine Learning 工作组正在推进标准化。

但要注意：WebMCP 仍处于早期。采纳率接近 0%——绝大多数网站还没有实现 WebMCP 声明。这是一个"先有鸡还是先有蛋"的问题：Agent 不够多时，网站没动力实现；网站不支持时，Agent 也用不上。

不过，Chrome 的分发能力是巨大的杠杆。一旦 WebMCP 从 flag-gated 变成默认启用，网站的适配动力会迅速增加。

WebMCP 与 MCP 的关系

名字里都有"MCP"，但 WebMCP 和 MCP 解决的问题不同。MCP 是后端协议——Agent 通过 MCP Server 连接数据库、API、文件系统，这些都发生在服务器端。WebMCP 是前端协议——它让浏览器中的网页能直接向 Agent 暴露操作能力。

可以这样理解：MCP 让 Agent 能"打电话给后厨"（调用后端服务），WebMCP 让 Agent 能"直接在餐厅点菜"（操作前端界面）。两者互补，不是替代关系。

对网站开发者来说，WebMCP 的实现成本很低——在现有页面上添加几行 JavaScript 声明即可。而且它是渐进式的：不支持 WebMCP 的浏览器会静默忽略这些声明，不影响正常用户体验。

协议栈全景：MCP + A2A + WebMCP = Agent 时代的 TCP/IP

三层协议各管什么

把三个协议放在一起看，它们形成了一个清晰的分层结构：

层级	协议	解决的问题	类比 TCP/IP
上层	WebMCP	Agent 如何与网页交互	HTTP（应用层）
中层	A2A	Agent 之间如何协作	TCP（传输层）
底层	MCP	Agent 如何连接工具和数据	IP（网络层）

WebMCP\nAgent ↔ 网页交互

协议采纳关键时间节点

一个完整的协作场景

用一个具体例子说明三层协议如何协同工作：

你对 Agent 说："帮我找下周去东京的机票，预算 5000 以内。"

A2A 层：你的主 Agent 通过 A2A 协议发现一个"航班搜索 Agent"，读取它的 Agent Card，确认它有航班比价能力，向它委托搜索任务。
MCP 层：航班搜索 Agent 通过 MCP 连接航空公司的数据库 Server、价格历史 Server，获取实时航班数据和历史价格趋势。
WebMCP 层：当需要在某个航空公司官网完成预订时，Agent 通过 WebMCP 直接调用网站声明的"搜索航班"和"创建订单"工具，无需模拟浏览器操作。

三层协议各司其职，组合起来覆盖了 Agent 与外部世界交互的完整链路。

为什么说这是"TCP/IP 时刻"

TCP/IP 协议栈的伟大之处不在于某一层有多精妙，而在于分层本身：每一层只解决一个问题，层与层之间通过清晰的接口组合。这让互联网能从几十台计算机扩展到几十亿台设备。

Agent 协议栈正在重复这个模式。MCP 不需要知道上层是谁在调用它——可以是单个 Agent，也可以是通过 A2A 协作的 Agent 集群。A2A 不需要关心底层工具是通过 MCP 连接的数据库还是通过 WebMCP 连接的网页。每一层独立演进，互不干扰。

当然，类比不是等式。TCP/IP 花了 20 年才成为事实标准。Agent 协议栈还在早期，很多边界还模糊，安全模型还不成熟。但方向已经清晰：不是一个协议统治一切，而是多个协议分层协作。

协议栈之外：还有谁在场

值得一提的是，MCP + A2A + WebMCP 并不是全部。2026 年的 Agent 协议生态还包括：

UCP（Universal Commerce Protocol）：Google 联合 Shopify、Walmart、Etsy 推出，标准化 Agent 的购物流程（发现商品→加购→结账）
AP2（Agent Payments Protocol）：Google 联合 Mastercard、PayPal 推出，解决 Agent 代替用户支付时的授权问题
AG-UI（Agent-User Interface）：CopilotKit 推出，解决 Agent 与前端 UI 的实时通信

这些协议各有分工，但 MCP、A2A、WebMCP 是最核心的三层——它们解决的是 Agent 与外部世界交互的基础问题，其他协议更多是垂直场景的扩展。

对开发者的实际影响

现在该学什么

MCP Server 开发——最高优先级。 MCP 是当前采纳率最高、生态最成熟的协议。学会写 MCP Server，你的工具就能被所有主流 AI 应用调用。TypeScript 和 Python 都有官方 SDK，一个下午就能写出第一个 Server。

腾讯云开发者社区已有大量中文教程，从零基础构建 MCP Server 到企业级部署实战都有覆盖。Google 的 Agent Development Kit（ADK）提供了 McpToolset 一等公民支持，几行代码就能把 MCP Server 接入你的 Agent。

一个典型的学习路径：先用 TypeScript SDK 写一个暴露本地文件系统的 MCP Server → 在 Claude Desktop 或 Cursor 中测试 → 然后把你团队的内部 API 包装成 MCP Server → 最后发布到官方注册表。整个过程不需要理解协议底层细节，SDK 封装得足够好。

现在该投入什么

工具标准化。 如果你维护内部工具或 API，现在就该考虑暴露 MCP 接口。这不是"未来可能有用"，而是"现在就有 Agent 在找你的 MCP Server"。

Agent Card 设计。 如果你在构建 Agent 产品，开始设计你的 Agent Card——描述你的 Agent 能做什么、接受什么输入、有什么限制。这是 A2A 生态中的"名片"，决定了其他 Agent 是否会把任务委托给你。

现在该观望什么

A2A 的生产部署——谨慎乐观。 A2A v1.0 已发布，大厂已在用，但多 Agent 协作的安全模型、错误处理、成本控制都还在摸索中。在内部系统中试验可以，面向用户的生产环境建议再等半年。

WebMCP 的网站适配——关注但不急。 除非你的网站是 Agent 的高频交互目标（电商、旅行、金融服务），否则现在实现 WebMCP 的 ROI 不高。等标准从 W3C 提案变成正式推荐，再投入不迟。

一个值得警惕的趋势

Gartner 预测 2026 年 40% 的企业应用将内置 AI Agent（2025 年这个数字不到 5%）。IDC 预测 Agentic AI 支出到 2029 年将超过 1.3 万亿美元。

这意味着：Agent 不是"未来某天可能用到的技术"，而是"现在正在重塑软件架构的力量"。不理解 Agent 协议栈的开发者，就像 2005 年不理解 REST API 的 Web 开发者——短期内不影响工作，但长期会被生态边缘化。

好消息是，这三个协议的学习曲线都不陡。MCP 的核心概念比 GraphQL 简单，A2A 的 Agent Card 比 OpenAPI Spec 简单，WebMCP 的实现比 Service Worker 简单。门槛不在技术复杂度，在于是否愿意现在就开始。

Agent 协议开发者行动

结语：协议之争的本质是生态之争

回到开头的问题：为什么一个创业公司能定义整个行业的基础协议？

答案不是技术。MCP 的技术并不复杂——JSON-RPC、Client-Server、三个核心概念。任何大厂都能在一个月内设计出类似的东西。

答案是时机和开放性。Anthropic 在正确的时间（Agent 爆发前夜）做了正确的事（开源+捐赠给中立基金会）。等其他公司反应过来时，生态已经形成，再造一个新协议的成本远高于加入现有协议。

这给我们一个启示：在 Agent 时代，协议之争的本质是生态之争。谁定义了协议，谁就定义了游戏规则。 不是谁的技术最好，而是谁的生态最大。

MCP + A2A + WebMCP 这个协议栈还在早期。安全模型不成熟，企业级特性在补课，很多边界还在争论。但方向已经不可逆：Agent 需要标准化的方式连接工具、协作、与 Web 交互。

对开发者来说，现在是参与协议生态建设的最佳窗口。不是等协议成熟了再学，而是在协议成长的过程中，用你的实践去影响它的方向。

协议战争的赢家不是写出最好协议的人，而是围绕协议建立最大生态的人。在这场战争中，开发者不是旁观者——每一个 MCP Server 的发布、每一个 Agent Card 的注册、每一个 WebMCP 声明的实现，都在为某个协议投票。

你的下一个项目，会为哪个协议投票？

参考链接

[1] MCP 2026 Roadmap — Model Context Protocol Blog；https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/

[2] Developer's Guide to AI Agent Protocols — Google Developers Blog；https://developers.googleblog.com/developers-guide-to-ai-agent-protocols/

[3] The Agent Protocol Stack: Why MCP + A2A + A2UI Is the TCP/IP Moment — Subhadip Mitra；https://subhadipmitra.com/blog/2026/agent-protocol-stack/

[4] Google Ships WebMCP, The Browser-Based Backbone For The Agentic Web — Forbes；https://www.forbes.com/sites/joetoscano1/2026/02/19/google-ships-webmcp-the-browser-based-backbone-for-the-agentic-web/

[5] AI Agent Protocol Guide: MCP, A2A, UCP, AP2, A2UI, and AG-UI — ceaksan.com；https://ceaksan.com/en/ai-agent-protocols-mcp-a2a-ucp-ap2-a2ui-ag-ui/

[6] A2A Protocol Surpasses 150 Organizations — Linux Foundation；https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year

[7] MCP Adoption Statistics 2026 — Digital Applied；https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol

[8] WebMCP just landed in Chrome 146 — bug0.com；https://bug0.com/blog/webmcp-chrome-146-guide

[9] 基于 MCP 协议的 LLM 工具调用 — 腾讯云开发者社区；https://cloud.tencent.com/developer/article/2645342

[10] MCP 与多 Agent 协作系统 — 腾讯云开发者社区；https://cloud.tencent.com/developer/article/2614922

[11] 零基础构建 MCP 服务器：TypeScript/Python 双语言实战指南 — 腾讯云开发者社区；https://cloud.tencent.com/developer/article/2549954