章节主旨
本章审视当前各种「多 agent 组织架构」尝试(CEO/销售/客服式的仿公司层级),指出它们普遍层级过深、收益不明;并给出作者眼中真正有效的两种精简委派模式:Parent-Researcher-QA 与 Developer-QA。
核心论点
- 仿公司式的多 agent org chart 现在基本都不好用——层级越深、直接下属越多,协作质量越差。(→ 详解1)
- Skills 与 Subagents 本质是同一种东西——都是带名称/描述/允许工具/SOP 的 markdown,只是组织信息的不同方式。(→ 详解2)
- 真正有价值的委派只有两种精简模式:Parent-Researcher-QA(带 fan-out)与 Developer-QA(最简双人循环)。(→ 详解3、4)
- 每次委派都有代价:固定的启动时间成本,加上无人在环时逐级放大的发散概率与质量稀释。(→ 详解5)
知识点详解
1. 组织层级的现状:层级越深越糟 1:24:23
作者列举了当下一批多 agent 编排项目:仿公司的 CEO / 销售 / 客服架构、号称 26 个专职 agent 覆盖架构到运维、市长(协调者)带 crew 和 worker 的分工、以及 crew AI、swarmclaw 这类把 agent 分成隔离工具集小队再层层委派的框架。
作者的判断很直接:这些不同团队对「最佳 agent 组织层级」的探索,眼下基本都还很烂。核心问题是层级堆得太多——不需要 700 层的 CEO、客户成功、首席工程师 agent。
他给出的反问是:这些角色其实都可以是同一个更聪明的 Opus,从一个共享 context pool 取信息,反而不会漏掉多少东西。层级化本身不创造价值。
2. Skills 与 Subagents 本质相同 1:24:40
作者提醒:不要被这些架构名词唬住,它们都只是「组织信息的不同方式」。Skill 是高度贴合你个人的一组 markdown 文件,含名称、描述、允许工具、以及 SOP。
Subagent 本质上是完全一样的东西——同样的构成、同样的角色。随着领域成熟、context 管理策略变多,这些 多 Agent 编排器 会越来越分化,但底层仍是同一类抽象。
看清这一点,就不会为花哨的 org chart 付出不必要的复杂度。
3. 设计模式一:Parent-Researcher-QA 1:24:58
第一种有价值的模式:一个聪明的 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
想更精简就用第二种:只有一个聪明的 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
每次 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(复合概率,多步无人独立执行时发散概率相乘放大)
自检问题
- 为什么 Parent-Researcher-QA 里 parent 不亲自做检索,而是派给 sonnet subagent? 答案:亲自查会把海量 token 塞进 parent 自己的 context window 造成污染;fan-out 到廉价的 sonnet、只回收摘要,既省成本又保住 parent 的 context 用于决策。见详解3 1:24:58
- Developer-QA 模式中,为什么 QA agent 要每次全新 spawn、且几乎不给 prompt? 答案:让它不知道项目是什么,从而不带 parent 在功能开发中形成的偏见,做出中立质检;parent 则保留反馈与历史尝试用于收敛。见详解4 1:27:01
- 作者反对深层级 org chart 的量化理由是什么? 答案:每次委派有固定时间成本,更关键是无人在环的独立步骤越多、发散概率复合相乘越大,链条离人越远质量被稀释越多。见详解5 1:28:26