主管-工人模式（Supervisor–Worker）
前置知识
一句话定义
主管-工人模式由一个主管智能体负责任务分解、分派、聚合与纠偏，多个工人智能体各承接一个子任务并只与主管交互，是控制权集中、结构最简单也最常用的多智能体拓扑。
直观类比
包工头带班组：包工头（主管）把工程拆成工序，分给水电工、瓦工（工人），收活验活再交给客户。工人不互相直接指挥，所有协调经过包工头。
为什么重要
它是「任务可分解、结果可聚合」类问题的默认答案，也是人机协同最自然的挂点（人只需监督主管）。Anthropic 的工程指南将其列为标准编排模式（Orchestrator-Workers），主流框架（AutoGen 的 GroupChat 管理者、LangGraph 的 supervisor 图模板）都有现成实现。
前置知识
kp-005（角色卡——主管与工人各需一份）；kp-004（分派后的并行成本直觉）。
核心概念
- 主管（Supervisor）：只做分解、分派、聚合、纠偏四件事，通常不亲自产出内容；
- 工人（Worker）：单一职责（kp-005），返回结构化结果与状态（成功/失败/需澄清）；
- 分派循环：主管按结果决定「继续分派 / 追加工人 / 汇总终止」；
- 上下文屏障：工人只见自己子任务的上下文，主管只见工人的摘要与状态——屏障两侧都是刻意收窄的。
原理与机制
一轮标准循环：主管把目标拆为子任务清单（带验收标准）→ 并行或串行分派给工人 → 工人执行并回传结构化产物 → 主管对照验收标准聚合：合格则汇总，不合格则附差距说明重派 → 达到终止条件（目标达成、预算耗尽或轮数上限）后输出。控制权集中带来三个好处：审计简单（所有决策点在主管）、纠偏闭环短（不合格结果立刻重派）、人机协同容易（人在主管处设审批门，见 kp-018）。代价是主管成为上下文瓶颈与单点故障：子任务一多，主管的窗口被摘要塞满，指令质量下降——这正是分层模式（kp-010）的动因。主管是否用 LLM 有两档实现：代码化主管（固定分解逻辑，确定性高）与 LLM 主管（灵活分解，需防分解漂移）。
图示
┌──────────────┐
目标 ────────▶ │ Supervisor │ 分解 · 分派 · 聚合 · 纠偏
└──┬────┬────┬─┘ ▲
┌─────┘ │ └─────┐ │ 摘要+状态
▼ ▼ ▼ │
┌─────────┐┌─────────┐┌─────────┐
│ Worker A ││ Worker B ││ Worker C │ 各自: 单一职责+工具白名单
└─────────┘└─────────┘└─────────┘ (工人之间不通信)实例或案例
深度报告系统：主管把「分析某行业」拆为数据收集、竞品梳理、风险分析三个子任务，分派给三个工人；数据工人返回「指标卡片」而非原始表格；主管发现风险分析缺少数据支撑，定向重派数据工人补充两项指标后汇总成稿。全程窗口占用远低于单智能体全量上下文方案。
常见误区
- 误区一：主管亲自干活。 主管一旦开始产出内容，就失去了中立聚合视角，且上下文迅速膨胀；
- 误区二：工人互相通信。 工人横向通信会把 O(n) 的星型结构变成 O(n²) 的网状，协调成本爆炸；确需协作应由主管中转或改用黑板（kp-013）；
- 误区三：给工人的子任务没有验收标准。 没有「做完长什么样」的定义，主管聚合时只能主观裁决，重派循环不可收敛。
与其他知识点的关系
kp-010 在主管过载时插入中间层；kp-016 讨论主管逻辑放代码还是放 LLM；kp-019 处理并行分派的汇合；kp-021 提示在「主管验收」这个级联点必须放验证。
自测题
- 主管的四项职责与一项「不该做」的事？
要点：分解、分派、聚合、纠偏；不该亲自产出内容。
- 为什么工人之间不直接通信？
要点：保持星型拓扑的 O(n) 协调成本，避免网状通信的复杂度与上下文污染。
- 工人返回结果时应包含哪两类信息？
要点：结构化产物与状态信号（成功/失败/需澄清），供主管机械地路由。
延伸阅读
Anthropic《Building Effective Agents》的 Orchestrator-Workers 一节；LangGraph 的 supervisor 模板是可运行的参考实现。