首页 › ai-agents › 并发即撕裂：时序四式实测

概述

多智能体系统的拓扑（谁连谁）已被反复拆解，但真正决定成败的另一个轴常被忽视——时序：多个智能体到底"同时跑"还是"排队跑"，是"边产边接"还是"被动响应"。同样的五节点拓扑，串行接力和并行扇出的端到端延迟能差出一个数量级，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 倍，因为每个子智能体都要独立装载规划、上下文和工具定义，编排者还要再做一次合并推理。更要命的是"撕裂"——并行子智能体互不可见，常基于相互矛盾的假设各干各的，合并时出现重复检索、口径冲突、单位不一。

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) 的极致低延迟，但比纯串行大幅压缩墙钟时间，同时吞吐量随流水线深度提升。典型形态是"研究→起草→润色"三段流式，或长文档的分块处理。

它的工程难点在背压与片段稳定性。下游智能体在收到不完整片段时容易基于局部信息下结论，等完整结果回流后又推翻自己，造成重算；上游吐得过快、下游消化不及则消息堆积。因此流水线式对"片段自洽性"要求高——每个流式单元必须语义完整，否则等于在并行扇出的撕裂风险上又叠了一层时序错位。

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 要靠运气；多个智能体响应同一事件可能触发级联激活，演变成活锁（互相反复唤醒）或死锁（互相等待对方消息）。在共享黑板上的并发读写如果没有协调，撕裂比并行扇出更隐蔽——因为连"合并点"都没有，状态在无人知晓处分叉。

# 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 年的主流形态，选型工具该问的不是"用哪个框架"，而是"这段依赖图配哪种时序最省且最稳"。

时序四式架构图

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{共享状态合并<br/>有 reducer 吗?}
    R -->|无| X[撕裂:最后写入胜出]
    R -->|有| OK[一致性收敛]

推荐方案

强依赖、合规审计场景（金融审批、法律文书、医疗复核）：首选串行接力。延迟痛点用"关键路径串行、旁路并行"缓解，但因果链上必须串行，可审计性优先于速度。

独立子任务聚合场景（多源检索、批量分析、研究系统）：首选并行扇出，但必须配套 reducer 或扇入去重。子智能体数量控制在 5–10 路以内性价比最高，超过这个数收益边际递减、合并税边际飙升，参考"四成五即反噬"的拐点。

长任务、分阶段生产场景（内容工厂、连续报告、客服流水）：首选流水线交叠。每个流式单元保证语义自洽，用背压控制防堆积，主打吞吐量而非单次延迟。

探索性、异构协同、动态扩缩场景（多工具编排、在线研究集群）：选事件驱动，但必须前置设计幂等、死锁检测、冲突重试，否则不可复现会拖垮运维。

通用生产建议：默认采用混合时序——外层流水线、段内并行扇出、关键节点串行接力、异常路径事件驱动，并把"共享状态合并策略"当作系统设计的第一评审项。

参考来源

  1. How we built our multi-agent research system — Anthropic — orchestrator-worker 架构、并行子智能体比单智能体高 90.2%、token 约为单聊 15 倍的原始披露
  2. Parallelization Techniques — LangChain Academy (DeepWiki) — 并行节点执行、并发状态更新与 reducer 合并机制
  3. LangGraph Map-Reduce: Parallel Execution with Send API — MachineLearningPlus — Send API 动态扇出、fan-in 合并代码示例
  4. Multi-Agent Fan-Out: Scatter-Gather, Map-Reduce, and DAG Patterns — aitoolskit — 扇出放大吞吐同时放大成本与失败面的权衡分析
  5. Claude Code Dynamic Workflows: Spawning 100 Parallel Subagents on Opus — Groundy — 单线程扇出 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 等场景全覆盖。

51学通信知识星球海报-扫码加入

📎 本分类最新文章