什么是 A2A 协议？它和 MCP 协议有什么区别？
参考答案
A2A（Agent-to-Agent）协议是 Google 在 2025 年发布的开放协议标准，专门解决不同 AI Agent 之间如何通信和协作的问题。
MCP 解决的是”Agent 怎么用工具”，A2A 解决的是”Agent 怎么跟别的 Agent 合作”。
两者的核心差异在于通信对象完全不同。MCP 是 Agent 宿主和工具、数据源之间的协议，工具本身不会主动思考和决策，只是被动响应调用。A2A 是 Agent 和 Agent 之间的对等协作协议，双方都有自主推理能力，可以协商、分工、交换中间结果。
MCP 就像你用手机 App 叫外卖，你下单，系统接单处理。A2A 就像你和同事一起合作完成一个项目，你们之间需要沟通进度、分配任务、互相交付成果。
还有一个关键区别是透明度。MCP 中 Client 知道 Server 提供了哪些具体的函数和参数，工具的内部实现对调用方是透明的。A2A 更强调能力发现，Agent 只需通过 Agent Card 声明自己能做什么，对方不需要知道它内部怎么实现的，实现了真正的封装和解耦。
扩展知识
A2A 协议的核心概念
A2A 围绕几个核心抽象设计整套交互流程：
1）Agent Card 是 Agent 的”名片”，描述能力范围、支持的交互模式、访问方式。其他 Agent 通过读取 Agent Card 来发现对方能做什么。Agent Card 通常以 JSON 格式发布在约定路径 /.well-known/agent-card.json 下，类似网站的 robots.txt，让整个发现过程标准化。
2）Task 是核心工作单元。一个 Agent 可以给另一个 Agent 创建 Task，任务有完整的生命周期：submitted → working → completed / failed。支持长时间异步执行，不需要同步等待。
3）Message 和 Artifact 负责信息交换。Message 用于双向沟通过程中的消息传递，Artifact 是最终产出的结果交付物，比如一份生成好的报告、一段处理完的数据。
两个协议为什么是互补而非竞争
一个完整的多 Agent 系统里，这两个协议工作在不同层级。Agent 之间通过 A2A 协商任务分配和结果交付，每个 Agent 内部再通过 MCP 调用各种工具完成具体执行。
举个实际场景：一个”数据分析 Agent”通过 A2A 协议把”生成可视化图表”的子任务分配给”图表 Agent”，图表 Agent 接到任务后，内部通过 MCP 调用 Python 绘图工具、数据库查询工具来完成工作，最后通过 A2A 把生成好的图表 Artifact 交付回去。
这种分层设计让生态各司其职：A2A 管 Agent 之间的对话协作，MCP 管单个 Agent 内部的工具调用。
A2A 的设计取舍
A2A 刻意选择了”不透明”的设计哲学。调用方不需要知道对方 Agent 内部用了什么模型、什么工具链、什么推理策略，只关心它声称的能力和最终交付物。这带来几个好处：
1）Agent 可以独立升级内部实现，不影响协作方
2）不同厂商的 Agent 可以无缝协作，不需要统一技术栈
3）安全边界更清晰，不会暴露内部实现细节
代价是调试和可观测性变难了，出了问题你只能看到 Task 失败，看不到对方 Agent 内部到底哪一步挂了。
面试官追问
提问：A2A 协议怎么处理长时间运行的任务？如果一个 Agent 给另一个 Agent 派了个要跑半小时的任务，调用方是干等着还是有别的机制？
回答：A2A 原生支持异步模式。创建 Task 后会立即拿到一个 Task ID 和初始状态，调用方可以通过轮询或者 SSE 流式推送来获取进度更新，不需要保持连接干等。Task 的状态机设计了 submitted、working、input-required、completed、failed 这些状态，working 期间还能通过 Message 进行中间沟通。这和传统 RPC 的同步请求-响应模式完全不同，更接近于工作流引擎里的任务调度思路。
提问：如果我已经有了 MCP 的工具生态，我能不能把一个 MCP Server 包装成 A2A Agent 暴露出去？
回答：完全可以，这也是社区里很常见的做法。你在 MCP Server 外面套一层 A2A 的 Agent Card 描述和 Task 处理逻辑，对外就是一个标准的 A2A Agent。对调用方来说它是个有自主能力的 Agent，实际上内部只是在转发 MCP 调用。这种方式的好处是能把已有的工具能力快速接入多 Agent 体系，坏处是你丧失了 A2A “对等协作”的优势，因为这个包装出来的 Agent 本质上还是个工具。
提问：Agent Card 里通常包含哪些关键信息？如果一个 Agent 的能力更新了怎么办？
回答：Agent Card 包含名称、描述、能力列表、支持的交互模式（同步/异步/流式）、认证方式、以及版本号。能力更新直接更新 Agent Card 的 JSON 就行，因为发现过程是动态的，调用方每次发起协作前都会重新拉取 Agent Card。这点类似于 DNS 解析，不是一次缓存永久生效。实践中建议 Agent Card 带上版本字段，调用方可以对比版本号决定是否需要调整自己的协作策略。