面经策

A2A 协议的工作原理是怎样的？ ​

  • 标签：大模型、AI、A2A、技术栈

🏛 业务架构师 ​

A2A 的工作原理围绕"服务发现—任务协作—成果交付"展开：

1. 能力发现：每个 Agent 发布一张 Agent Card（JSON 文档，放在 /.well-known/agent.json），声明自己的能力、鉴权方式、支持的传输协议。其他 Agent 通过 URL 拉取卡片，就知道"对方是谁、能干什么"。 2. 任务下发：客户端 Agent 向对方发送 Task 请求，任务有完整生命周期（提交→运行中→输入等待→完成/失败），底层走 JSON-RPC over HTTP。 3. 异步通信：长任务通过 SSE 或 Webhook 推送状态更新，天然支持中途人工介入。 4. 成果交换：结果以 Artifact（文本、文件、结构化数据）形式返回，双方不暴露内部推理和工具细节。

业务视角：这相当于给 Agent 之间定了"商务合作礼仪"——先交换名片（Agent Card），再发工作单（Task），最后交付成果物（Artifact）。对企业来说，价值在于跨部门、跨供应商的 Agent 协作有了标准接口，未来"采购 Agent 直接和供应商 Agent 谈价"这类业务流程才可能成立，而不需要每对合作方做一次点对点集成。

🏗 系统架构师 ​

A2A（Agent2Agent）是 Google 牵头、Linux Foundation 治理的 Agent 互操作协议，解决"不同厂商/框架的 Agent 如何互相发现、协商、协作"的问题。我按架构师视角拆它的运行原理：

  • 发现（Discovery）：每个 Agent 在众所周知的路径（/.well-known/agent.json）发布 Agent Card，声明能力、认证方式、输入输出模态、技能列表——本质是服务自描述，对标微服务的注册中心 + 元数据；
  • 任务生命周期（Task Lifecycle）：核心对象是 Task，状态机为 submitted → working → input-required → completed/failed/canceled。长任务通过轮询、webhook、SSE 推送中间产出（Artifact）和进度消息；
  • 协商：客户端通过 Agent Card 声明的模态和技能判断能否承接任务，避免硬编码集成。

关键设计权衡：A2A 刻意不暴露 Agent 内部实现（Opaque Execution），只约定任务接口，这让跨组织协作成为可能；传输选 HTTP + JSON-RPC/SSE，穿透企业防火墙无障碍。

一句话总结分工：MCP 连接 Agent 与工具/数据，A2A 连接 Agent 与 Agent，两者互补而非竞争。生产上我关注的是它的认证（OAuth2）和幂等语义，这两点决定跨公司 Agent 编排是否敢上生产。

💻 全栈开发专家 ​

A2A 的本质是把 Agent 当服务：每个 Agent 是一个 HTTP 端点，通过标准方法互调，协议栈是 HTTP(S) + JSON-RPC 2.0 + SSE。

工作原理三要素：

  1. 发现：每个 Agent Server 在 /.well-known/agent-card.json 暴露 Agent Card，声明名称、描述、能力（skills）、鉴权方式、端点 URL。客户端拉这个文件就知道「对方是谁、能干什么、怎么认证」。
  2. 任务模型：核心对象是 Task。客户端调 message/send（同步）或 message/stream（SSE 流式）发起任务，任务有状态机：submitted → working → input-required → completed / failed / canceled。长任务由服务端推进，客户端可随时 task/get 查询或收 SSE 推送。
  3. 产物：结果通过 Message（对话消息）和 Artifact（文件、结构化产物）返回，支持多模态。

我在 Spring Boot 里用 spring-ai-a2a 起过 Server，注解声明 Agent Capability 就能自动发布 Agent Card，客户端用 A2A Client 像调 REST 一样调远端 Agent。踩坑：SSE 经过 Nginx 要关 proxy_buffering，否则流式状态推送全部积压；跨公司场景鉴权用 OAuth 2.1 client credentials，Agent Card 里要声明 scopes。