A2A：Agent 间的工厂无线电

3.1 为什么需要 A2A？

随着 AI 系统演化为分布式专业 Agent 网络，标准化通信成为规模化必需。A2A（Agent-to-Agent）协议解决以下问题：

问题	传统解决方案的局限	A2A 的优势
Agent 碎片化	每个 Agent 用不同框架、语言、payload 结构	通用通信层，框架无关
跨网络协作	需要自定义错误处理、状态管理	标准化协商和恢复机制
维护税	自建第三方平台 Agent → 需跟踪上游 API 变化	使用官方 Agent → 维护责任转移给专家团队

3.2 架构演进：从单体到分布式

白皮书描绘了 AI Agent 架构的历史性转变，类比软件从单体到微服务：

┌─────────────────────────────────────────────────────────────┐
│  Stage 1: Single Agent Monolith                            │
│  ────────────────────────────                              │
│  单个 Agent + 巨大系统提示 + 所有工具                       │
│  问题：Scaling Friction、Contextual Overload、单点故障     │
├─────────────────────────────────────────────────────────────┤
│  Stage 2: Internal Specialization                          │
│  ───────────────────────────                               │
│  逻辑划分的 sub-agent，共享运行时和内存                     │
│  优势：减少搜索空间、缓解注意力稀释                         │
│  限制：仍在同一进程内，不跨网络边界                         │
├─────────────────────────────────────────────────────────────┤
│  Stage 3: Distributed Multi-Agent                          │
│  ────────────────────────────                              │
│  远程、域特定的 Agent 通过 A2A 协议协作                     │
│  优势：官方维护、跨组织协作、商业化潜力                     │
└─────────────────────────────────────────────────────────────┘

关键洞察：

“Does the caller need a result, or does the caller need another participant to take responsibility?”
— 调用者需要的是结果，还是需要另一个参与者承担责任？这是判断是否需要协作语义的最清晰框架。

3.3 Bounded vs. Unbounded Domains

为什么 Agent 不能简单当作 Tool？

特性	Tool/API	Agent
交互模式	Fire-and-forget（一发一收）	多轮协商、中断恢复
输入要求	需要完美格式的请求	处理模糊数据、冲突偏好
输出保证	返回确定响应	可能中断、请求更多信息、用户可能改变主意
控制流	线性、结构化	类似 GOTO 的非线性流

GOTO 问题：

当将协作 Agent 强制装入标准 Tool wrapper 时，引入架构级混乱：

┌────────────────────────────────────┐
│  Tool Wrapper 的假设：             │
│  ① 输入 → 输出（单轮）            │
│  ② 结构化控制流                   │
│                                    │
│  实际 Agent 行为：                 │
│  ① 可能中断（需要更多信息）       │
│  ② 用户可能改变主意               │
│  ③ 可能永远不返回预期输出         │
│                                    │
│  结果：控制流离开结构化上下文      │
│        → 引入 GOTO 式混乱          │
└────────────────────────────────────┘

3.4 Agent Card：AI 的标准化简历

每个 A2A Agent 通过 Agent Card 定义其身份：

┌────────────────────────────────────┐
│  Agent Card（机器可读身份）        │
├────────────────────────────────────┤
│  Capabilities: 可执行的任务        │
│  Security & Compliance: 数据处理策略、权限要求 │
│  Interaction Schemas: A2A 通信方式 │
└────────────────────────────────────┘

3.5 Agent Registry：从公共市场到私有企业

Registry 类型	角色	开发者路径
公共 Registry（Marketplace）	全球人才代理	将 Agent 列表供全世界发现，支持许可证授权
私有 Registry	企业内部知识共享	在公司内注册 Agent，跨部门复用专业知识

3.6 A2A 实现路径

供应端（暴露 Agent）：

Step 1: 定义 Agent Card
  → 正式化 Agent 规格

Step 2: 实现 Agent Executor（翻译层）
  → 将 A2A 请求/响应转换为底层框架调用（ADK、LangGraph 等）

Step 3: 建立 A2A Endpoint
  → 暴露为 A2A-compliant endpoint

需求端（连接远程 Agent）：

两种连接模式：

# 1. Direct Instantiation（直接实例化）
# 适用：特定供应商集成或私有 Agent
billing_specialist = RemoteA2aAgent(
    name="billing_agent",
    endpoint="https://api.vendor.com/v1/billing/a2a"
)

# 2. Indirect via Registry（通过 Registry 发现）
# 适用：公共/私有 Agent Registry
registry = AgentRegistry(project_id=project_id, location=location)
agent_name = f"projects/{project_id}/locations/{location}/agents/YOUR_AGENT_ID"
my_remote_agent = registry.get_remote_a2a_agent(agent_name=agent_name)

---