多 Agent 系统协作失败，根因往往不在单个 Agent 能力不足，而在 Agent 之间的信息交换出了问题。Agent 之间的通信带宽有限，无法把一个 Agent 脑中的全量上下文原封不动搬给另一个，只能通过消息传递。交接点最容易出现三种断裂：信息传丢（关键参数遗漏）、信息传歪（原始意图被下游曲解）、上下文断裂（多轮交接后丢失全局视野）。因此，通信要当成一个专门的架构问题来设计，核心是三件事。

第一是选对通信拓扑，决定谁跟谁说话。中心化模式（主管与执行者模式）由一个主 Agent 居中调度，负责拆解任务、分发任务、收集并汇总结果，所有子 Agent 只与主 Agent 通信，彼此不直接对话。它通信路径清晰、全局状态由主 Agent 统一维护，系统可控、好调试、好观测，通常优先推荐。接力交接模式是 Agent 之间直接传递，谁处理完就交给下一个，更灵活，但更容易在交接点出故障。

第二是定好消息契约，决定用什么协议和结构说话。应避免 Agent 之间用自然语言自由发挥，这一步最容易被忽略，也最容易引发歧义和信息丢失。更稳的做法是用结构化消息格式，把每次交互携带的数据固定成标准化接口，例如 JSON。派发任务时用清晰接口消除模糊空间，交代清楚子任务目标、期望输出格式、可用工具列表、边界与限制，以及上一步的结果。

第三是管好共享状态，确保各 Agent 看到同一份真相。如果每个 Agent 只掌握局部信息，系统会陷入协作混乱。可以建立一块统一维护的共享记忆区，也叫公共黑板，各 Agent 把关键进度、中间结论和状态写进去，需要时再读取，而不是靠一条条消息互相追问。子 Agent 返回结果时，不必把冗长推理过程原样传回，只需把精简结论写入共享状态，既省通信带宽，也保持各 Agent 上下文干净。共享状态要由编排者统一维护写入入口，保证全局视图一致。

落地时可以概括为四条：中心化编排管住通信路径，结构化消息管住交互语义，共享状态黑板管住全局真相，全流程可观测（例如贯穿的 Trace ID）保证每次交互和通信链路可追溯。