模式矩阵 /模式白皮书/C2

C2 · Fan-out / Gather · 扇出聚合

它解决什么问题

有些任务单 agent 顺序做就是太慢。十万页财务文档让一个 agent 读完要 35 小时，可法务团队季报披露前只有 24 小时窗口——再强的单 agent 也搬不动这堵墙。

扇出聚合把一个大任务切成多个可独立执行的子任务，并行分发给 N 个 sub-agent，最后聚合。它的收益不在省 token——token 成本是线性翻倍的——而在压缩 wall-clock 时间：worker 数量上去，总时长几乎线性下降。但它有一个常被低估的难点：把任务派出去几乎不花工程成本，把结果合回来才是真正的工程。多个 worker 看到同一份材料时输出会重叠，聚合阶段如果不做去重和冲突消解，再多 worker 也只是堆噪声。

为什么坐标是「协作 × 并行」

• 纵轴 · 协作：这是把一个任务拆给多个 sub-agent 并行做再汇总，分发的实体是不同的子任务，属于多 agent 协作拓扑。区别于推理模块的并行探索——后者并行的是同一道题的多条解法（推理策略），前者并行的是切给不同 agent 的不同子任务（协作拓扑）。
• 横轴 · 并行：N 个 sub-agent 同时跑、互不知情，最后统一 gather，是经典的 map-reduce 式并行结构。不是顺序串联，也不是循环迭代。

核心机制

一次扇出聚合由三段组成：

1. 切分扇出：把大任务按"语义独立性"切成 N 份，并行分发。切分标准不是按文档数等分，而是让子任务彼此独立——worker B 不能依赖 worker A 的输出，否则就该用交接链而不是扇出。
2. 隔离执行：每个 sub-agent 跑在独立 context 里完成自己的子任务，互不通信。隔离强度跟输出冲突可能性成正比——各查不同语料的研究任务用软隔离就够，多 agent 改重叠文件的写代码任务要用物理隔离（独立 Git worktree 或独立容器）。
3. 聚合收回：用聚合策略把 N 路结果合并。这才是扇出的灵魂，聚合没做对全套链路就废。

聚合不是简单拼接，至少要做五件事：

适合的生产场景

• wall-clock 时间紧迫的批量任务：季报合规扫描、大规模文档审查、批量投标书评审，总时长是硬瓶颈、子任务彼此独立。
• 可按语义独立切分的研究任务：跨多个语料源的并行查证，每个 sub-agent 各查一类内容，输出几乎不冲突。
• 多 agent 并行写代码：UI、API、数据库、测试各一个 agent，配合物理隔离的 worktree 把 8 小时压到 2 小时。

三个条件要同时满足：任务可独立并行、总时长是瓶颈、能负担 N 倍 token。任一不满足，扇出就只是把瓶颈从时长挪到质量。

容易出错的地方

• 子任务有强依赖还硬切：worker 之间需要交换中间状态、或必须按顺序看才能识别演化轨迹的任务，扇出会把顺序依赖强行拍平成并行，gather 阶段要花大量工作重新建立依赖关系。这种场景应该用交接链。
• 聚合比执行还贵：aggregation 投入不够时，扇出只是把瓶颈从时长挪到质量。如果业务没有工程精力做去重、冲突消解、跨切整合，就不该开扇出。
• 聚合瓶颈：worker 数 N 增加时，aggregator 要读完所有 worker 输出，context 撑爆、质量直线下降。N 大时 aggregator 要分层做（先分组 sub-aggregation，再最终综合），把 context 压力压到对数级。
• 切片按职能切而非按冲突切：按"职能最齐全"切（前端/后端/算法/测试各一组）会导致集成阶段天天解冲突；按"输出冲突最小化"切才对。扇出拓扑应该 mirror 业务团队真实的协作拓扑。
• 隐式 batch 削并发：以为开了 50 并发，实际 LLM provider 那边在做隐式 queue 加 batch 调度，真实并发被悄悄削到 10。扇出实现要跟 provider 的 batching 行为对齐。

关键指标

• 成功率（健康区 ≥ 95%）：返回有效结果的 worker 占比。合规审查场景这是硬底线，漏评几份在审计阶段会被卡。
• 重复率（健康区 < 30%）：聚合后相似条目占比。超过说明去重没做好，报告会膨胀到"读者看不动"。
• 加速比（健康区接近 N）：N 个 worker 实际带来的时长压缩倍数。明显低于 N 说明并发被限流削掉、或任务其实有依赖。
• 聚合成本占比（健康区 < 15%）：聚合这一步消耗的算力占总成本的比例，过高就换更轻的聚合策略或分层聚合。

最小骨架

FanoutGather.execute(goal, perspectives, strategy):
    workers = decompose(goal, perspectives)    # 按语义独立性切 N 份
    results = 并行 gather(                       # 信号量控并发 + retry + backoff
        execute_worker(w) for w in workers      # 每个独立 context,失败不阻塞其他
    )
    return aggregate(goal, results, strategy)   # 灵魂在这一步

aggregate(results, strategy):
    concatenate → 简单拼接(仅无重叠时)
    vote        → 多数投票
    synthesize  → 强模型综合,显式消解矛盾 + 去重
    structured  → schema 化结构合并

四个工程要点：worker model 用便宜的、aggregator model 必须用强的（综合是质量瓶颈）；并发初始值跟 provider 的 RPM tier 对齐，从 5-10 起步加监控逐步上调；失败 worker 不阻塞其他、设 partial failure 阈值；保留每路完整 trace 供审计。

企业落地一例

某上市公司的季度合规扫描 Agent，第一版单 agent 顺序读完十万页财务文档要 35 小时，直接超出法务团队 24 小时的披露前窗口。第二版改成 12 个 worker 各负责一类文档（财报 4 个、邮件 4 个、合同 4 个）并行扫描，总时长压到 4 小时。但上线后立刻撞上聚合难题：12 个 worker 各标了 200 多个风险点，同一份合同变更被三个 worker 用三种说法标记（"对赌条款增加""earnout clause expansion""对赌新增可触发回购"），gather 阶段统计出 600 项风险，其中至少六成是重复。法务总监的原话是"agent 跑得快，但报告我看不动"。第三版给 gather 加了三件事：基于 embedding 的语义去重、概念归一化（把三种说法 canonical 成一条）、置信度加权（单 worker 标的权重 0.6，多 worker 都标的权重 1.0）。最终风险报告从 600 多项压到 80 项 high-confidence 加 120 项 needs-review。如果是政府或国企的大型招标投标书评审场景，还要叠加合规约束：worker 间严格隔离满足评委独立性要求、全 trace 留档 7 年、partial failure 阈值不低于 95%（漏评一份在审计阶段会被卡）。

与其他模式的关系

• 并行探索（推理模块 R3）：结构同源、聚合机制相通，区别在并行的实体。扇出聚合是不同子任务分给不同 agent（协作拓扑），并行探索是同一道题的多条解法（推理策略）。两者都遵循"N 倍 token 换 1/N 时长"，但分发对象不同。
• 层级委派（C1）：同为一对多，但扇出是一对多分量（多个 worker 同时干同一类活的不同部分）、浅协作（fire-and-collect），层级委派是一对多分专业、深协作（supervisor 持续监督）。Anthropic 多 agent research 同时是层级（lead 主管）加扇出（subagents 并行）。
• 对抗评审（C3）：扇出的 N 个 worker 是互补关系（各看一面拼出全景），对抗评审的 reviewer 是对抗关系（独立审查决策健壮性）。
• 子代理隔离（C5）：扇出的每个并行 branch 都依赖隔离这个内功——独立 context，gather 阶段只看 reduced 结果。

一句话记住它

扇出聚合看上去是省 wall-clock 时间，工程实战里是投资 aggregation 复杂度加复刻你团队真实的协作拓扑——N 倍 worker 让时长变 1/N 的前提，是你给聚合也投了 N 倍的工程精力。

本页属于 ADPS 33 模式白皮书。返回 模式矩阵与白皮书目录， 或查看配套 可运行代码目录。