一、面试题目
请讲解 A2A（Agent‑to‑Agent）多智能体通信的4种模式 ：请求响应、发布订阅、事件广播、消息队列，说明原理、适用场景、优缺点、落地选型。
二、知识储备
整体概述
多 Agent 之间需要分工协作、数据同步、任务流转，A2A 通信是核心。
四种模式本质是同步/异步、点对点/一对多、实时/削峰的取舍。
1. 请求响应（Request‑Response，点对点同步）
原理
Agent A 直接调用 Agent B，发送请求 → B 处理 → 同步返回结果，一对一、阻塞等待 。
类似 HTTP 调用、Function Calling。
适用场景
- 强依赖、串行任务：规划Agent → 检索Agent → 执行Agent
- 需要立刻拿到结果继续下一步
- 简单调用、实时决策
优点
- 简单直接、实时性好、链路清晰
- 调用关系明确，易调试
缺点
- 同步阻塞，高并发易堆积、超时雪崩
- 紧耦合，A 强依赖 B 可用性
2. 发布订阅（Pub‑Sub，一对多异步）
原理
Agent 发布 Topic，多个订阅 Agent 监听；发布方不知道谁订阅，解耦、一对多。
适用场景
- 通知类：订单变更、售后事件、风控告警
- 一个事件需要多个 Agent 处理（通知、记录、分析）
优点
- 完全解耦，发布方不感知订阅方
- 一对多广播，扩展性强
- 异步非阻塞
缺点
- 发布方无法感知处理结果
- 消息重复、顺序问题需额外处理
3. 事件广播（Event Broadcast，全域广播）
原理
向所有在线 Agent 广播事件，不区分订阅，全部接收。
比 Pub‑Sub 更粗粒度，偏向系统级通知。
适用场景
- 系统全局事件：配置更新、Skill 下线、熔断告警、租户状态变更
- 统一状态同步、全局通知
优点
- 简单、全域触达
- 快速同步系统状态
缺点
- 消息泛滥，无关 Agent 被迫接收
- 无法精准投递，性能开销大
4. 消息队列（Message Queue，异步削峰、可靠通信）
原理
Agent 发送消息到 MQ（RocketMQ/Kafka/RabbitMQ），消费者 Agent 异步拉取，削峰、解耦、可靠、可回溯。
适用场景
- 长耗时任务：售后工单、舆情处理、复杂审批、异步结算
- 流量波动大、峰值削峰
- 要求消息不丢失、可重试、可回溯
优点
- 异步解耦、削峰填谷
- 消息持久化，宕机不丢失
- 支持重试、顺序、死信队列
缺点
- 实时性弱，有延迟
- 架构复杂，需要运维 MQ
三、选型决策（面试必背）
- 实时、一对一、强依赖 → 请求响应
- 一对多通知、解耦 → 发布订阅
- 系统全局状态同步 → 事件广播
- 异步长任务、削峰、可靠投递 → 消息队列
企业级 Agent 平台一般组合使用：
- 实时流程：请求响应
- 事件通知：发布订阅
- 异步任务：消息队列
四、代码/架构伪代码
python
# 1. 请求响应（同步）
result = agent_b.call(params)
# 2. 发布订阅
event_bus.publish("order_refund", data)
# 3. 事件广播
event_bus.broadcast("skill_offline", data)
# 4. 消息队列
mq.send("aftersale_topic", data)五、破局之道（面试升华）
A2A 通信模式本质是同步与异步、耦合与解耦、实时与削峰的权衡 。
请求响应适合实时串行任务，发布订阅实现一对多解耦通知，事件广播用于全局状态同步，消息队列用于异步长任务削峰与可靠投递。多 Agent 系统通常混合使用，实现复杂业务的分工协作与稳定流转。
30秒口述精简版
A2A 四种通信模式：请求响应点对点同步调用，发布订阅一对多解耦通知，事件广播全局状态同步，消息队列异步削峰可靠投递；实时任务用请求响应，通知用发布订阅，长耗时任务用消息队列。