--- layout: post.njk source: https://yage.ai/share/agent-swarm-communication-20260811.html speaker: yage.ai title: Agent 通信越来越简单，为什么 Swarm 依然很难落地？ date: '2026-08-11' summary: 文章探讨了Agent通信从团队框架向底层进程间通信演进的工程现实，指出仅靠自然语言文本的交流无法解决并发冲突、权限穿透等底层工程问题。文章提出了构建Multi-Agent系统所需的五层基础设施，包括通信寻址、租约与所有权、写入隔离、冲突裁决和零信任验收，强调系统层面的排他锁、隔离和硬门禁是实现可靠协作的关键。 area: tech-engineering category: ai-application tags: - multi-agent-system - process-communication - concurrency-control - zero-trust-acceptance - workflow-tools people: [] companies_orgs: [] products_models: [] media_books: [] draft: true status: evergreen --- 写 Agent 框架的时候，大家很容易习惯性地把 Agent 怎么交流和 Agent 怎么组队绑在一起，觉得得先搞出一套有 PM、有 Coder 的 Team 逻辑，它们才能开始对话。但仔细看最近的技术演进，事情的方向刚好相反：通信能力正在从大一统的团队框架里脱离出来，变成类似操作系统底层的进程间通信。 在 macOS 或 Linux 上启动多个 Claude Code 进程，它们已经能发现同机其他会话，并通过 SendMessage 相互发文本了。但这暴露了一个非常直观的工程现实：管道连通了，并不代表工程协作就建立了。 ## Claude 扩大的是消息边界，不是 Team 的成熟度 两个进程能互相 SendMessage，就像两台电脑刚连通 TCP Socket，离跑起一个分布式数据库还差得远。回看 Claude 的各种交互动作，Agent 之间的交流其实在分化成三种完全不同的层次： 父子委派：最简单的单向控制，就像主程序调了一个子函数。父进程拉起子进程干活并拿回结果；从 v2.1.77 起，父会话还可以用 SendMessage 继续或恢复先前拉起的 Subagent，但不需要维持什么团队状态。 跨进程寻址：刚剥离出来的底层通信。两个独立会话知道了对方的地址，能发裸文本。但管道打通归打通，双方不共享上下文、不共享文件状态，也没有任何互斥锁。 团队协作：这才是真正的 Agent Teams。它试图在通信管道之上，搭起任务看板、认领机制和团队生命周期。 这三种形态在接口上都叫 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 的文本群聊当成数据库、文件锁和验收系统。 ## 从底层矛盾推导：Multi-Agent 的 5 维基础设施 解决这三大矛盾，靠在 Prompt 里教 Agent 如何成为更好的团队成员是没有用的。就像分布式系统从来不靠节点互相谈心达成一致一样，多 Agent 系统要把这些能力沉淀成 5 层基础设施： Multi-Agent 协作的 5 层基础设施：从通信寻址到零信任验收，把排他锁、隔离、裁决和硬门禁下沉为系统层 ### 1. 通信寻址层：寻址路由与 RPC 隔离 在操作系统里，进程通信靠的是明确的套接字和消息总线。这一层只解决发现、路由和消息传递，提供纯粹的传输管道。把投递细节从上下文剥离，能防止网络重试或卡顿污染 Agent 的记忆。 ### 2. 租约与所有权层：原子 Lock 与 TTL Lease 为了解决文本搞不定排他锁的问题，可以直接借鉴 Chubby 或 Redis 租约机制。任意任务在认领时，控制面会签发带生存时间的原子锁。如果持有锁的 Agent 挂了或者陷入死循环，超时后租约会自动释放，防止任务一直悬空或多节点重复认领。 ### 3. 写入隔离层：Copy-on-Write 与 Worktree 沙箱 为了解决并发覆盖修改，引入写时复制思想。系统给每个并发 Worker 挂载独立的 Git Worktree 或沙箱 Namespace。Worker 的所有修改都在独立的物理快照里进行，主干保持只读。如果 Worker 最终没有跑通过门禁，控制面直接把快照扔掉，没有任何副作用。 ### 4. 冲突裁决层：确定性 Merge 与中立裁判 Agent 两个 Worker 提交的代码冲突时，别让它们在对话框里拉锯扯皮。控制面先尝试基于语法树的确定性合并；如果遇到设计分歧，拉起一个上下文完全干净的中立裁判 Agent。它只读增量 Diff 和需求定义，给出一次性裁决，避免原修改方带着偏见吵架。 ### 5. 零信任验收层：Shift-Left 机械硬门禁 工程上自然语言的承诺完全不可靠。这一层把质量控制前移，在代码合入主干前，强制在隔离容器里跑编译、类型检查和测试。门禁系统只看确定性的退出代码。哪怕 Agent 宣称自己写得再完美，测试未全绿，系统将物理拒绝提交。把排他锁、隔离空间、裁决和硬门禁下沉到这 5 层基础设施后，Agent 之间的通信才能从无序聊天变成可靠的工程流水线。 ## Swarm 的核心 Trade-off 与落地指南 把这 5 层基础设施建齐成本并不低，这就带来了一个现实问题：我们什么时候才真正需要 Swarm？ ### 1. 核心 Trade-off：到底用不用？ 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 才能发挥优势。 ### 2. 拓扑收敛与 Multi-Agent 落地的三大原则 全网状对等 Swarm 天然存在二次方灾难。如果让 NN 个 Agent 自由网状通信，通信链路是 O(N2)O(N^2)，不仅 Token 暴增，还会导致架构多头指挥和脑裂。 软件工程本身的演进也是天然的树状分层：从架构决策、接口定义，到模块并行实现，最后合入代码。所以行业主导产品普遍收敛到了主控扇出拓扑： 主控扇出拓扑：Orchestrator 拆解任务并签发 Lease，三个 Worker 在独立 Worktree 中提交 Diff 并跑通门禁 Cursor 在 2026 年 7 月展示的 SQLite Swarm 虽然探索了自研版本控制和裁判 Agent，但未被记录为已发布的 Cursor 产品能力。随后在 Cursor 2.5 更新日志 中实际推送给用户的，依然是异步 Subagent 与有限嵌套树。从 OpenAI Codex 到 Devin，主控扇出架构把拓扑复杂度降到了 O(N)O(N)，主控握着全局上下文，Worker 保持轻量专注，这是目前最稳固、性价比最高的选择。 如果工程上决定搭建 Multi-Agent 系统，无需罗列复杂的 SOP 步骤，本质上只需要贯彻三大原则： #### 原则一：验收与隔离先行，避免无保护并发 没有硬门禁的并发只会加速生产垃圾代码，没有写入隔离的协作一定会污染主干代码。在让 Agent 并行干活前，第一步是建好自动化测试与编译门禁（零信任硬验收），第二步是给每个 Worker 挂载独立的 Git Worktree 或沙箱（写入隔离）。把试错成本限制在物理隔绝的局部空间里，门禁没过就直接丢弃快照，保证主干不受任何污染。 #### 原则二：控制面下沉，用系统锁与凭证替代自然语言 不要试图靠 Prompt 对话去解决状态排他、身份恢复和权限问题。分布式系统怎么管节点，控制面就怎么管 Agent。在控制面维护 Worker 的生命周期与并发上限，用带生存时间的租约（Lease）替代文本认领，并显式校验消息来源与权限认证。用确定性代码与控制面原语，把自然语言引发的竞态条件和越权隐患彻底关进盒子里。 #### 原则三：极简拓扑优先，按任务依赖关系选择收敛路径 架构的目的是收敛结果，而不是展示复杂度。避开网状 Swarm 的二次方灾难，优先选择 O(N)O(N) 的主控扇出；遇到分歧时用确定性 Merge 规则或中立裁判 Agent 裁决，而不是让修改方拉锯。更重要的是根据任务依赖动态选择拓扑：串行依赖或热点集中时坚决使用单 Agent，只有边界清晰、易于并行校验时才进行扇出。 打通消息管道只是第一步。真正决定 Multi-Agent 系统能否跑在生产环境里的，始终是底层的隔离、所有权和硬验收基础设施。