Agent 到底
是怎么互相通信的？

先给最终结论

“多个 Agent 可以协作”与“实现了标准 A2A Protocol”是两个层次。前者只要求系统能投递消息；后者要求不同厂商的 Agent 按同一网络协议互操作。

先分清六个经常混淆的对象

最常见的误解，是把 Agent、Session、Run、进程和模型当成同一个东西。它们其实分别属于配置层、状态层、调度层和操作系统层。

Agent 通信系统的最小组成

一次 Agent 通信的完整生命周期

点击“逐步播放”，观察一条“请审查认证模块”的消息，从 A 的模型输出一路走到 B 的模型，再返回 A。

A2A、MCP、ACP 到底分别管什么

三个协议经常一起出现，但服务对象不同。判断一个项目是否“使用 A2A”，不能仅凭文档出现了 agent-to-agent 字样。

标准 A2A 的网络过程

Agent A Runtime
  │
  ├─ GET https://agent-b/.well-known/agent-card.json
  │        └─ 能力、技能、接口、认证、协议版本
  │
  ├─ POST /message:send  (或 JSON-RPC / gRPC)
  │        └─ Message + contextId + metadata
  │
  ├─ 收到 Task { id, state: WORKING }
  │
  └─ 结果取得方式
           ├─ 同步 Message
           ├─ Streaming events
           ├─ Push Notification/Webhook
           └─ GetTask 轮询兜底

Agent B 内部如何把 Task 变成模型 Run：A2A 不规定。

Pi：三个项目，三套完全不同的发动机

父 Pi Extension
    │ 创建任务 / runId
    ▼
Runner（管理程序）
    │ spawn("pi", ["--mode", "json", ...])
    ▼
子 Pi OS 进程
    │ stdout / session 文件 / result JSON
    ▼
Runner 收集完成结果
    │ 同步返回，或写结果文件后通知
    ▼
父 Pi Session

~/.pi/agent/messenger/
├── registry/
│   ├── GoldFalcon.json       ← 身份、PID、Session、心跳
│   └── BlueTiger.json
└── inbox/
    ├── GoldFalcon/           ← 只由 GoldFalcon 监听
    └── BlueTiger/            ← 只由 BlueTiger 监听

Pi A                                  Pi B
 │                                     │
 ├─ mDNS 浏览 _pi-a2a._tcp ───────────►│ 广播名称、端口、workspace
 │◄──────────── 发现 B ─────────────────┤
 │                                     │
 ├─ GET Agent Card ────────────────────►│
 ├─ JSON-RPC SendMessage(request) ─────►│ 创建 Task: WORKING
 │                                     ├─ pi.sendUserMessage(followUp)
 │◄────── Task ID ─────────────────────┤
 │                                     │ 模型处理、a2a_reply
 │◄──── Push Notification COMPLETED ───┤
 └─ 若 Push 丢失：GetTask 轮询兜底 ───►│

Claude Code：Subagent 与 Agent Team 不是一回事

Main Claude
  │ Agent tool
  ▼
Child context
  │ final summary
  ▼
Main Claude

Lead ───── Teammate A
 │  ╲       ╱
 │   Mailbox
 │  ╱       ╲
 └────── Teammate B
      Shared Tasks

Agent Teams 的公开底层结构

~/.claude/teams/{team-name}/
├── config.json                  ← members、agent ID、session ID、运行信息
└── inboxes/
    ├── lead.json                ← lead 的邮箱
    ├── researcher.json          ← researcher 的邮箱
    └── reviewer.json

~/.claude/tasks/{team-name}/     ← 持久任务列表

1. Lead 创建 teammate 时，Claude Runtime 建立独立 Session，并把成员写入 config.json。
2. Teammate 加载自己的系统上下文、项目 CLAUDE.md、技能和 MCP；不会自动继承 Lead 的完整对话历史。
3. SendMessage(to="reviewer") 根据成员名定位目标邮箱。
4. 消息落到目标 JSON mailbox，Claude Runtime 自动投递给目标 Session。
5. 目标的下一次 Run 把消息标记为“来自另一个 Claude Session”，而不是用户授权。
6. 回复仍通过 Mailbox 反向发送；完成或空闲时也会通知 Lead。

共享任务的“认领”使用文件锁避免两个 teammate 同时拿到一张任务卡；它只解决任务状态竞态，并不锁住源代码文件。

不是标准 A2A 这是 Claude Code 私有的本机 Team Mailbox 协议。

OpenClaw：所有路由都经过 Gateway

OpenClaw 不是让 Session 自己在网络上寻找其他 Session。Gateway 是中心路由器、Session 注册表和调度器。

                    ┌─ Agent 配置 A ─ Session A1 ─ Run 1, Run 2...
外部频道 / UI ─ Gateway
                    ├─ Agent 配置 B ─ Session B1 ─ Run 1, Run 2...
                    └─ Agent 配置 C ─ Subagent Session ─ Run...

sessions_send 的完整过程

sessions_spawn 与 Announce

Parent Session
  │ sessions_spawn(task)
  ▼
Gateway 创建 childSessionKey + transcript + 权限边界
  │ 放入全局 subagent lane
  ▼
Child Session 执行工作 Run
  │
  ▼
Child Session 内执行 Announce Step
  │ 生成：状态、最终文本、耗时、Token、sessionKey
  ▼
Completion Event
  ├─ 顶层父 Session：follow-up agent call + 外部投递
  └─ 嵌套父 Session：内部注入，供 orchestrator 综合

Announce 不是子函数直接 return String。它是工作 Run 结束后，由子 Session 再执行的交付步骤，然后 Gateway 把标准化完成事件送到父级。

不是标准 A2A 文档中的 “A2A follow-up” 是泛指 Session 间对话。OpenClaw 调用 Claude/Codex 外部 Harness 时主要使用 ACP，这也不是标准 A2A Protocol。

Hermes：短任务用线程池，长期协作用数据库

Parent AIAgent
  │ submit
  ▼
ThreadPoolExecutor
  ├─ Child AIAgent 1
  ├─ Child AIAgent 2
  └─ Child AIAgent 3
        │ completion
        ▼
state.db → fresh-turn queue → Parent

Orchestrator / Human
  │ INSERT task
  ▼
SQLite Kanban DB
  │ Dispatcher atomic claim
  ▼
Named Profile OS Process
  │ heartbeat / comment / complete
  ▼
SQLite events + downstream task

为什么 Kanban 的 Comment 也算通信

因为接收方不一定正在运行。Researcher 完成后把结果和备注写进任务行/评论；Writer 可能十分钟后才被 Dispatcher 启动。Writer 的系统提示词要求它首先调用 kanban_show()，把父任务交付物、此前尝试和评论线程装入自己的上下文。

Researcher Process ── kanban_complete/comment ──► SQLite
                                                     │
                                                     │ task dependency satisfied
                                                     ▼
                                              Dispatcher spawn
                                                     │
                                                     ▼
                                                Writer Process

这不是实时聊天，但从分布式系统角度，它是比聊天更耐久的异步消息传递。

不是标准 A2A delegate_task 是父子 RPC；Kanban 是单机 SQLite 协作协议。

Codex：公开 App Server 与团队编排器要分层看

公开的 Codex App Server

Codex App / IDE / Web Worker
  │ JSON-RPC over stdio (JSONL)
  ▼
Long-running App Server Process
  ├─ stdio reader
  ├─ message processor
  ├─ thread manager
  ├─ Core Session / Thread A
  └─ Core Session / Thread B

一个 App Server 进程可以承载多个 Codex Core Session。客户端发送 Thread/Turn 请求，Server 连续产生 item started/delta/completed、turn completed 等事件。它是“客户端控制 Agent Harness”的协议，不是标准 Agent-to-Agent 网络协议。

当前团队运行时的控制面

Codex App 的多 Agent 界面通常让不同 Agent 使用独立 Thread，并可用 Git Worktree 隔离代码修改；当前团队运行时则可能共享同一工作目录，这两种部署形态不能混为一谈。

不是标准 A2A App Server JSON-RPC 是客户端—Harness 协议；团队工具是内部 Orchestrator 协议。

目标 Agent 正忙时，会发生什么

消息送达、进程崩溃与重复执行

真正成熟的 Agent 协作，不只要“能发消息”，还要回答：写成功但没处理怎么办？处理完成但回执丢了怎么办？重启后会不会重复执行？

多个 Agent 同时修改一个文件，通信系统不会自动救你

底层实现总表

按架构而不是项目名来记

该怎么选

资料来源与事实边界

• A2A Protocol v1.0 规范
• Pi Messenger 仓库
• Pi Messenger store.ts
• Pi A2A 仓库
• Claude Code Agent Teams
• OpenClaw Session Tools
• OpenClaw Command Queue
• OpenClaw Subagents / Announce
• Hermes Subagent Delegation
• Hermes Kanban
• Codex App Server 架构
• Codex App 多 Agent 与 Worktree