多Agent架构详解（三）：一文讲透Hierarchical分层协同

Hierarchical 分层协同的本质，不是简单地“多加几层 Agent”，而是每一层主管都能自己决定往下派给谁——说到底，它就是 Supervisor 的递归复合。

一个 Agent 原本要独自搞定整个软件交付——前端、后端、数据库、接口全归它一个人管。一开始还好，任务一复杂，问题就冒出来了：上下文越堆越长，它要记住的细节越来越多，决策链条越拉越长。慢慢地，这个 Agent 变成了什么都要管一遍的巨型单体，谁也说不清它现在到底在忙前端还是后端。

一个很自然的问题就出来了：如果一个主管管不过来，怎么办？答案不是继续往它身上塞工具、塞提示词，而是——给主管再配一个主管。这就是本篇要聊的 Hierarchical 分层协同。

看点：分层协同本质是 Supervisor 的递归复合 · 五框架仅两家能原生搭多层 · 世界观决定模式上限

Hierarchical 的本质，其实没那么复杂

先把结论摆在最前面：

「分层协同不是简单地“多加几层 Agent”，而是要求每一层主管都能自己决定往下派给谁，下级主管还能接着往下派。」

这句话稍微拆开讲。想象一个三层的组织：

CTO 不直接指挥四个工程师，他只对两个组长说话；组长再把拆好的活派给自己手下的工程师；工程师干完，逐层往上汇报。CTO 全程不需要知道前端用了哪个状态管理库，他只需要知道“前端这块已经完成”了。

看懂这张图你会发现一件事：这里面没有任何新机制。CTO 管两个组长，是一个主管带团队；组长管工程师，也是一个主管带团队。整个结构，不过是把“一个主管带几个专家”这个模式，一层套一层地嵌套了两次。

所以但凡你之前理解过 Supervisor 模式（一个主管派活给几个平级专家），Hierarchical 在概念上真没什么新东西——它就是 Supervisor 的递归复合。

那这套结构值得费劲搭吗？值得。理由就是前面提到的那句话：逐层收窄的上下文。顶层永远只拿到最抽象的结论，细节被挡在下面几层。任务一旦复杂到需要分组分工——比如软件交付天然要分前端组、后端组——这种结构就比一个主管硬扛所有细节要合理得多。

当然代价也不是没有。层级越多，调用链越长，token 消耗、延迟、错误传播路径都会跟着涨。这点先记在心里，后面讲到“什么时候不该用”还会回来聊。

真正有意思的问题在后面：五个主流的多 Agent 框架里，谁能把这套“每层都自主派单”的结构原生搭出来？答案可能有点反直觉——只有两家。

LangGraph：主管的主管

LangGraph 做这件事做得最干净。关键就在于上一层用来搭 Supervisor 的 create_supervisor，它编译出来的产物可以再被更上一层的 create_supervisor 当成一个普通 agent 来用。

也就是说，一个组长本身也是个主管，但对 CTO 来说，组长就是“一个可以派活的下属”，CTO 根本不关心组长内部是怎么运作的。

代码里最值得盯着看的就是这几行：

frontend_team = create_supervisor(
　　agents=[fe_ui, fe_state], model=model, ...
).compile(name="frontend_team")

backend_team = create_supervisor(
　　agents=[be_api, be_db], model=model, ...
).compile(name="backend_team")

top = create_supervisor(
　　agents=[frontend_team, backend_team],　# 注意这里传进去的不是 worker
　　model=model, ...
).compile()

top 这一层的 agents 参数里，放的是两个编译好的 Supervisor，不是普通的 worker——这就是嵌套的落点。

跑起来之后，整条协作轨迹大致是这样的：

用户 → CTO
　→ 转交给前端组
　　　组长派 UI 工程师 → 派状态工程师 → 组长汇总 → 交回 CTO
　→ 转交给后端组
　　　组长派接口工程师 → 派存储工程师 → 组长汇总 → 交回 CTO
　→ CTO 综合成一份交付简报

关键在于，这条路径里没有一步是代码写死的。CTO 先派给谁、组长先找哪个工程师，全是模型当场做的决定。换句话说，从上到下每一次“转交”，都是当前那一层的主管自己拿的主意。

这也是 LangGraph 在这个模式上最大的优势：图结构本身就能表达层级，多层自主不需要绕弯子。

OpenAI Agents SDK：把 Agent 包成 Tool

OpenAI Agents SDK 没有专门为层级设计一个构造器，它靠的是另一个思路：把一个 Agent 包装成另一个 Agent 能调用的工具（as_tool）。

上一层的做法是单层——主管把专家包成工具。这里往上再叠一层：组长把工程师包成工具，总监再把组长包成工具。

def make_lead(side):
　　eng = Agent(name=f"{side}_eng", ...)
　　return Agent(
　　　　name=f"{side}_lead",
　　　　tools=[eng.as_tool(...)],　# 第一层：组长把工程师包成工具
　　　　...
　　)

fe_lead = make_lead("前端")
be_lead = make_lead("后端")

cto = Agent(
　　name="cto",
　　tools=[fe_lead.as_tool(...), be_lead.as_tool(...)],　# 第二层：总监把组长包成工具
　　...
)

运行的时候，总监调用“问前端组长”这个工具，前端组长在自己内部又会去调“问前端工程师”这个工具——一次调用连环触发下一层的调用，层级就这样叠出来了。

和 LangGraph 一样，这两层调用没有一步是代码预先定死的：总监要不要问组长、先问哪个，是总监自己决定的；组长要不要调工程师，也是组长自己决定的。所以按前面立的判据，它同样成立。

两家的差别可以简单归纳一下：

维度	LangGraph	OpenAI SDK
核心方式	Supervisor 嵌套	agents-as-tools 嵌套
层级表达	显式（图结构自带层级）	隐式（藏在工具调用里）
控制方式	transfer 转交	tool call
主要代价	图结构相对复杂	Token 和调用轮次涨得快

💡 有一点要提醒：两层嵌套意味着总监一次调用可能会触发组长再调工程师，max_turns 这类参数一定要给够，不然很容易在中途就被截断。

另外三家，为什么做不到

按照前面那条判据——每一层都要模型自主派单、下层还能自主往下派——剩下的 CrewAI、MAF、Claude Agent SDK 都不成立。但三家卡住的地方各不相同，值得分开说清楚，这比硬凑一段似是而非的多层代码更有意义。

CrewAI：单层是真的，跨层是代码拼的

CrewAI 的 Process.hierarchical 配上 manager_llm，manager 确实是模型自主派单，单层的 Supervisor 完全成立。但它没有跨 Crew 的层级机制——要搭三层结构，只能在外面写代码依次跑几个 Crew，把上一个的产出手动塞进下一个的任务描述里。“总监把活派给哪个组”这一跳，是代码固定的顺序，不是框架自己表达的语义。

MAF：没有层级构造器，写出来本质是流程编排

微软的 MAF 五种官方编排模式里没有专门给层级用的构造器。要多层，只能用 as_agent 把总监、组长、工程师各自建出来，再用代码把“谁先答、谁后答”逐行写死。这条路能跑，但每一层“派给谁”都是代码决定的，模型只是在被点到名的位置产出内容——这不是分层协同，是套了组织架构名词的流程编排。

Claude Agent SDK：被一条官方规则直接封死

它的 subagent 机制是主智能体挂一组子智能体，单层没问题。但分层协同要求组长这一层的 subagent 还能再往下派工程师，也就是 subagent 自己再创建下一层的 subagent——而官方文档里有一句很直白的话：

「Subagents cannot spawn other subagents.」
—— 子智能体不能创建其它子智能体

这条规则把结构锁死在“主智能体 + 一层 subagent”，没有第三层的空间。

这不是缺陷，更像是刻意的选择。Claude Agent SDK 的世界观是“一主多仆”：一个强大的主智能体，管理一组各有专长但彼此平级的 subagent。它把复杂度都押在了单层编排和把单个 subagent 做强这件事上，而不是支持任意深度的嵌套组织。官方文档给的替代方向也印证了这一点：真要嵌套委派，改用 Skills，或者从主对话里串联多个 subagent。

世界观决定模式上限

这五家的差异其实指向一个更普遍的判断方法：一个框架支持哪些协作模式，根子上是设计哲学决定的，而不是功能堆得多不多。

• LangGraph：把世界看成一张图。节点可以自由组合，Supervisor 嵌套 Supervisor 天然成立。
• OpenAI Agents SDK：把 Agent 看成可互相包装的 Tool。递归组合是顺手的事。
• CrewAI：把世界看成一支团队。角色、任务、流程都是它的主场，跨团队的组织层级不在它的语义里。
• MAF：把自己定位成企业级编排体系。重心在工具集成和单层编排，不在递归层级。
• Claude Agent SDK：把世界看成“一主多仆”。层级嵌套对它来说天然不成立。

选框架的时候，与其一个个去查“这个框架有没有 X 功能”，不如先想清楚“这个框架怎么看待 Agent 之间的关系”。世界观对上了，能力自然就有；世界观拧着来，再怎么拼代码都别扭。

一张表和一个简单的判断顺序

把五家放一张表里看，谁原生支持、谁做不到，一目了然：

框架	出品方	支持	实现方式	一句话点评
LangGraph	LangChain	原生	create_supervisor 嵌套	多层自主最完整，每层都是真主管
OpenAI SDK	OpenAI	原生	嵌套 agents-as-tools	极简但 token 开销大
CrewAI	CrewAI 公司	不适配	单层原生 + 外层代码串 Crew	单层真，跨层是代码模拟
MAF	Microsoft	不适配	as_agent + 代码固定顺序	写出来本质是流程编排
Claude SDK	Anthropic	不适配	—	官方规则封死，两层到顶

真要落地，可以按这个顺序问自己三个问题：

1. 任务复杂到天然需要分组分工吗？不需要的话，一个 Supervisor 就够，别硬凑层级。
2. 是不是要求每一层都能自主决定派给谁？如果流程本身就是固定顺序，直接用代码编排（Workflow）反而更省心也更好调试。
3. 两条都成立的话，看你在哪个生态：已经在用 LangGraph，直接嵌套 create_supervisor；已经在用 OpenAI SDK，嵌套 agents-as-tools 也一样成立。如果两边都没有，认真考虑换框架——真有多层组织的需求，换框架比硬拼更划算。

🕳 踩坑提示：如果两个 Agent 就能解决问题，别为了“架构看起来高级”硬塞三层。分层解决的是复杂度分治，不是“Agent 数量不够”的问题。层级越深，调试起来越麻烦，出了问题很难说清是哪一层的锅。

写在最后

Workflow 有固定流程，Supervisor 有一个中央主管，Hierarchical 有多层主管——但这三种模式其实都有一个共同点：总有一个明确的上层控制者在统筹全局。

下一个自然的问题是：如果把这个上层也拿掉呢？让 Agent 之间彻底平起平坐，自己决定把控制权交给谁，不再有固定的中央主管——这就是 Swarm 自主协作，也是下一篇要聊的东西。关于多 Agent 架构的选型与实践，欢迎到云栈社区与更多开发者一起交流。