并行 / 蜂群 / 网状架构 — AI 工程从零开始

与监督员模式相对：没有中心决策者。Agent 读取共享的事件总线（event bus），异步领取工作，再把结果写回。LangGraph 明确支持「蜂群架构」（Swarm Architecture），用于去中心化、动态变化的环境。Matrix（arXiv:2511.21686）把控制流与数据流都表示为经由分布式队列传递的序列化消息，以消除编排器瓶颈。代价是明摆着的：用确定性与可追踪性换取可扩展性。蜂群适合包含大量独立子问题的任务，不适合需要单一连贯计划的任务。

问题

监督员模式能扩展到几个工作者。那几百个呢？监督员本身就成了瓶颈：每一个「谁做什么」的决定都要经过同一个 Agent。一个缓慢的计划步骤就能拖住整个系统。

蜂群架构把设计翻转过来。不再由中心规划者分派工作，而是工作者从共享队列中领取工作。「协调」被固化进事件总线的语义里。没有编排器；系统可以一直扩展，直到队列成为瓶颈。

概念

结构形态

                ┌──── shared queue ────┐
                │                      │
       ┌────────┼────────┐  ◄──────┬───┘
       ▼        ▼        ▼         │
     Worker  Worker  Worker   Worker
      A       B       C        D
       │        │        │         │
       └────────┴────────┴─────────┘
                 │
                 ▼
            results pool

没有编排器。每个工作者不断重复：领取任务、处理、写回结果（可选地再入队后续任务）。

蜂群适用的情况

大量独立任务。 抓取、转换、分类。任务之间互不依赖。
任务耗时不一。 如果有的任务耗时 100ms、有的 10s，蜂群会自动均衡负载——先做完的工作者去领下一个任务。监督员则必须预判耗时。
吞吐量优先于确定性。 你关心的是总完成时间，而不是严格的顺序。

蜂群失效的情况

有顺序的工作流。 如果第 3 步需要第 2 步的输出，蜂群可能让第 3 步在第 2 步完成前就触发。
需要全局计划的任务。 复杂研究问题受益于规划者。一群研究者各自产出独立的事实，而不是一份连贯的报告。
调试。 没有中心日志，工作又是异步的，复现一个 bug 的代价很高。

Matrix（arXiv:2511.21686）

Matrix 是 2025 年的论文，把蜂群推到了它的自然终点：控制流与数据流都是分布式队列上的序列化消息。没有中心协调者。容错来自消息的持久性。可扩展性变成消息代理（message broker）的问题，而不是系统的问题。

贡献在于一种编程模型：多 Agent 协调变成了「这个 Agent 订阅哪个消息主题？」，而不是「监督员下一个选哪个 Agent？」。这让系统看起来像一张发布/订阅（pub/sub）的事件网格。

图框架中的蜂群

LangGraph 2025 年的文档明确把「Swarm Architecture」列为多 Agent 模式之一：Agent 是节点，但边构成带环的有向图，任何节点都可以从池中被激活。工作者按条件从可用工作中挑选，而不是由监督员分配。

失效模式：饥饿与热点

如果所有工作者都挑最快能做完的任务，长耗时任务就会一直没人领，直到只剩它们为止。这就是经典的队列饥饿（starvation）。

缓解办法：

带显式老化（aging）的优先队列（等待越久优先级越高）。
工作者专精：让部分工作者只接「长」任务。
背压（back-pressure）：限制快速任务进入队列的数量。

与基于内容的路由的联系

蜂群与基于内容的路由（content-based routing，第 22 课）天然搭配。不要用一条通用队列，而是每种消息类型一条队列。专门的工作者只订阅自己那一种。这正是能扩展到数千个 Agent 的消息总线架构的基础。

sw-work-stealing静态版本未包含此交互图

构建它

code/main.py 实现一个由 4 个工作线程组成的蜂群，从共享的 queue.Queue 中领取任务。任务耗时各不相同（有的快、有的慢）。演示对比三种方式：

顺序基线： 一个工作者串行处理所有任务。
固定分配： 每个任务预先分配给特定工作者（监督员风格）。
蜂群： 工作者从共享队列中领取任务。

蜂群会自动均衡负载；固定分配下，当某个工作者分到的任务很慢时，快的工作者只能闲着。

运行：

python3 code/main.py

输出会显示每个工作者处理的任务数（蜂群的分发并不均匀，但整体最优）以及墙钟时间。

使用它

outputs/skill-swarm-fit.md 评估一个任务该用蜂群还是监督员。输入：任务独立性、耗时方差、顺序要求、可调试性需求。

交付它

检查清单：

带老化的优先队列。 防止长任务饥饿。
工作者幂等性。 如果工作者执行到一半崩溃，同一个任务可能被领取不止一次。工作者必须幂等。
持久化队列。 生产环境用 Kafka、Redis Streams 或基于数据库的队列。queue.Queue 只在内存中。
按任务可观测。 每个任务都有 trace ID；每个工作者在开始和结束时都带着它写日志。
背压。 如果队列增长快于工作者消费，就放慢生产者。

练习

运行 code/main.py。在耗时不一的工作负载上，蜂群比顺序处理快多少？比固定分配快多少？
增加一个优先队列版本（使用 queue.PriorityQueue）。按任务的 "importance" 字段分配优先级。观察在持续负载下，低优先级任务是否会发生饥饿。
实现一个热点探测器：当任意一个工作者处理的任务数达到最慢工作者的 3 倍时记录日志。这说明了任务耗时分布的什么情况？
阅读 Matrix 论文（arXiv:2511.21686）的摘要与第 3 节。找出 Matrix 明确接受的一项取舍（可扩展性收益）和一项它放弃的东西（可追踪性、确定性）。
把蜂群演示改成使用装着 (task_type, payload) 元组的 queue.Queue，并让工作者只订阅特定类型。当任务异构时，什么样的路由规则才合理？

关键术语

术语	常见说法	实际含义
蜂群架构（Swarm architecture）	「去中心化 Agent」	工作者从共享队列领取任务；没有中心编排器。
事件总线（Event bus）	「Agent 订阅主题」	按类型或内容把任务路由给工作者的消息代理。
饥饿（Starvation）	「任务永远轮不到」	高优先级工作源源不断，导致低优先级任务始终没被领取。
热点（Hot-spotting）	「一个工作者被淹没」	负载不均，某个工作者拿到了大部分任务。
背压（Back-pressure）	「让生产者慢下来」	队列填满时向上游发出停止生产的信号机制。
幂等工作者（Idempotent worker）	「重跑也安全」	同一任务处理两次得到相同结果。由于工作者可能中途崩溃，这是必需的。
持久化队列（Durable queue）	「崩溃后还在」	由磁盘或复制存储支撑的队列；工作者崩溃时任务不会丢失。
Matrix 框架	「完全消息传递的蜂群」	数据流与控制流都是分布式队列上的序列化消息。

示意图共 1 张

问题

概念