🌐 A2A Protocol

Agent-to-Agent Protocol — 技术架构与商业生态深度拆解

基于 v1.0.0 规范 · 2026-06-24 更新 · 来源：Linux Foundation / Google / GitHub / 各厂商官方文档

🔵 Google 发起 🟢 Linux Foundation 治理 🟡 v1.0.0 正式版 🔴 150+ 组织支持
14
个月发展
150+
支持组织
22k
GitHub Stars
3
大云集成
5
SDK 语言
60+
AP2 金融机构
🔧 技术架构

🏗️ 三层协议栈

┌──────────────────────────────────────────────────────┐
  Layer 1 · 数据模型                                │
  Task · Message · AgentCard · Part · Artifact · Ext │
├──────────────────────────────────────────────────────┤
  Layer 2 · 抽象操作                             │
  Send · Stream · Get · List · Cancel · GetCard    │
├──────────────────────────────────────────────────────┤
  Layer 3 · 协议绑定                             │
  JSON-RPC 2.0  │  gRPC  │  HTTP/REST  │  可扩展 │
└──────────────────────────────────────────────────────┘
  • Layer 1 用 Protocol Buffers 定义，保证语言和协议无关性
  • Layer 2 描述行为语义，不绑定传输协议——这是 A2A 的精髓
  • Layer 3 可插拔，未来可加 WebSocket、QUIC 等绑定
  • 权威源文件：a2a.proto，所有 SDK 从它生成

📋 核心数据对象

对象职责核心字段Web 类比
AgentCard身份与能力声明name, url, skills[], capabilities, securitySchemesDNS SRV 记录
Task工作单元 & 状态容器id, status, contextId, history[], artifacts[]HTTP Request
Message通信回合role(user/agent), parts[]Chat 消息
Part内容原子TextPart / FilePart / DataPartMIME part
Artifact任务产出name, parts[], index, appendResponse body
Extension扩展声明uri, params, requiredHTTP Extension

🪪 Agent Card — 自动发现的钥匙

每个 A2A Server 必须在 /.well-known/agent.json 发布元数据：

{
  "protocolVersion": "1.0.0",
  "name": "Procurement Agent",
  "url": "https://procurement.corp/a2a",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "skills": [{
    "id": "create_po",
    "name": "Create Purchase Order",
    "tags": ["procurement", "po"]
  }],
  "securitySchemes": { "oauth2": { "type": "oauth2" } }
}

v1.0 关键新增：Signed Agent Cards — RSA/Ed25519 签名，密码学验证 Agent 身份，防止中间人伪造。

发现路径：/.well-known/agent.json → Registry 查询 → 直接配置（三种可选）

⚡ Task 状态机

        ┌───────────┐
        │ SUBMITTED  │
        └─────┬──────┘
            │
     ┌──────▼──────┐  ┌──────────────┐
     │  WORKING    │◄─┤ INPUT_REQUIRED│ ← 等人工
     └──┬──┬──┬──┬─┘ └──────────────┘
       │  │  │  │  ┌──────────────┐
  ┌──▼─┐│  │  └─►│ AUTH_REQUIRED │ ← 需认证
  │DONE ││  │    └──────────────┘
  └─────┘│  │
  ┌──────▼──▼┐  终态不可逆：后继任务共享 contextId
  │ FAILED   │
  └─────────┘
  • 4 种终态：COMPLETED / FAILED / CANCELED / REJECTED
  • 2 种中间态：INPUT_REQUIRED / AUTH_REQUIRED — 支持人机协作
  • contextId：串联多个 Task 形成业务会话，类似 thread_id

📨 六大核心操作

操作JSON-RPC 方法返回核心语义
SendMessagemessage/sendTask│Message发起交互，可开新 Task 或追加到已有
StreamMessagemessage/streamSSE 事件流实时推送状态变化 + Artifact 分块
GetTasktasks/getTask 快照轮询查询，支持 historyLength 控制条数
ListTaskstasks/listTask 列表按 context/state 过滤
CancelTasktasks/cancel确认请求取消，Agent 自主决定是否终止
GetAgentCardHTTP GETAgentCard发现层入口：/.well-known/agent.json

🔌 三种消息投递模式

🔄 轮询 Polling
Client 定时 GetTask

延迟高，实现最简
适合：低频查询、内部工具

📡 SSE 流式 Streaming
Server-Sent Events

实时推送 StatusUpdate + ArtifactUpdate
适合：需要进度反馈的交互

🔔 Webhook 推送
Server 主动 POST 回调

长任务/离线场景
Client 注册 callbackUrl，完成后通知

🔀 可组合
三种模式可叠加

先 SSE 流式获取进度
断线后切 Webhook 保送达

🧩 Part 类型 — 模态无关的内容模型

类型结构典型场景
TextPart{type:"text", text:"..."}自然语言、指令
FilePart{type:"file", file:{uri, mimeType, bytes?}}文档/图片/音频传输
DataPart{type:"data", data:{k:v...}}结构化参数、表单、API 参数

Agent Card 通过 defaultInputModes / defaultOutputModes 声明支持的 MIME 类型，Client 据此做兼容协商。

🔒 安全体系

层机制v1.0 新增
传输MUST HTTPS / TLS 1.3—
身份Agent Card 声明 securitySchemes✅ Signed Agent Cards
认证API Key / OAuth2 / JWT / mTLS—
多租户请求中 tenant 字段路由✅ v1.0 正式定义
隔离不透明执行 — 不泄漏内部状态—
授权业务层自定义（A2A 不规定）—

⚡ Extension 扩展机制 — 协议的"App Store"

核心刻意精简，扩张靠 Extension：

  • 声明：Agent Card 中 extensions[].uri
  • 使用：请求中传 extensions 参数激活
  • 关键扩展：AP2 Agent Payments Protocol
A2A 最关键的设计哲学：宁可核心精简到"无用"，也绝不做一个试图解决所有问题的巨型协议。把复杂度推到 Extension 层。

🔄 A2A vs MCP — 互补而非竞争

  用户
   ↓
  Agent A ◄──── A2A ────► Agent B
   │                  │
  MCP↓                ↓MCP
  工具/DB/API        工具/DB/API
🟣 MCP（Anthropic）

纵向 Agent ↔ 工具/数据
类比 USB-C（设备接外设）
单 Agent 系统
Client-Server 架构
GitHub ~40k+ stars

🔵 A2A（Google）

横向 Agent ↔ Agent
类比 WiFi（设备间通信）
多 Agent 系统
Peer-to-Peer 架构
GitHub ~22k stars

两者同属 Linux Foundation，官方声明互补。OpenAI 已同时支持 MCP 和 A2A。

💰 商业生态

📈 发展时间线

2025.04
Google 发布 A2A，50+ 组织联合支持（AWS、Microsoft、Salesforce、SAP）
2025.05
Microsoft Azure AI Foundry + Copilot Studio 集成
2025.06
捐赠 Linux Foundation，开放治理
2025.11
AWS Bedrock AgentCore Runtime 原生支持
2026.04
一周年：150+ 组织、v1.0 发布、22k stars、5种 SDK
2026.04
AP2（Agent Payments Protocol）作为 A2A 扩展发布，60+ 金融机构支持

🏢 150+ 支持组织生态

层代表动机
云平台AWS · Azure · GCP锁定开发者到自家 Agent 运行时
企业 SaaSSalesforce · SAP · ServiceNow · Workday开放 Agent 接口 → 更多被调用 → 收入
开发框架LangChain · CrewAI · Google ADK降低集成门槛 → 更多用户
咨询巨头Accenture · Deloitte · BCG · Capgemini企业落地账单 $百万级
金融Stripe · PayPal · 60+ 机构AP2 扩展 → Agent 经济的结算管道

⚔️ 竞品协议全景

维度A2AACP IBMANP 社区
架构点对点 Peer中间人 Broker去中心化 P2P
发起方Google + AWS + MicrosoftIBM 独推小社区
发现Agent Card + Registry集中注册中心DID 去中心化身份
传输JSON-RPC + gRPC + RESTHTTP/REST + MIMEHTTPS + JSON-LD
企业就绪✅ 多租户/OAuth2/签名⚠️ 有限❌ 太早
云支持AWS + Azure + GCP无无
GitHub Stars22k~2k~1k
威胁等级—🟡 低🟢 极低

结论：A2A 是 Agent 间通信的事实标准，没有真正的对手。ACP 太弱，ANP 太理想。IBM 自己也在 A2A 支持名单里。

🏭 已落地的行业场景

📦 供应链

采购Agent ↔ 库存Agent ↔ 物流Agent
自动协调下单、补货、配送

🏦 金融服务

合规Agent ↔ 风控Agent ↔ 审批Agent
多方风险评估自动化

🛡️ 保险理赔

采集Agent ↔ 定损Agent ↔ 赔付Agent
全流程无人干预

🖥️ IT运维

监控Agent ↔ 诊断Agent ↔ 修复Agent
自愈系统闭环

⚠️ AP2 — 直接竞合信号

A2A 生态官方推出的 Agent Payments Protocol：

  • AP2 作为 A2A Extension 定义 Agent 间支付结算
  • 60+ 支付与金融机构支持（Stripe、PayPal 等）
  • 解决 Agent 经济的"谁来付多少"问题
  • 与 A2A 深度绑定：ap2-protocol.org
AP2 定义的是协议层（"怎么付"），你做的是产品层（"帮谁付、付多少、最优路由"）。就像 HTTP 是协议，Stripe 是产品。

但如果你不做，AP2 自己会长出产品层。窗口期正在关闭。
💡 对 OpenClaw 的战略启示

✅ 已验证的机会

  • Agent 互操作是真实刚需，150+ 组织不会一起演戏
  • 三大云集成 = 渠道已通，不需要教育市场
  • 企业已有生产部署 = 付费意愿已验证
  • Agent 经济的结算层是空白 — A2A 规约里完全没有

⚠️ 必须应对的威胁

  • AP2 正在填补结算空白 — 60+ 金融机构已站队
  • 如果 AP2 做成产品，你的定位就被吃掉
  • 云平台可能做结算中间件 — AWS/Azure 内建billing
  • 时间窗口：AP2 目前只是协议，没有可用产品

🎯 行动建议

优先级行动理由
P0兼容 A2A + AP2 协议不兼容 = 自动出局
P0做 AP2 的产品层协议 ≠ 产品，Stripe 证明了这一点
P1多模型路由 + 计费网关你的现有能力，A2A 生态没有
P1Agent Registry + 发现服务类似 npm registry，A2A 只定义规范没做服务
P2可观测性 / 审计日志企业合规刚需，不透明执行需外部观测
P2开发者工具链Agent Card 编辑器、调试器、模拟器

🧭 YC 叙事策略

  • 核心定位："A2A 生态的 Stripe" — 协议层跟随 AP2，产品层做结算网关 + 路由 + 计费
  • 不要说："我们做 Agent 协议" — A2A 已经赢了，你不是协议层玩家
  • 要说："A2A 让 Agent 能说话，我们让 Agent 能做生意" — 聚焦交易层
  • 护城河：多模型路由优化、结算基础设施、企业合规堆栈 — 协议无法替代的 know-how
  • 对标：Stripe（协议 HTTP 上的支付产品）→ 你（协议 A2A/AP2 上的结算产品）

A2A Protocol 深度拆解 · 2026-06-24 · GitHub · a2a-protocol.org · AP2

← 知识库