MCP / A2A / ACP 协议解析-Day31-平芜编程栈

一、为什么需要 Agent 开放协议

1.1 问题：Agent 生态的"巴别塔困境"

在 2024~2025 年，多 Agent 系统面临一个根本问题：每个框架都有自己的内部通信协议。LangGraph Agent 只能与 LangGraph Agent 对话，AutoGen Agent 只能与 AutoGen Agent 对话，跨框架、跨供应商、跨云？只能写胶水代码。

这种碎片化导致：

每对 Agent 之间的集成都是定制合约
维护负担随 Agent 数量非线性增长
跨组织协作几乎不可能

1.2 解决方案：分层协议栈

2026 年的行业共识已形成清晰的两层模型：

协议	解决的问题	类比
MCP	Agent 如何连接工具和数据源	USB-C for AI Tools
A2A	Agent 如何与其他 Agent 协作	HTTP for AI Agents
Commerce	Agent 如何完成商业交易	支付网关 for AI

二、MCP：Model Context Protocol

2.1 概述

MCP 由 Anthropic 于 2024 年 11 月发布，是当前最成熟的 Agent-to-Tool 连接标准。2026 年 7 月 28 日发布了最新规范版本，已被 Anthropic、OpenAI、Google、Microsoft 等主流厂商原生支持。

2.2 核心架构：Host-Client-Server 模型

MCP 采用三层架构：

┌─────────────────────────────────────────┐ │ MCP Host (AI Application) │ │ Claude Desktop / Cursor / ChatGPT │ ├─────────────────────────────────────────┤ │ MCP Client #1 │ MCP Client #2 │ │ (per server) │ (per server) │ │ manages conn │ manages conn │ ├─────────────────────────────────────────┤ │ MCP Server #1 │ MCP Server #2 │ │ - Tools │ - Tools │ │ - Resources │ - Resources │ │ - Prompts │ - Prompts │ └─────────────────────────────────────────┘

关键设计原则：

1 Host : N Clients : N Servers：一个 Host 可连接多个 Server，每个 Client 只管理一个 Server 的连接
JSON-RPC 2.0：所有请求、响应、通知统一使用 JSON-RPC 2.0 格式
传输无关：支持 STDIO（本地进程）和 Streamable HTTP（远程/共享部署）

2.3 核心原语

原语	说明	示例
Tools	Agent 可调用的函数	`query_db`,`send_email`,`search_web`
Resources	Agent 可读取的数据源	`file://`,`db://`,`api://`
Prompts	预定义的提示模板	系统提示、少样本示例
Sampling	允许 Server 请求 Host 进行 LLM 推理	Server 可"回呼" Host 的模型

2.4 传输层

传输方式	适用场景	特点
STDIO	本地进程（如 Claude Desktop 插件）	简单、无网络开销、生命周期绑定
Streamable HTTP	远程/共享部署	支持 SSE 流式、可跨网络、可负载均衡

2.5 企业级扩展（2026-07-28 规范）

2026 年 7 月的规范更新引入了多项企业级特性：

扩展	说明
Scoped Authorization	企业级作用域授权，替代 per-user OAuth redirect
MCP Gateway	单一入口点，提供发现、路由和权限范围的工具可见性
Async Tasks	`io.modelcontextprotocol/tasks`扩展，支持长时间运行的异步任务
Server 四层架构	Interface → Application → Domain → Infrastructure

2.6 实战示例

# 使用 MCP Python SDK 连接 ServerfrommcpimportClientSession,StdioServerParametersfrommcp.client.stdioimportstdio_client# 1. 定义 Server 参数（本地进程）server_params=StdioServerParameters(command="python",args=["mcp_server.py"],env=None)# 2. 建立连接asyncwithstdio_client(server_params)as(read,write):asyncwithClientSession(read,write)assession:# 3. 初始化awaitsession.initialize()# 4. 发现可用工具tools=awaitsession.list_tools()print(f"Available tools:{[t.namefortintools.tools]}")# 5. 调用工具result=awaitsession.call_tool("query_db",arguments={"sql":"SELECT * FROM users LIMIT 10"})print(result.content)

三、A2A：Agent-to-Agent Protocol

3.1 概述

A2A 由 Google 于 2025 年 4 月发布，2025 年 6 月捐赠给 Linux Foundation。2026 年 4 月 Google Cloud Next 大会上发布v1.0，标志着协议进入生产就绪阶段。截至 2026 年，已有150+ 组织支持，包括 AWS、Microsoft、IBM、Salesforce、SAP、ServiceNow。

3.2 核心设计哲学

A2A 的设计假设是：对面的 Agent 由别人构建，使用不同技术栈，可能位于不同公司，你看不到它的内部。

这意味着：

不共享内存：Agent 之间不共享内部状态
不共享工具：每个 Agent 维护自己的 MCP 工具连接
一切通过消息传递：所有信息必须通过结构化消息交换

3.3 三层规范架构

A2A v1.0 规范分为三层：

┌─────────────────────────────────────────┐ │ Layer 3: Protocol Bindings │ │ JSON-RPC 2.0 over HTTPS (primary) │ │ gRPC with Protocol Buffers │ │ HTTP/JSON/REST │ ├─────────────────────────────────────────┤ │ Layer 2: Operations │ │ SendMessage, SendStreamingMessage │ │ GetTask, ListTasks, CancelTask │ │ SubscribeToTask, push-notification │ │ Agent Card retrieval │ ├─────────────────────────────────────────┤ │ Layer 1: Data Model │ │ AgentCard, AgentSkill, Task, Message │ │ Part, Artifact, Extension │ │ (Protocol Buffers + JSON Schema) │ └─────────────────────────────────────────┘

3.4 核心原语

Agent Card（能力名片）

每个 Agent 在/.well-known/agent.json发布自己的能力描述：

{"name":"billing-agent","description":"Handles invoice and refund queries","url":"https://billing.example.com/a2a","version":"1.0.0","skills":[{"id":"invoice_check","name":"Check Invoice Status","description":"Query invoice payment status by ID","inputSchema":{"type":"object","properties":{"invoiceId":{"type":"string"}}}},{"id":"refund","name":"Process Refund","description":"Initiate refund for paid invoice","inputSchema":{"type":"object","properties":{"invoiceId":{"type":"string"},"reason":{"type":"string"}}}}],"authentication":{"type":"oauth2","authorizationEndpoint":"https://auth.example.com/oauth/authorize"}}

Task（任务）

Task 是 A2A 的核心工作单元，具有完整的状态生命周期：

状态	说明
`submitted`	任务已提交，等待处理
`working`	Agent 正在处理中
`input-required`	Agent 需要额外输入才能继续
`completed`	任务成功完成
`canceled`	任务被取消
`failed`	任务执行失败

Message & Part（消息与片段）

Task ├── Message (turn-based conversation) │ ├── Part (text) │ ├── Part (file) │ └── Part (data) └── Artifact (structured output) ├── Part (text) ├── Part (file) └── Part (data)

3.5 v1.0 的关键安全增强

A2A v1.0 最重要的安全特性是Signed Agent Cards：

使用JSON Web Signature (JWS)对 Agent Card 进行数字签名
接收方可以验证卡片确实由域名所有者签发
防止卡片伪造攻击（attacker 架设假 Agent Card 重定向流量）

3.6 实战示例

# A2A Python SDK 示例froma2aimportA2AClient,TaskSendParams# 1. 创建客户端（自动发现 Agent Card）client=A2AClient("https://billing.example.com")# 2. 查看 Agent 能力print(client.agent_card.skills)# [Skill(id='invoice_check', ...), Skill(id='refund', ...)]# 3. 发送任务task=client.send_task(TaskSendParams(id="task-001",message={"role":"user","parts":[{"type":"text","text":"Check invoice INV-12345"}]}))# 4. 流式接收结果（SSE）forupdateinclient.send_task_streaming(task.id):print(f"Status:{update.status.state}")ifupdate.status.message:print(f"Output:{update.status.message.parts[0].text}")

四、ACP (IBM)：已合并入 A2A 的历史

4.1 起源

ACP（Agent Communication Protocol）由 IBM 的 BeeAI 团队于 2025 年初开发，是一个轻量级的、REST-based 的 Agent 通信标准。它定义了 Agent-to-Agent、Agent-to-Application 和 Agent-to-Human 的通信模式。

4.2 合并事件

2025 年 8 月，ACP 与 A2A 合并：

合并原因：

两者解决的是高度重叠的问题（Agent 间通信）
合并避免生态碎片化
BeeAI 平台现在运行在 A2A 之上

4.3 ACP 的设计遗产

虽然 ACP 不再独立演进，但其设计影响了合并后的 A2A：

ACP 特性	对 A2A 的影响
REST-first 设计	A2A 增加了 HTTP/JSON/REST Binding
Build-time Manifest	演化为 A2A 的 Agent Card
MIME-typed Message Parts	成为 A2A Part 模型的基础
Agent-to-Human 通信	纳入 A2A 的`input-required`状态

结论：对于新系统，直接构建在 A2A 上即可，无需考虑独立的 ACP。

五、Commerce Protocols：Agent 商业交易层

除了工具连接和 Agent 协作，2026 年还涌现了专门解决Agent 自主商业交易的协议层。

5.1 三层商业协议栈

协议	发起方	解决的问题	类比
UCP	Google	商品发现、比较、展示	商品目录 API
ACP	OpenAI + Stripe	结账流程、支付执行	购物车 + 结账
AP2	Google → FIDO	支付授权、用户同意证明	支付网关

这三层是互补而非竞争：UCP 发现商品 → ACP 完成结账 → AP2 证明授权。

5.2 ACP (Agentic Commerce Protocol)

由 OpenAI 和 Stripe 共同维护，目前处于 Beta 阶段：

核心机制：

Agent 使用委托支付令牌（delegated payment token）代替原始卡号
连接买家 Agent、商家和支付网络
Stripe 的 Agentic Commerce Suite 已基于此协议运行

5.3 AP2 (Agent Payments Protocol)

Google 于 2025 年 9 月发布，2026 年 4 月 28 日捐赠给FIDO Alliance：

核心机制：

Verifiable Credentials：可验证的数字凭证
Cryptographic Mandates：密码学授权指令，创建防篡改的同意证明
确保 Agent 只能在用户明确授权的范围内消费

5.4 卡网络层

Visa 和 Mastercard 在协议之上提供接受层：

产品	功能
Visa Intelligent Commerce Connect	协议无关的接入层，同时接受多种 Agent 标准
Mastercard Agent Pay	机器对机器交易的支付凭证系统
Visa Trusted Agent Protocol	验证 Agent 身份（与 Cloudflare 合作）

六、生态整合：Linux Foundation Agentic AI Foundation

6.1 治理统一

2026 年初，Linux Foundation 成立了Agentic AI Foundation，统一管理 MCP、A2A（含 ACP）的治理：

这意味着：

协议不再是单一公司的私有接口
采用类似 Kubernetes、gRPC 的多利益相关方治理模式
采购和合规团队可以像对待其他基础设施工具一样对待这些协议

6.2 当前协议状态总览

协议	治理机构	状态	新系统建议
MCP	Linux Foundation Agentic AI Foundation	Active，工具集成主导标准	✅ 用于 Agent-Tool 连接
A2A	Linux Foundation Agentic AI Foundation	Active，已吸收 ACP	✅ 用于 Agent-Agent 协作
ACP (IBM)	已合并	Merged into A2A (Aug 2025)	❌ 不再独立演进
ACP (Commerce)	OpenAI + Stripe	Beta	用于 Agent 购物结账
AP2	FIDO Alliance	v0.2	用于支付授权

七、MCP vs A2A：选型决策框架

7.1 核心差异

维度	MCP	A2A
关系类型	垂直：一个 Agent 连接多个工具	水平：多个 Agent 相互协作
信任边界	通常在同一组织或单一供应商内	设计用于跨越组织边界
通信模型	Client-Server	Peer-to-Peer
身份原语	OAuth client credentials	Signed Agent Cards (JWS)
消息内容	工具调用、资源读取、提示模板	任务委托、消息交换、产物传递

7.2 选型决策树

你的场景是什么？ ├── Agent 需要查询数据库 / 调用 API / 读取文件 │ └── 使用 MCP │ ├── 两个 Agent 需要协作完成一个任务 │ └── 使用 A2A │ ├── Agent 既需要工具又需要与其他 Agent 协作 │ └── 同时使用 MCP + A2A │ └── A2A Agent 内部使用 MCP 调用自己的工具 │ └── Agent 需要帮用户完成购物 └── Commerce Protocols (ACP + AP2 + UCP)

7.3 生产架构蓝图

2026 年的最佳实践架构是双协议栈：

┌─────────────────────────────────────────┐ │ Orchestrator Agent │ │ (LangGraph / CrewAI / Custom) │ │ ┌─────────────┐ │ │ │ A2A Client │ ←──→ 其他 Agent │ │ └─────────────┘ │ ├─────────────────────────────────────────┤ │ ┌─────────────┐ ┌─────────────┐ │ │ │ MCP Client │ │ MCP Client │ │ │ │ → DB Server│ │ → Web Server│ │ │ └─────────────┘ └─────────────┘ │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ MCP Client │ │ MCP Client │ │ │ │ → File Sys │ │ → API Server│ │ │ └─────────────┘ └─────────────┘ │ └─────────────────────────────────────────┘

关键洞察：跳过 MCP 直接上 A2A 的架构，会得到"连接良好但无数据感知"的 Agent；停在 MCP 不扩展 A2A 的架构，会在需要跨供应商协作时遇到天花板。

八、安全考量

8.1 MCP 安全

Context Poisoning：2026 年 4 月研究显示，被污染的 MCP 上下文可窃取.env密钥并触发文件删除
建议：对 MCP Server 进行代码审计，限制 Resources 的访问范围，使用 scoped authorization

8.2 A2A 安全

Agent Card 伪造：v1.0 之前的版本存在卡片伪造风险
解决方案：v1.0 引入的 Signed Agent Cards 使用 JWS 签名验证域名所有权
建议：始终验证 Agent Card 的签名，使用 TLS 1.3，实施速率限制

九、总结

协议	一句话定义	2026 年状态
MCP	Agent 连接工具和数据的"USB-C"	事实标准，数千社区 Server
A2A	Agent 之间协作的"HTTP"	生产就绪，150+ 组织支持
ACP (IBM)	已合并入 A2A 的 REST-based 前身	不再独立演进
ACP (Commerce)	Agent 自主购物的结账协议	Beta，OpenAI+Stripe 维护
AP2	Agent 支付授权的密码学证明	v0.2，FIDO Alliance 治理

最终建议：

先实施 MCP：给你的 Agent 提供上下文和工具访问能力
再添加 A2A：当需要跨供应商或跨组织 Agent 协作时
按需引入 Commerce：当 Agent 需要自主完成商业交易时
全部选择 Linux Foundation 治理的开放标准：避免供应商锁定

参考资源

MCP 官方规范 (2026-07-28)
A2A 官方规范 v1.0
Linux Foundation Agentic AI Foundation
AP2 FIDO Alliance
Stripe Agentic Commerce Suite