## 概述 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。 ```python 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。任意一个监督者节点的上下文里，只需要容纳它**直接下属**的转写，从而把上下文压力摊薄到树的每一层。 ```python # 团队 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 不再参与。 ```python 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 都能读到此前所有人的发言轮次）。 ```python 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 协调，没有谁需要持有全局上下文。 ```mermaid flowchart TB subgraph 星型["扁平监督者（星型）"] S1["Supervisor
上下文膨胀→溢出"] 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[("共享黑板
分区状态")] -.发布.-> D1["Agent A"] BB -.发布.-> D2["Agent B"] BB -.发布.-> D3["Agent C"] end 星型 -- "上下文隔离不足
→ 上层级" --> 层级 层级 -- "延迟/委派幻觉
→ 去中心化" --> 去中心 ``` 去中心化的红利是**零序列化单点、上下文隔离度极高、天然并行**——任意两个 Agent 只通过它们共同订阅的分区通信，互不污染上下文。代价是**最终一致性治理**：没有中心仲裁者，多 Agent 并发写同一分区时的冲突消解、任务收敛的判定、死锁检测都要重新设计。LangGraph 的 `Send` API 与多 Agent 子图并行、AutoGen 的 topic 路由、Google ADK 的分层上下文工程，都在为这种去中心化提供基础设施。一个务实的中庸路线是**混合拓扑**：顶层用监督者保证治理可控与可观测，叶子层用黑板让 worker 并行读写共享状态——既不放弃中心的回环纠错能力，又拿到去中心化的上下文隔离红利。 ## 八、架构选型决策与变现评估 把六种原语压回三轴决策——**上下文税、延迟税、控制权税**——可以画出一张选型地图：任务上下文能装进单窗口且需要严格可观测，选扁平监督者；上下文装不下但治理可控是硬约束，选两层嵌套层级；任务是接力式分流（客服、工单），选 Handoff；任务需要互相启发的涌现协作且团队 ≤4，选 Selector GroupChat；任务高度并行、Agent 间低耦合，选黑板去中心化。 这套判据本身具备清晰的训练营变现价值。一个"多智能体架构实战营"可以这样切分模块：**模块一**讲第一性原理（上下文隔离而非角色模拟），用扁平监督者的上下文溢出实验让学员亲眼看到红线；**模块二**做层级团队的延迟实测，量化每加一层的延迟倍数与委派失真率；**模块三**横向对比 Handoff/GroupChat/黑板，给学员一套决策树；**模块四**落地混合拓扑与企业级治理（预算闸门、级联隔离、可观测性）。差异化卖点在于"**拓扑决策框架**"而非"如何调用某个 API"——这正是当前市面多数 Agent 课程缺失、而企业最痛的点。 ## 推荐方案 - **企业深度调研 / 跨仓库代码改造**：两层嵌套层级团队。顶层监督者只认识子团队，子团队监督者管 worker；严格限两层，第三层改并行黑板。 - **客服分流 / 工单流转**：OpenAI Handoff 原语。线性交接、责任清晰，配合 guardrail 防止交接死循环。 - **创意协作 / 代码评审 / 辩论**：AutoGen SelectorGroupChat，团队规模 ≤4，开 `allow_consecutive_same_agent=False` 抗抖动。 - **高并发数据流水线**：黑板 + 发布订阅，worker 订阅各自分区并行读写，外挂冲突消解与收敛判定。 - **稳妥的默认起点**：扁平监督者起步，监控上下文利用率，逼近 70% 红线再上层级——**宁扁平、不嵌套**。 ## 参考来源 1. [Architecting Multi-Agent Systems: Solving the 'Supervisor Bottleneck' in Production — dev.to](https://dev.to/ameer-pk/architecting-multi-agent-systems-solving-the-supervisor-bottleneck-in-production-286g) — 系统拆解监督者瓶颈的成因与去中心化对策 2. [Solving Context Window Overflow in AI Agents — arXiv 2511.22729](https://arxiv.org/abs/2511.22729) — 工具返回值与多轮循环导致的上下文溢出机理 3. [Context Is the Bottleneck: Why Multi-Agent LLM Systems Fail (MAST) — Medium](https://medium.com/@daniel.lh.gordon/context-is-the-bottleneck-why-multi-agent-llm-systems-fail-and-what-mast-teaches-us-b336b9f76e03) — "多智能体唯一理由是上下文隔离"的第一性命题 4. [Hierarchical Agent Teams — LangGraph 官方教程](https://github.com/langchain-ai/langgraph/blob/main/examples/multi_agent/hierarchical_agent_teams.ipynb) — 嵌套监督者树的参考实现 5. [Handoffs — OpenAI Agents SDK 官方文档](https://openai.github.io/openai-agents-python/handoffs/) — Handoff 原语与控制权交接机制 6. [Selector Group Chat — AutoGen 官方文档](https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/selector-group-chat.html) — 发言权调度的群聊编排 --- 本文由微信公众号「**51学通信**」原创整理，站长爱卫生（微信：gprshome201101）。多智能体的真相，从来不在"更像一个团队"，而在"谁的上下文最干净"。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。