背景扇出是 2026 年 Agent 编排的默认姿势多智能体 / sub-agent 编排已经从研究论文走进了工程基线2026 年 Tokenomicsarxiv 2601.14470用 30 个 ChatDev 任务实测发现 59.4% 的 token 烧在迭代 review 阶段而非首次生成Anthropic 工程团队也公开过「multi-agent 比 chat 多用约 15× token」。与之并行的另一面是「顺序工具调用」的延迟痛点——单步 ReAct 循环里5 步工具串行就是 5 倍等待多篇 2026 报告把工具串行点名为 Agent 延迟的头号瓶颈。于是工程团队普遍走向同一种妥协把独立子任务扇出fan-out给 N 个子 Agent让延迟逼近 1 拍。但「扇出」这条捷径的代价社区里讲得不够直白。解剖扇出到底复制了什么一个 orchestrator 把任务切给 N 个子 Agent 时每个子 Agent 都会拿到一份完整的共享上下文——system prompt、任务背景、全部工具的 JSON Schema。orchestrator 不是只把「这个子任务」递过去而是把整本说明书复印一份再递。我把一份真实可用的共享 prompt系统准则 任务背景 8 个工具的 JSON Schema喂给 tiktoken 的 cl100k_base实测 853 token。这 853 不会因为子任务变小而缩水它是随每一次请求整包注入的。图16 个子 Agent 各自带一份 853 token 的共享上下文光这一项就多烧 5×853 4,265 tokenN 越大复制税线性增长。实证一并行把延迟砍到三成但 N1 时反而慢近一倍延迟是扇出最直观的收益。我用 Node 起一个子进程当「子 Agent」setTimeout 80ms 模拟一次 I/O 工具调用跑了 20 次取中位对比三种编排# bench_agent.js每配置 20 次取中位performance.now() # serial 一个一个 spawn 再 await # parallel 全部 spawn 一起 await # inline 当前进程 setTimeout不开子进程Nserialparallelinline并行 vs 串行并行 vs 内联1155 ms171 ms93 ms0.91×1.83×2341 ms202 ms186 ms1.69×1.09×4682 ms279 ms372 ms2.44×0.75×81 255 ms373 ms743 ms3.37×0.50×162 693 ms760 ms1490 ms3.54×0.51×图2并行 vs 串行子 Agent 在 N16 达到 3.54×但 N1 时并行 171ms 反而比内联 93ms 慢近一倍。两个发现值得贴墙上第一并行对串行子 Agent 的优势随 N 增长到 3.5× 左右收敛N≥8 后基本吃满第二并行对「不开子进程、内联做完」的 baseline 有一个临界 N ≈ 3~4N1 时每个 Node 子进程冷启动要 ~80ms把并行收益吃光N2 时并行只比内联慢 9%N4 之后并行才稳定反超内联279ms vs 372ms0.75×。实证二上下文被复制 N 份token 账单线性膨胀延迟账算完再看 token 账。我把上面 853 token 的共享上下文代入一个简单模型每个子 Agent 还会带自己的私有任务上下文这里假设 1,200 tok可按你的真实情况替换那么// token_model.cjs节选 const shared 853; // 共享 prompt 工具 schematiktoken 实测 const work 1200; // 每子任务私有 ctx假设按你的任务替换 const subTotal N * (shared work); // N 个子 Agent 总 token const singleTotal shared N * work; // 单 Agent 串行做同一件事NN 子 Agent 总单 Agent 总复制税多烧倍数48,2125,6532,559 tok1.45×816,42410,4535,971 tok1.57×1224,63615,2539,383 tok1.62×1632,84820,05312,795 tok1.64×图3仅「共享上下文被复制」一项N16 就多烧 12,795 token账单是单 Agent 的 1.64 倍。倍数收敛在 1.6× 附近看上去没传说中那么夸张——但绝对值是真实的N16 时光复制就多花了近 13k token 才开始干活。生产系统里 853 这个数往往偏小把工具集扩到 30 个、加上 RAG 检索结果与长 system promptshared 跑到 3k~8k 很常见届时 N16 的复制税是5万–13万 token 起步。这还只是「上下文复制」一项没算 orchestrator 复读所有子 Agent 输出的监管开销、跨轮重新注入、失败重试的级联——也就是 2026 年研究里 2.9×–15× 倍数差的主要来源。局限并行不是免费的生产里还有更狠的叠加项把这条经验搬上线前请先校准三件事子任务真独立吗后一步依赖前一步结果的依赖链并行发出去也会被串行化重排。生产里更糟的是「假独立」——模型以为独立并发了 N 个调用实际有数据依赖结果要么白烧 token 重发要么答案错。这也是为什么实测里「开启 parallel 后 p50 只省 18% 而不是 60%」的案例不少。临界 N 别忽略。N1~2 时子进程的冷启动 IPC 会把并行收益吃光——这种小任务宁愿让单 Agent 顺序做完。orchestrator 自己的账别忘了。监管型 orchestrator 要把所有子 Agent 输出读一遍才能往下走它的输入随 N 增长这部分 supervision 开销在我的静态模型里没有但生产里是实打实的二次放大器。缓解手段prompt cache 共享、子 Agent 只接收「自己需要的」上下文子集、给每个子 Agent 设硬性 token 上限。结论先算两笔账再决定要不要扇出工程上可复用的方法论只有一句任何想扇出的任务先并行算「能省多少 round-trip」再除以 N 算「共享上下文被复制几份」两者同时划算才拆。我这张双账本图延迟 vs token以后会直接进我们做 Agent 架构评审的 checklist——左轴决定用户体验右轴决定账单。两个都赢才值得拆两个只赢一个就别拆。开源地址结论段指向同一组织即可3 个矩阵门户GitHub - wangzifan396-wzf/WB: nano-tools: 1200 single-file, zero-dependency, local-first web utilities in one portal. Offline and private, nothing leaves your browser. Binary protocol parsers, crypto, dev, audio, visualization, productivity. · GitHub单文件工具聚合器GitHub - wangzifan396-wzf/nano-workbench: Single-file tabbed launcher for the nano-tools matrix - one tab, 382 curated tools (of 1228), instant switching. Zero-dep. Part of nano-tools. · GitHubGitHub 组织主页wangzifan396-wzf (WangZi) · GitHub