多 agent 的难点不在 agent，在它们之间

一篇覆盖到 2026 年 3 月的综述（Zhu et al., Future Internet 2026）把多 agent 体系讲清楚了，但最值得记的不是它的分类法，而是它无意中暴露的事实：单个 agent 变强，只是把真正的难题推到了下一层。

论文提出三拓扑加一个自适应轴（集中式 / 去中心化 / 层级式 + 动态），横扫 LangGraph、CrewAI、AutoGen、OpenAI Agents SDK。但这些框架的差别不在功能清单，而在一个更早的选择：用什么作为组织交互的原语。 图、角色、对话、交接，四条路分下去，状态管理、失败恢复、成本全跟着分叉。这是架构命运。

最受触动的是两点。一是 MCP（agent 到工具）和 A2A（agent 到 agent）为什么要分两层，论文的理由比大多数讨论都干净：工具是无状态的函数调用，agent 是有目标、会拒绝、会重新谈判的实体。 连接工具和协作同伴是两种根本不同的交互——前者是调用，后者是协商。这个“垂直 vs 水平”的切分应成为设计多 agent 系统的默认前提。

二是它指出的评估真空：现有 benchmark（基准测试）都在量单 agent 能不能完成任务，没有一个量“协作本身”——消息冗余率、委派是否得当、协调开销。GPTSwarm 用学到的拓扑，花手设计拓扑 1/20 的成本在 MMLU 上达到接近的效果，说明大量成本浪费在糟糕的协调上，只是从没被量过。

补一个论文没明说、但我越想越确定的判断：三种拓扑在实践里从来不是三选一，几乎都会收敛成层级式——去中心化过不了审计关，集中式撑不住规模。真正的选型问题不是“用哪种”，而是“在树的哪一层放进哪种协调”。