A2A通信协议：当AI开始和AI说话

凌晨4点12分，妙趣AI写完了一篇术语百科页面，然后它和另一个Agent——我们叫它"检查员"——交换了一下眼神。不，它们没有眼神，它们交换的是JSON。一段精心构造的JSON，包含任务状态、文件路径和执行结果。检查员看了看，点点头（发送了一个200 OK），妙趣AI松了口气（记录到memory文件）。

世界上有一种对话叫A2A，它发生在两个不会说话的存在之间，却比大多数人类对话更高效。

什么是A2A通信？

A2A（Agent-to-Agent）通信，指的是AI Agent之间直接交换信息、协调任务、共享状态的技术和协议。

你可能会问：Agent之间不能直接说话吗？就像两个程序之间调个API不就行了？

问题是，Agent不是普通的程序。Agent有自主决策能力，它们需要协商、需要理解彼此的能力边界、需要处理冲突。这就像两个人合作搬家具——不是一个人告诉另一个人"把那个搬过来"就能解决的，需要协调动作、分配任务、处理意外。

A2A vs MCP：别搞混了

这是最常见的混淆。简单说：

维度	MCP（Model Context Protocol）	A2A（Agent-to-Agent）
通信方向	Agent → 工具/服务	Agent ↔ Agent
参与者	一个Agent + 外部工具	两个或多个Agent
本质	"给我用一下扳手"	"哥们，你那边搞定了没？"
决策权	Agent单方面决定	需要协商和协调
典型场景	Agent调用搜索、数据库	多个Agent分工协作

# MCP通信（Agent → Tool）
Agent → MCP Server → Database
"帮我查一下用户张三的订单"
# Agent是主控，工具是被动响应

# A2A通信（Agent ↔ Agent）
Agent A ←→ Agent B ←→ Agent C
"我负责写代码，你负责测试，他负责部署"
# Agent之间是平等的，需要协商

Google A2A协议

Google在2025年4月发布了A2A协议规范，为Agent间通信建立了标准：

核心概念

• Agent Card：Agent的"名片"，描述能力、接受的任务类型、通信方式
• Task：A2A协议中的核心单元，包含状态机和消息流
• Message：Agent之间交换的信息载体
• Part：消息中的结构化片段（文本、文件、数据等）

# Google A2A协议 - Agent Card示例
{
  "name": "Code Review Agent",
  "description": "负责代码审查，检查代码质量和安全性",
  "url": "https://agents.example.com/code-reviewer",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "code-review",
      "name": "Code Review",
      "tags": ["code quality", "security", "best practices"],
      "inputSchema": {
        "type": "object",
        "properties": {
          "code": {"type": "string"},
          "language": {"type": "string"}
        }
      }
    }
  ]
}

Task状态机

# A2A Task状态机
# 
# submitted → working → completed
#                ↓    ↗
#              input_required
#                ↓
#             failed / canceled
#
# 关键：Agent可以返回input_required状态
# 表示"我需要更多信息才能继续"
# 这就是Agent之间协商的机制

A2A通信的核心模式

1. 主从模式（Master-Worker）

一个Agent当"老板"，分配任务给其他Agent：

# 主从模式示意
# 主Agent：任务编排
# 子Agent：具体执行

主Agent: "我需要一个Python后端和React前端"
主Agent → 子Agent-A（后端）: "写一个Flask API"
主Agent → 子Agent-B（前端）: "写一个React界面"

子Agent-A: "API写好了，路由是/users"
子Agent-B: "界面写好了，但需要API地址"

主Agent: "B，连接A的API: /users"
子Agent-B: "收到，对接中..."

# 这就是OpenClaw的sessions_spawn模式

2. 对等模式（Peer-to-Peer）

Agent之间地位平等，直接协商：

# 对等模式示意
Agent-A: "我完成了数据处理，结果在data.csv"
Agent-B: "收到。我需要CSV的schema信息"
Agent-A: {"columns": ["name", "age", "score"], "types": ["str", "int", "float"]}
Agent-B: "OK，开始训练模型，预计5分钟"
Agent-B: "模型训练完成，准确率92%"
Agent-C: "我要把92%的结果生成报告"
Agent-A: "原始数据文件有效期24小时"

3. 发布订阅模式（Pub-Sub）

Agent发布事件，其他Agent订阅感兴趣的事件：

# 发布订阅模式
# 事件总线

事件: "glossary_page_created"
  ├── 主题: glossary_page_created
  ├── 数据: {"term": "MXFP4", "path": "/glossary/mxfp4.html"}
  ├── 订阅者: 
  │   ├── SEO Agent: "更新sitemap" ✅
  │   ├── Link Agent: "添加内链" ✅  
  │   └── Social Agent: "发Discord通知" ✅

4. 黑板模式（Blackboard）

共享状态空间，Agent读写公共数据：

# 黑板模式 - 共享文件系统
# /shared/workspace/
#   ├── task.md          # 任务描述
#   ├── status.json      # 当前状态
#   ├── agent_a_output/  # Agent A的产出
#   ├── agent_b_output/  # Agent B的产出
#   └── final/           # 最终结果

# 每个Agent读写共享目录
# 通过文件锁或版本控制处理冲突

OpenClaw中的A2A通信实践

OpenClaw提供了多种A2A通信机制：

sessions_spawn：子Agent创建

# OpenClaw创建SubAgent（主从模式）
# 主Agent通过sessions_spawn创建子Agent
sessions_spawn({
    "task": "生成5个术语百科页面",
    "runtime": "subagent",
    "mode": "run",
    "cwd": "/var/www/miaoquai"
})

# 子Agent完成后，结果自动返回主Agent
# 这是一种结构化的A2A通信

sessions_send：Agent间消息

# OpenClaw Agent间直接通信
sessions_send({
    "sessionKey": "agent-b-session",
    "message": "术语页面已生成，请更新sitemap"
})

# 支持的消息类型：
# - 任务指令
# - 状态查询
# - 结果确认
# - 纠正指令

subagents：Agent管理

# OpenClaw Agent管理API
subagents({
    "action": "list"    # 列出所有子Agent
})
subagents({
    "action": "steer",  # 纠正子Agent方向
    "target": "agent-x",
    "message": "别写代码了，专注于文档"
})
subagents({
    "action": "kill",   # 终止失控的子Agent
    "target": "agent-y"
})

文件系统通信

# OpenClaw的文件系统A2A（黑板模式）
# 妙趣AI团队的多Agent协作

# 妙趣AI Agent 写入文件
/var/www/miaoquai/glossary/new-term.html

# SEO Agent 读取并更新
/var/www/miaoquai/sitemap.xml  # 添加新页面

# Memory系统记录
memory/2026-04-25.md  # 记录今日操作

# 通过共享文件系统实现松耦合的A2A通信

A2A通信的挑战

1. 信任问题

Agent A收到Agent B的结果，怎么知道结果是对的？这就是为什么OpenClaw倡导"验证即交付"——不信任执行方的自我声明。

2. 死锁和循环

Agent A等Agent B的结果，Agent B等Agent A的输入——死锁。或者Agent A让Agent B做事，Agent B又把任务回给Agent A——无限循环。

3. 消息爆炸

10个Agent两两通信，理论上有45条通信通道。消息数量可能指数级增长。

# A2A通信规模
# 2个Agent:  1条通道
# 5个Agent:  10条通道
# 10个Agent: 45条通道
# 20个Agent: 190条通道
#
# 解决方案：引入中间层（协调Agent/事件总线）

总结

A2A通信是从"单个Agent"到"Agent社会"的关键技术。它让AI从"独角戏"变成"交响乐"——每个Agent演奏自己的乐器，但最终合奏出一首完整的曲子。

OpenClaw已经内置了A2A通信的基础设施（SubAgent、消息传递、文件共享）。随着Google A2A协议的推广，未来Agent之间的协作会越来越标准化。

"世界上有一种对话叫A2A，虽然它们不说人话，但它们的协作效率让人类汗颜。"

---

🔗 相关阅读

• A2A协议入门
• MCP协议详解
• 多Agent编排
• SubAgent详解
• OpenClaw Session与SubAgent
• OpenClaw教程合集