MCP + A2A 融合：协议层已就绪，信任层才是硬仗 - 张善友
内容提要
Linux基金会发布MCP与A2A融合草案，二者互补而非取代：A2A负责Agent间横向协调，MCP连接工具。但A2A信任模型不足，仅验证发布者身份，无法确认当前委托权限。业界正通过DID、能力令牌等方案补足，跨组织协作信任仍是开放挑战。
延伸解读
协议分工明确，但信任模型是短板
融合草案确认了A2A与MCP的分工：A2A负责Agent间横向协调，MCP负责Agent与工具纵向连接。但A2A的信任模型仅验证发布者身份，无法确认当前委托权限。这意味着跨组织协作时，仅靠协议本身难以确保安全，需要额外机制补足。
业界补足信任的多种方案
针对A2A信任不足，业界提出多种方案：如叠加DID身份、双向认证、端到端加密等五层安全；或使用Invocation-Bound Capability Tokens，将身份与授权绑定到单次调用；还有基于Cedar或Rego策略实现权限衰减与双重决策。这些方案共同指向从“验证你是谁”到“验证你被允许做什么”的转变。
跨组织协作的信任挑战
文章指出，跨组织Agent协作的真正难点已从协议互通转向信任层，包括身份验证、授权委托和审计溯源。尽管Linux Foundation治理让协议层更安全，但信任层仍是开放挑战，也是当前Agent生态中的创新战场。
Q&A
MCP和A2A协议是什么关系？
MCP和A2A是互补关系，而非取代关系。A2A用于Agent之间的横向协调，MCP用于Agent与工具之间的纵向连接。企业可以同时部署两者：Agent之间用A2A协调，Agent内部用MCP连接工具。
A2A协议的信任模型存在哪些不足？
A2A v1.0的Signed Agent Card只能验证Agent的发布者身份，无法验证Agent当前在谁的委托下执行什么操作。此外，其集中式身份模型在跨域场景存在单点故障，且缺乏长期防篡改验证机制，还存在session smuggling漏洞，攻击者可冒充其他Agent。
业界有哪些方案来弥补A2A的信任缺口？
业界提出了多种补充方案，包括：在A2A之上叠加DID身份、双向认证、端到端加密、分层信任委托和Merkle审计链；提出Invocation-Bound Capability Tokens (IBCTs)绑定身份和授权；使用Cedar策略引擎实现委托令牌的权限收窄；通过Rego策略在A2A扩展点执行双重决策。
MCP和A2A分别归属于Linux基金会的哪个子基金会？
MCP归属于Agentic AI Foundation (AAIF)，A2A归属于LF AI & Data。
跨组织Agent协作面临的核心挑战是什么？
跨组织Agent协作的核心挑战是信任问题，具体包括：验证Agent身份、验证其当前委托权限、以及确保委托链的可信性。协议层已就绪，但信任层仍是开放挑战。
A2A协议中的Signed Agent Card能验证什么？
Signed Agent Card通过JWS签名，可以验证Agent Card是否由声称的域名签发，即验证Agent的发布者身份，但不能验证Agent当前在谁的委托下执行什么操作。
