---
title: '09 随机共识与辩论'
video_id: UPtmKh1vMN8
part: 9
---

> 章节 9 / 29 · [[00-总览|课程总览]] · 起始 [42:07](https://youtu.be/UPtmKh1vMN8?t=2527)


> [!warning] 标题与实际内容有偏差
> 
> 本章标题为「随机共识与辩论」,但 debate / stochastic consensus 的具体机制在本章只是**预告**(作者说"接下来会专门演示")。本章真正讲透的是**为什么要并行化**(随机性只是四个理由之一)以及 fan-out/fan-in 研究-综合模式。按真实内容记录。

## 章节主旨

讲清为什么要把 agent 工作并行化(省时、提质、绕开上下文退化、利用随机性),并给出最常用的落地模式:fan-out/fan-in 研究-综合,配合按步骤分散模型。

## 核心论点

1. **并行化的第一收益是省时**——autonomous agent 单任务可跑十几分钟,串行等待极不经济,拆成可并行的独立子步能把总时长压到约六成。([[#1-为什么并行化省时与提质-4302|→ 详解1]])
2. **agent 是随机的,多跑几次能采到"平均答案之外"的解**——同一 query 跑五次,结果会发散,合并去重后拿到约 2.5 倍的唯一答案。([[#2-随机性多跑几次采到平均之外的答案-4550|→ 详解2]])
3. **模型质量随上下文增长而退化**,给每个 subagent 喂小块问题能让它们都待在"zone of good"。([[#3-上下文退化与-zone-of-good-4858|→ 详解3]])
4. **fan-out/fan-in 是最通用的并行模式**:多个研究 agent 独立并行,再由一个 synthesizer 汇总;综合 agent 的 prompt 更短、可上更强推理。([[#4-fan-out--fan-in研究-综合模式-5013|→ 详解4]])
5. **按步骤分散模型**:研究这种耗 token 但不需重推理的活用便宜模型,综合用贵模型,兼顾质量与成本。([[#5-按步骤分散模型-5421|→ 详解5]])

## 知识点详解

### 1. 为什么并行化:省时与提质 [43:02](https://youtu.be/UPtmKh1vMN8?t=2582)

**是什么**:并行化就是同时做多件事,而不是等一件做完再做下一件。作者的动机很直接——去年 Claude 一次只能干 30 秒,现在能连续干 15 分钟以上,如果只是坐着等,产出就被"等待-取结果-微调-再等"打成碎片。

**为什么**:很多任务本身含**可拆的独立步骤**。串行做 step 1→2→3→4 各 5 分钟共 20 分钟;若把 2、3、4 三步并行(各 5 分钟)、末尾加一个 2 分钟的整合步,总时长降到 12 分钟,约为原来的 60%。

**怎么用**:识别任务里彼此不依赖的子步,把它们叠起来同时跑,再加一个 synthesizer 步骤(下面详解4)把结果并回来。不能拆的强依赖链条不适用。

### 2. 随机性:多跑几次采到"平均之外"的答案 [45:50](https://youtu.be/UPtmKh1vMN8?t=2750)

**是什么**:LLM 是随机的——同一 prompt 跑五次,每次结果都略有不同。作者现场开三个 Claude Code tab 跑同一句"找出五处可改进",三次给出的问题清单只有开头重合、越往后越发散。

**为什么**:模型逐 token 相乘统计概率,开头处于"相似区"(zone of similarity),但因为这种**乘性发散**,末尾差异被放大——一次可能只到 ABC,另一次到 D、E,甚至冒出 Q、Zed。

**怎么用**:并行跑多次同/近似 query,再把所有唯一输出**合并去重**,等于采样到平均单次跑不会给你的"分布外"解——作者称约能拿到 [2.5 倍](https://youtu.be/UPtmKh1vMN8?t=2899)的唯一答案。这正是后续 [debate / stochastic consensus](https://youtu.be/UPtmKh1vMN8?t=2924) 的底层原理(本章只预告,未展开)。

### 3. 上下文退化与 zone of good [48:58](https://youtu.be/UPtmKh1vMN8?t=2938)

**是什么**:模型表现随上下文长度增长而下降。上下文越短越干净,结果通常越好。作者把"上下文适中、表现最佳"的那一段戏称为 zone of good(他自嘲这名字是现编的)。

**为什么与怎么用**:串行让一个主 agent 累积超长上下文,会一路滑出 zone of good;而并行把问题切成小块喂给一批新 Subagent,每个新 agent 上下文都短,几乎都待在 zone of good。不是一个 agent 干所有活,而是每个都在最佳区工作。

### 4. Fan-out / Fan-in:研究-综合模式 [50:13](https://youtu.be/UPtmKh1vMN8?t=3013)

**是什么**:Fan-out Fan-in是最通用的团队模式。fan-out = 主 agent 一次性 spawn 若干独立研究 subagent(如找最佳 API,派 4 个各查不同来源);fan-in = 把它们的输出全部喂给一个 synthesizer agent 汇总。

**为什么**:串行逐站调研会一路累积上下文(质量下滑)且时间线性叠加(4 站+综合 = 25 分钟)。fan-out 让各 agent 独立并行、上下文都短且在 zone of good;fan-in 时 synthesizer 的 [prompt 更短](https://youtu.be/UPtmKh1vMN8?t=3195)("这里是别人已做好的调研,请整合"),可加载高阶推理策略——总时长压到约 10 分钟且质量更高。

**怎么用**:给 synthesizer 明确指令,如"整合重叠项、保留离群项、再做差异化打分"。综合步能和研究几乎同时长完成,因为研究 subagent 数量可近乎无限扩。作者强调这不限于代码——商业系统设计、定价打包、竞品调研都能套。

### 5. 按步骤分散模型 [54:21](https://youtu.be/UPtmKh1vMN8?t=3261)

**是什么**:模型分散指在流水线不同步骤用不同档位的模型。研究阶段耗 token 但主要是数据抽取、不需重推理,用便宜的 Haiku/Sonnet;综合阶段需要强推理,用 Opus。

**为什么**:一是快——Sonnet 比 Opus 跑得快,研究步可能从 5 分钟降到 3 分钟;二是省钱——按作者举的价(Opus 每百万输入 token $5、Sonnet $3)光输入就省约 60%,输出 token 差距更大,越往 Haiku 走越省。

**怎么用**:落成一句 prompt 即可,如"用 fan-out/fan-in 研究-综合法调研如何优化本代码库,最少 5 个 subagent,Sonnet 做研究与独立思考,Opus 做综合";也可固化成 skill。作者现场跑出 6 个 Sonnet agent 并行、Opus 汇总,呼应 Anthropic "Opus + 一批 Sonnet subagent" 在时间与质量上都显著优于单 Opus 的结论。

## 术语

- parallelization(并行化,同时做多件独立子任务而非串行等待)
- stochasticity(随机性,LLM 同一输入多次输出会发散的特性)
- zone of good(作者自造词,上下文适中、模型表现最佳的区间)
- fan-out / fan-in(先并行 spawn 多个 agent、再汇总到一个 synthesizer 的模式)
- synthesizer(综合 agent,负责把多个子 agent 输出整合成最终答案)
- agent teams(Claude Code 内置的并行协作功能,本章只提及未展开)

## 自检问题

1. 为什么"多跑几次同一个 query 再合并"能拿到更好的答案集?
   **答案**:因为 LLM 是随机的(逐 token 相乘发散),单次只采到平均分布内的一条路径;并行多跑再去重能采到分布外的解,作者称约 2.5 倍唯一答案。见详解2。[48:19](https://youtu.be/UPtmKh1vMN8?t=2899)
2. fan-in 阶段 synthesizer 的 prompt 为什么可以更短、还能上更强推理?
   **答案**:因为研究已由 subagent 做完,synthesizer 的任务从"去调研"变成"整合已有 context",prompt 变短,省下的空间可加载高阶推理策略。见详解4。[53:15](https://youtu.be/UPtmKh1vMN8?t=3195)
3. 为什么研究步用 Sonnet/Haiku、综合步才用 Opus?
   **答案**:研究耗 token 但主要是数据抽取、不需重推理,用便宜模型又快又省(输入省约 60%);综合需要强推理才用 Opus。见详解5。[54:21](https://youtu.be/UPtmKh1vMN8?t=3261)
4. 并行化如何同时改善"速度"和"质量"两件事?
   **答案**:速度上把串行叠加压成并行(20 分钟→12 分钟);质量上每个新 subagent 上下文短、都待在 zone of good,避免单 agent 长上下文导致的退化。见详解1、详解3。[48:58](https://youtu.be/UPtmKh1vMN8?t=2938)