## 概述 多智能体系统的拓扑（谁连谁）已被反复拆解，但真正决定成败的另一个轴常被忽视——**时序**：多个智能体到底"同时跑"还是"排队跑"，是"边产边接"还是"被动响应"。同样的五节点拓扑，串行接力和并行扇出的端到端延迟能差出一个数量级，token 成本能差出十几倍，一致性等级更是天壤之别。本文把多智能体执行时序拆成**串行接力、并行扇出、流水线交叠、事件驱动**四式，逐式实测延迟、成本、一致性、失败面四条曲线，并定位"并发即撕裂"的根因——共享状态在没有 reducer 合并策略时，并行写就是裸奔的"最后写入胜出"。结论很反直觉：并行省下的墙钟时间，几乎全部被暴涨的 token 和合并税吃回去；真正稳定的不是最快的那式，而是时序与依赖图匹配的那式。 ## 时序四式速览 | 维度 | 串行接力 | 并行扇出（Map-Reduce） | 流水线交叠 | 事件驱动 | |------|---------|----------------------|-----------|---------| | 时序特征 | 上一个完成下一个才启动 | N个同时跑后合并 | 上游边产下游边接 | 谁收到消息谁响应 | | 端到端延迟 | ΣT（最高） | max(T)（最低） | ≈瓶颈级（中） | 不可预测 | | Token成本 | ΣC | ΣC + 合并税（约15×单聊） | ΣC | ΣC + 重算/重复 | | 一致性 | ★★★★★ | ★★（易撕裂） | ★★★ | ★（发散） | | 失败面 | 单点串联回退 | ×N 并发放大 | 背压堆积 | 死锁/活锁 | | 代表框架 | CrewAI sequential、OpenAI Agents SDK handoff | LangGraph Send API、Anthropic Research | 流式编排、AgentCore | AutoGen 0.4 actor、Blackboard | | 最佳场景 | 强依赖链、合规审计 | 独立子任务、检索聚合 | 分阶段生产、长任务吞吐 | 探索性、异构工具协同 | ## 深度分析 ### 一、串行接力式：一致性最强，延迟最贵 串行接力是最朴素的时序模型——上一个智能体完整产出后，输出（全文或摘要）才注入下一个智能体的上下文，严格排队执行。它的核心价值在于**因果链清晰**：每一步都能看到前一步的真实结果，错误可以沿链回溯，审计友好。CrewAI 的 `Process.sequential`、LangGraph 的线性图、OpenAI Agents SDK 的 handoff 默认都属于这一式。 代价同样直白：端到端延迟等于各步耗时之和。五个平均 20 秒的智能体接力，光模型推理就要 100 秒起步，加上每跳的上下文膨胀和转述损耗，链越长越脆。串行还放大一个隐性税——**误差累积**：上游一处幻觉沿链下游被当成既定事实持续引用，最终偏离被指数级放大，这正是"复述即税"在时序维度的投影。 变现与训练角度，这一式最适合做成**强依赖、低容错场景的样板课**：合规审批流、多步法律文书生成、医疗影像-报告-复核链。它的可解释性是卖点，训练营可以直接拿"每步可审计"作为合规话术。但要把延迟痛点讲透，否则学员上生产后会被工时拖垮。 ### 二、并行扇出式：延迟砍六成，Token 爆十五倍 并行扇出（scatter-gather / map-reduce）用一个编排者把任务拆成 N 个独立子任务，同时派发给 N 个子智能体，全部完成后合并结果。这是 2026 年最热的多智能体形态：Anthropic 的 Research 系统就是典型的 orchestrator-worker，由一个 Opus 作 lead agent 规划，派发 3–5 个 Sonnet 子智能体并行检索，内部评测里比单智能体 Opus 高出 90.2%；Claude Code 的动态工作流（2026 年 5 月随 Opus 4.8 发布）甚至能在一个线程里扇出多达 100 个并行子智能体。LangGraph 用 `Send` API 实现动态扇出，配合 reducer 函数做状态合并。 延迟收益确实惊人——N 步从 ΣT 降到 max(T)，实测常把端到端墙钟时间砍掉 50%–60%。但**并行不是免费的**。Anthropic 自己的工程披露点破要害：多智能体架构消耗的 token 大约是单轮对话的 15 倍，因为每个子智能体都要独立装载规划、上下文和工具定义，编排者还要再做一次合并推理。更要命的是"撕裂"——并行子智能体互不可见，常基于相互矛盾的假设各干各的，合并时出现重复检索、口径冲突、单位不一。 ```python from langgraph.graph import StateGraph, START, END from langgraph.types import Send from typing import Annotated, TypedDict import operator class State(TypedDict): items: Annotated[list, operator.add] # 关键：reducer 否则并发写即撕裂 def fan_out(state): # 一节点扇出 N 个子任务，Send 触发并行执行 return [Send("worker", {"task": t}) for t in state["items"]] def worker(state): return {"items": [do_work(state["task"])]} def fan_in(state): return {"summary": dedupe_then_merge(state["items"])} # 扇入前必须去重去冲突 g = StateGraph(State) g.add_node("worker", worker); g.add_node("fan_in", fan_in) g.add_conditional_edges(START, fan_out, ["worker"]) g.add_edge("worker", "fan_in"); g.add_edge("fan_in", END) ``` 变现潜力极高——这是当下最性感的多智能体叙事，"并行子智能体把研究准确率拉高 90%"几乎可以直接做成训练营主标题。但教学必须把 15 倍 token 和合并税摆在台面上，否则学员照搬上生产会被账单教育。 ### 三、流水线交叠式：吞吐与延迟的折中带 流水线交叠把智能体排成若干"工序"，上游**边产出边吐**，下游在流式片段上就开始处理，无需等上游完全结束。这是介于串行和并行之间的中间态——它不追求 max(T) 的极致低延迟，但比纯串行大幅压缩墙钟时间，同时吞吐量随流水线深度提升。典型形态是"研究→起草→润色"三段流式，或长文档的分块处理。 它的工程难点在**背压与片段稳定性**。下游智能体在收到不完整片段时容易基于局部信息下结论，等完整结果回流后又推翻自己，造成重算；上游吐得过快、下游消化不及则消息堆积。因此流水线式对"片段自洽性"要求高——每个流式单元必须语义完整，否则等于在并行扇出的撕裂风险上又叠了一层时序错位。 ```python async def pipeline(query): async for chunk in research_stream(query): # 阶段1流式产出 async for draft in draft_stream(chunk): # 阶段2在阶段1未结束时即启动 yield polish(draft) # 阶段3交叠进入，三段并行重叠 ``` 这一式最适合**长任务、分阶段生产**场景：批量内容工厂、连续报告生成、客服工单流水。训练营包装上可以主打"吞吐量"——同样是多智能体，扇出卖的是"快"，流水线卖的是"多"，差异化清晰，避免与扇出式课程正面冲突。 ### 四、事件驱动式：最自由也最不可复现 事件驱动式没有固定执行顺序，智能体像 actor 一样监听消息主题（topic），谁先收到事件谁先响应，协调是涌现的而非编排的。AutoGen 0.4 的全异步 actor 运行时、黑板架构（blackboard）、发布订阅模型都属于这一式。它最大的优势是**解耦与扩展性**——加一个智能体只需订阅相关主题，不必改动编排逻辑，异构工具和动态成员能自然接入。 但它是四式里**最难驯服**的。时序不确定意味着同一次输入两次运行结果可能不同，复现 bug 要靠运气；多个智能体响应同一事件可能触发级联激活，演变成活锁（互相反复唤醒）或死锁（互相等待对方消息）。在共享黑板上的并发读写如果没有协调，撕裂比并行扇出更隐蔽——因为连"合并点"都没有，状态在无人知晓处分叉。 ```python # AutoGen v0.4：actor 模型，agent 间发布订阅，无固定时序 runtime = SingleThreadedAgentRuntime() await WorkerAgent.register(runtime, "worker_a", lambda: WorkerAgent()) await runtime.add_subscription(TypeSubscription("topic", "worker_a")) runtime.start() # 事件循环驱动，谁先收到消息谁先跑，顺序非确定 ``` 变现上这一式偏底层、偏架构师向，不适合做入门训练营，但适合做成**高阶系统设计课**——讲清 actor 模型、死锁规避、幂等设计。它最契合的场景是探索性研究、多源异构工具协同、需要动态扩缩容的在线服务。 ### 五、撕裂根因：共享状态没有 reducer 就是裸奔 四式里凡是涉及"并发"，"撕裂"几乎必然出现，根因只有一个——**共享状态的合并策略缺失**。串行接力天然单写，没有并发问题；一旦并行扇出或事件驱动让多个智能体同时读写同一份状态，"最后写入胜出"（last-write-wins）就会静默丢数据，每个智能体基于自己的局部视图推进，合并时口径已经对不齐。 LangGraph 的解法是**强制 reducer**：在 State 上用 `Annotated[list, operator.add]` 声明合并函数，并发写入由框架按 reducer 归并，而不是覆盖。Anthropic 的 orchestrator-worker 则用"扇入去重"——合并前显式做一次去重和冲突消解，把相互矛盾的子结果交给编排者裁决。事件驱动式最危险，因为它常常连合并点都没有，补救靠**幂等设计 + 单调时钟 + 冲突检测重试**。 这条根因的直接推论：**并行的天花板不在算力，而在合并策略的设计能力**。一个 100 路扇出的系统，如果合并只是简单拼接，撕裂会让结果质量不升反降——这解释了为什么"四成五即反噬"会在加到一定人数后由正转负。把 reducer/扇入去重当作多智能体系统的第一公民来设计，是 2026 年从 demo 走向生产的分水岭。 ### 六、成本账与时序税：墙钟省的钱 token 还回去 把四式摊在成本账上看，会发现一个残酷的平衡——**时序省下的墙钟，几乎都被 token 吃回去**。串行接力 token 最省（ΣC），但墙钟最长；并行扇出墙钟最短（max(T)），但 token 膨胀最猛，Anthropic 实测约 15 倍单聊；流水线和事件驱动介于两者之间，但事件驱动的重算/重复订阅税常常隐形。 这意味着**时序选择本质是"买时间还是省钱"的资源置换**。对用户体感敏感的实时场景（客服、搜索摘要），花 token 买低延迟划算；对后台批处理（报表、批量分析），宁可串行慢跑省 token。训练营如果只教"并行更快"而不教"并行更贵"，学员上生产会被云账单毒打——必须把"延迟-成本-一致性"三维置换讲成可量化公式，而不是口号。 ### 七、选型决策：按依赖图选时序，而不是按框架选 四式不是优劣排序，而是**任务依赖图的不同映射**。决策只有一条主线：看子任务之间有没有依赖。完全独立（N 个检索、N 个文件分析）→ 并行扇出；严格链式依赖（A 的输出是 B 的输入）→ 串行接力；分阶段且阶段内可流式（研究→写→改）→ 流水线交叠；成员动态、触发条件复杂 → 事件驱动。 现实里多数生产系统是**混合时序**：外层流水线，每段内部并行扇出，关键审批节点串行接力，异常路径事件驱动。这种混搭才是 2026 年的主流形态，选型工具该问的不是"用哪个框架"，而是"这段依赖图配哪种时序最省且最稳"。 ## 时序四式架构图 ```mermaid flowchart TB subgraph SEQ["① 串行接力"] direction LR S1[A] --> S2[B] --> S3[C] end subgraph PAR["② 并行扇出 Map-Reduce"] direction TB O1[编排者] --> P1[子A] & P2[子B] & P3[子C] P1 & P2 & P3 --> M[扇入合并+去重] end subgraph PIP["③ 流水线交叠"] direction LR Q1[研究·流式] --> Q2[起草·流式] --> Q3[润色·流式] end subgraph EVT["④ 事件驱动"] direction TB E0([事件]) -.发布.-> EA[Actor A] & EB[Actor B] EA -.订阅.-> EB EB -.订阅.-> EA end In([输入任务]) --> D{依赖分析} D -->|链式依赖| SEQ D -->|子任务独立| PAR D -->|分阶段可流式| PIP D -->|成员动态触发复杂| EVT SEQ & PAR & PIP & EVT --> R{共享状态合并
有 reducer 吗?} R -->|无| X[撕裂:最后写入胜出] R -->|有| OK[一致性收敛] ``` ## 推荐方案 **强依赖、合规审计场景（金融审批、法律文书、医疗复核）**：首选串行接力。延迟痛点用"关键路径串行、旁路并行"缓解，但因果链上必须串行，可审计性优先于速度。 **独立子任务聚合场景（多源检索、批量分析、研究系统）**：首选并行扇出，但必须配套 reducer 或扇入去重。子智能体数量控制在 5–10 路以内性价比最高，超过这个数收益边际递减、合并税边际飙升，参考"四成五即反噬"的拐点。 **长任务、分阶段生产场景（内容工厂、连续报告、客服流水）**：首选流水线交叠。每个流式单元保证语义自洽，用背压控制防堆积，主打吞吐量而非单次延迟。 **探索性、异构协同、动态扩缩场景（多工具编排、在线研究集群）**：选事件驱动，但必须前置设计幂等、死锁检测、冲突重试，否则不可复现会拖垮运维。 **通用生产建议**：默认采用混合时序——外层流水线、段内并行扇出、关键节点串行接力、异常路径事件驱动，并把"共享状态合并策略"当作系统设计的第一评审项。 ## 参考来源 1. [How we built our multi-agent research system — Anthropic](https://www.anthropic.com/engineering/multi-agent-research-system) — orchestrator-worker 架构、并行子智能体比单智能体高 90.2%、token 约为单聊 15 倍的原始披露 2. [Parallelization Techniques — LangChain Academy (DeepWiki)](https://deepwiki.com/langchain-ai/langchain-academy/7.3-parallelization-techniques) — 并行节点执行、并发状态更新与 reducer 合并机制 3. [LangGraph Map-Reduce: Parallel Execution with Send API — MachineLearningPlus](https://machinelearningplus.com/gen-ai/langgraph-map-reduce-parallel-execution/) — Send API 动态扇出、fan-in 合并代码示例 4. [Multi-Agent Fan-Out: Scatter-Gather, Map-Reduce, and DAG Patterns — aitoolskit](https://www.aitoolskit.io/learn/multi-agent-fan-out-scatter-gather-architecture-2026) — 扇出放大吞吐同时放大成本与失败面的权衡分析 5. [Claude Code Dynamic Workflows: Spawning 100 Parallel Subagents on Opus — Groundy](https://groundy.com/articles/claude-code-dynamic-workflows-spawning-100-parallel-subagents-on-opus/) — 单线程扇出 100 子智能体的动态工作流实测 > [!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 等场景全覆盖。