多智能体监督者栈与上下文塌方

2026 年多智能体架构的争论，已经从"用不用编排器"收敛到一个更尖锐的命题：监督者（Supervisor）究竟是在分担上下文，还是在制造上下文瓶颈。本文横向拆解 LangGraph 的扁平监督者、嵌套层级团队（Hierarchical Teams）、OpenAI 的 Handoff 原语、AutoGen 的 Selector/Swarm 编排，以及 MAST 提出的去中心化模型。核心结论有三：第一，多智能体的根本目的不是"模拟组织角色"，而是上下文隔离——这是判断一切拓扑的第一性原理；第二，扁平监督者是星型拓扑，所有消息必须经它汇总，它会率先撞上上下文窗口，成为序列化单点；第三，嵌套层级团队用"监督者之上的监督者"换来了上下文隔离，但会引入控制权稀释、延迟叠加与委派幻觉三类新塌方。选型本质是在上下文税、延迟税、控制权税三轴之间做取舍。

核心命题：监督者为何而生

理解监督者架构，必须先破除一个流传甚广的迷思——"多智能体是在模拟一个公司团队"。这个类比便于教学，却掩盖了工程真相。一组来自 MAST 框架与多份生产复盘的共识是：构建多智能体系统的唯一理由，是上下文窗口有限而任务无限。单 Agent 会撞上三道硬墙：上下文窗口天花板、无法按任务特化、单线程串行。监督者本质是一种"上下文路由器"：它把一个大任务切成若干子任务，每个子任务交给一个上下文干净的工作 Agent，从而把"塞不下"的内容隔离到不同子图里。

这个第一性原理决定了所有拓扑的评价标准：谁的上下文隔离效率最高，谁的序列化损失最小，谁就赢。监督者栈的演化，就是围绕这两个指标不断重构的过程。

多智能体控制原语横评

一、扁平监督者：星型拓扑与序列化瓶颈

控制原语	代表实现	调度方式	上下文隔离度	延迟层数	主要塌方模式
扁平监督者	LangGraph `create_supervisor`	LLM 路由选下一个 worker	中（worker 隔离，supervisor 不隔离）	1 层	监督者上下文溢出、序列化瓶颈
嵌套层级团队	LangGraph Hierarchical Teams	监督者树，逐层委派	高（每层只看局部）	2–N 层	委派幻觉、延迟叠加、控制权稀释
Handoff 原语	OpenAI Agents SDK	Agent 主动交出控制权 + 历史	高（移交完整会话）	1 层（扁平）	不可回退、责任链断裂
Selector GroupChat	AutoGen v0.4	LLM 选下一个发言者	低（全员共享黑板的轮次历史）	1 层	广播冗余、发言权抖动
Swarm（去中心化）	AutoGen Swarm / OpenAI Swarm	每个 Agent 自带 handoff 关系图	高	1 层	路由死循环、不可预测
黑板/发布订阅	共享 KV + topic 订阅	事件驱动，无中心编排	极高	0 层（无编排器）	最终一致性、收敛困难

LangGraph 的 langgraph-supervisor 库是扁平监督者最主流的实现。一个监督者 Agent 包着若干 create_react_agent 工作节点，监督者本质是一个 LLM 节点，每轮读取共享状态，输出一个 Command(goto="worker_name") 指向下一个要执行的工作 Agent。

from langgraph_supervisor import create_supervisor
from langgraph.prebuilt import create_react_agent

researcher = create_react_agent(model, tools=[web_search])
writer    = create_react_agent(model, tools=[write_file])

team = create_supervisor(
    agents=[researcher, writer],
    model=model,
    prompt="You route tasks. Pick 'researcher' for lookup, 'writer' for drafting.",
).compile()

这个模式的优雅之处在于控制流显式、可观测、可回放——整个多智能体被编译成一张 StateGraph，每一步状态可 checkpoint、可时间旅行调试。代价同样清晰：它是星型拓扑，所有 worker 的输入输出都必须经过监督者这一个节点。worker 之间不能直接对话，必须"上报→监督者决策→再下发"。当任务链变长，监督者的上下文里会累积每一步的转写、子结果摘要与路由决策，率先撞墙的永远是监督者，而不是 worker。这就是生产环境最常被报告的"监督者瓶颈"。

二、上下文溢出：监督者的隐性税收

监督者瓶颈的物理本质是上下文窗口溢出。arXiv 2511.22729《Solving Context Window Overflow in AI Agents》系统刻画了这个问题：工具返回值、中间推理、对话历史会指数级膨胀，尤其在多轮 Agent 循环里，单次工具调用的返回就可能塞进数百 KB。在监督者架构里，这个问题被放大——监督者必须同时持有"原始任务 + 全部子结果 + 路由理由"，而 worker 反而因为上下文被隔离而干净。

缓解手段有四类，各有副作用：结果压缩让 worker 只返回摘要而非原始输出，代价是监督者丢失细节、无法追问；上下文滑窗滚动丢弃旧轮次，代价是长程任务丢失前文约束；外置记忆把状态卸载到向量库/KV，代价是每次召回又是一次工具调用延迟；层级拆分把一个胖监督者拆成一棵监督者树，这是下一节的正题。工程上需要监控一个关键指标：监督者节点的上下文利用率，一旦超过 70%，序列化延迟与路由错误率会非线性飙升，这是扁平监督者即将塌方的红线信号。

三、嵌套层级团队：用监督者树换上下文隔离

LangGraph 的 Hierarchical Agent Teams（源自 AutoGen 论文思路）给出了扁平监督者的标准升级路径：把单个监督者裂变成一棵树。顶层监督者只协调"研究团队监督者"和"写作团队监督者"，每个子团队监督者再管自己的 worker。任意一个监督者节点的上下文里，只需要容纳它直接下属的转写，从而把上下文压力摊薄到树的每一层。

# 团队 A：研究子树
research_team = create_supervisor(
    agents=[search_agent, arxiv_agent], model=model,
    prompt="You are the research team lead.",
).compile(name="research_team")

# 团队 B：写作子树
writing_team = create_supervisor(
    agents=[draft_agent, editor_agent], model=model,
    prompt="You are the writing team lead.",
).compile(name="writing_team")

# 顶层监督者：只认识两个团队，不知道底层 worker
org = create_supervisor(
    agents=[research_team, writing_team], model=model,
    prompt="Delegate to research_team or writing_team.",
).compile()

这是一笔精确的工程交易：用深度换宽度，用延迟换上下文隔离。三层的树意味着任务要经过三次"上报—决策—下发"的往返，每次往返都是一次 LLM 调用与一次状态序列化。对于上下文确实装不下的复杂任务（如多源深度调研、跨仓库代码改造），这笔税是值得的；但对于能装进单监督者上下文的中等任务，加层就是纯亏损。判断准则很朴素：只有当扁平监督者的上下文利用率逼近红线时，才上层级；否则宁扁平、不嵌套。

四、Handoff 原语：控制权交接 vs 监督者路由

OpenAI Agents SDK 走了一条与监督者截然不同的路。它没有常驻编排器，而是给每个 Agent 配一个 handoffs 列表，声明"我可以把控制权交给谁"。当 Agent A 判断任务超出自己职责，它主动调用 handoff(B)，SDK 会把完整会话历史与新 Agent 一起打包，控制权直接从 A 转移到 B，A 不再参与。

from agents import Agent, Runner, handoff

billing = Agent(name="Billing", model=model, tools=[query_invoice])
triage = Agent(
    name="Triage",
    model=model,
    handoffs=[handoff(billing)],   # 主动交接，而非上报监督者
)

result = Runner.run_sync(triage, "查一下我上个月的账单")

Handoff 与监督者的根本差异在控制权流向：监督者是"worker 把结果交回中枢，中枢再决定下一步"，信息流是星型回流；Handoff 是"Agent 把控制权线性向前交接"，信息流是接力棒式前传。Handoff 的优势是零序列化单点、上下文随控制权整体迁移，特别适合客服分流、工单流转这类"一次交接、责任清晰"的场景。代价是不可回退——一旦把客户交接给计费 Agent，前序 Agent 就出局了，若交接错了需要重新分流；而且 Handoff 链一旦过长，会形成"责任链断裂"，无人对全局负责。它本质是一种去中心化的、扁平的、单向的协调，与监督者的中心化、可回环协调是两个极端。

五、Selector GroupChat：发言权调度的代价

AutoGen v0.4 的 SelectorGroupChat 是另一种中心化思路：所有 Agent 围坐一个"群聊"，由一个 selector 模型在每一轮决定"下一个该谁发言"。它和监督者的相似点是都有中心决策者，差异在于拓扑形态——监督者是星型（worker 之间隔离），GroupChat 是广播黑板（每个 Agent 都能读到此前所有人的发言轮次）。

from autogen_agentchat.teams import SelectorGroupChat
from autogen_agentchat.agents import AssistantAgent

team = SelectorGroupChat(
    participants=[planner, coder, reviewer],
    model_client=llm,
    allow_consecutive_same_agent=False,  # 禁止同一 Agent 连续发言
    max_turns=12,
)

GroupChat 的杀手锏是涌现式协作——Agent 能基于彼此的可见发言做出反应，适合头脑风暴、辩论、代码评审这类需要互相启发的任务。但广播黑板的代价极为昂贵：每个 Agent 的上下文里都装着整个群的轮次历史，N 个 Agent 就是 N 份重复的上下文账单。而且 selector 的发言权决策容易抖动——同一个 Agent 反复被点名、或关键 Agent 一直轮不到发言。allow_consecutive_same_agent=False 这类约束就是在对抗抖动。GroupChat 是上下文隔离度最低的主流模式，团队规模一旦超过 4–5 个 Agent，上下文冗余税会压垮它的涌现红利。这也是为什么 AutoGen 同时提供 Swarm——基于 handoff 的去中心化变体，用来在需要隔离时替代广播。

六、层级塌方：监督者之上的监督者

层级团队解决了扁平监督者的上下文溢出，却打开了潘多拉魔盒。生产复盘反复报告三类层级塌方：

委派幻觉（Delegation Hallucination）——顶层监督者把任务下发给子团队监督者，子监督者再往下派，每一层都在"翻译"任务。翻译层数越多，原始意图失真越严重。顶层说"调研 6G 太赫兹的信道编码进展"，到了底层 worker 可能变成"搜索太赫兹"，原始的"信道编码进展"这个约束在层级传递中被稀释。

延迟叠加——N 层监督者意味着 N 次 LLM 路由决策加 N 次状态序列化。一个三层团队完成一次"调研—写作"往返，可能产生 8–12 次模型调用，端到端延迟从秒级膨胀到分钟级。深度是延迟的乘法因子。

控制权稀释——在层级树里，顶层监督者根本看不到底层 worker 的存在，它只认识子团队。这意味着顶层无法做细粒度纠错，任何底层异常都要逐层上报、逐层再决策。一个底层 worker 报错，可能要在树里来回弹跳好几轮才被正确处理。这恰恰呼应了去中心化派对层级派的批评：层级是为了治理可控，但治理一旦超过两层，可控性反而下降。经验法则：监督者树最多两层，超过两层就该考虑扁平化或转黑板。

七、去中心化突围：从星型到发布订阅

当监督者与层级都显疲态，一批去中心化架构在 2026 年回潮。MAST 框架（Multi-Agent System Topology）的立场很鲜明：既然上下文是唯一瓶颈，那就彻底取消中心节点，让每个 Agent 直接读写一块共享的、分区的状态空间（blackboard），通过发布订阅 topic 协调，没有谁需要持有全局上下文。

flowchart TB
    subgraph 星型["扁平监督者（星型）"]
        S1["Supervisor<br/>上下文膨胀→溢出"]
        S1 --> W1["Worker A"]
        S1 --> W2["Worker B"]
        S1 --> W3["Worker C"]
    end
    subgraph 层级["嵌套层级（树）"]
        T0["Top Supervisor"] --> T1["团队监督者A"]
        T0 --> T2["团队监督者B"]
        T1 --> A1["worker"]
        T2 --> A2["worker"]
    end
    subgraph 去中心["黑板/发布订阅"]
        BB[("共享黑板<br/>分区状态")] -.发布.-> D1["Agent A"]
        BB -.发布.-> D2["Agent B"]
        BB -.发布.-> D3["Agent C"]
    end
    星型 -- "上下文隔离不足<br/>→ 上层级" --> 层级
    层级 -- "延迟/委派幻觉<br/>→ 去中心化" --> 去中心

去中心化的红利是零序列化单点、上下文隔离度极高、天然并行——任意两个 Agent 只通过它们共同订阅的分区通信，互不污染上下文。代价是最终一致性治理：没有中心仲裁者，多 Agent 并发写同一分区时的冲突消解、任务收敛的判定、死锁检测都要重新设计。LangGraph 的 Send API 与多 Agent 子图并行、AutoGen 的 topic 路由、Google ADK 的分层上下文工程，都在为这种去中心化提供基础设施。一个务实的中庸路线是混合拓扑：顶层用监督者保证治理可控与可观测，叶子层用黑板让 worker 并行读写共享状态——既不放弃中心的回环纠错能力，又拿到去中心化的上下文隔离红利。

八、架构选型决策与变现评估

把六种原语压回三轴决策——上下文税、延迟税、控制权税——可以画出一张选型地图：任务上下文能装进单窗口且需要严格可观测，选扁平监督者；上下文装不下但治理可控是硬约束，选两层嵌套层级；任务是接力式分流（客服、工单），选 Handoff；任务需要互相启发的涌现协作且团队 ≤4，选 Selector GroupChat；任务高度并行、Agent 间低耦合，选黑板去中心化。

这套判据本身具备清晰的训练营变现价值。一个"多智能体架构实战营"可以这样切分模块：模块一讲第一性原理（上下文隔离而非角色模拟），用扁平监督者的上下文溢出实验让学员亲眼看到红线；模块二做层级团队的延迟实测，量化每加一层的延迟倍数与委派失真率；模块三横向对比 Handoff/GroupChat/黑板，给学员一套决策树；模块四落地混合拓扑与企业级治理（预算闸门、级联隔离、可观测性）。差异化卖点在于"拓扑决策框架"而非"如何调用某个 API"——这正是当前市面多数 Agent 课程缺失、而企业最痛的点。

推荐方案

参考来源

本文由微信公众号「51学通信」原创整理，站长爱卫生（微信：gprshome201101）。多智能体的真相，从来不在"更像一个团队"，而在"谁的上下文最干净"。

概述