层级架构及其失败模式

层级架构及其失败模式

本节摘要:层级架构就是监督者嵌套——经理 Agent 之上还有子经理,子经理之上还有工人。CrewAI 的 Process.hierarchical 是教科书版:一个 manager_llm 动态委派任务并校验输出;LangGraph 的对应物是 create_supervisor(create_supervisor(...))。当任务真的是一张组织架构图时,这是最自然的模式;但它也是最容易坍塌进管理循环的模式——经理派活不当、误读子输出、无法达成共识。本节搭出一个三级层级,对比「happy path」与「扰动 path」(顶层把「legal」错标成「finance」),让你亲眼看到错误如何沿树级联,最后给出工程护栏:树深封顶 2、显式和解预算、每层加金丝雀问题、每个综合带溯源。多数时候,顺序流水线反而胜过层级。

学习目标

阅读完本节,你应当能够:

1. 说清层级架构的形状(监督者嵌套,只有叶子做实际工作)与它的两类适用场景。
2. 识别 2026 事后分析反复发现的三类失败(任务分配错误、输出误读、共识循环)。
3. 用 Python 从零实现一个三级层级,并演示错误级联。
4. 应用工程护栏:树深封顶 2、显式和解预算、金丝雀问题、综合溯源、分解漂移告警。
5. 判断任务该用层级、顺序流水线还是扁平监督者。

一、问题与直觉

监督者模式一旦想通,自然的下一步是「要是工人自己也是监督者呢?」团队有子团队,公司有部门的部门。层级架构镜像这种结构。

问题在于:LLM 经理不是人类经理。人类经理对下属「知道什么」有稳定的先验;LLM 经理每一轮都从上下文里重新推理整个组织。上下文一丝漂移,整棵树就把活派错。

每个内部节点规划、派发、综合;只有叶子做工作。

哪里出彩

• 清晰的组织映射:若真实任务就是部门化的(「法务审文档、财务审文档、工程审文档,再汇总给高管」),层级显式直接。
• 局部摘要:每个子经理先综合自己团队的输出,顶层经理只看三个子经理摘要,而非十五个工人输出。

哪里崩坏:三类失败

2026 的事后分析反复发现这三类:

1. 任务分配错误:经理读目标,幻觉出一个分解,派给错误的子经理。子经理乖乖做被派的事,错误只在顶层综合时浮现——离人类本可拦截之处已隔了一层。
2. 输出误读:子经理返回「无法验证声明 X」,顶层综合成「声明 X 未被确认」。含义在每一层漂移。
3. 共识循环:两个子经理分歧;顶层让他们和解;他们重新向下派;工人重跑;子经理返回略不同的答案;循环。CrewAI 的 Process.hierarchical 用步数上限防这个,但上限本身又成了超参。

⚠️ 这正是「协调难点在协调而非多」的集中体现——Agent 不多,但层级越多,信息逐级有损,错误的发现点离源头越远。每一层综合都是一次有损压缩,语义漂移累积。

决定性的一问

顺序(线性流水线)vs 层级:你的任务真的有独立子团队,还是只是一条伪装成树的线性流?若是后者,用顺序;若是前者,用层级但预算显式的和解规则。

框架落地

• CrewAI Process.hierarchical:在专职 crew 之上挂一个 manager LLM,接收顶层任务、派子任务、评 crew 输出、决定接受/重派/迭代。
• LangGraph 嵌套 create_supervisor:内层 supervisor 有自己的图,外层把内层图当不透明节点。比 CrewAI 更易调试(可分别单步每张图),但更难表达树的动态重塑。

二、从零实现

code/main.py 跑一个三级层级:顶层经理把任务拆成「engineering」与「legal」两支;engineering 子经理再拆成「frontend」「backend」工人;legal 子经理带一个工人。

骨架

class Manager:
    def __init__(self, name, children, decompose_fn, synthesize_fn):
        self.name = name; self.children = children
        self.decompose = decompose_fn; self.synthesize = synthesize_fn
    def run(self, task):
        subtasks = self.decompose(task)         # 经理分解(可能幻觉)
        outputs = {label: child.run(sub) for label, (child, sub) in subtasks.items()}
        return self.synthesize(outputs)        # 综合可能误读

class Worker:
    def __init__(self, name, policy): self.name = name; self.policy = policy
    def run(self, sub): return self.policy(sub)
​

扰动路径:看错误级联

def perturbed_decompose(task):
    # 顶层把 "legal" 错标成 "finance" —— 分解漂移
    return {
        "engineering": (eng_sub_mgr, task + " · engineering"),
        "finance":     (legal_sub_mgr, task.replace("legal", "finance")),
    }
​

扰动路径下:legal 子经理乖乖做 finance 工作,顶层综合报告 finance 发现,原 legal 问题无人回答。错误在顶层综合时才暴露,离源头(顶层分解)已隔了一层。

设计要点:子经理的「服从性」是层级的双刃剑——它让分工干净,却让错误能无声穿透多层。这正是为什么需要金丝雀问题:在每个子经理处放一个总是被问原问题的工人,用它检测分解漂移。

金丝雀检测漂移

def run_with_canary(manager, task):
    result = manager.run(task)
    canary = task                       # 原问题不动
    canary_answer = canary_worker.run(canary)
    if contradicts(result, canary_answer):
        alert("分解漂移:综合与原问题答案矛盾")
    return result
​

三、框架对比

💡 Anthropic 在研究系统里故意选扁平监督者而非层级,正是因为层级的错误发现点离源头太远。层级是「任务真像组织架构图」时的选择,不是默认。

四、可复用产物

outputs/skill-hierarchy-fitness.md:评估给定任务该用层级、顺序还是扁平监督者。输入:任务描述、组织结构、和解预算。输出:模式推荐 + 需防范的具体失败模式。

五、练习

1. 观察级联:跑 code/main.py 对比 happy 与扰动路径。从顶层输出完全偏离用户问题,要经过几层经理交接?
2. 加深层级:加第三层(顶层→子→子子→工人)。测量扰动路径随深度增长,自我纠正 vs 完全偏离的频率。
3. 金丝雀:在每个子经理处加一个总被问原问题的金丝雀工人,用它检测分解漂移。金丝雀与综合答案矛盾时,经理该如何反应?
4. 读 CrewAI 文档:识别 CrewAI Process.hierarchical 的一条具体护栏(步数上限、manager_llm 约束),描述它针对哪个失败模式。
5. 嵌套对比:对比嵌套 LangGraph supervisor 与 CrewAI 层级,哪个让共识循环更易检测?

本节要点回顾

1. 层级 = 监督者嵌套:经理之上还有经理,只有叶子做工作;每个内部节点规划、派发、综合。
2. LLM 经理不是人类经理:它每轮从上下文重推理组织,上下文一丝漂移,整棵树派错活。
3. 三类失败:任务分配错误(幻觉分解派错人)、输出误读(语义逐层漂移)、共识循环(子经理分歧→重派→重跑→循环)。
4. 信息逐级有损:每层综合都是有损压缩,错误发现点离源头越来越远——这是层级最难的问题。
5. 决定性一问:任务真有独立子团队用层级,否则用顺序;前者必须预算显式和解规则。
6. 工程护栏:树深封顶 2(3 层就藏掉大部分可观测性)、显式和解预算(通常 2 轮)、每个综合带溯源、分解漂移告警。
7. 金丝雀问题:每个子经理处放一个总被问原问题的工人,检测分解漂移。
8. 多数时候顺序胜过层级:Anthropic 研究系统故意选扁平监督者;层级是「任务真像组织架构图」时的选择,不是默认。

下一节,我们换一个角度——心智社会(Society of Mind)与多智能体辩论,看多个 Agent 如何通过对抗性争论而非层级派发来逼近更可靠的答案。