2026年，多智能体协作的默认姿势已经收敛成一个动作：扇出（fan-out）—并行跑—归并（merge）。Cursor 3 的 Agents Window、Windsurf Wave 13、LangGraph 的 Send API、OpenAI Agents SDK 的 asyncio.gather，底层都是同一套——一个规划者把任务切给 N 个 worker，再由一个合流者把碎片缝回去。这套范式之所以流行，是因为它在 p50 延迟和"看起来很并行"上极其讨好。
但斯坦福 Tran 与 Kiela 在 2026 年 4 月的预印本（arXiv:2604.02460）给这股热潮浇了一盆冷水：当把"思考 token 预算"对齐之后，单智能体在多跳推理上反过来击败了五种主流多智能体架构。换言之，过去两年 MAS 报告的"提升"，很大一部分是靠多烧算力换来的，而不是架构红利。更尖锐的是 tianpan 的生产实测：扇出能让 p50 掉下来，却把 p99 从 4 秒顶到 22 秒——炸点不在任何单个 worker，而在归并那一步。
本期把"扇出—归并"这条链单独拆出来，实测归并黑洞：为什么缝回去的成品，比任何一片碎片都差。
| 归并策略 | 信息保真 | 冲突处理 | p99 延迟 | 合流者上下文成本 | 最适场景 |
|---|---|---|---|---|---|
| 拼接（concat） | 极低，噪声淹没信号 | 无 | 低（O(1)） | 线性暴涨 | 调试/日志汇总 |
| 多数投票（vote） | 中，少数派被抹掉 | 多数决 | 等长尾 | 低 | 有标准答案的判题 |
| 摘要（summary） | 低，细节蒸发 | 隐式 | 中 | 中 | 状态汇报 |
| 刻意合成（deliberate merge） | 高，但单点瓶颈 | 显式裁决 | 高 | 高（需读全部） | 高风险架构决策 |
| 分层归并（hierarchical） | 中高 | 局部裁决 | 对数级 | 分摊 | 超大规模扇出 |
| 增量/流式归并（progressive） | 中高 | 滚动裁决 | 低 | 恒定窗口 | 长任务流式产出 |
这张表的关键结论：刻意合成是唯一保真度合格的策略，但它恰恰是最贵的——而且贵在延迟和上下文，不是 token 数量。多数团队本能地选"投票"或"摘要"，于是在归并这一步悄悄丢掉了保真度，却以为是 worker 不够强。
这套范式之所以成为默认，是因为它把"并行"这件事做成了开箱即用的原语。LangGraph 用 Send 对象做动态扇出，OpenAI Agents SDK 直接 asyncio.gather 凑一组 runner，CrewAI 用 hierarchical process 让 manager 派活。骨架本身极简：
from langgraph.types import Send
def fanout(state):
return [Send("worker", {"sub": s}) for s in state["subtasks"]]
def merge(state): # 归并节点：缝合所有 worker 输出
return {"result": synth.invoke({"parts": state["partials"]})}
graph.add_conditional_edges("planner", fanout, ["worker"])
graph.add_edge("worker", "merge") # reducer 自动累加 partials
架构清晰、调试直观、账面上看每个 worker 都在"干活"。问题是这套骨架把所有不确定性都推给了 merge 这一个节点。worker 各自独立、上下文隔离，于是合流者要承担三件 worker 从不需要做的事：理解全局、裁决冲突、保证内部一致。当 worker 数量从 3 涨到 8，merge 的工作量不是线性增长，而是组合级增长——它要两两对照 N 份产出里每一处潜在的矛盾。
优缺点：优点是并行度可见、错误隔离好、可观测；缺点是单点瓶颈、合流者成为新的隐式串行段。变现/训练营：这个骨架最适合做成"多智能体入门营"的开场，因为代码短、效果直观，但要警惕——它给学员一个"并行=快"的错误心智模型，真正的税在后面。
agentpatterns.ai 对 fan-out synthesis 的定义很精准："同一个任务跑 N 遍，再由一个 agent 把每份里最好的部分拼起来——不是投票，不是摘要，而是刻意合成"。这句话点破了黑洞的本质：合流者必须读完所有 N 份完整产出，才能做取舍。
假设 5 个 worker 各产出 4K token 的方案，合流者的输入就是 20K+。这还没完——为了裁决冲突，它往往要把"问题陈述"也带进来，再叠加"合成指令"。一个归并动作轻易吃掉 25–30K 输入。这正好撞上 2026 年的另一个趋势：上下文工程本身正在成为显学（Gartner 报告 2026 年 3 月 agentic/context 相关咨询激增 1,445%）。当合流者上下文塞满，它对深层冲突的裁决能力反而下降——这正是"8KB 盲区"现象在合流节点的高发区。
实测建议：给 merge 节点单独打"上下文利用率"指标。一旦 worker 数量让 merge 输入超过模型有效注意力窗口的 60%，保真度就开始崩。变现点：可以把"归并上下文预算审计"做成 SaaS 诊断项，按 merge 节点的 token 占用计费，这是大多数团队没意识到的成本黑洞。
斯坦福论文的核心方法论是一个被业界长期回避的变量：思考 token 预算对齐。过去 MAS 的对比，单智能体往往只跑一遍、思考预算默认值；多智能体则是 N 个 agent 各自思考，总预算天然是单智能体的数倍。一旦把这个变量锁死——让单智能体也拥有等量的"思考额度"——五种 MAS 架构在多跳推理上集体跑输。
这等于是给"扇出"做了一次分解测试（decomposition test）：把任务拆给并行 worker，到底是因为"并行带来了新信息"，还是只是"多烧了算力"？tianpan 的横评给出一个刺眼的数字：单智能体在 64% 的评测任务上追平或反超多智能体 pipeline。结论不是"多智能体无用"，而是：只有当子任务真正互相独立（embarrassingly parallel，如批量抽取、多源检索）时，扇出才有红利；一旦子任务之间存在隐式依赖，归并成本就吃掉全部收益。
优缺点：分解测试是廉价的——同一任务跑"单 agent + 加倍思考预算"和"N agent 扇出"两版对比即可。缺点是它只能告诉你"不该拆"，给不出"该怎么拆"。训练营价值：这几乎是最适合做教学演示的实验——10 分钟代码、结论震撼、能直接改变学员的架构选型。
扇出对 p50 极其友好——并行 N 个，理论上 p50 ≈ 单个 worker 的 p50。但归并是屏障（barrier）：必须等所有 worker 返回才能合并。于是 p99 ≈ 最慢那个 worker 的 p99。tianpan 的生产案例最典型：p50 美化了，p99 却从 4 秒窜到 22 秒，原因不在任何 worker 变慢，而在"长尾 worker + 归并屏障"的组合放大。
这个税有两个放大器：一是 worker 之间负载不均（一个 worker 抽到了慢数据源），二是合流者本身要时间消化大上下文。两个叠加，p99 可以是 p50 的 5–10 倍。在面向用户的场景里，这意味着扇出越多、超时越多。
缓解：引入部分归并（partial merge）——不设硬屏障，先到先合并，超时的 worker 用降级结果兜底。LangGraph 里可以用带超时的 reducer，OpenAI SDK 里用 asyncio.wait(..., timeout=) 配 FIRST_COMPLETED。实测能把 p99 压回 1.5–2 倍 p50。变现点："多智能体长尾延迟急诊"是一个高频咨询需求，尤其金融/客服等对 p99 敏感的行业。
当 N 个 worker 对同一个共享产物（同一段代码、同一个 schema、同一份配置）各自给出方案时，归并就不再是"取各家之长"，而是"裁决谁对"。Taskade 把这个现象命名为 interference merge（干扰式归并）：并行 agent 在同一份 artifact 上各自演化，合并时产生互相打架的修改，最终成品是 Frankenstein——局部都对，整体不成立。
这是扇出范式最隐蔽的税，因为它在评测里几乎测不到（评测通常给每个 worker 独立的、可拼接的子任务），却在生产里天天发生。一个 IDE 里 3 个 agent 同时改同一个文件，归并阶段冲突的行数可能比任何单个 agent 改的都多。
对策：把"共享可写 artifact"从扇出模型里剔除。要么让每个 worker 只产出只读的提案、由合流者单一写入；要么用分片归并——按文件/模块把 artifact 切成不重叠的领地，每个 worker 只能写自己的领地。后者把 N 个 writer 的冲突归零，代价是规划阶段要预先切好边界。训练营：这是"从玩具到生产"的关键一课，演示一次 Frankenstein 合并比讲十页理论都管用。
大部分团队根本没有"归并质量"这个指标——他们测 worker 的准确率，假设合起来就好。但斯坦福的分解测试给了一个可直接搬用的范式：往返分解（round-trip decomposition）。
做法：拿归并后的成品，再用一个独立 agent 把它"反分解"成子任务，与原始子任务集做语义对齐。如果反分解出来的子任务和原始子任务对不上，说明归并丢了信息——丢得越多，归并黑洞越深。配合"等预算单 agent"作对照基线，就能算出净归并保真度 = 多智能体成品质量 − 等预算单智能体质量。这个值在很多多跳任务上是负数——这正是斯坦福论文的结论落点。
# 伪代码：净归并保真度
score_mas = eval(merge(worker_outputs))
score_solo = eval(solo_agent.run(task, budget=N*worker_budget))
net_gain = score_mas - score_solo # <0 即"归并税为负"
变现：把这套测量做成一个开源 benchmark 套件或付费 dashboard，是少有的"卖方法论"而非"卖 API"的路径，毛利高、护城河深。
归并黑洞不是无解，关键是不再让一个节点扛全部：
flowchart LR
P[Planner 规划] --> W1[worker 1]
P --> W2[worker 2]
P --> W3[worker 3]
P --> W4[worker 4]
W1 --> M1[一阶归并]
W2 --> M1
W3 --> M2[一阶归并]
W4 --> M2
M1 --> RM[根归并]
M2 --> RM
RM --> OUT[成品]
RM -.->|上下文恒定: 只读2份| note((黑洞缩小))
classDef blk fill:#fee,stroke:#c33,color:#900;
class RM,note blk;
这三种都把"读全部 N 份"降级为"读少量份"，是治本方向。适用：分层适合超大规模（>10 worker）；流式适合长任务和延迟敏感；预结构化适合需要审计和复现的生产系统。变现：三种拓扑各对应一个咨询场景，可打包成"归并税优化工作坊"。
把上面七层叠起来，最值钱的单一产品不是某个框架，而是"分解测试 + 归并保真度"这条诊断流水线。它满足好训练营的三个标准：结论反直觉（多智能体常常更差）、实验门槛低（一个任务两版对比）、可量化（净归并保真度是一个数）。
课程结构建议：第一模块用斯坦福实验打掉"多即强"的迷思；第二模块实测长尾延迟税，让学员亲眼看到 p99 飙升；第三模块动手实现分层/流式归并，把税降回来；第四模块做冲突合并税的 Frankenstein 演示。这套课程的企业买单意愿高——因为它直接对应"我们上了多智能体之后反而更慢更贵"的真实痛点。产品化上，诊断流水线可作为 SaaS 入口，深度优化作为高客单咨询，是一条从工具到服务的清晰漏斗。
一句话收口：扇出的红利在并行，代价全在归并；先测分解值不值，再决定要不要缝——而缝的方式，决定了你是在合成成品，还是在制造科学怪人。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。