并行 / 集群 / 网络化架构

并行 / 集群 / 网络化架构

本节摘要:与监督者相对——集群(Swarm)没有中心决策者。Agent 读共享事件总线、异步取活、写回结果。LangGraph 显式支持「集群架构」用于去中心化、动态环境;Matrix(arXiv:2511.21686)把控制流与数据流都表示为流经分布式队列的序列化消息,以消除编排者瓶颈。权衡是显式的:用确定性与可追溯性换可扩展性。集群适合大量独立子问题的任务,不适合需要单一连贯计划的。本节用 Python threading + queue 实现一个四工人集群,对比串行基线、固定派发、集群三种方式,展示集群如何自动负载均衡,并覆盖两类失败(饥饿与热点)及其缓解——优先队列加老化、工人专精、背压。

学习目标

阅读完本节,你应当能够:

1. 说清集群架构的形状(共享队列、无中心编排者、工人 pull-处理-写回)。
2. 判断集群何时适合(大量独立任务、变时长、吞吐优先于确定性)与何时失败(有序工作流、需全局计划、需调试)。
3. 用 Python queue.Queue 实现一个多工人集群,并测量相对串行/固定派发的墙钟收益。
4. 识别饥饿与热点两类失败,应用优先队列老化、工人专精、背压缓解。
5. 解释 Matrix 的「控制流也是消息」设计,及其用可追溯性换可扩展性的权衡。

一、问题与直觉

监督者扩展到几个工人还行。几百个呢?监督者自己成了瓶颈:每个「谁干什么」的决策都汇到一个 Agent。一个慢的规划步骤就拖垮整个系统。

集群架构翻转设计。不再是中心规划者派活,而是工人从共享队列取活。「协调」烘焙进事件总线语义。没有编排者;系统一直扩展,直到队列本身成为瓶颈。

每个工人重复:拉任务 → 处理 → 写结果(可选地入队后续)。

集群何时适合

• 大量独立任务:抓取、转换、分类,任务互不依赖。
• 变时长工作:有些任务 100ms,有些 10s,集群自动负载均衡——快工人拉下一个;监督者得预先估时长。
• 吞吐优先于确定性:你在意总完成时间,不严格在意顺序。

集群何时失败

• 有序工作流:步骤 3 需要步骤 2 的输出,集群可能让步骤 3 在步骤 2 完成前就触发。
• 全局计划任务:复杂研究问题受益于规划者;一群研究员产出独立事实,而非连贯报告。
• 调试:没有中心日志、工作异步,复现一个 bug 代价高昂。

Matrix:控制流也是消息

Matrix(2025)把集群推到自然结论:控制流与数据流都是分布式队列上的序列化消息。无中心协调者;容错来自消息持久化;可扩展性是消息代理的问题,不是系统的问题。

贡献:一种编程模型,多智能体协调是「这个 Agent 订阅哪个消息主题?」而非「监督者下一个选哪个 Agent?」。系统看起来像 pub/sub 事件网格。

⚠️ Matrix 的权衡正是「协调难点」的另一种回答:与其让一个中心艰难地协调,不如让协调从消息路由规则中涌现。 代价是失去单一可追溯的执行轨迹——这是用可追溯性换可扩展性。

失败模式:饥饿与热点

若所有工人都拉最快可用的任务,长任务永远不被选,直到只剩它。经典队列饥饿。

缓解:

• 带显式老化的优先队列(随等待时间提升优先级)。
• 工人专精:某些工人只取「长」任务。
• 背压:限制快任务进队列的速度。

与内容路由的天然搭配

集群天然搭配内容路由(第 22 节):不用通用队列,而是每种消息类型一个队列,专职工人只订阅自己的类型。这是扩展到数千 Agent 的消息总线架构的基础。

二、从零实现

code/main.py 实现一个四工人集群,从共享 queue.Queue 拉取。任务时长可变(有快有慢)。演示对比:串行基线、固定派发(监督者式)、集群。

骨架

import threading, queue, time

def worker(q, results, worker_id):
    while True:
        item = q.get()
        if item is None:            # 哨兵,停止
            q.task_done(); break
        task_id, duration = item
        time.sleep(duration)       # 模拟变长工作
        results.append({"task": task_id, "worker": worker_id, "dur": duration})
        q.task_done()

def run_swarm(tasks, n_workers=4):
    q = queue.Queue(); results = []; threads = []
    for t in tasks: q.put(t)
    for i in range(n_workers):
        th = threading.Thread(target=worker, args=(q, results, i))
        th.start(); threads.append(th)
    for _ in range(n_workers): q.put(None)   # 停止哨兵
    for th in threads: th.join()
    return results
​

三种对比

tasks = [(f"t{i}", 0.1 if i%2==0 else 0.5) for i in range(8)]  # 4快4慢
# 串行: sum = 2.4s
# 固定派发: 每工人2个,可能快工人干完闲着等慢工人 = ~1.0s
# 集群: 快工人干完自动拉慢任务 = ~0.6s
​

设计要点:集群的每工人任务数分布不均但最优——快工人处理更多任务,慢工人少。这正是自动负载均衡的体现,也是它胜过固定派发(快工人空等)的原因。

三、框架对比

💡 心法:监督者要连贯计划,集群要吞吐。 Anthropic 研究系统故意选监督者而非集群,正因研究需要连贯报告而非独立事实。先确认你任务要的是哪个,再选架构。

四、可复用产物

outputs/skill-swarm-fit.md:评估任务该用集群还是监督者。输入:任务独立性、时长方差、顺序要求、可调试性需求。输出:架构推荐。

五、练习

1. 测收益:跑 code/main.py。集群在变长工作负载上比串行快多少?比固定派发快多少?
2. 优先队列:加一个 queue.PriorityQueue 变体,按任务「重要性」分优先级。观察低优先任务在持续负载下是否饥饿。
3. 热点检测:实现热点检测器——任一工人处理任务数是最慢工人的 3 倍时记日志。这说明了任务时长分布的什么?
4. 读 Matrix:读 Matrix(arXiv:2511.21686)摘要与第 3 节,识别它接受的一个权衡(可扩展收益)与放弃的一个(可追溯、确定性)。
5. 内容路由:把演示改成 queue.Queue 里放 (task_type, payload) 元组,工人只订阅特定类型。任务异构时什么路由规则合理?

本节要点回顾

1. 集群无中心编排者:工人从共享队列 pull-处理-写回,协调烘焙进事件总线语义。
2. 何时适合:大量独立任务、变时长、吞吐优先于确定性——集群自动负载均衡。
3. 何时失败:有序工作流(步骤乱序)、全局计划任务(产出独立事实而非连贯报告)、调试(无中心日志、异步)。
4. Matrix 把控制流也消息化:数据与控制流都是分布式队列消息,用可追溯性换可扩展性。
5. 两类失败:饥饿(长任务永不被选)与热点(一个工人被淹没)。
6. 缓解手段:优先队列加老化、工人专精、背压、内容路由(每类型一队列)。
7. 生产化清单:优先队列加老化、工人幂等、持久队列(Kafka/Redis Streams)、每任务 trace id、背压。
8. 监督者 vs 集群:前者要连贯计划,后者要吞吐——先确认任务要哪个再选架构。

下一节,我们聚焦一种特殊的集群形态——群聊与发言者选择,看一组 Agent 在共享上下文里轮流发言时,「下一个谁说」这一决策如何由 LLM 或规则做出。