MCP与A2A互操作实战：一个PoC验证者的三点反思

当智能体协议生态分化为MCP（Model Context Protocol）与A2A（Agent-to-Agent）两大阵营时，"互操作"这个看似美好的词，在工程实践中往往意味着大量隐性的摩擦成本。一位开发者在Reddit上分享了自己构建MCP与A2A桥接PoC（概念验证）的经历，结论相当直接：互操作比看起来难得多。这不是一篇唱衰协议的帖子，而是来自一线代码的清醒复盘。

为什么要在MCP和A2A之间架桥

MCP解决的是"智能体如何接入外部工具与数据源"的问题，它的核心抽象是客户端-服务器模式下的能力暴露；A2A则聚焦"智能体之间如何协同完成任务"，强调对等通信与任务委托。两者在协议设计目标上本就不同，但现实场景里，一个基于MCP接入工具的智能体，经常需要把任务转交给另一个以A2A方式暴露能力的智能体——桥接需求由此产生。

作者构建PoC的动机，正是想把这两种通信范式打通，让工具调用与智能体协作在同一个流程中自然衔接。听起来只是两个API之间的翻译工作，实际动手后才发现，协议语义的错位远比接口格式的差异更棘手。

MCP（Model Context Protocol）由 Anthropic 于 2024 年底提出并开源，定位是让模型以标准化方式访问外部工具、资源和提示模板，采用 JSON-RPC 通信，围绕 tools、resources、prompts 三类原语构建客户端-服务器交互。A2A（Agent-to-Agent Protocol）则由 Google 在 2025 年发布并捐赠给 Linux 基金会，面向智能体之间的任务委托与协作，核心概念包括 Agent Card（描述智能体能力与端点的元数据文档）、Task（可长期跟踪的任务对象）和消息流。二者一个向外接工具、一个向内连同行，恰好覆盖智能体系统的两个通信方向，这正是实践中常需同时使用、进而产生桥接需求的原因。

互操作真正的难点不在协议转换层

从工程视角看，把MCP的请求映射成A2A的消息格式，或者反过来，技术上并非不可行。作者在PoC中确实跑通了基础链路，但过程中暴露的问题集中在语义层面。

能力描述的不对称

MCP用工具描述（tool schema）精确界定一个能力能接受什么参数、返回什么结构；A2A的能力表达则更偏向任务级描述，粒度更粗。当桥接器试图把A2A智能体包装成一个MCP工具时，参数约束的缺失会直接导致调用方无法可靠地构造请求。作者指出，这种不对称不是加一层适配代码就能消除的，它源于两个协议对"能力"这个概念本身的定义差异。

Agent Card 是 A2A 中描述智能体能力的核心机制，它以 JSON 形式声明智能体的名称、描述、支持的技能（skills）、输入输出模态、认证方式和服务端点 URL，便于其他智能体自动发现与调用。但 Agent Card 的 skills 字段多为自然语言描述加少量示例，缺少类似 JSON Schema 那样对参数类型、必填项、取值范围的形式化约束。这正是桥接时把 A2A 智能体包装成 MCP 工具的主要障碍：MCP 的 tool schema 要求逐字段定义类型与约束，调用方模型据此生成结构化参数，而 A2A 侧缺乏对等的形式化信息，适配层只能靠推测或人工补写 schema。

生命周期与状态管理的冲突

MCP的调用通常是短生命周期的请求-响应模式，而A2A的任务委托可能跨越较长时间，涉及多轮状态更新和异步回调。PoC中处理这种生命周期错配时，桥接层不得不承担额外的状态跟踪职责，这已经超出了"翻译器"的范畴，变成了一个准协调器。作者坦言，这部分复杂度在最初的方案设计中严重低估了。

A2A 的任务模型为长时间运行场景设计：一次任务委托会产生一个带唯一 ID 的 Task 对象，其状态在 submitted、working、input-required、completed、failed 等之间迁移，期间可通过 SSE 流式推送进度更新，也支持推送通知回调。MCP 的 tools/call 则是典型的同步请求-响应，即便引入进度通知，调用方仍期待在单次会话内得到结果。桥接层因此需要把 A2A 的 Task 状态机映射为 MCP 调用方可理解的中间态，并处理会话断开后任务仍在后台运行的情况，这实际上要求桥接器持久化任务映射表并实现轮询或推送转发。

错误语义难以对齐

两个协议对失败的定义和传播方式不同。MCP的错误码倾向于面向工具执行的异常，A2A则要考虑任务级别的失败与重试语义。桥接层在转译错误时，信息丢失几乎不可避免，下游调用方拿到的错误描述可能已经偏离了原始失败原因。这对生产环境的可观测性是一个现实威胁。

对协议生态的一点判断

这位开发者的PoC经验指向一个更宏观的结论：协议互操作的成本，往往不在协议规范本身，而在规范没有覆盖的语义缝隙里。标准化组织可以定义消息格式，却很难定义两个协议在概念模型上的映射规则，这部分工作只能由实践者用代码去试探和沉淀。

对打算做类似桥接的团队，作者的经历提供了几个参考信号：优先评估语义对齐的可行性再动手写适配层；把状态管理复杂度纳入工期估算；为错误转译设计可追溯的日志策略。互操作不是一次性工程，而是需要持续维护的语义协商过程。

MCP与A2A的融合趋势在社区中讨论热度不减，但这个PoC提醒我们，协议之间的"连通"和"互通"是两件事。前者靠接口，后者靠对语义的深刻理解与妥协设计。

资料来源：Reddit开发者分享的MCP与A2A桥接PoC复盘。