A2A 协议 v1.0 详解：多 Agent 互操作的生产级标准

A2A 是什么？

A2A（Agent2Agent Protocol）是面向 Agent 与 Agent 之间通信的开放标准，让不同厂商、不同框架、不同部署位置的 Agent 可以互相发现、通信和协作。

2026 年 4 月底，A2A Protocol v1.0 正式发布，这是第一个生产级稳定版本，由 AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNow 八家公司的技术指导委员会共同维护。

一句话理解分层：

• MCP 解决"Agent 怎么接工具和上下文"
• A2A 解决"Agent 怎么找别的 Agent 并协同完成任务"

v1.0 带来了什么？

v1.0 不是概念重做，而是在 v0.3 草稿基础上加了企业级生产环境必需的能力：

v1.0 对齐了 Web 架构原则：无状态、分层、标准协议绑定、基础设施友好。这意味着组织可以用现有负载均衡、网关、安全和可观测工具来扩展 Agent 交互。

为什么 2026 年必须关注 A2A

A2A 的核心对象

1) Agent Card（能力名片）

Agent Card 公开 Agent 的能力、接口地址、认证方式和支持的协议版本。v1.0 Agent Card 向后兼容 v0.3，可同时声明多个协议绑定：

{
  "name": "research-agent",
  "version": "1.0.0",
  "skills": [
    { "id": "web_search", "description": "Web search and summarization" },
    { "id": "report_writer", "description": "Markdown report generation" }
  ],
  "endpoints": [
    {
      "url": "https://agent.example.com/a2a",
      "protocol": "http+json",
      "auth": { "type": "bearer" }
    },
    {
      "url": "https://agent.example.com/a2a-jsonrpc",
      "protocol": "json-rpc",
      "auth": { "type": "bearer" }
    }
  ],
  "agentCard": {
    "signature": "base64-encoded-signature",
    "tenant": "org-example"
  }
}

调用方先读名片，根据 skills 做动态路由，根据 endpoints 选择协议。

2) Task（任务）

跨 Agent 协作的核心单位，支持创建、进行中、完成、失败等状态。v1.0 强化了长任务的生命周期管理。

3) Artifact（产物）

任务输出结果，可以是文本、结构化 JSON、文件链接或多模态内容。

基本交互流程

[Client Agent]
    │ 1. 发现远端 Agent Card（支持签名验证）
    ▼
[Remote Agent]
    │ 2. 通过协商协议发送 Task
    │ 3. 持续回传状态/事件（streaming）
    ▼
[Client Agent]
    │ 4. 收集 Artifact
    ▼
[最终用户结果]

v1.0 交互示例：HTTP+JSON（首选）

v1.0 首选协议绑定是 HTTP+JSON，比 JSON-RPC 更符合 Web 标准，便于使用现有负载均衡和安全设施：

POST /a2a HTTP/1.1
Host: agent.example.com
Content-Type: application/json
Authorization: Bearer <token>

{
  "method": "tasks.send",
  "params": {
    "id": "task-001",
    "skill": "web_search",
    "input": {
      "query": "A2A protocol v1.0 enterprise adoption 2026",
      "language": "en"
    }
  }
}

流式响应：

HTTP/1.1 200 OK
Content-Type: application/x-ndjson

{"type": "status", "data": {"state": "working", "progress": 0.3}}
{"type": "status", "data": {"state": "working", "progress": 0.7}}
{"type": "artifact", "data": {"type": "text/markdown", "content": "# Search Results..."}}
{"type": "status", "data": {"state": "completed"}}

如果客户端不支持 HTTP+JSON，可以降级到 JSON-RPC（v0.3 风格，v1.0 保留兼容）。

从 v0.3 迁移到 v1.0

迁移时，Agent Card 可同时声明两个版本的 endpoints，客户端渐进式切换，无需一次性 cutover。

A2A 与 MCP 怎么配合？

这是很多人容易混淆的地方，v1.0 官方文档也专门澄清了两者的关系：

MCP 和 A2A 解决不同层次的问题，实际系统中通常会同时使用两者：

用户
  ↓
总控 Agent（A2A Client）
  ├─ A2A 调用 研究 Agent（内部用 MCP 连接搜索引擎）
  ├─ A2A 调用 报告 Agent（内部用 MCP 连接文档库）
  └─ A2A 调用 执行 Agent（内部用 MCP 连接 API）

每个 Agent 内部：MCP 接工具 ↔ Agent 之间：A2A 做协作

这个模式可以避免单 Agent 过度膨胀，也方便团队按职责拆分。

实战建议

1. 先定义 Agent Card 规范：技能命名、输入输出约定、错误码统一。v1.0 Agent Card 的签名机制可以保证跨组织调用的可信度。
2. 任务要可恢复：长任务务必支持幂等重试与状态查询。
3. 协议协商用默认值：首选 HTTP+JSON，客户端不支持时自动降级 JSON-RPC。
4. 多租户设计前置：如果系统需要服务多个团队或客户，从第一天就使用 v1.0 的多租户能力。
5. 把可观察性前置：记录 task id、调用链、耗时和失败原因。HTTP+JSON 绑定让标准 Web 观测工具可直接复用。

典型落地场景

与单体 Agent 方案对比