单 agent vs 多 agent

阶段: B4 · reasoning/planning/multi-agent + 何时不用 agent（Day 31-40） 标签: #single-vs-multi-agent #token-multiplier #ablation #cost-aware

今日导引（由浅入深）

昨天（Day36）我们把 orchestrator-workers 编排搭出来、跑通了一条确定性 transcript。但「能搭」不等于「该搭」。今天在 B1→B18 能力曲线上做的是一次对照消融（ablation）：

• 用同一个 8 任务集分别跑单 agent 和 supervisor/worker；
• 把「多 agent 更好」从信仰变成可证伪的数字——accuracy Δ 和 token 倍数。

这是 B4 的核心方法论纪律：架构选型必须用同任务集实测，而非拍脑袋。最小可判定产出：一张对比表（accuracy Δ + 多/单 token 倍数）。

1. 机理精读

核心命题：多 agent 不总更好。直觉上「多个专家协作 > 一个通才」，但在 LLM agent 里这个直觉常常失效。Cognition《Don't Build Multi-Agents》（2025-06）给出系统性反例论证，三条代价压过收益：

① token 常翻 2×+。

• supervisor 自身的拆解/汇总要 token；
• 同一份背景信息可能要分别喂给多个 worker；
• worker 的结果回传后 supervisor 还要二次消化。

结果是端到端 token 倍数往往 2× 起跳——而成本与 token 成正比（Day38 会把这变成「单位成本」维度）。

② 协调引入新失败点。

• 单 agent 只有「模型推理对不对」一个失败维度；
• 多 agent 多了「supervisor 拆解对不对」「子查询表述对不对」「结果汇总对不对」三个新维度。

系统可靠性是各环节可靠性的乘积，环节越多，端到端越脆。

③ 错误沿 worker 链放大。Cognition 的关键观察是 context 共享难题：

• worker 之间若不共享上下文，各自基于片面信息做决策，汇总时矛盾；
• 若共享，又失去隔离收益且 token 爆炸。

错误一旦在某个 worker 产生，supervisor 难以察觉，会把错误结论当事实汇总进最终答案。

何时多 agent 才赢。仅当子任务真正可并行（彼此独立、无需互相看中间结果）或需 context 隔离（单窗口确实装不下、信号被严重稀释）时，隔离收益才压过 token 翻倍的代价。AML 调查里「并行核查多个对手方的 OFAC/PEP 状态」是可并行的真实场景；而「一步推理就能答的合规问题」上多 agent 纯亏。

与 Day36 的边界：Day36 回答「怎么搭 orchestrator-workers」，Day37 回答「该不该搭」——用数据。这正是 Day40「何时不用 agent gate」要收敛的判据之一。

2. 推导 / 手算 / 代码走读

今天是实测对照日，核心是「同任务集、两套架构、比 accuracy 与 token」。

手算 token 倍数的最小例子（占位结构，真实数字待 key）。设单 agent 在某任务上消耗 prompt+completion = T_single；supervisor/worker 端到端消耗：

• supervisor 拆解 T_sup
• workerA T_a
• workerB T_b
• supervisor 汇总 T_merge

则 token 倍数 = (T_sup + T_a + T_b + T_merge) / T_single。

判定逻辑：若该倍数 > 2 而 accuracy Δ 的 95% CI 跨 0（Day35 的 pairedBootstrap 判定），结论就是「多 agent 多花 2× token 没换来显著更准」⇒ 不该上。

代码侧复用三处真实资产：

• 单 agent 直跑：Day36 的 runAgentLoop（src/agent/loop.ts:34），LoopResult 已带 toolCalls、steps，token 可由 harness 在真实 model 调用处累加。
• 多 agent：runOrchestrator（src/agent/orchestrator/orchestratorAgent.ts:22），其 onSubAgentEnd(kind, text, usage) 回调（如 :36、:53）已透出每个 worker 的 usage?.inputTokens / outputTokens——这是统计 token 倍数的真实采集点。
• n-run 取均值：复用 Day33 的 runNTimes（对 8 任务跑多次取均值，压掉单跑抖动），避免拿单次随机结果下结论。
• accuracy 来源：runTaskEval（src/agent/eval/agentEval.ts:77）的 completionRate（judge.label==='pass' 占比，agentEval.ts:120）作为两套架构的 accuracy 指标。

预算栅的副作用：runOrchestrator 内每个 dispatch 都 assertCostOk() / assertCanStep()（orchestratorAgent.ts:27 等），所以多 agent 一旦 token 失控会被 Budget 抛错截断——这本身就是「多 agent 更易触顶」的工程证据。

对比表读法（占位结构，真实数字待 key）：

读法纪律：先看 Δaccuracy 的 CI 是否跨 0；若跨 0，再大的 token 倍数都意味着「多花钱没换来更准」，直接判单 agent 胜。这张表是 Day40 gate 的直接输入。

token 采集的两条路径要对齐口径：

• 单 agent 路径：token 在真实 model 调用处（makeModelGenerate，agentEval.ts:150）从 r.usage 取 inputTokens + outputTokens 累加。
• 多 agent 路径：token 从 onSubAgentEnd 的 usage 回调累加，还要叠加 supervisor 自身的 usage（否则会系统性低估多 agent 成本，把对比做得偏向多 agent）。
• 两路必须用同一 tokenizer 口径，否则倍数不可比——这是 Day41 context 审计要统一的前提。

3. 今日实战

1. 同一 8 任务集（Day31 标注的子集），路径 A：用 runAgentLoop 单 agent 直跑，记 completionRate + 累加 token。
2. 路径 B：用 runOrchestrator（supervisor + 2 worker），用 Qwen3（OpenRouter）作 modelOrchestrator / modelSubAgent，通过 onSubAgentEnd 回调累加各 worker 的 input/output tokens。
3. 两路各跑 n 次（Day33 runNTimes）取均值，算 Δaccuracy = acc_multi − acc_single 与 token 倍数 = token_multi / token_single。
4. 把结果填进对比表：列 = accuracy(单/多) | Δaccuracy | token(单/多) | 倍数。Qwen3 的 OpenRouter slug 执行当周复验。

4. 今日实测 / 产出

• 「待跑（需 OPENROUTER_API_KEY）」；harness 可先离线 fixture 跑通出 completion%。
• 将产出对比表：accuracy Δ + token 倍数（多/单）。

5. 常见误区 / 陷阱

• 不在同任务集上比：换了任务再比 accuracy，task-difficulty variance 会污染结论；必须 paired 在同 8 任务上（这正是 pairedBootstrap 要求等长配对的原因）。
• 只看 accuracy 不看 token：哪怕多 agent 略高 0.x pp，若 token 翻 2.x×，单位成本上多半不划算（Day38 三维度）。
• 单跑下结论：agent 输出非确定，一次跑的 Δ 可能纯噪声，必须 n-run + bootstrap CI（Day35）。
• 把 Qwen3 当固定 slug：模型 id 会变，必须执行当周到 OpenRouter 复验。

6. 学习资源（每条带 YYYY-MM）

• Cognition《Don't Build Multi-Agents》(2025-06)——单 vs 多 agent 反例论证（token 翻倍 / context 共享难题）主引用。
• Anthropic《Building Effective Agents》(2024-12)——多 agent 适用边界（并行/隔离）的互补来源。
• 本仓 src/agent/orchestrator/orchestratorAgent.ts（onSubAgentEnd 透出 worker usage，token 采集点）。
• 本仓 src/agent/loop.ts（单 agent 直跑基线）。
• 本仓 src/agent/eval/agentEval.ts（completionRate 作 accuracy 指标）。

SOTA检查 (2026-06 更新)

Cognition《Don't Build Multi-Agents》(2025-06) 与 Anthropic 多 agent 研究并存，2026 共识是「默认单 agent，证明必要才上多 agent」。该共识现行有效。

• 避免：把 multi-agent 当默认架构（成本 ×2、失败点 ×3）；只报 accuracy 不报 token 倍数。
• 下次复查点：Qwen3 的 OpenRouter slug 执行当周复验；关注 Cognition / Anthropic 是否在 2026 出新的多 agent 收益边界研究。

衔接

• 昨天：Day 36 — supervisor/worker 模式（搭出 orchestrator-workers 编排）。
• 今天：用同 8 任务集实测单 vs 多 agent 的 accuracy Δ 与 token 倍数——验证多 agent 不总更好。
• 明天：Day 38 — cost/latency 度量（把可靠性扩成 accuracy + p95 延迟 + 单位成本三维）。