标题与实际内容有偏差
本章标题为「随机共识与辩论」,但 debate / stochastic consensus 的具体机制在本章只是预告(作者说”接下来会专门演示”)。本章真正讲透的是为什么要并行化(随机性只是四个理由之一)以及 fan-out/fan-in 研究-综合模式。按真实内容记录。
章节主旨
讲清为什么要把 agent 工作并行化(省时、提质、绕开上下文退化、利用随机性),并给出最常用的落地模式:fan-out/fan-in 研究-综合,配合按步骤分散模型。
核心论点
- 并行化的第一收益是省时——autonomous agent 单任务可跑十几分钟,串行等待极不经济,拆成可并行的独立子步能把总时长压到约六成。(→ 详解1)
- agent 是随机的,多跑几次能采到”平均答案之外”的解——同一 query 跑五次,结果会发散,合并去重后拿到约 2.5 倍的唯一答案。(→ 详解2)
- 模型质量随上下文增长而退化,给每个 subagent 喂小块问题能让它们都待在”zone of good”。(→ 详解3)
- fan-out/fan-in 是最通用的并行模式:多个研究 agent 独立并行,再由一个 synthesizer 汇总;综合 agent 的 prompt 更短、可上更强推理。(→ 详解4)
- 按步骤分散模型:研究这种耗 token 但不需重推理的活用便宜模型,综合用贵模型,兼顾质量与成本。(→ 详解5)
知识点详解
1. 为什么并行化:省时与提质 43:02
是什么:并行化就是同时做多件事,而不是等一件做完再做下一件。作者的动机很直接——去年 Claude 一次只能干 30 秒,现在能连续干 15 分钟以上,如果只是坐着等,产出就被”等待-取结果-微调-再等”打成碎片。
为什么:很多任务本身含可拆的独立步骤。串行做 step 1→2→3→4 各 5 分钟共 20 分钟;若把 2、3、4 三步并行(各 5 分钟)、末尾加一个 2 分钟的整合步,总时长降到 12 分钟,约为原来的 60%。
怎么用:识别任务里彼此不依赖的子步,把它们叠起来同时跑,再加一个 synthesizer 步骤(下面详解4)把结果并回来。不能拆的强依赖链条不适用。
2. 随机性:多跑几次采到”平均之外”的答案 45:50
是什么:LLM 是随机的——同一 prompt 跑五次,每次结果都略有不同。作者现场开三个 Claude Code tab 跑同一句”找出五处可改进”,三次给出的问题清单只有开头重合、越往后越发散。
为什么:模型逐 token 相乘统计概率,开头处于”相似区”(zone of similarity),但因为这种乘性发散,末尾差异被放大——一次可能只到 ABC,另一次到 D、E,甚至冒出 Q、Zed。
怎么用:并行跑多次同/近似 query,再把所有唯一输出合并去重,等于采样到平均单次跑不会给你的”分布外”解——作者称约能拿到 2.5 倍的唯一答案。这正是后续 debate / stochastic consensus 的底层原理(本章只预告,未展开)。
3. 上下文退化与 zone of good 48:58
是什么:模型表现随上下文长度增长而下降。上下文越短越干净,结果通常越好。作者把”上下文适中、表现最佳”的那一段戏称为 zone of good(他自嘲这名字是现编的)。
为什么与怎么用:串行让一个主 agent 累积超长上下文,会一路滑出 zone of good;而并行把问题切成小块喂给一批新 Subagent,每个新 agent 上下文都短,几乎都待在 zone of good。不是一个 agent 干所有活,而是每个都在最佳区工作。
4. Fan-out / Fan-in:研究-综合模式 50:13
是什么: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 更短(“这里是别人已做好的调研,请整合”),可加载高阶推理策略——总时长压到约 10 分钟且质量更高。
怎么用:给 synthesizer 明确指令,如”整合重叠项、保留离群项、再做差异化打分”。综合步能和研究几乎同时长完成,因为研究 subagent 数量可近乎无限扩。作者强调这不限于代码——商业系统设计、定价打包、竞品调研都能套。
5. 按步骤分散模型 54:21
是什么:模型分散指在流水线不同步骤用不同档位的模型。研究阶段耗 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 内置的并行协作功能,本章只提及未展开)
自检问题
- 为什么”多跑几次同一个 query 再合并”能拿到更好的答案集? 答案:因为 LLM 是随机的(逐 token 相乘发散),单次只采到平均分布内的一条路径;并行多跑再去重能采到分布外的解,作者称约 2.5 倍唯一答案。见详解2。48:19
- fan-in 阶段 synthesizer 的 prompt 为什么可以更短、还能上更强推理? 答案:因为研究已由 subagent 做完,synthesizer 的任务从”去调研”变成”整合已有 context”,prompt 变短,省下的空间可加载高阶推理策略。见详解4。53:15
- 为什么研究步用 Sonnet/Haiku、综合步才用 Opus? 答案:研究耗 token 但主要是数据抽取、不需重推理,用便宜模型又快又省(输入省约 60%);综合需要强推理才用 Opus。见详解5。54:21
- 并行化如何同时改善”速度”和”质量”两件事? 答案:速度上把串行叠加压成并行(20 分钟→12 分钟);质量上每个新 subagent 上下文短、都待在 zone of good,避免单 agent 长上下文导致的退化。见详解1、详解3。48:58