智能体间通信（A2A）：当 Agent 开始互相说话，话会变形
多 Agent 协作的真正难点不是分工，而是它们之间怎么传话不失真。
立靶：分好工，结果却拼不拢
很多人以为多 Agent 系统的难点在「分工」——把一个大任务切成几块，每块派给一个 Agent。但真正翻车的地方从来不是分工，而是它们之间怎么把话传清楚。
设想一个再普通不过的场景：一个「研究 Agent」产出一份用户调研结论，交给「写作 Agent」成稿，再交给「审校 Agent」把关。三个 Agent 各自都很聪明，单独测都没问题。可一旦串起来，三种事故反复出现：
- 信息失真：研究 Agent 说的是「用户在第 3 步流失最多，疑似表单太长」，传到写作 Agent 嘴里变成「用户讨厌填表单」，到审校 Agent 那里又被「润色」成「产品体验差」。每跳一次，语义漂移一点，三跳之后结论已经和原始事实对不上。这是通信失真，多 Agent 系统的头号杀手。
- 结果拼不拢：让三个 Agent 并行分析同一批数据，A 说留存 40%，B 说 45%，C 用另一套口径说 30%。谁来裁决？没有聚合机制，三份结果就是三份互相打架的草稿。
- Orchestrator 变单点：为协调架了一个中心调度 Agent，结果所有消息都过它，它一卡住、一理解错、一上下文爆了，整个系统跟着停摆。中心化解决了协调，却制造了单点。
这三件事的共同根源，是本课其它模式很少正面回答的问题：当 Agent 之间需要互相说话，这个「说话」本身该怎么设计。 这就是智能体间通信（业界常简称 A2A）要解决的。它和单 Agent 的 Tool Use 不是一回事：调工具是「我命令一个确定性函数，它老实返回」；A2A 是「我把意图托付给另一个会自己思考、会改写、会出错的 Agent」——后者的不确定性是前者的好几倍。
框架：通信结构的三层
第 1 层：消息传递（结构化消息）
Agent 之间不能靠裸文本糊弄。一句「帮我处理一下那个」在人之间靠默契能补全，在 Agent 之间就是失真的源头。可靠 A2A 的第一步是把消息结构化，至少四个字段：
| 字段 | 作用 | 裸文本时丢失的东西 |
|---|---|---|
| 发起者 sender | 谁发的，出问题能溯源 | 不知道这条结论是哪个 Agent 给的 |
| 接收者 recipient | 发给谁，避免广播噪声 | 所有人都收到，谁都不负责 |
| 意图 intent | 这是请求？回答？还是质疑？ | 把「我猜测」当成「我确认」来执行 |
| 内容 content | 真正的载荷，最好带证据来源 | 只传结论不传依据，下游无法复核 |
意图（intent）最容易被忽略却最关键。把「待验证的假设」和「已确认的事实」用同一种格式传过去，下游根本分不清该不该照单全收——通信失真往往就从这里开始。
第 2 层：编排模式（谁指挥谁）
结构化消息解决「怎么说一句话」，编排模式解决「一群 Agent 整体怎么协同」：
| 编排模式 | 怎么运作 | 优点 | 风险 | 适用 |
|---|---|---|---|---|
| Orchestrator-Worker（中心编排） | 中心 Agent 派活、收活、做决策，Worker 只干分内事 | 责任清晰、好聚合、易调试 | 中心是单点；上下文易爆 | 任务可清晰拆解、需统一裁决（多数生产系统默认） |
| Peer-to-peer（对等协商） | Agent 直接对话、互相质疑、协商出结论，无中心 | 灵活、抗单点、能涌现 | 难收敛、易死循环、调试地狱 | 开放式探索、辩论式求解 |
| Blackboard（共享黑板） | 所有 Agent 读写同一块共享空间 | 解耦彻底、易扩展新 Agent | 黑板成争用焦点、一致性难保 | 多专家异步贡献、拼全局图景 |
三种不是优劣关系，是适配关系。绝大多数实战系统以 Orchestrator-Worker 打底（好聚合、好排错），在需要发散的子环节局部用 Peer-to-peer 或 Blackboard。
第 3 层：协议标准化趋势
前两层是你自己系统内部的事。当 Agent 要跨系统、跨厂商通信时，需要协议标准：Google A2A protocol 定义 Agent 与 Agent 之间怎么发现彼此、交换结构化消息、协商任务（解决「我的 Agent 怎么跟你的 Agent 说话」）；MCP（Model Context Protocol） 解决另一层——Agent 与工具/数据源怎么对接。一句话记：MCP 管 Agent 到工具，A2A 管 Agent 到 Agent，互补不替代。 协议化的意义在于：通信格式被标准约束，「失真」的空间就被压缩了。
三类新成本：多 Agent 特有的代价
单 Agent 不需要操心的三笔账，多 Agent 一上来就得还。这三类成本正是 Module B「多 Agent 平台四阶段」里讲过的同一组东西——B 站在平台演进视角讲「为什么平台要分阶段消化它们」，这一讲站在通信协议视角讲「它们在消息流里具体长什么样」。同一回事，两个剖面。
| 成本 | 在问什么 | 不付会怎样 | 对应设计动作 |
|---|---|---|---|
| 交接成本 handoff | 消息从 A 传到 B，语义能不能不变形 | 多跳后结论漂移，事实被改写 | 结构化消息 + 带证据来源 + 意图字段 |
| 共享成本 shared context | 几个 Agent 看到的世界状态一不一致 | 各算各的，口径打架 | 共享黑板/统一事实源，明确谁可写 |
| 聚合成本 aggregation | 多份结果怎么合成一份一致的 | 三份草稿互相矛盾，没人裁决 | 编排者负责仲裁，定义合并规则 |
把三笔账摊开看，它们都指向同一个核心风险——通信失真：交接是单跳的失真，共享是状态不同步的失真，聚合是多份结果无法收敛的失真。多 Agent 系统的工程量，本质上有一大半花在压制这三种失真上。
Case：一个三 Agent 调研流水线的失真与修复
修复前（裸文本交接）：研究 Agent 输出自然语言「用户在注册第 3 步流失明显，可能和表单长度有关」。写作 Agent 为行文流畅改写成「用户普遍反感冗长的注册流程」，审校 Agent 再加工成「产品注册体验存在严重问题」。最终稿里那个具体、可行动、带定位的洞察（第 3 步、表单长度、疑似）全没了，只剩一句正确的废话。
修复后（结构化消息 + 中心编排 + 意图字段）：研究 Agent 输出结构化消息——sender: research-agent；intent: finding-hypothesis（明确标注是假设）；content: { 现象: "第 3 步流失 47%", 推测: "表单 12 字段疑似过长", 证据: "漏斗数据 link" }。写作 Agent 因为看到 intent 是 hypothesis，不能把「疑似」写成「确实」，保留了「数据显示第 3 步流失率最高，初步推测与表单长度相关」。审校 Agent 不再链式改写，而是把稿子和原始消息一起回传给 Orchestrator，由它对照「证据来源」做一致性裁决。差别的关键不在哪个 Agent 更聪明，而在：意图字段挡住了语义升级，证据来源给了下游复核的锚点，中心编排提供了裁决人。
可操作做法
- 先别急着上多 Agent。 单 Agent 加几个工具能搞定就别拆。只有出现这些信号才考虑：子任务需要不同专长/系统提示、需要并行才能接受时延、单上下文窗口装不下全部职责。这和 Module A 五层 L5 一致——L5 是地基最高层，建立在前四层都稳的前提上，不是起手式。
- 选编排模式按「要不要裁决」分。 需要统一可信可追责的结论 → Orchestrator-Worker；要发散探索、没标准答案 → Peer-to-peer；多异步专家添砖 → Blackboard。拿不准就 Orchestrator-Worker（最好调试）。
- 防失真三件套，每件对应一笔成本：防交接——消息一律结构化、强制带 intent 和证据来源，禁止下游做无依据的语义升级；防共享——建单一事实源，明确谁能写、写需不需要仲裁；防聚合——让编排者承担裁决责任，预先定义「结果冲突时按什么规则合并」。
- 给 Orchestrator 减负与冗余：它只管协调和裁决，重活下放 Worker；为它的上下文设上限，超了就摘要分批，避免中心上下文爆炸拖垮全局。
- 跨系统优先靠协议而非自定义格式：内部小系统自定义 schema 没问题；要和外部 Agent 互通，优先对齐 Google A2A，对接工具层用 MCP。
收口
A2A 补全了本门课一个常被跳过的盲区：我们花大量篇幅讲单个 Agent 怎么思考、用工具、规划，却很少正面讲两个 Agent 之间那条线。而恰恰是这条线，决定了多 Agent 系统是「1+1>2」还是「三个聪明人吵成一团」。
单个 Agent 的上限取决于它有多聪明；一群 Agent 的上限取决于它们之间的话有没有传变形。分工是加法，通信才是乘法——也是除法。