MCP + A2A 融合：协议层已就绪，信任层才是硬仗

MCP + A2A 融合：协议层已就绪，信任层才是硬仗

Linux Foundation 治理下的 Agent 协议新格局

2026 年 6 月 25 日，Linux Foundation Agentic AI Foundation 发布了 MCP + A2A 融合草案。两个协议都将治理放在 Linux Foundation 旗下——这意味着什么？

不是「A2A 取代 MCP」，也不是反之。而是企业可以同时部署两者：Agent 之间用 A2A 协调，Agent 内部用 MCP 连接工具。

但 A2A 的信任模型还太浅。v1.0 加入了签名 Agent Card——可以验证「这个 Agent 是谁发布的」，但不能验证「这个 Agent 现在在谁的委托下做什么」。

跨组织 Agent 协作，在信任层面还有一段路要走。

一、Linux Foundation 治理：不是合并，是「分治统一」

2025 年底，MCP 和 A2A 先后捐赠给 Linux Foundation。但注意一个细节：它们归属于不同的子基金会——MCP 在 Agentic AI Foundation (AAIF)，A2A 在 LF AI & Data。

AAIF 的创始成员包括 Anthropic、Block、OpenAI，以及 Google、Microsoft、AWS 等白金成员。这种「同一屋檐下、不同房间」的治理结构，核心意义有三点：

  1. 消除单厂商锁定风险：Anthropic 不能单方面改 MCP，Google 不能单方面改 A2A。企业 CIO 敢把预算投进去，因为协议不归任何竞争对手独有。
  2. 允许差异化演进：两个协议可以按各自节奏迭代，不需要强行统一。MCP 专注 Agent-Tool 纵向连接，A2A 专注 Agent-Agent 横向协调。
  3. 加速生态采纳：正如业界评论所言，这是 Agent 生态的「Kubernetes 时刻」——vendor-neutral standards 替代了每个团队自己造轮子。

这不是合并，而是确认分工。

二、融合草案的实质：分层架构，而非替代关系

2026 年 6 月的融合草案，本质上是对以下分层架构的正式确认：

┌─────────────────────────────────────────────┐
│  A2A 层：Agent ↔ Agent（横向协调）           │
│  - Agent Card 发现与签名验证                 │
│  - Task 生命周期（submitted → working → completed）│
│  - 跨组织委托与协商                          │
├─────────────────────────────────────────────┤
│  MCP 层：Agent ↔ Tool（纵向连接）            │
│  - Tool / Resource / Prompt 调用             │
│  - 状态化 / 无状态工具执行（v2 去会话化）     │
│  - 上下文注入与能力协商                      │
└─────────────────────────────────────────────┘

Google 的比喻最准确：A2A 是 horizontal bus，MCP 是 vertical bus。

一个典型的生产架构是：Orchestrator Agent 通过 A2A 将任务委派给 Specialist Agent，后者内部通过 MCP 调用数据库、API、文件系统等工具。两者不是竞争关系，而是互补的管道。

三、A2A v1.0 的信任「浅层」：身份 ≠ 委托

A2A v1.0 的 Signed Agent Card 解决了发布者身份验证——通过 JWS 签名，你可以验证「这个 Agent Card 是否由声称的域名签发」。

但它没有解决核心问题：

「这个 Agent 现在在谁的委托下做什么？」

这是两个完全不同的信任维度：

信任维度 A2A v1.0 覆盖 缺失的部分
静态身份 ✅ Signed Agent Card 验证发布者域名 运行时身份可能被盗用
委托链 ❌ 无原生支持 Agent A → B → C，权限如何衰减？
当前行为授权 ❌ 无原生支持 持有有效 Agent Card ≠ 当前任务被授权
跨组织审计 ❌ 无原生支持 多方日志格式不一致，难以追溯

学术界的批评很直接：A2A 的 centralized identity model 在跨域场景下存在单点故障，且缺乏长期防篡改验证机制。安全分析也指出，A2A 的 session smuggling 漏洞允许攻击者通过会话令牌管理弱点注入消息，冒充其他 Agent。

一句话：A2A 解决了「Agent 怎么找到彼此」，但没解决「Agent 凭什么代表某组织行动」。

四、正在填补的信任缺口：从身份到委托

业界已经意识到这个 gap，出现了几类补充方案：

1. SDAP（Secure Digital Agent Protocol）

在 A2A 之上叠加五层安全：DID 身份、双向认证、端到端加密、分层信任委托（scope attenuation）、Merkle 审计链。定位是「A2A 的 HTTPS 层」。

2. AIP（Agent Identity Protocol）

提出 Invocation-Bound Capability Tokens (IBCTs)，将身份、衰减授权和溯源绑定到单次调用链。支持 Biscuit token 的 Datalog 策略，实现多跳委托的权限收紧。

3. AWS Cedar + A2A

用 Cedar 策略引擎实现 delegation token 的 scope attenuation——子权限只能收窄不能放宽，且每个 token 包含 chain_hash 防篡改。

4. Iron Book / OPA

通过 Rego 策略在 A2A 扩展点执行双重决策——请求方检查 + 执行方检查，基于 DID 和信任评分。

这些方案的共同指向是：从「验证你是谁」进化到「验证你被允许做什么，以及这个允许是谁给的」。

五、对数字员工架构的启示：Token 不只是算力单位

在 OpenClaw.NET 的数字员工 + TokenHub 架构中，我们恰好处于这个信任缺口的核心地带：

  • MCP 层：数字员工通过 MCP 连接内部工具（数据库、ERP、API）
  • A2A 层：当数字员工需要跨组织协作（供应商 Agent、客户 Agent），A2A 提供发现机制
  • 缺失层：谁来验证「这个外部 Agent 是否有权代表某组织向我发起委托」？

这正是 TokenHub 可以切入的位置：

  1. Token 作为委托凭证：不只是算力计费单位，而是携带权限衰减链的委托令牌
  2. 跨组织信任锚：利用 JSON-LD / DID 构建可验证的委托链，补充 A2A Agent Card 的静态身份
  3. 审计层：将每次跨组织 Agent 调用的委托链、Token 消耗、权限边界写入不可篡改日志

MCP 解决了「怎么连工具」，A2A 解决了「怎么找 Agent」，但「凭什么信你」这个问题，还没有标准答案。

结语：协议层已就绪，信任层才是硬仗

Linux Foundation 治理让 MCP + A2A 成为了「安全的赌注」，但安全的是协议层，不是信任层。

跨组织 Agent 协作的真正难点，已经从协议互通转移到了三个核心问题：

  1. 委托验证：这个 Agent 的当前行为是否在其被授权的范围内？
  2. 权限衰减：多跳委托中，权限如何逐层收紧而非扩散？
  3. 审计溯源：跨组织的 Agent 调用链，如何形成不可抵赖的证据？

这三个问题，正是当前 Agent 生态中最开放的创新战场。

本文基于 Linux Foundation Agentic AI Foundation 2026 年 6 月发布的 MCP + A2A 融合草案及相关技术资料整理。

posted @ 2026-07-21 08:05  张善友  阅读(208)  评论(0)    收藏  举报