A2A 概览与协议
A2A（Agent-to-Agent / Agent2Agent） 是 Google 贡献、Linux Foundation 托管的开放协议，让 不同框架、不同厂商的 Agent 能互相发现能力、委派任务、交换结果，而无需暴露各自内部记忆与工具实现。本篇讲选型与面试答法；单 Agent 循环见 Agent 核心概念与架构；工具接入见 MCP 概览与实践。
A2A 解决什么问题
| 痛点 | 没有 A2A | 有 A2A |
|---|---|---|
| 多 Agent 协作 | 自定义 HTTP / 消息队列，每家一套 | 统一 Task / Message 语义 |
| 能力发现 | 硬编码 endpoint | Agent Card 自描述能力 |
| 跨团队 / 跨云 | 集成成本高 | 标准绑定（JSON-RPC / gRPC / REST） |
| 长任务 | 各写各的轮询 | 原生 异步、流式、推送 |
一句话：A2A 是 Agent 之间的「商务语言」——谈任务、进度、交付物，不谈对方脑子里怎么想。
核心原则（规范强调）
| 原则 | 含义 |
|---|---|
| Simple | 复用 HTTP、JSON-RPC 2.0、SSE 等成熟标准 |
| Enterprise Ready | 鉴权、审计、追踪对齐企业实践 |
| Async First | 长任务、人审、多步协作是一等公民 |
| Modality Agnostic | 文本、文件、结构化数据、可嵌 UI |
| Opaque Execution | 只交换 能力声明与结果，不暴露内部 CoT / 工具链 |
协议分层
Layer 1 数据模型 Task / Message / AgentCard / Part / Artifact …
Layer 2 抽象操作 Send Message / Stream / Get Task / Cancel / Get Agent Card …
Layer 3 协议绑定 JSON-RPC · gRPC · HTTP/REST
面试记忆：先统一「说什么」（数据模型），再统一「怎么调」（绑定）。
关键概念
Agent Card（能力名片）
每个 Remote Agent 发布 Agent Card，描述：
- 身份与版本
- 支持的技能 / 输入输出类型
- 端点与认证方式
- 是否支持流式、异步回调
Client Agent 通过 Card 发现「谁能做这件事」，而不需要知道对方用 LangGraph 还是自研框架。
Client Agent vs Remote Agent
| 角色 | 做什么 |
|---|---|
| Client Agent | 代表用户拆解目标、发起任务、汇总结果 |
| Remote Agent | 对外暴露能力，执行 Client 派来的 Task |
这与 MCP 的 Host/Server 不同：A2A 两边都是 对等意义上的 Agent 服务，只是这次对话里一个扮演发起方。
Task / Message / Artifact
| 对象 | 直觉 |
|---|---|
| Task | 一次协作工单：有状态（进行中 / 完成 / 失败 / 取消） |
| Message | 任务中的往来消息（可含多 Part） |
| Part | 内容片段：文本、文件引用、结构化字段等 |
| Artifact | 任务产出物（报告、文件、结构化结果） |
用户目标
→ Client Agent 读 Agent Card，选 Remote Agent
→ Send Message / Stream Message 创建或推进 Task
→ Remote Agent 异步执行（可 SSE 推送进度）
→ Client 收 Artifact，继续编排或回复用户
交互模式
| 模式 | 适合 |
|---|---|
| 同步请求/响应 | 短问答、轻量查询 |
| Streaming（SSE） | 实时进度、生成式输出 |
| 异步 + 推送通知 | 长任务、人审、批处理 |
规范当前稳定版为 1.0.0；实现以 a2a-protocol.org 与 a2a.proto 为准。
vs MCP：互补而非竞争
| MCP | A2A | |
|---|---|---|
| 连接对象 | 应用 ↔ 工具/数据 Server | Agent ↔ Agent |
| 暴露什么 | Tools、Resources、Prompts | 任务能力、Agent Card |
| 典型问题 | 「帮我把这个 PR 建好」的工具从哪来 | 「差旅 Agent 把行程交给审批 Agent」 |
| 官方定位 | 给 Agent 上下文与工具 | 让 Agent 协作完成任务 |
Google 公开材料明确：A2A 与 MCP 互补——MCP 接工具，A2A 接同事。
vs 多 Agent 框架内置编排
| 维度 | 框架内多 Agent（如 [LangGraph](/docs/ai/Agent/LangGraph 编排实践) 子图） | A2A |
|---|---|---|
| 边界 | 通常同代码库、同运行时 | 跨服务、跨组织 |
| 发现 | 编译期已知节点 | 运行时读 Agent Card |
| 适用 | 单产品内分工 | 企业间、多产品组合 |
| 复杂度 | 较低 | 鉴权、版本、SLA 更重 |
单产品内子 Agent 用框架编排往往够用；跨团队可替换的 Agent 市场才更需要 A2A。
何时用 / 不用
| 信号 | 建议 |
|---|---|
| 多个独立部署的 Agent 要互相派活 | 评估 A2A |
| 同一进程里的 planner / worker 子角色 | 框架内编排即可 |
| 只需调数据库、API | MCP 或直连工具 |
| 强合规、需审计谁调了谁 | A2A + 标准 OAuth / mTLS |
| 纯 FAQ、单轮 RAG | 不需要 A2A |
落地注意点
- 先画信任域：哪些 Agent 可互调、数据能否出境
- Agent Card 版本化：能力变更要向后兼容或显式升级
- 幂等与取消：长任务必须支持
Get Task/Cancel Task - 可观测性：Task ID 贯穿日志与追踪，便于排障
- 别过早多 Agent：单 Agent + MCP 工具往往更简单；见 Agent 核心概念与架构 决策表
常见误解
- 「A2A = 多 Agent 框架」——A2A 是 跨系统 wire 协议，不是编排 DSL
- 「有 A2A 就不要 MCP」——工具层仍常用 MCP；协作层用 A2A
- 「Remote Agent 要暴露思维链」——规范强调 Opaque Execution
- 「A2A 适合所有多 Agent」——同应用内子角色用框架更轻
面试速记
- A2A 是什么？ 开放标准，让异构 Agent 通过 Agent Card 发现能力，用 Task/Message 协作，不暴露内部实现。
- 和 MCP 区别？ MCP：应用连工具与数据；A2A：Agent 连 Agent。互补。
- Agent Card 干什么？ 自描述能力、端点、认证与交互模式，供发现与路由。
- 为什么强调 Async？ 企业场景长任务、人审、流式进度是常态。
- 何时不上 A2A？ 单 Agent 闭环、同进程子角色、纯工具调用——用框架 + MCP 即可。