层级架构及其失效模式 — AI 工程从零开始

层级架构就是把监督员（supervisor）嵌套起来。管理者 Agent 之下是子管理者，再之下是工作者。CrewAI 的 Process.hierarchical 是教科书式的版本：manager_llm 动态分派任务并校验输出。LangGraph 中的对应写法是 create_supervisor(create_supervisor(...))。当任务本身就是一张真实的组织架构图时，这是最自然的模式。它也是最容易塌缩成「管理者循环」的模式——管理者 Agent 分派工作不当、误读子级输出，或者无法达成一致。顺序流程（sequential）往往能胜过它。

问题

一旦理解了监督员模式，接下来很自然会问：「如果工作者本身也是监督员会怎样？」团队之下有子团队，公司之下有部门套部门。层级架构正是对这种结构的映射。

问题在于：LLM 管理者与人类管理者并不相同。人类管理者对下属掌握什么有稳定的先验判断。LLM 管理者则在每一轮里，仅凭上下文中的内容重新推演整个组织关系。上下文稍有漂移，整棵树就会把工作分派错。

概念

结构形态

                 Manager
                 ┌─────┐
                 └──┬──┘
           ┌────────┴────────┐
           ▼                 ▼
       Sub-Mgr A         Sub-Mgr B
       ┌─────┐           ┌─────┐
       └──┬──┘           └──┬──┘
         ┌┴──┬──┐          ┌┴──┐
         ▼   ▼  ▼          ▼   ▼
       W1  W2  W3         W4  W5

每个内部节点都负责规划、分派与综合。只有叶子节点真正干活。

适用之处

组织结构清晰映射。 如果真实任务本身就是按部门切分的（「法务审这份文档，财务审这份文档，工程审这份文档，再向管理层汇总」），层级结构就是显式的。
局部汇总。 每个子管理者先综合本团队的输出，顶层管理者看到的才是结果。顶层管理者看到的是 3 份子管理者摘要，而不是 15 份工作者输出。

失效之处

2026 年的复盘分析反复发现三类失效模式：

任务分派错误。 管理者读了目标，幻觉出一个分解方案，然后把任务交给错误的子管理者。由于子管理者会顺从地处理收到的内容，这个错误只会在顶层综合时才暴露——距离人本可以拦下它的位置已经隔了一层。
输出误读。 子管理者返回「无法核实断言 X」。顶层管理者却总结成「断言 X 未被确认」。含义在每一层都发生漂移。
共识循环。 两个子管理者意见相左；顶层管理者要求它们协调；它们把任务重新下派；工作者重新执行；子管理者返回略有差异的答案；如此循环。CrewAI 的 Process.hierarchical 用步数上限来防止这种情况，但这个上限本身又成了一个超参数。

决定性问题

顺序流程（线性 pipeline）对层级架构：你的任务里真的存在彼此独立的子团队，还是只是一条线性流程伪装成树？如果是后者，用顺序流程。如果是前者，可以用层级架构，但要为协调规则预留明确的预算。

角色框架中的实现

CrewAI 的 Process.hierarchical 在专家 crew 之上接入一个管理者 LLM。管理者会：

接收顶层任务，
把子任务分配给各个 crew，
评估 crew 的输出，
决定是接受、重新分派，还是继续迭代。

文档：https://docs.crewai.com/en/introduction（在 Core Concepts 下找 "Hierarchical Process"）。

图框架中的实现

LangGraph 使用嵌套的 create_supervisor 调用。内层监督员拥有自己的图；外层监督员把内层图当作一个不透明的节点。调试时这比 CrewAI 更干净（你可以分别单步跟踪每个图），但表达树的动态重塑更困难。

参考：https://reference.langchain.com/python/langgraph-supervisor。

swarm-hierarchy-token静态版本未包含此交互图

构建它

code/main.py 运行一个 3 级层级架构：

顶层管理者：把任务拆成「工程」和「法务」两个分支，
工程子管理者：再拆成「前端」和「后端」两个工作者，
法务子管理者：只有一个工作者。

演示对比两条路径：一条是顺利路径（所有人意见一致），另一条是扰动路径——顶层管理者在分解时把「法务」错标成「财务」，然后观察错误如何级联：子管理者忠实地做了财务工作，顶层综合者汇报了财务结论，原本的法务问题无人回答。

运行：

python3 code/main.py

输出会并列展示两条路径，清楚对照「问的是什么」与「交付了什么」。

使用它

outputs/skill-hierarchy-fitness.md 评估一个给定任务应该采用层级架构、顺序流程，还是扁平监督员。输入包括：任务描述、组织结构、协调预算。输出是模式建议，并列出需要重点防范的具体失效模式。

交付它

如果你要交付层级架构：

树深度上限设为 2。 三层就已经把大多数错误挡在可观测性之外了。
显式的协调预算。 设定顶层管理者必须作出决定前的最大轮数，通常是 2 轮。
每次综合都标注来源。 每个节点的摘要都必须注明它由哪些叶子节点的输出产生。
对分解漂移告警。 逐步记录管理者的分解结果，并与用户查询做比对。如果分解已不再覆盖该查询，就触发告警。

练习

运行 code/main.py，比较顺利路径与扰动路径。经过多少层管理者转手之后，顶层输出才完全偏离用户的问题？
增加第三级（顶层 → 子级 → 子子级 → 工作者）。测量随着深度增加，扰动路径自我纠正与完全偏离各占多大比例。
在每个子管理者下实现一个「金丝雀」工作者，始终向它原样提出用户的原始问题。用金丝雀的回答来检测分解漂移。当金丝雀的答案与综合答案不一致时，管理者应如何反应？
阅读 CrewAI 的 Process.hierarchical 文档。找出 CrewAI 实际采用的一项具体防护措施（步数上限、manager_llm 约束等），并说明它针对的是哪种失效模式。
对比嵌套的 LangGraph 监督员与 CrewAI 的层级流程。哪一种让协调循环的检测成本更低？

关键术语

术语	常见说法	实际含义
层级架构（Hierarchical）	「组织架构图模式」	监督员之上再有监督员；只有叶子节点真正干活。
管理者 LLM（Manager LLM）	「老板」	在内部节点上负责分解、分派与校验的 LLM。
分解漂移（Decomposition drift）	「老板跑题了」	顶层管理者的拆分不再覆盖原始问题。
协调循环（Reconciliation loop）	「开不完的会」	子管理者意见相左；顶层重新下派；工作者重跑；如此循环直到预算耗尽。
深度 2 上限（Depth-2 ceiling）	「别超过两层」	经验性防护线：3 层及以上会让可观测性崩塌。
金丝雀问题（Canary question）	「每一层的真值锚点」	始终原样收到原始查询的工作者，用于检测漂移。
来源链（Provenance chain）	「谁说了什么」	从每份综合结果回溯到产生它的叶子输出的追踪链。

示意图共 1 张

hierarchy-drift diagram — hierarchy-drift

问题

概念