Hierarchical 分层协同的本质，并非简单增加 Agent 层级，而是实现 Supervisor 模式的递归复合。其核心在于每一层主管均具备自主决策权，可动态决定任务下放对象。
单一 Agent 试图独立完成从前端到后端的全栈软件交付时，往往面临上下文无限膨胀、决策链条过长的困境，最终演变为难以维护的“巨型单体”。
解决之道不在于堆砌工具或提示词，而在于引入管理层级：为现有主管配置上级主管。这便是 Hierarchical 分层协同模式的核心逻辑。
核心看点：分层协同本质是 Supervisor 的递归复合；五大主流框架中仅两家支持原生多层搭建；框架的世界观决定了其模式上限。
ESSENCE
Hierarchical 的本质：Supervisor 的递归复合
分层协同的定义可概括为：“每一层主管都能自主决定任务下放对象，且下级主管具备继续向下派单的能力。”
以三层组织架构为例：
CTO 仅对接两位组长，组长再管理各自团队工程师。任务逐层下发，结果逐层汇报。CTO 无需知晓前端具体技术细节，仅需关注“前端任务完成”这一抽象结论。
该结构并未引入新机制，仅是将“主管带团队”模式进行了两次嵌套。因此，Hierarchical 在概念上即为 Supervisor 模式的递归复合。
其核心价值在于逐层收窄上下文：顶层仅处理抽象结论，细节被隔离在下层。适用于软件交付等需分组分工的复杂场景。但需注意，层级增加会导致调用链变长，Token 消耗、延迟及错误传播风险随之上升。
在五大主流多 Agent 框架中，能原生实现“每层自主派单”结构的仅有两家。
LANGGRAPH
LangGraph：主管嵌套主管
LangGraph 通过 create_supervisor 实现了最纯粹的分层架构。编译后的 Supervisor 可直接作为普通 Agent 被上层 Supervisor 调用。
对 CTO 而言，组长仅为一个可派活的下属，其内部运作完全封装。
关键代码逻辑如下：
顶层 agents 参数接收的是两个已编译的 Supervisor，实现了真正的嵌套。
协作轨迹示例：
全流程无硬编码路径，每一次转交均由当前层主管自主决策。LangGraph 的优势在于其图结构天然支持层级表达，无需额外迂回。
OPENAI SDK
OpenAI Agents SDK：Agent 即工具
OpenAI Agents SDK 未设专用层级构造器，而是采用"Agent 包装为工具（as_tool）”的思路实现嵌套。
实现逻辑为：组长将工程师封装为工具，总监再将组长封装为工具。
运行时，总监调用组长工具触发下一层调用，形成级联效应。与 LangGraph 类似，各层决策均由模型自主完成。
两家框架对比：
| 维度 | LangGraph | OpenAI SDK |
|---|---|---|
| 核心方式 | Supervisor 嵌套 | Agents-as-tools 嵌套 |
| 层级表达 | 显式（图结构自带） | 隐式（隐藏于工具调用） |
| 控制方式 | Transfer 转交 | Tool Call |
| 主要代价 | 图结构复杂 | Token 与调用轮次激增 |
注意：多层嵌套会导致单次请求触发多次子调用，务必调大 max_turns 参数，防止流程中途截断。
WHY NOT
其他三家为何无法实现原生分层
依据“每层自主派单且支持下延”的标准，CrewAI、MAF 及 Claude Agent SDK 均不满足要求，原因各异。
CrewAI：单层真实，跨层靠代码拼接
CrewAI 的 Process.hierarchical 配合 manager_llm 可实现单层主管自主派单。但缺乏跨 Crew 的原生层级机制。构建三层结构需在外部代码中串行执行多个 Crew，并将上一轮输出手动注入下一轮。“总监派活给哪组”由代码顺序固定，非框架语义。
MAF：本质为流程编排
微软 MAF 官方五种模式中无层级构造器。虽可通过 as_agent 创建多级 Agent 并硬编码执行顺序，但这属于“套用了组织名词的流程编排”，每层派单逻辑由代码决定，模型仅负责生成内容。
Claude Agent SDK：官方规则限制
Claude 的 subagent 机制支持单层挂载，但官方文档明确规定：
「Subagents cannot spawn other subagents.」
（子智能体不能创建其它子智能体）
该规则将结构锁定在“主智能体 + 单层 subagent"，彻底封死了第三层空间。这源于其“一主多仆”的设计哲学，侧重于强化单层编排与子智能体能力，而非支持深度嵌套。
WORLDVIEW
世界观决定模式上限
框架支持的协作模式根植于其设计哲学：
- LangGraph：视世界为图，节点自由组合，嵌套自然成立。
- OpenAI Agents SDK：视 Agent 为可互相包装的工具，递归组合顺理成章。
- CrewAI：视世界为团队，聚焦角色与任务，缺乏跨团队层级语义。
- MAF：定位企业级编排，重心在工具集成与单层流程。
- Claude Agent SDK：视世界为“一主多仆”，层级嵌套与其核心理念相悖。
选择框架时，应优先考量其对 Agent 关系的定义。世界观契合，能力自然显现；反之则事倍功半。
DECISION GUIDE
选型指南与避坑建议
五大框架原生支持情况一览：
| 框架 | 出品方 | 支持度 | 实现方式 | 点评 |
|---|---|---|---|---|
| LangGraph | LangChain | 原生支持 | create_supervisor 嵌套 | 多层自主最完整，每层均为真主管 |
| OpenAI SDK | OpenAI | 原生支持 | 嵌套 agents-as-tools | 极简实现，但 Token 开销较大 |
| CrewAI | CrewAI | 不适配 | 单层原生 + 外层代码串联 | 单层真实，跨层属代码模拟 |
| MAF | Microsoft | 不适配 | as_agent + 代码固定顺序 | 本质为流程编排 |
| Claude SDK | Anthropic | 不适配 | — | 官方规则限制，仅限两层 |
落地决策三问：
- 任务是否复杂到必须分组？若否，单一 Supervisor 足矣，勿强行分层。
- 是否要求每层自主决策？若流程固定，直接使用代码编排（Workflow）更稳健易调试。
- 生态匹配度如何？若上述两点皆成立，优先复用现有生态（LangGraph 或 OpenAI SDK）。若无，更换框架比硬拼代码更划算。
避坑提示：若两个 Agent 即可解决问题，切勿为追求架构美观而强行增加层级。分层旨在分治复杂度，而非堆砌数量。层级越深，调试难度与故障定位成本越高。
THE END
结语与展望
无论是固定流程的 Workflow，还是拥有中央主管的 Supervisor，亦或是多层主管的 Hierarchical，其共性在于均存在明确的上层控制者统筹全局。
若彻底移除上层控制者，让 Agent 间完全平权、自主移交控制权，便进入了 Swarm 自主协作 的范畴。这将是后续探讨的重点方向。
END