深入浅出多 Agent 之间应该如何通信 —— 把协作当成一次分布式系统设计多 Agent 系统里Agent 之间的通信方式决定了协作的上限。而这里的绝大多数问题 —— 超时、死锁、重复执行、写冲突 —— 分布式系统二十年前就解决过了只是换了层皮。目录一、多 Agent 通信的本质二、四种通信拓扑三、三种通信载体四、消息该长什么样五、传递什么不传递什么六、失败与协调七、总结一、多 Agent 通信的本质1.1 它其实是个分布式系统分布式系统的老问题多 Agent 系统里的新马甲进程间通信Agent 之间怎么传消息超时与重试子 Agent 迟迟不返回死锁A 等 BB 等 A重复执行 / 幂等重试导致同一任务跑两次并发写冲突两个 Agent 改同一个文件服务发现Agent 怎么知道有哪些同伴核心观点别把通信想成聊天。一旦有多个执行体并行、共享资源、相互等待你面对的就是分布式系统 —— 该有的问题一个都不会少。1.2 三个常见误解误解为什么错“通信 让 Agent 互相聊天”自由对话不可验证、不可复现、token 爆炸“传得越多越好”上下文污染把噪音灌进每个 Agent“点对点最自然”N 个 Agent 两两通信是 O(N²) 条边很快失控二、四种通信拓扑2.1 拓扑全景拓扑结构优点缺点星型中心化一个 Orchestrator 中转可控、可观测、易调试中心是瓶颈与单点层级式Supervisor主管管小组层层向上可扩展到很多 Agent链路长信息衰减点对点网状Agent 直接对话灵活、低延迟O(N²) 复杂度难追踪黑板共享状态都读写同一块状态区解耦、异步冲突与一致性难保证2.2 三点建议默认选星型主 Agent 当 Orchestrator子 Agent 之间不直接通信 规模变大 升级成层级式每层一个 Supervisor 只有在 需要异步、松耦合、长时间协作时才上黑板模式2.3 Claude Code 的选择Claude Code 走的是典型星型事实说明子 Agent 之间不直接通信全部经主 Agent 中转主 Agent 只把一个 prompt递给子 Agent不是对话是一次任务投递子 Agent 只回final message且不展示给用户主 Agent 必须转述核心观点子 Agent 不能互相聊天是特性不是缺陷。星型牺牲了一点灵活性换来的是可观测、可复现、可调试 —— 这在生产环境里远比灵活性值钱。三、三种通信载体3.1 消息 vs 状态 vs 文件载体机制优点代价消息传递显式发一条消息意图明确可追踪需要协议与生命周期管理共享状态黑板都读写一块共享区解耦无需知道对方并发冲突、一致性文件 / 产物通过产物文件交接天然持久化可 review需要约定路径与格式3.2 实战中最实用的组合任务指令 - 消息传递显式、结构化 中间产物 - 文件存盘可 review、可重跑 进度状态 - 共享状态谁做完了一目了然3.3 一个具体的例子一个代码迁移工作流[扫描 Agent] - 产出 scan-report.json (产物文件) | [改写 Agent] - 读 scan-report.json 任务消息 - 改代码 写 change-log.md (产物文件) | [验证 Agent] - 读 change-log.md 任务消息 - 产出 verify-result.json (产物文件) | [汇总 Agent] - 只读三个产物合成最终报告核心观点产物文件是 Agent 之间最好的接口。它比消息更持久、比共享内存更安全还能被人直接打开检查 —— 这是消息传递给不了的可审计性。四、消息该长什么样4.1 结构化而不是自然语言维度自然语言消息结构化消息可验证❌ 靠模型自己理解✅ Schema 校验可路由❌ 得读完才知道给谁✅ 看字段即可分发可截断❌ 一截就丢语义✅ 按字段裁剪可复现❌ 表述随机✅ 稳定4.2 消息信封四个必备字段{task:把 product 模块的 JDBC 调用迁移到 MyBatis,context:{scope:[src/main/java/com/x/product/**],artifacts:[scan-report.json],conventions:见 CLAUDE.md 第 3 节},constraints:[不要引入新依赖,公共方法签名不可变更,每改一个文件必须保持可编译],expected_output:{format:json,schema:{changed:string[],blocked:string[]}}}字段作用缺了会怎样task做什么Agent 不知道目标context在什么背景下做Agent 去猜、去乱搜constraints不许越过哪些线产出不可用白写expected_output交什么格式回传格式不统一下游解析不了4.3 三个协议名词别搞混协议连接什么一句话MCPAgent ↔工具/数据源让 Agent 能用外部能力不是Agent 间通信A2AAgent ↔Agent跨系统 Agent 协作有 Agent Card 做服务发现HandoffAgent → Agent 的控制权移交把整个对话上下文交给下一个 Agent⚠️最常见的混淆把 MCP 当成 Agent 间通信协议。MCP 是 agent-to-tool要 Agent 之间通信才轮到 A2A 这类协议出场。五、传递什么不传递什么5.1 三种传递策略策略做法适用token 成本全量传递把完整历史塞给对方强依赖上下文的推理任务极高摘要传递传一份压缩摘要大多数任务交接中引用传递只传文件路径 / ID大产物、长文档低全量把 50 轮对话全贴过去 - 贵且未必有用 摘要传结论 关键决策 未决项 - 推荐默认 引用传 见 change-log.md - 产物大时首选5.2 引用传递为什么常被低估好处说明省 token内容只在需要时读取保持新鲜文件更新了读到的就是最新的可人工介入人可以直接打开文件改5.3 一条铁律self-contained核心观点一个好的任务投递要做到接手者不需要追问。如果子 Agent 还得反过来问你说的那个文件在哪说明主 Agent 的任务描述写失败了。5.4 回传什么该回传不该回传结论大段原始日志证据文件:行号、命令输出摘要复述一遍任务不确定性哪里没把握无依据的猜测未完成项被什么卡住假装全部完成⚠️假装全部完成是多 Agent 系统里最贵的 bug—— 它会让主 Agent 在错误的假设上继续往下编排。六、失败与协调6.1 五种典型失败失败表现对策超时子 Agent 迟迟不返回设超时 降级路径死锁A 等 BB 等 A严格 DAG禁止环重复执行重试导致跑两次幂等 任务 ID 去重写冲突两个 Agent 改同一文件文件隔离worktree信息衰减摘要传了 5 层原意没了限制层级深度6.2 写冲突最该提前防的一个❌ 两个 Agent 并行改同一个文件 - 后写的覆盖先写的 ✅ isolation: worktree - 各给一个 git worktree互不踩踏场景要不要隔离只读搜索 / 审查❌ 不需要并行改不同文件⚠️ 视冲突风险并行改同一批文件 / 重构✅ 必须6.3 人工介入点多 Agent 系统不能全自动必须在关键处留闸门闸门位置计划确认编排开始前人确认拆解是否合理高影响操作发布、删除、对外发请求之前收敛不了同一问题重试 K 次仍失败升级给人6.4 循环检测现象判断处理两个 Agent 互相等待图里有环拓扑排序时判环直接报错反复来回传同一份信息无进展循环记录轮次超限即中断核心观点能画成 DAG 就别画成网状。无环保证了任务一定会终止这是多 Agent 系统最基本的可用性前提。七、总结7.1 核心要点把通信当分布式系统设计超时、死锁、幂等、写冲突一个都躲不掉默认星型拓扑主 Agent 中转子 Agent子 Agent 之间不直接通信产物文件是最好的接口比消息持久比共享内存安全还可人工 review消息要结构化task / context / constraints / expected_output 四件套默认摘要传递大产物用引用传递任务投递必须 self-contained回传要带不确定性假装全部完成是最贵的 bug并行写必须隔离能画 DAG 就别画网状7.2 最后的话核心观点多 Agent 通信设计的好坏最终只体现在一件事上 ——主 Agent 能不能在子 Agent 失败、超时、撒谎的时候依然拼出一个正确的结论。通信协议不只是怎么传更是传错了怎么办。记住面试/设计题常考Agent 间如何传递上下文、如何避免上下文爆炸与写冲突工程红线并行写文件必须隔离任务投递必须自包含进阶方向A2A 的 Agent Card 服务发现、MCP 与 A2A 的分工、Workflow 的 pipeline/parallel 编排标签AI Agent, 多智能体, Agent通信, A2A, MCP, 分布式系统, 上下文工程