---
title: '17 AI 中的组织层级'
video_id: UPtmKh1vMN8
part: 17
---

> 章节 17 / 29 · [[00-总览|课程总览]] · 起始 [1:22:58](https://youtu.be/UPtmKh1vMN8?t=4978)


## 章节主旨

本章审视当前各种「多 agent 组织架构」尝试(CEO/销售/客服式的仿公司层级),指出它们普遍层级过深、收益不明;并给出作者眼中真正有效的两种精简委派模式:Parent-Researcher-QA 与 Developer-QA。

## 核心论点

1. **仿公司式的多 agent org chart 现在基本都不好用**——层级越深、直接下属越多,协作质量越差。([[#1-组织层级的现状层级越深越糟-12423|→ 详解1]])
2. **Skills 与 Subagents 本质是同一种东西**——都是带名称/描述/允许工具/SOP 的 markdown,只是组织信息的不同方式。([[#2-skills-与-subagents-本质相同-12440|→ 详解2]])
3. **真正有价值的委派只有两种精简模式**:Parent-Researcher-QA(带 fan-out)与 Developer-QA(最简双人循环)。(→ 详解3、4)
4. **每次委派都有代价**:固定的启动时间成本,加上无人在环时逐级放大的发散概率与质量稀释。([[#5-委派的代价时间成本与逐级稀释-12826|→ 详解5]])

## 知识点详解

### 1. 组织层级的现状:层级越深越糟 [1:24:23](https://youtu.be/UPtmKh1vMN8?t=5063)

作者列举了当下一批多 agent 编排项目:仿公司的 CEO / 销售 / 客服架构、号称 26 个专职 agent 覆盖架构到运维、市长(协调者)带 crew 和 worker 的分工、以及 crew AI、swarmclaw 这类把 agent 分成隔离工具集小队再层层委派的框架。

作者的判断很直接:这些不同团队对「最佳 agent 组织层级」的探索,眼下基本都还很烂。核心问题是层级堆得太多——不需要 700 层的 CEO、客户成功、首席工程师 agent。

他给出的反问是:这些角色其实都可以是同一个更聪明的 Opus,从一个共享 context pool 取信息,反而不会漏掉多少东西。层级化本身不创造价值。

### 2. Skills 与 Subagents 本质相同 [1:24:40](https://youtu.be/UPtmKh1vMN8?t=5080)

作者提醒:不要被这些架构名词唬住,它们都只是「组织信息的不同方式」。Skill 是高度贴合你个人的一组 markdown 文件,含名称、描述、允许工具、以及 SOP。

Subagent 本质上是完全一样的东西——同样的构成、同样的角色。随着领域成熟、context 管理策略变多,这些 多 Agent 编排器 会越来越分化,但底层仍是同一类抽象。

看清这一点,就不会为花哨的 org chart 付出不必要的复杂度。

### 3. 设计模式一:Parent-Researcher-QA [1:24:58](https://youtu.be/UPtmKh1vMN8?t=5098)

第一种有价值的模式:一个聪明的 parent(通常是 Opus)作为 orchestrator——任何处在顶端的都可视为 orchestrator——它同时管理复数的 researcher 和若干 QA agent。

researcher 用更便宜、更擅长检索的 Sonnet:这利用了 Fan-out 思路。当 parent 需要资料时,它不亲自去查(那会污染自己的 context window),而是把海量 token 塞进 sonnet 的 context,只取回摘要用于决策。

QA 用 Opus,专调做质检。运行逻辑是一个循环:Opus 决策并委派 → 拿回信息自己构建 → 把成品交给 QA → QA 返回修改建议 → Opus 改完再交 → 如此往复直到完成。

这是在「臃肿 org chart」与「充分发挥各类 agent 天生所长」之间的良好平衡。可以再加测试、设计、前后端 agent,但通常越复杂越糟。

### 4. 设计模式二:Developer-QA(最精简) [1:27:01](https://youtu.be/UPtmKh1vMN8?t=5221)

想更精简就用第二种:只有一个聪明的 parent(developer)和一个聪明的 QA,两者来回循环。关键靠 CLAUDE.md 或 system prompt 里烘焙一句指令:每次开发完成后,交给一个新的 QA agent 检查。

精髓在于这个 QA 每次都是全新 spawn、几乎无 prompt——只被告知「你是 QA,没有上下文,读这段代码并套用如下设计原则」。正因为它不知道项目是什么,就不会像 parent 那样在功能开发中带有偏见。

parent 则相反:它保留 QA 的反馈、累积了此前所有失败与成功的尝试清单。于是形成「parent 开发 → QA 给反馈 → parent 改 → …… → QA 无反馈 = 通过」的收敛过程。

作者认为这种更简单,但因为 parent 要自己做研究,他个人觉得不如模式一理想。

### 5. 委派的代价:时间成本与逐级稀释 [1:28:26](https://youtu.be/UPtmKh1vMN8?t=5306)

每次 spawn 一个 subagent 都有固定的时间成本。更隐蔽的是复合概率:agent 委派给 agent、中间没有 Human-in-the-loop,无人在环的独立步骤越多,偏离预定目标的概率越高。

具体说,当 parent 生成一堆研究 query 派给 sonnet subagent,并不能保证这些 subagent 的研究 100% 忠于最初 query。链条上每一步离你越远,结果和质量就被稀释得越多。

这正是作者反对深层级 org chart 的量化理由:层级不是免费的,它在乘一串小于 1 的概率。

## 术语

- orchestrator(编排者,处在层级顶端、负责分派与汇总的 agent)
- fan-out(扇出,parent 把检索并行下发给多个廉价 subagent、只回收摘要)
- QA agent(质检 agent,每次新 spawn、无项目上下文以保持无偏见)
- human-in-the-loop(人在环,委派链中保留人工介入的环节)
- compound probability(复合概率,多步无人独立执行时发散概率相乘放大)

## 自检问题

1. 为什么 Parent-Researcher-QA 里 parent 不亲自做检索,而是派给 sonnet subagent?
   **答案**:亲自查会把海量 token 塞进 parent 自己的 context window 造成污染;fan-out 到廉价的 sonnet、只回收摘要,既省成本又保住 parent 的 context 用于决策。见详解3 [1:24:58](https://youtu.be/UPtmKh1vMN8?t=5098)
2. Developer-QA 模式中,为什么 QA agent 要每次全新 spawn、且几乎不给 prompt?
   **答案**:让它不知道项目是什么,从而不带 parent 在功能开发中形成的偏见,做出中立质检;parent 则保留反馈与历史尝试用于收敛。见详解4 [1:27:01](https://youtu.be/UPtmKh1vMN8?t=5221)
3. 作者反对深层级 org chart 的量化理由是什么?
   **答案**:每次委派有固定时间成本,更关键是无人在环的独立步骤越多、发散概率复合相乘越大,链条离人越远质量被稀释越多。见详解5 [1:28:26](https://youtu.be/UPtmKh1vMN8?t=5306)