考察点
这道题出自阿里和快手的 Agent 方向面试，属于 A2A 协议的深挖题——不考「A2A 是什么」，直接考它最工程化的机制 push notification。面试官想看你是否理解 A2A 和 MCP 面对的根本不是同一类问题：MCP 的工具调用通常是秒级同步，而 A2A 的 Agent 间委托是分钟到小时级的异步任务，通信机制的设计因此完全不同。能讲清轮询、SSE、push 三种完成感知方式的取舍，答案就到位了。追问常往 webhook 安全、断线补偿、协议选型走。
参考答案
先铺垫：A2A 的任务模型为什么是异步的
A2A（Agent2Agent，Google 2025 年提出后移交 Linux Foundation）标准化的是独立 Agent 之间的任务委托：通过 Agent Card 发现对方能力，以 Task 为单位发起协作，任务有 submitted、working、completed、failed 等状态流转。它和 MCP 的分工一句话说清——MCP 是 Agent 向下连工具的垂直协议，A2A 是 Agent 与 Agent 对等协作的水平协议。一个典型系统里两者共存：主 Agent 通过 A2A 把任务委托给专业 Agent，专业 Agent 内部再用 MCP 调自己的工具。
关键差异在时间尺度。MCP 调一个工具，毫秒到秒级返回，同步等待天经地义。A2A 委托的任务可能是「分析这个季度的全量销售数据并出报告」——跑几十分钟甚至几小时，而且两个 Agent 可能分属不同系统、不同公司。让客户端挂着一个连接等几小时，或者每秒问一次「好了没」，都不现实。完成感知（怎么知道任务做完了）就成了协议必须正面回答的问题。
三种完成感知方式的取舍
- 轮询：客户端定时调
tasks/get查状态。实现最简单，但两个问题——感知延迟取决于轮询间隔，间隔大了结果到了也不知道；间隔小了全是空转请求，服务端白白承压。任务一多，轮询流量会淹没正常流量。 - SSE 流式订阅：客户端挂一条流，服务端推送状态更新。感知实时，但占着长连接——任务跑两小时连接就挂两小时，跨公网、跨组织时长连接被中间代理掐断是常态，客户端自己也不能一直在线等着。
- push notification：创建任务时客户端带上
pushNotificationConfig（一个 webhook 地址加鉴权信息），任务状态变化时服务端主动 POST 回调。客户端发出委托后就可以离线去干别的，任务完成时被叫醒——这才是长周期异步委托的正确姿势。
push notification 解决的核心问题因此是三层：解放客户端连接（不用为长任务维持在线）、感知实时（状态变化即推送，无轮询延迟）、跨越组织边界（两个独立系统之间不可能维持长连接，webhook 是唯一现实的通道，这也是企业间 Agent 协作能成立的前提）。
工程细节决定成败
几个面试能加分的实践点：回调通常只通知状态变化，不带完整结果——客户端收到通知后再调 tasks/get 拉结果，这样既避免把大量数据推给未经实时校验的通道，也防止伪造回调直接投毒数据；webhook 要鉴权，注册时协商 token 或签名密钥，回调请求带签名验证，否则任何人都能伪造「任务完成」通知；推送要有重试与幂等设计，客户端回调接口必须能安全处理重复通知；回调地址本身要做 SSRF 防护，别让攻击者注册一个指向内网的 webhook 把服务端变成攻击跳板。
和 MCP 的关系：不是竞品
收尾回应第二问。MCP 和 A2A 解决的问题正交：工具是无状态、调用即返回的能力，用 MCP；对方是有自主性、任务长周期的对等实体，用 A2A。只选一个的前提是场景单一——你的 Agent 只需要调工具，MCP 就够；一旦要跨系统委托任务，MCP 帮不了你，它不是为此设计的。
可能的追问
- webhook 回调被伪造怎么办？ 答：注册时协商签名密钥，回调带 HMAC 签名加时间戳防重放；回调内容只当「提醒」，结果一律回源拉取并校验任务 id 归属。
- SSE 和 push 怎么选？ 答：同一信任域内、任务秒级到分钟级、客户端持续在线（如控制台实时进度）用 SSE；跨网络边界、长任务、客户端不能常驻的场景用 push。
- A2A 任务失败了错误怎么传播？ 答：任务状态进 failed 并带错误信息，push 通知触发后委托方拉取详情；工程上要有重试策略和人工兜底队列，跨 Agent 的错误链要在两侧日志里用 task id 串起来。