多智能体的真相：星型拓扑，与 MCP / ACP / A2A 三个协议

“发一个任务下去，很多子任务并行处理”——看起来像一群 Agent 在协作。拆开 Claude Code、Codex、grok-build 的实现，真相朴素得多。

真相一：多智能体 = 编排，不是实现

派生子代理就是封装一条提示词 + 选择上下文策略（完整 fork / 截取 / 不给），子代理本体可以是任何现成的 Agent：另一个进程里的 CLI（grok headless）、一个云端 API（现成的法务 Agent）、甚至同一个模型换个系统提示。架构的价值全在编排层：派谁、给什么上下文、什么权限、结果怎么回收。

真相二：子代理之间不直接通信

生产级 harness 全是星型拓扑：主 Agent 居中，子代理彼此隔离。”通信”通过三条间接通道发生——

父中转：主 Agent 读 A 的报告，把要点写进 B 的提示词；
共享工件：文件系统就是黑板，A 写文件 B 读（worktree、plan.md）；
顺序流水线：A 的结构化输出是 B 的输入契约。

子代理缺信息怎么办？首选问世界不问人——它自己有工具，缺什么自己去 grep / 读文件 / 查记忆。兜底是结构化要料：返回 need_info，主 Agent 补料后 resume 同一个子会话。不存在”子代理实时反问主 Agent”的活通道。

AutoGen、CrewAI、LangGraph 这些框架早就实现过真正的 Agent 群聊（互相发消息、互相提问），但两年实践暴露了代价：上下文纠缠、成本失控、不可调试。生产 harness 集体收敛回星型，不是不会做，是权衡后的选择。

真相三：三个协议各管一个方向

协议	方向	管什么
MCP	南向：Agent 到工具	工具与数据源的发现和调用
ACP	北向：Agent 到客户端	会话、流式更新、权限请求（编辑器接 Agent 用它）
A2A	东西向：Agent 到 Agent	跨进程跨厂商互通：Agent Card 能力发现、任务委派

最容易被忽略的事实：同一 harness 内部的主子通信不走任何标准协议——就是工具契约（spawn 进、report 出）。协议只在跨边界时才有意义：跨应用用 MCP，跨客户端用 ACP，跨组织用 A2A。

选型口诀：同进程星型够用；跨应用接工具上 MCP；要让别人的客户端驱动你，实现 ACP；跨公司互派任务，才轮到 A2A。 拿协议堆简历之前，先问一句：对面是谁？没有对手方的协议就是空转。