写 Agent 框架的时候，大家很容易习惯性地把 Agent 怎么交流和 Agent 怎么组队绑在一起，觉得得先搞出一套有 PM、有 Coder 的 Team 逻辑，它们才能开始对话。但仔细看最近的技术演进，事情的方向刚好相反：通信能力正在从大一统的团队框架里脱离出来，变成类似操作系统底层的进程间通信。
在 macOS 或 Linux 上启动多个 Claude Code
进程，它们已经能发现同机其他会话，并通过 SendMessage
相互发文本了。但这暴露了一个非常直观的工程现实：管道连通了，并不代表工程协作就建立了。
两个进程能互相 SendMessage，就像两台电脑刚连通 TCP Socket，离跑起一个分布式数据库还差得远。回看 Claude 的各种交互动作，Agent 之间的交流其实在分化成三种完全不同的层次：
v2.1.77
起，父会话还可以用 SendMessage 继续或恢复先前拉起的
Subagent，但不需要维持什么团队状态。这三种形态在接口上都叫
SendMessage，但解决的完全不是同一个维度的工程问题。在官方设计里，Claude Code Agent
Teams 至今依然带着
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
这个显式开关。因为定义一个团队框架并不难，真正的工程难点在于：如何确保
Agent
之间发送的自然语言文本，不会演变为并发冲突、权限穿透和不可靠的代码覆盖。
另一个关键点是信任与权限。在操作系统里，一个进程给另一个进程发消息，不可能自动继承对方的权限。在
v2.1.166、v2.1.198
和 v2.1.222
的更新里，官方反复强调：另一个 Agent
发来的可以执行，在系统眼里只是一段建议文本，无法自动升级为人类用户的授权。通信通道容易打通，但信任和安全边界无法靠自然语言文本建立。
如果只把通信管道打通，却没有任何基础设施约束，拿裸文本做协调就会撞上三大底层矛盾：
自然语言文本是连续流动的，天然没有数据库事务里的排他锁。在 GitHub Issue #23884 里，三个同名 Teammate 同时认领同一任务，并发修改同一个文件。因为没有系统维度的排他锁，并发修改最后直接变成了互相覆盖，四次测试里 Agent 最终分别只保住了 3/3、1/3、2/3 和 1/3 行代码。这说明文本对话根本承担不了排他锁的职责。
进程间通信需要明确的投递状态、超时重试和会话生命周期，而裸文本通道发出去就管不着了。在
2026 年 8 月 7 日针对 v2.1.224
提交的 Issue
#84945 里，单向消息发送 5/5 成功，反向发送却全部失败。更早发布的 v2.1.212
不可能是这个具体 Bug 的后续修复，后续版本也没有明确记录覆盖这个本地
socket case。问题在于：裸文本通道自己无法处理传输和状态感知。
模型生成自然语言是高成本的推理操作，而系统协调需要的是极低延迟、高精度的状态信号。在 Issue #47930 分析的一份含 8 个 Teammate 的协作记录里，13% 的 Teams 阶段输入 Token 用于纯 acknowledgement；把所有没有人类输入、由 Teammate 触发的 lead 唤醒纳入后，比例为 22.2%。用高成本的文本生成去充当低层的 ACK 握手，造成严重的计算开销。
自然语言干不了排他锁、传输协议和低层握手，所以不能直接把 Agent 的文本群聊当成数据库、文件锁和验收系统。
解决这三大矛盾，靠在 Prompt 里教 Agent 如何成为更好的团队成员是没有用的。就像分布式系统从来不靠节点互相谈心达成一致一样，多 Agent 系统要把这些能力沉淀成 5 层基础设施：
在操作系统里，进程通信靠的是明确的套接字和消息总线。这一层只解决发现、路由和消息传递，提供纯粹的传输管道。把投递细节从上下文剥离，能防止网络重试或卡顿污染 Agent 的记忆。
为了解决文本搞不定排他锁的问题，可以直接借鉴 Chubby 或 Redis 租约机制。任意任务在认领时，控制面会签发带生存时间的原子锁。如果持有锁的 Agent 挂了或者陷入死循环，超时后租约会自动释放，防止任务一直悬空或多节点重复认领。
为了解决并发覆盖修改，引入写时复制思想。系统给每个并发 Worker 挂载独立的 Git Worktree 或沙箱 Namespace。Worker 的所有修改都在独立的物理快照里进行，主干保持只读。如果 Worker 最终没有跑通过门禁，控制面直接把快照扔掉，没有任何副作用。
两个 Worker 提交的代码冲突时，别让它们在对话框里拉锯扯皮。控制面先尝试基于语法树的确定性合并；如果遇到设计分歧，拉起一个上下文完全干净的中立裁判 Agent。它只读增量 Diff 和需求定义，给出一次性裁决，避免原修改方带着偏见吵架。
工程上自然语言的承诺完全不可靠。这一层把质量控制前移，在代码合入主干前，强制在隔离容器里跑编译、类型检查和测试。门禁系统只看确定性的退出代码。哪怕 Agent 宣称自己写得再完美，测试未全绿，系统将物理拒绝提交。把排他锁、隔离空间、裁决和硬门禁下沉到这 5 层基础设施后，Agent 之间的通信才能从无序聊天变成可靠的工程流水线。
把这 5 层基础设施建齐成本并不低，这就带来了一个现实问题：我们什么时候才真正需要 Swarm？
Swarm 的底层账本非常清晰：用额外的计算开销和通信磨损，去换取探索空间和质量天花板。
Google Research 对 180 组系统配置的实验 给出了具体数据：在一项可并行的金融推理任务里，集中协调的多 Agent 相比单 Agent 带来 80.9% 的性能提升；但在需要严格顺序推理的 PlanCraft 任务里，所有受测多 Agent 结构的性能都下降了 39% 到 70%。
微软工程师公布的 Coding 实测 也是同样的逻辑：在相同 Prompt、相同 GPT-5-nano 的两项对照里，5-Agent 方案的 LLM 评分提升了 28% ~ 32%，但代价是 Token 飙升到 3.4 ~ 3.9 倍，耗时拉长了 2.2 ~ 4.5 倍。所以答案很明确，按任务的依赖拓扑来决定：强顺序逻辑、修改热点集中或需要共享大上下文的任务，单个能力更强的 Agent 效率最高；而在任务边界清晰、高度可并行解耦且有自动化校验手段的场景下，Swarm 才能发挥优势。
全网状对等 Swarm 天然存在二次方灾难。如果让 个 Agent 自由网状通信，通信链路是 ，不仅 Token 暴增，还会导致架构多头指挥和脑裂。
软件工程本身的演进也是天然的树状分层：从架构决策、接口定义，到模块并行实现，最后合入代码。所以行业主导产品普遍收敛到了主控扇出拓扑：
Cursor 在 2026 年 7 月展示的 SQLite Swarm 虽然探索了自研版本控制和裁判 Agent，但未被记录为已发布的 Cursor 产品能力。随后在 Cursor 2.5 更新日志 中实际推送给用户的，依然是异步 Subagent 与有限嵌套树。从 OpenAI Codex 到 Devin，主控扇出架构把拓扑复杂度降到了 ，主控握着全局上下文，Worker 保持轻量专注，这是目前最稳固、性价比最高的选择。
如果工程上决定搭建 Multi-Agent 系统，无需罗列复杂的 SOP 步骤，本质上只需要贯彻三大原则：
没有硬门禁的并发只会加速生产垃圾代码，没有写入隔离的协作一定会污染主干代码。在让 Agent 并行干活前，第一步是建好自动化测试与编译门禁（零信任硬验收），第二步是给每个 Worker 挂载独立的 Git Worktree 或沙箱（写入隔离）。把试错成本限制在物理隔绝的局部空间里，门禁没过就直接丢弃快照，保证主干不受任何污染。
不要试图靠 Prompt 对话去解决状态排他、身份恢复和权限问题。分布式系统怎么管节点，控制面就怎么管 Agent。在控制面维护 Worker 的生命周期与并发上限，用带生存时间的租约（Lease）替代文本认领，并显式校验消息来源与权限认证。用确定性代码与控制面原语，把自然语言引发的竞态条件和越权隐患彻底关进盒子里。
架构的目的是收敛结果，而不是展示复杂度。避开网状 Swarm 的二次方灾难，优先选择 的主控扇出；遇到分歧时用确定性 Merge 规则或中立裁判 Agent 裁决，而不是让修改方拉锯。更重要的是根据任务依赖动态选择拓扑：串行依赖或热点集中时坚决使用单 Agent，只有边界清晰、易于并行校验时才进行扇出。
打通消息管道只是第一步。真正决定 Multi-Agent 系统能否跑在生产环境里的，始终是底层的隔离、所有权和硬验收基础设施。