2024年末到2026年初，AI Agent互操作协议经历了一场堪比浏览器大战的混战。MCP、A2A、ACP、A2UI、AG-UI、ANP、AGNTCY SLIM、x402、UCP、AP2——超过十个协议在不到一年内密集发布。到2026年5月，硝烟散去，产业已经收敛出一套清晰的四层协议栈架构：MCP管工具连接，A2A管Agent间协调，A2UI/AG-UI管用户交互，AP2/UCP管商业交易。IBM的ACP并入A2A，AGNTCY的SLIM进入IETF标准化流程，ANP坚守去中心化定位。本文深入拆解这场协议战争的终局格局，分析每一层的胜出者、落败者、以及生产环境中的真实选型策略。
timeline
title Agent互操作协议爆发时间线 (2024.11 - 2026.05)
section 2024 Q4
2024.11 : Anthropic发布MCP
section 2025 Q1-Q2
2025.03 : IBM发布ACP
2025.04 : Google发布A2A (50+创始伙伴)
2025.06 : ANP白皮书提交W3C
section 2025 Q3-Q4
2025.08 : ACP并入A2A (Linux Foundation)
2025.09 : CopilotKit发布AG-UI
2025.11 : Cisco/Galileo发起AGNTCY
section 2026 Q1-Q2
2026.01 : Google发布A2UI
2026.02 : AGNTCY提交SLIM至IETF
2026.03 : x402扩展至多链
2026.04 : AP2捐赠FIDO Alliance
2026.05 : 协议栈收敛定局
这场混战的核心时间窗口只有18个月。从2024年11月Anthropic发布MCP开始，到2026年5月AP2捐赠FIDO Alliance为止，平均每6周就有一个新协议诞生。密集程度堪比2010年前后的移动操作系统大战。
2026年产业已经形成共识：不是"一个协议统治一切"，而是每一层各司其职。类比TCP/IP栈的四层模型——链路层、网络层、传输层、应用层——Agent协议栈也有清晰的分层。
graph TB
subgraph "Agent协议栈 2026终局"
subgraph "L4 商业层 Commerce"
AP2["AP2<br/>Agent支付<br/>(Google→FIDO)"]
UCP["UCP<br/>通用商务<br/>(Google)"]
X402["x402<br/>HTTP微支付<br/>(Coinbase)"]
end
subgraph "L3 交互层 Interface"
A2UI["A2UI<br/>Agent→用户界面<br/>(Google)"]
AGUI["AG-UI<br/>Agent→前端事件<br/>(CopilotKit)"]
end
subgraph "L2 协调层 Coordination"
A2A["A2A<br/>Agent→Agent<br/>(Google/Linux Foundation)"]
SLIM["SLIM<br/>低延迟消息<br/>(AGNTCY/IETF)"]
end
subgraph "L1 连接层 Connection"
MCP["MCP<br/>Agent→工具/数据<br/>(Anthropic)"]
end
end
AP2 -.-> A2A
UCP -.-> A2A
A2UI -.-> A2A
AGUI -.-> A2A
A2A -.-> MCP
SLIM -.-> A2A
style MCP fill:#4CAF50,color:#fff
style A2A fill:#2196F3,color:#fff
style A2UI fill:#FF9800,color:#fff
style AGUI fill:#FF9800,color:#fff
style AP2 fill:#9C27B0,color:#fff
style UCP fill:#9C27B0,color:#fff
style X402 fill:#9C27B0,color:#fff
style SLIM fill:#00BCD4,color:#fff
| 层级 | 职责 | 胜出协议 | 发起方 | 治理 | 传输方式 | 生产就绪度 |
|---|---|---|---|---|---|---|
| L1 连接层 | Agent↔工具/数据 | MCP | Anthropic | 开源社区 | JSON-RPC/stdio/SSE | ★★★★★ |
| L2 协调层 | Agent↔Agent | A2A | Linux Foundation | JSON-RPC/HTTP/SSE | ★★★★☆ | |
| L2b 消息层 | 低延迟Agent消息 | SLIM | Cisco/AGNTCY | IETF Draft | 自定义二进制 | ★★★☆☆ |
| L3 交互层 | Agent↔用户界面 | A2UI + AG-UI | Google / CopilotKit | 开源项目 | 声明式UI/事件流 | ★★★★☆ |
| L4 商业层 | Agent支付/交易 | AP2 + x402 | Google / Coinbase | FIDO Alliance | HTTP 402 | ★★★☆☆ |
| 特殊 | 去中心化发现 | ANP | 社区驱动 | W3C CG | DID/P2P | ★★☆☆☆ |
MCP（Model Context Protocol）是这场协议战争中唯一没有真正对手的协议。Anthropic在2024年11月发布MCP时，定位非常精准：标准化Agent如何连接外部工具和数据源。这个定位恰好避开了与其他协议的正面冲突。
MCP的核心架构围绕三个原语：Resources（静态数据源）、Tools（可执行函数）、Prompts（提示模板）。传输层支持stdio（本地进程间通信）和SSE over HTTP（远程服务）。截至2026年5月，MCP npm包下载量超过9700万次，GitHub Star数突破5万，成为事实标准。
关键代码片段——一个最简MCP Tool Server：
from mcp.server import Server
import mcp.types as types
server = Server("my-tool-server")
@server.list_tools()
async def list_tools() -> list[types.Tool]:
return [
types.Tool(
name="query_database",
description="Execute SQL query",
inputSchema={
"type": "object",
"properties": {
"sql": {"type": "string"}
},
"required": ["sql"]
}
)
]
@server.call_tool()
async def call_tool(name: str, arguments: dict):
if name == "query_database":
result = execute_sql(arguments["sql"])
return [types.TextContent(type="text", text=str(result))]
MCP的胜出不仅因为先发优势，更因为它精确地卡在了"Agent需要调用工具"这个最基础的需求上。OpenAI、Google、Microsoft的Agent SDK全部内置了MCP支持。
变现评估：MCP Server开发是目前Agent生态中最直接的变现路径。企业需要将内部API包装为MCP Server供Agent调用，单个MCP Server的开发报价在$5K-$50K之间。训练营方向明确：3天教会开发者封装MCP Server，市场需求旺盛。
A2A（Agent-to-Agent）协议的胜出过程值得单独拆解。Google在2025年4月发布A2A时，IBM的ACP已经存在了约一个月。两者的功能高度重叠——都是解决Agent之间如何通信的问题。
转折点发生在2025年8月。IBM将ACP正式并入A2A，纳入Linux Foundation的LF AI & Data基金会管理。这不是技术层面的合并，而是政治层面的妥协。IBM发现自己无法单独推动ACP成为行业标准，而Google已经拉拢了50+创始伙伴（包括Atlassian、Salesforce、SAP等企业软件巨头）。
A2A的核心概念是Agent Card + Task生命周期：
{
"name": "Invoice Processing Agent",
"description": "Processes invoices and handles payment workflows",
"url": "https://agents.example.com/invoice",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"authentication": {
"schemes": ["Bearer Token"]
},
"skills": [
{
"name": "process_invoice",
"description": "Parse and process a vendor invoice"
}
]
}
Agent Card本质上是一张"数字名片"。一个Agent发布自己的Card后，其他Agent可以通过/.well-known/agent.json路径发现它的能力。通信基于JSON-RPC 2.0，任务状态机如下：
stateDiagram-v2
[*] --> Submitted: tasks/send
Submitted --> Working: Agent开始处理
Working --> Completed: 返回结果
Working --> Failed: 处理失败
Working --> InputRequired: 需要人工输入
Working --> Canceled: 任务取消
InputRequired --> Working: 用户提供输入
Submitted --> Canceled: 取消
Working --> Working: 流式更新(Artifact)
A2A的关键设计决策是不要求共享内存。与LangGraph/CrewAI等框架内部的Agent共享state不同，A2A的Agent之间完全通过消息传递交互。这使得跨组织、跨框架的Agent协作成为可能——一个OpenAI Agent可以调用一个Google Agent的能力，无需共享运行时。
A2A升级方向（2026年进展）：Google Cloud博客确认A2A正在获得多项升级，包括增强的流式支持、更细粒度的权限控制、以及与Adobe等企业Agent的实际集成案例。Amazon Bedrock AgentCore也已经支持A2A协议契约。
在A2A占据Agent间协调主导地位的同时，AGNTCY联盟（Cisco、Galileo、LangChain联合发起）推出了SLIM（Secure Low-Latency Interactive Messaging）协议，走了一条差异化路线。
SLIM解决的是A2A不擅长的问题：实时、低延迟的Agent间消息传递。A2A基于HTTP/SSE，适合"发一个任务，等结果"的模式。但当多个Agent需要实时协作编辑、协同推理、流式对话时，HTTP的请求-响应模型就显得笨重了。
SLIM的核心特性：
- 二进制协议：相比A2A的JSON-RPC，SLIM使用自定义二进制格式，消息开销降低60-80%
- 双向流：原生支持双向实时数据流，不需要SSE变通方案
- 安全内置：mTLS + 端到端加密，不需要在应用层额外处理安全
- IETF标准化：已提交为draft-mpsb-agntcy-slim-01，正在标准化流程中
SLIM的定位不是替代A2A，而是作为高性能通道补充A2A。类比网络协议栈：A2A是HTTP，SLIM是QUIC/HTTP3。当Agent之间的交互频率低于"每秒几次"时，A2A足够；当需要"每秒几十到几百次"消息交换时，SLIM更合适。
生产就绪度评估：SLIM目前仍处于早期阶段（IETF Draft），缺少成熟的生产部署案例。但对实时协作场景（如多Agent协同编码、实时交易系统），SLIM代表了一个明确的未来方向。
Agent如何与用户交互？这个问题催生了两个并行协议。
Google在2026年1月发布A2UI（Agent-to-User Interface），定位是让远程Agent能够生成丰富的、安全的用户界面。A2UI采用声明式UI范式——Agent不直接操控DOM，而是描述"我想要什么样的界面"，由客户端渲染。
核心设计原则： - 安全优先：Agent不能执行任意JavaScript，只能声明UI结构 - 跨平台：同一份A2UI描述可以在Web、移动端、桌面端渲染 - 可访问性：内置ARIA支持，确保生成的界面符合无障碍标准
{
"type": "form",
"elements": [
{
"type": "text-input",
"label": "Destination",
"placeholder": "Where do you want to go?",
"required": true
},
{
"type": "date-picker",
"label": "Travel Date",
"min": "2026-06-01"
},
{
"type": "submit",
"label": "Search Flights"
}
]
}
AG-UI（Agent-User Interaction Protocol）由CopilotKit推出，走的是完全不同的技术路线。不是声明式UI，而是事件流——Agent通过发送结构化事件来驱动前端应用的状态变化。
AG-UI定义了16种标准事件类型，包括：
- TEXT_MESSAGE_START/CONTENT/END：流式文本输出
- STATE_SNAPSHOT：Agent状态同步
- TOOL_CALL_START/ARGS/END：工具调用可视化
- STEP_START/END：推理步骤展示
// AG-UI 事件驱动模式示例
const agentEvents = [
{ type: "TEXT_MESSAGE_START", message_id: "msg-1" },
{ type: "TEXT_MESSAGE_CONTENT", message_id: "msg-1", delta: "正在分析" },
{ type: "TOOL_CALL_START", tool_call_id: "tc-1", tool_name: "search" },
{ type: "TOOL_CALL_ARGS", tool_call_id: "tc-1", delta: '{"query":"..."}' },
{ type: "TOOL_CALL_END", tool_call_id: "tc-1" },
{ type: "TEXT_MESSAGE_CONTENT", message_id: "msg-1", delta: "找到了3个结果" },
{ type: "TEXT_MESSAGE_END", message_id: "msg-1" },
];
A2UI更适合"Agent生成完整界面"的场景（如远程Agent为你动态创建一个数据看板），AG-UI更适合"Agent嵌入已有应用"的场景（如Agent在你的IDE或CRM中操作）。生产环境中，两者可以同时使用——AG-UI处理实时交互流，A2UI处理动态界面生成。
Microsoft已经在Agent Framework中同时集成了A2A和AG-UI的支持，验证了这种"共存模式"的可行性。
这是协议栈中最新的战场。当Agent需要代表用户进行交易时，如何安全地授权、执行、记录支付？
x402（Coinbase）：基于HTTP 402状态码的微支付协议。Agent在调用付费API时，收到HTTP 402响应后自动附带加密货币支付。特点是极致简单——一个HTTP中间件就能实现。但受限于加密货币生态。
UCP（Google）：Universal Commerce Protocol，在Google I/O 2026上发布。UCP解决的不是"怎么付钱"，而是"怎么描述一个可购买的东西"。UCP定义了商品目录、价格方案的标准化描述格式。
AP2（Google→FIDO Alliance）：Agent Payments Protocol。2026年4月，Google将AP2捐赠给FIDO Alliance——就是那个定义了WebAuthn/FIDO2无密码认证标准的组织。这个选择意味深长：AP2的支付授权模型借鉴了FIDO的设备认证模型，用户在Agent支付时的体验类似"指纹确认"。
graph LR
subgraph "Agent支付流程 (AP2)"
A1[Agent发起购买请求] --> A2[AP2授权检查]
A2 --> A3{用户预设策略}
A3 -->|自动批准| A4[执行支付]
A3 -->|需确认| A5[推送用户确认]
A5 --> A6{用户响应}
A6 -->|批准| A4
A6 -->|拒绝| A7[取消交易]
A4 --> A8[返回支付凭证]
A8 --> A9[Agent继续任务]
end
AP2的关键创新是分层授权策略：用户可以为Agent预设不同层级的消费权限——低于$5自动批准、$5-$50需要推送通知确认、超过$50需要生物识别验证。这解决了"Agent会不会乱花钱"的核心焦虑。
在所有协议中，ANP（Agent Network Protocol）是一个独特的存在。它不走"大厂主导+基金会治理"的路线，而是基于W3C DID（去中心化身份）标准，追求完全P2P的Agent网络。
ANP的技术白皮书（已提交arXiv）提出了三层架构： 1. 身份层：基于W3C DID标准的去中心化身份验证 2. 发现层：去中心化的Agent注册与发现，不依赖中心化注册表 3. 消息层：端到端加密的P2P消息传递
ANP的理想场景是：当没有任何中心化平台可以信任时，Agent之间如何自主发现、验证身份、建立通信。这在跨国企业联盟、去中心化自治组织、以及需要避免平台锁定的场景中有实际需求。
但ANP面临严峻的现实挑战：缺乏大厂支持、没有成熟的SDK、生产案例为零。截至2026年5月，ANP更适合作为"学术实验"关注，而非生产选型。
IBM的ACP（Agent Communication Protocol）是这场战争中最重要的"失败者"案例。ACP在2025年3月由IBM Research发布，定位是轻量级Agent间通信的REST协议。
ACP的核心设计并不差： - 基于REST（而非JSON-RPC），降低了理解门槛 - 原生支持Agent的创建、运行、等待、取消等完整生命周期 - IBM的BeeAI平台作为参考实现
但ACP败在了生态上。Google的A2A在一个月后发布，但迅速获得了Atlassian、Salesforce、SAP等50+企业的支持。IBM意识到ACP不可能独立成为行业标准，在2025年8月选择将其并入A2A。
这个决定的影响深远：ACP并入A2A后，BeeAI平台从ACP迁移到A2A，IBM的Agent生态完全融入了Google主导的轨道。这是Agent协议领域的第一个"标准战争"终结事件，也为后续的协议收敛奠定了基调。
到2026年中期，已经有一批企业完成了多协议栈的实际部署。以下是基于公开案例总结的三种主流部署模式。
[用户] ←AG-UI→ [协调Agent] ←A2A→ [专家Agent A] ←MCP→ [数据库]
←A2A→ [专家Agent B] ←MCP→ [API]
←A2A→ [专家Agent C] ←MCP→ [文件系统]
适用场景：企业内部的多Agent系统，所有Agent由同一团队管理。
技术栈：AG-UI（交互）+ A2A（协调）+ MCP（工具连接）。这是目前最成熟的组合，Microsoft Agent Framework 1.0原生支持。
成本：MCP Server开发约占总工时的60%，A2A集成约30%，AG-UI前端适配约10%。
[企业A Agent] ←A2A→ [企业B Agent] ←MCP→ [企业B系统]
←A2A→ [企业C Agent]
[企业A Agent] ←MCP→ [企业A系统]
适用场景：供应链协作、跨组织业务流程自动化。
关键挑战：Agent Card的安全策略协商、认证互信、审计日志。A2A的authentication.schemes字段需要双方预先约定。
技术栈：A2A（核心）+ AP2（支付，如果涉及商业交易）。不需要AG-UI，因为用户不直接参与Agent间交互。
[用户] ←A2UI→ [平台Agent] ←A2A→ [第三方Agent A] ←MCP→ [外部服务]
←A2A→ [第三方Agent B]
[用户] ←AG-UI→ [界面渲染]
[平台Agent] ←AP2/x402→ [支付系统]
适用场景：Agent市场、SaaS平台的Agent生态。
技术栈：全栈——A2UI（动态界面）+ AG-UI（实时交互）+ A2A（Agent发现与协调）+ MCP（工具连接）+ AP2/x402（支付）。这是最复杂的部署模式，需要所有四层协议。
| 你的场景 | 推荐协议栈 | 理由 | 上手时间 |
|---|---|---|---|
| 单Agent + 工具调用 | MCP | 不需要其他协议，MCP足够 | 1-2天 |
| 多Agent同框架协作 | 框架原生协议 | LangGraph/CrewAI内部协调已够用 | 0（框架自带） |
| 多Agent跨框架协作 | A2A + MCP | 需要标准化Agent间通信 | 1-2周 |
| Agent需要生成界面 | A2UI 或 AG-UI | 按场景选：生成完整UI用A2UI，嵌入已有应用用AG-UI | 2-3周 |
| Agent涉及商业交易 | + AP2/x402 | 按支付类型选：法币用AP2，加密货币用x402 | 3-4周 |
| 全栈Agent平台 | 全四层 | 需要完整的协议栈工程能力 | 2-3月 |
| 实时协作场景 | + SLIM | 当A2A的延迟无法满足时引入 | 额外2-3周 |
2026年Agent协议栈的收敛，与1990年代TCP/IP栈的标准化有着惊人的相似性：
当前正处于第2阶段向第3阶段过渡的关键窗口。协议层趋于稳定，应用层的创新才刚刚开始。
| 方向 | 市场规模(估) | 竞争度 | 上手门槛 | 推荐指数 |
|---|---|---|---|---|
| MCP Server开发 | $100M+ | 中 | 低 | ★★★★★ |
| A2A Agent集成 | $200M+ | 低 | 中 | ★★★★★ |
| A2UI界面开发 | $50M+ | 低 | 中 | ★★★★☆ |
| 全栈协议集成咨询 | $500M+ | 极低 | 高 | ★★★★★ |
| AP2支付集成 | $300M+ | 极低 | 高 | ★★★★☆ |
| SLIM高性能Agent | $100M+ | 极低 | 高 | ★★★☆☆ |
| ANP去中心化Agent | $20M+ | 极低 | 高 | ★★☆☆☆ |
最佳训练营方向：5天"Agent全栈协议工程师"认证——Day 1-2 MCP Server开发，Day 3 A2A集成，Day 4 A2UI/AG-UI界面，Day 5 全栈实战项目。市场尚无成熟竞品，先发优势明显。
A2UI vs AG-UI统一：两个交互层协议能否合并？目前没有迹象，但这增加了开发者的认知负担和集成成本。
ANP的去中心化悖论：ANP的理想很美好，但去中心化身份验证的用户体验远不如中心化方案。没有大厂推动，ANP可能长期停留在学术阶段。
SLIM的IETF不确定性：IETF标准化流程通常需要2-3年。在这期间，SLIM的API可能频繁变更，不适合现在就绑定。
支付层的碎片化：AP2、UCP、x402三者之间的关系尚未厘清。AP2管授权，UCP管描述，x402管执行——但三者的边界正在模糊。
版本兼容性：A2A在2026年经历了多次spec升级，早期实现的Agent可能无法与新版Agent正确交互。协议版本协商机制尚不完善。
安全审计缺口：四层协议栈的安全模型各自独立，跨层攻击（如通过MCP工具注入操纵A2A任务状态）尚无系统性防护方案。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。