Workflow 里代码决定流程，Supervisor 里模型掌握决策权。当任务路径无法预定义时，将动态调度权交给模型才是更优的工程解法。
以“撰写《2026 年多智能体协作模式现状》研究简报”为例，若采用多 Agent 分工，需安排技术原理、落地场景及内容整合三个角色。然而，谁先执行、是否全量询问、何时收尾等逻辑，难以在编码阶段完全固化，必须依赖临场判断。
这正是从 Workflow 向 Supervisor 模式转变的关键：前者由代码硬编码下一步，后者由模型动态决策下一步。
核心机制在于引入一个中央主管 Agent，负责统筹派单、控制节奏并综合结果，即Supervisor 集中调度模式。
本文看点：派单模式与控制权归属 · 五大主流框架实战横评 · Supervisor 适用边界分析
FUNDAMENTALS
Supervisor 的核心定义
Supervisor 本质是一个中央协调者，根据任务动态分配子智能体工作，并统一汇总结果。其与 Workflow 的根本区别在于“下一步行动”的决策权归属：Workflow 由代码预设，Supervisor 由模型实时推断。
该架构具有显著的中心辐射（Hub-and-Spoke）特征：子智能体之间互不可见，仅与主管单线通信。所有信息流均需经过主管中转。这种设计使得协作关系清晰、全局可控且易于调试，但也带来了潜在的主管瓶颈问题。
DISPATCH MODES
两种核心派单模式：控制权转移 vs 工具调用
尽管表象均为“派单”，底层实现存在控制权是否转移的本质差异：
模式一：控制权转移（Transfer）
主管将执行权完全移交子智能体，待其完成后收回。此过程类似函数跳转，子智能体拥有独立的上下文执行空间。LangGraph是此类模式的典型代表。
模式二：Agent 即工具（Agents-as-Tools）
主管将子智能体封装为工具（Tool），调用过程类似函数执行。子智能体返回结果后，主管继续主导推理，控制权始终未离开主管。OpenAI Agents SDK采用此方案。
| 模式 | 控制权归属 |
|---|---|
| Transfer（控制权转移） | 临时转移给子 Agent，完成后归还 |
| Agents-as-tools | 始终保留在 Supervisor 手中 |
VS SWARM
概念辨析：Supervisor 与 Swarm 的区别
需严格区分 Supervisor 与 Swarm 模式：
- Supervisor：“你去做，做完向我汇报。”无论何种派单方式，最终责任与控制权均回归主管。
- Swarm：“接下来由你全权负责。”控制权发生实质性交接（Handoff），后续流程由接收方自主决定，原主管不再兜底。
核心差异：as_tool 仅为函数调用，handoff 才是真正的控制权移交。
FRAMEWORK COMPARISON
五大主流框架实战横评
基于同一案例（多智能体协作研究简报），对比 LangGraph、OpenAI Agents SDK、CrewAI、MAF 及 Claude Agent SDK 的实现差异。
LangGraph：控制权转移的典型代表
通过langgraph-supervisor扩展包原生支持。利用create_supervisor自动装配星形结构，无需手动编写派单逻辑。执行顺序完全由模型运行时动态决定，非代码硬编码。
注意事项：查看执行轨迹时，invoke返回的是整理后的状态消息，可能与实际时间线不符；需使用stream模式获取真实的执行先后顺序。
点评：控制粒度最细，派单轨迹完整可视。
OpenAI Agents SDK：极简的工具化方案
采用 Agents-as-Tools 模式。通过agent.as_tool()将专家封装为主管可调用的工具。主管全程掌控控制权，像调用普通函数一样获取专家结果，代码量极少（百行内即可运行）。
点评：实现最简洁，控制权不转移，开发效率高。
CrewAI：参数切换实现模式转换
仅需将Process从sequential改为hierarchical，并指定manager_llm，即可从流水线模式切换至 Supervisor 模式。CrewAI 会自动生成 Manager 进行动态调度。
点评：上手门槛最低，仅需修改枚举值即可切换架构。
NAMING TRAP
命名陷阱：Hierarchical 的真实含义
CrewAI 中的Process.hierarchical虽名为“层级”，实则为单层 Supervisor 结构（一个 Manager 管理多个平级专家）。
真正的Hierarchical（分层协同）指多层嵌套结构（如 CEO 管理 Manager，Manager 再管理 Agent）。切勿因术语相同而混淆单层调度与多层嵌套的概念。
MICROSOFT MAF
MAF：从调度员升级为项目经理
微软 MAF（Magentic Framework）提供更为重型的Magentic 编排方案。其主管不仅负责派单，还维护“任务账本”与“进度账本”，具备规划、监控及异常重规划能力。
通过max_round_count参数设置确定性保险丝，防止模型陷入无限循环。这体现了重要工程原则：模型可拥有决策权，但边界必须由代码约束。
点评：架构最重型，适合复杂长程任务；简单任务使用属于过度设计。
CLAUDE SDK
Claude Agent SDK：原生 Orchestrator-Worker 架构
Claude SDK 原生支持subagents模式（即 Orchestrator-Worker 架构）。主智能体依据子智能体的description字段自动路由任务，子智能体在隔离上下文中执行。
实测显示，该模式产出的综合结果往往更具批判性，能主动识别错误级联与编排成本问题，适合对输出质量要求较高的生产场景。
点评：Anthropic 核心架构，经生产验证，子智能体隔离性好，产出扎实。
DECISION GUIDE
选型指南：五大框架横向对比
| 框架 | 出品方 | 核心原语 | 特点总结 |
|---|---|---|---|
| LangGraph | LangChain | create_supervisor | 控制最细，轨迹可视 |
| OpenAI SDK | OpenAI | agent.as_tool | 代码最简，控制权不转移 |
| CrewAI | CrewAI | Process.hierarchical | 配置灵活，切换成本低 |
| MAF | Microsoft | MagenticBuilder | 重型架构，双账本管理 |
| Claude SDK | Anthropic | subagents | 生产实证，隔离性好 |
目前，Orchestrator-Worker 家族已占据生产级多智能体部署的主流地位。选型建议如下：
- 追求可观测性与精细控制：选择 LangGraph。
- 追求开发效率与轻量化：选择 OpenAI SDK。
- 已有 CrewAI 存量项目：直接切换 Process 参数。
- 应对复杂长程任务：选择 MAF。
- 深耕 Anthropic 生态：首选 Claude SDK。
LIMITATIONS
适用边界：何时不应使用 Supervisor
多 Agent 并非万能，以下场景需谨慎使用 Supervisor：
1. 任务过于简单
若单 Agent 即可完成，引入 Supervisor 会增加 Token 消耗、延迟及系统复杂度。
2. 需高频直接交互
Supervisor 结构为"A → 主管 ← B"，若子任务间需频繁直接通信或上下文动态流转，中心辐射架构将成为阻碍。
3. 主管成为瓶颈
随着子任务增多，主管上下文膨胀会导致显著的 Token 与延迟成本，这是集中式架构的固有代价。
判断准则：任务可拆分为独立子任务且需中心统筹时，适用 Supervisor；若子任务间依赖紧密、对话焦点频繁漂移，则不适用。
THE END
结语
Supervisor 并非更高级的架构，而是解决“任务路径无法预定义”问题的工程化方案。它通过中央控制实现了专业分工与动态调度，但也带来了上下文膨胀与成本增加的代价。
当单 Agent 能力不足，而又无需构建完全去中心化的网络时，Supervisor 是最自然的演进方向。若未来业务需要“主管之下设主管”的多层管理，则将进入Hierarchical 分层协同的新阶段。
END