Part B · 横切深挖 · B05

Why not multi-agent?为什么不 multi-agent

口述 2 min 追问 6 层 适合 垂直 Agent 研发, FDE, Solutions
Prompt 题面

先想清楚再开口

你讲完深度研究 Agent：6 个子问题并行，每个交给一个上下文隔离的子 Agent。面试官说：「团队里有人坚持单 Agent 就够了。你说并行版更好——拿什么证明？实验怎么设计才算公平？」

题面为本书自拟的训练题，不代表任何公司的真实面试题或真实系统。

约束

约束取值（练习设定）
两个方案方案 S：单 Agent 循环，自己拆子问题、检索、写报告；方案 M：代码定 6 个子问题的大纲，6 个子 Agent 并行检索，最后一个综合步骤合并
任务来源过去半年分析师实际提过的研究问题，约 600 个；其中一部分有分析师写过的参考报告
判定「成功」= 报告通过核查：关键事实有可核查引用、没有漏掉分析师列出的必答要点；部分要点可自动核对，其余靠评委
资源同一个模型、同一套检索与抓取工具；公开网页会随时间变化
预算实验总花费需要事先申请，希望控制在一个月的研究预算之内
决策方研究负责人要一个明确结论：上并行版、留单 Agent，还是按任务类型分开用
答到一半再点开：面试官补了一句

「结果出来了：并行版成功率高 8 个百分点，墙钟时间少一半，但总 token 是单 Agent 的 2.5 倍。负责人问你：该不该上？」

Answer 参考回答

先口答，再展开

展开参考回答

该先问的问题

  1. 「更好」指什么：成功率、墙钟时间、成本，还是三者的某种组合？负责人最在意哪个？这决定主指标和判定规则，必须在跑实验之前写下来。
  2. 任务集能代表真实流量吗？有没有按任务类型（单一事实查询 / 多来源综述 / 需要追查的调查）分层？这决定结论能推广到哪里。
  3. 「成功」由谁判、看不看得出是哪个方案产出的？这决定评分会不会偏向某种风格的报告。
  4. 两个方案的预算怎么对齐：给同样的 token 上限，还是各自跑到收敛再比成本？这决定比的是架构还是钱。
  5. 线上网页会变，两个方案是同时跑还是先后跑？有没有网页快照？这决定外部环境是否一致。

一句话框架

只在子任务真能独立、结果能合并时才试 multi-agent；证明它更好要用同一批任务、同样的模型和工具、同口径的预算做配对对照，以任务为单位算统计，把质量、时延、成本分开报。

设计取舍表

对照要素采用否决的备选什么证据会让我改
任务集跑实验前就固定：从真实问题里按任务类型分层抽样，写下纳入规则，不在看到结果后增删任务挑几个「适合并行」的演示题；或者看完结果再剔除「异常任务」某一类任务在真实流量里占比变化很大时，重新分层抽样，旧结论只对旧分布成立
预算口径两个方案都按同口径记总 token：输入、输出、缓存读写分别记；另跑一组「给单 Agent 同样多预算」的对照只比默认配置，或者只数输入 token在多个预算水平上画出「预算–成功率」曲线后，如果两条曲线交叉，就按预算区间分别下结论
模型、工具、提示同一模型版本、同一工具集、同样的停止条件；两个方案投入同样多的提示调优（都调或都不调）给新方案精调提示，旧方案用原样不改；调优投入不对等时，结论比的是调参功夫
外部环境两个方案同时跑，或者都读同一份网页快照；抓取失败率分方案统计先跑一个方案、隔几天再跑另一个快照无法覆盖任务所需网页时，至少同一时段交替运行，并报告两边的抓取失败率
评分能自动核对的要点用程序判；其余由评委盲评，只看报告和评分标准，看不到方案名；评分标准控制长度与引用数量的影响，评委先与人工标注校准让评委看出哪个是并行版；或者按「引用越多越好」打分评委与人工的一致率低于事先约定的阈值时，改为人工评分或缩小自动评分的范围
统计单位与判定以任务为单位配对比较。主分析事先指定：每个任务、每个方案只取一次预先指定的运行（例如第 1 次），得到一对成功 / 失败，用 McNemar 检验；另外 k − 1 次重复只用来报告稳定性（pass^k），不进主检验。判定规则、主指标、显著性水平事先写下把每次运行当独立样本；或者只比两个总体成功率的区间是否重叠；或者把重复运行既当成提升精度、又沿用单次二元结果的样本量公式试点显示单次运行波动很大、单次结果不足以代表方案时，主分析改用每个任务 k 次的成功比例，做配对任务 bootstrap 或用试点方差模拟功效，样本量重新算
报告内容成功率差（附区间）、墙钟时间、总 token、合并冲突率、每类任务分开报；另报「并行版赢、单 Agent 输」和反过来的任务各有哪些只报一个总成功率不改；负责人要的是「在哪类任务上、付多少钱、换多少质量」
Two-minute English 口述

两分钟，先结论后展开

展开 2 分钟英文口述稿

I'd only try multi-agent when the subtasks are genuinely independent and the results can be merged cleanly. And before I claim it's better, I'd run a fair comparison.

Fair means four things. Same tasks: a fixed set sampled from real questions, stratified by task type, chosen before I see any results. Same model, tools and prompt-tuning effort for both designs. Same budget accounting: input, output and cache tokens counted the same way, plus a run where the single agent gets the same budget as the multi-agent version, so I'm comparing architectures, not spending. And the same environment: both run at the same time or on the same web snapshot.

Grading is blind, and the rubric doesn't reward length or citation count.

The statistics are paired and task-level. Every task runs under both designs, and the unit is the task, not the run. The main test uses one pre-specified run per design; extra runs measure stability. What matters is the tasks where one design wins and the other loses.

Finally, I report quality, latency and cost separately, per task type. When subtasks can run in parallel and merging is cheap, multi-agent may finish sooner, but that has to be measured too. If it wins on quality only because it spent more tokens, that's a budget decision for the business.

Follow-ups 追问

一层一层往下问

  1. 为何不用备选为什么不直接拿公开基准的分数，或者直接上线做 A/B？
    先口答，再展开要点
    • 公开基准的任务分布和你的研究问题不同，也未必覆盖「追查」「来源冲突」这类任务；它能帮你筛掉明显不行的方案，但回答不了「在我们的问题上哪个更好」。
    • 线上 A/B 能量真实效果，但研究报告的质量要等分析师核查才知道，反馈慢、样本少；而且每份报告的成本是真实支出。先做离线配对对照，把明显的差异和成本算清楚，再用小流量线上实验确认。
    • 离线对照的代价是任务集可能不代表真实流量，所以要按任务类型分层，并在线上阶段检查分布是否一致。
  2. 需求变化负责人说：「预算只给单 Agent 的量，你的并行版还赢吗？」
    先口答，再展开要点
    • 这就是「等预算」对照：给并行版设同样的 token 上限（按同口径计），到上限就停并出报告，比成功率。
    • 更好的做法是在 3–4 个预算水平上都跑，画出两条「预算–成功率」曲线。如果并行版只在高预算时领先，结论是「钱多时用并行版」，不是「并行版更好」。
    • 同时报墙钟时间：子任务能并行、合并开销小时，同样预算下并行版可能仍然更快，但这也要实测；如果确实更快，单独算它值多少钱。
    • 注意：等预算的成功率要在这个配置下重新测，不能沿用默认配置下观察到的 70% 对 78%。
  3. 失败反证实验里并行版赢了，上线后反而更差。可能是哪里出了问题？
    先口答，再展开要点
    • 任务集不代表真实流量：实验里「多来源综述」占比高，线上大多是单一事实查询，拆成 6 个子 Agent 只是多花钱、多出冲突。按任务类型分层报告，才能事先看到这一点。
    • 外部环境不一致：实验时两个方案先后跑，网页变了；或者线上抓取被限流，并行版的并发请求更容易失败。
    • 评分有偏：评委偏爱更长、引用更多的报告，而并行版天然写得更长。要回头用人工盲评抽一批任务，核对评委的判断。
    • 调优不对等：新方案在实验前被反复调过提示，旧方案没有。
  4. 评分偏差你用 LLM 评委打分，怎么保证它不偏向并行版？
    先口答，再展开要点
    • 盲评：评委只看报告正文和评分标准，报告里去掉方案名、子 Agent 标记这类痕迹。
    • 评分标准按「必答要点是否覆盖、关键事实是否有可核查引用」给分，不按长度、引用数量给分；可以再加一组「长度相近」的配对样本，检查评委是否仍然偏向长的。
    • 先用一批人工标注校准评委，报告评委与人工的一致率；一致率不够时，这部分改由人工评。
  5. 统计你跑了 50 个任务：并行版赢 12 个、输 5 个，其余两边结果相同。能下结论吗？
    先口答，再展开要点
    • 配对比较只看结果不同的任务：17 个不一致的任务里 12 比 5。用符号检验（McNemar 的精确版），双侧 p ≈ 0.14，这个样本量还不能说两个方案有差异。
    • 不要把 50 个任务里的总成功率各算一个区间、看是否重叠；配对设计的信息都在「不一致的任务」里。
    • 下一步是按估算加任务数，而不是加重复次数：同一个任务多跑几次能减少单次运行的噪声，但增加不了任务之间的差异信息。
  6. 运行每个方案在每个任务上跑 3 次：单 Agent 每题过 2 次，并行版每题过 3 次。这一题算谁「赢」？McNemar 还能用吗？
    先口答，再展开要点
    • 统计单位是任务，不是运行。同一任务的 k 次运行彼此相关，把它们当独立样本会让区间窄得不真实（伪重复）。
    • McNemar 只适用于每个任务、每个方案一个二元结果。所以要事先二选一：主分析只用一次预先指定的运行（如第 1 次），McNemar 和 243 这个样本量都指这种设计，其余重复只报稳定性；或者主分析用每个任务的成功比例（2/3 对 3/3），这时不再有「赢 / 输」二元，要做配对任务 bootstrap（按任务重抽样，比较成功比例之差），样本量用试点的任务内、任务间方差模拟功效，不能套 McNemar 的公式。
    • 两种做法不能混用：不能一边用 3 次运行让结果更稳，一边沿用单次二元结果的样本量。
    • 稳定性单独报告：同一任务 k 次全部成功的比例（pass^k，定义见 B06），因为线上用户只会看到一次运行的结果。
Failure Modes 失败模式

这些地方最容易栽

比的是预算，不是架构
  • 症状：并行版成功率更高，但它的 token 是单 Agent 的几倍；给单 Agent 同样的预算后，差距缩小或消失。
  • 根因：两个方案各自按默认配置跑，没有对齐预算，也没有统一 token 的统计口径（只数输入、漏了输出和缓存读写）。
  • 防线：同口径记账；跑「等预算」对照组；在多个预算水平上画曲线，按预算区间下结论。
把运行次数当样本量
  • 症状：「我们跑了 900 次，差异显著」，但只有 150 个任务；换一批任务再跑，结论就翻了。
  • 根因：伪重复。同一任务的多次运行共享同样的难度和资料，彼此高度相关，有效样本量接近任务数，而不是运行次数。
  • 防线：以任务为单位做配对比较；样本量按任务数估算；重复运行只用于估计每个任务的成功比例和稳定性。
任务集被结果挑过
  • 症状：实验报告里并行版全面领先，但任务集是看完初步结果后「清理」过的，剔掉的恰好是并行版失败的任务。
  • 根因：纳入规则没有在实验前写下，事后删改让任务集偏向某个方案。
  • 防线：实验前固定任务集和纳入、剔除规则并存档；需要剔除的任务按事先的规则处理，并在报告里列出剔除数量和原因，两个方案一起剔除。
Estimate 估算

带着量纲算一遍

问：要可靠地看出两个方案差 8 个百分点，需要多少个任务？整个实验要花多少 token？

两种比较要分开算，数字不能互相借用：

  • 默认配置比较（中途变化里观察到的那一组）：两个方案各按默认配置跑，并行版的 token 约是单 Agent 的 2.5 倍。成功率 70% 对 78% 属于这一组。
  • 等预算比较：两个方案按同一 token 上限跑。这一组的成功率和不一致比例要重新测，不能沿用 70% / 78% 和下面的 243。

假设（练习设定，全部待实测）：主分析用每个任务、每个方案一次预先指定的运行（二元成功 / 失败）；默认配置下，「并行版成功、单 Agent 失败」的任务占 14%，反过来占 6%，差 8 个百分点，不一致的合计 20%；双侧显著性 5%（z = 1.96），把握度 80%（z = 0.8416）；另外每个方案每个任务再跑 2 次，只用于稳定性；单 Agent 每次运行约 0.886M tokens（本卡独立的练习假设，待实测；不是 A02 的口径），并行版按观察到的 2.5 倍计。

配对设计（McNemar 近似）  n = (z_α × √p_d + z_β × √(p_d − δ²))² / δ²
  p_d = 0.14 + 0.06 = 0.20，δ = 0.14 − 0.06 = 0.08
  n = (1.96 × √0.20 + 0.8416 × √0.1936)² / 0.0064
    = (0.8765 + 0.3703)² / 0.0064 ≈ 242.9  → 243 个任务（两个方案都跑）

对照：不配对的两组比较（70% 对 78%）
  每组 ≈ 470.7 → 471 个任务，两组共 942 个任务

默认配置的实验 token（243 个任务）
  单 Agent 0.886M + 并行版 0.886M × 2.5 = 3.101M / 任务 / 次
  主分析 1 次运行    243 × 3.101M       ≈ 754M tokens
  含稳定性共 3 次    243 × 3 × 3.101M   ≈ 2,261M tokens

等预算情景的试点（两个方案都以 0.886M 为上限）
  30 任务 × 2 方案 × 3 次 × 0.886M       ≈ 159M tokens

结论：配对设计需要的任务数约是不配对的一半，因为难度差异在同一任务内相互抵消了。243 只适用于默认配置、单次运行二元结果的主分析，是「任务之间独立、不一致比例稳定在 20%」时的算术估计，不是保证：任务按类型分层后，每层需要各自的样本量，区间只会更宽。默认配置的实验本身很贵（主分析约 7.5 亿 tokens，含稳定性约 23 亿），总量要先实测两边的 token 分布再定。等预算比较先用 30 个任务的试点测出这一配置下的成功率、不一致比例和单次运行的波动，再算它自己的样本量；若主分析改用每任务 3 次的成功比例，样本量要用试点方差做模拟。这里只算了模型 token，搜索与抓取的费用、评委调用和人工评分的工时另计。

敏感性：不一致比例从 20% 升到 30%（差值仍是 8 个百分点），需要约 366 个任务；差值只有 4 个百分点（不一致比例 20%），需要约 979 个任务。想看出的差异越小，任务数增长越快，大约与差值的平方成反比。

怎么实测：试点记录每个任务在两个方案下的成功次数、总 token（输入、输出、缓存分开）和墙钟时间；用试点的不一致比例重算样本量；正式实验后按任务做 bootstrap，报告成功率差的区间，并分任务类型报告。

Cross-references 回链

原理去哪里补

  • A02 深度研究 Agent：固定大纲内的并行子 Agent，本卡的对照对象
  • A06 长任务 goal Agent：长任务里拆不拆子 Agent，同样要按本卡的方法对照
  • B01 编排光谱：先分清「谁拆子任务」和「是否委派给自主 worker」，再谈对照
  • B06 Agent 怎么评估：评委校准、配对比较与 pass^k 的口径
  • AI 4.4 多 agent 的收益来自并行，代价来自上下文割裂 · AI 系统工程手册
  • AI 4.5 为什么 agent 的评估比模型的评估难 · AI 系统工程手册
  • AI 6.4 离线评测与线上 A/B 的分工 · AI 系统工程手册
  • AR ch03 多智能体编排：coordinator 分工与上下文传递 · CCAR 备考手册
Your Turn 本人填写

只写真实经历

只写真实经历，没有就空着，不编。公开版只有空表；填好的版本存在自己的私用练习记录里。

场景当时发生了什么我亲自做了什么（团队 / AI 做了什么）怎么发现的，结果和证据之后怎么防
比较两个方案时，后来发现对比条件并不对等
一个看起来显著的改进，换一批数据后消失了

练习记录

日期口述用时脱稿？答不上的追问下一轮修正（≤2）