并行工具调用：扇出易，聚合难

并行工具调用（Parallel Tool Calling）是 2026 年生产级 Agent 最被高估也最被低估的能力——高估在"60–80% 延迟红利"的营销话术，低估在它真正改变的是延迟分布的形状而非均值。一家 fintech 团队把财报分析 Agent 从 45 秒压到 12 秒靠的不是换模型，而是架构：依赖感知调度 + 推测预取。但另一家客服 booking Agent 盲目打开 parallel_tool_calls=true，p50 只快了 18%（而非预期的 60%），浪费调用率却从 0.3% 飙到 7.1%，还因为模型"猜"了一个 slot_id 把错误预约判为成功。本期聚焦一个与"框架并发内核横评"完全不同的轴：模型层扇出能力、聚合语义、浪费调用税与 p99 陷阱——扇出是模型一句话的事，聚合才是工程地狱。

与"并发内核横评"的边界

先划清红线：此前"并行调度内核六框架并发横评"评估的是框架的线程池/asyncio.gather/并发上限这层基础设施。本期不碰线程池，只问三个模型语义层的问题：模型能否在一轮里吐出 N 个工具调用（扇出）、N 个结果如何回灌并保证一致性（聚合）、以及这个开关打开后沉默地多花了多少钱（税）。两者正交：线程池再强，也救不了模型在依赖调用上瞎并发。

并行机制多维度对比

深度分析

一、扇出三式：参数开关、代码块、DAG 编排

维度	OpenAI parallel_tool_calls	Claude 程序化工具调用	LangGraph DAG 编排	推测执行层
并行触发层	模型在单条响应吐多个 tool_calls 对象	模型生成代码块，单块内调 20+ 工具	显式依赖图，调度器分波	工具执行期模型预测输出
并发上限	`max_tool_concurrency` 默认 8	代码块内天然并行，省 19+ 轮推理	按拓扑分层，每波并发	受预测窗口约束
依赖感知	弱（靠 prompt + strict schema）	中（代码可见变量依赖）	强（显式 DAG 边）	强（预测基于已知依赖）
聚合方式	tool_call_id 配对回灌，乱序可接受	代码块内变量直连，无回灌	reduce 节点显式合并	到达后校验，错则回滚
实测浪费调用率	0.3%→7.1%（裸开）	依赖工具标记正确性	低（依赖显式）	取决于预测命中率
p99 表现	平均快、尾延迟易恶化	省 19 轮推理显著降尾	受最慢波支配	预测命中则大幅降尾
上手难度	低（一个布尔位）	中（需理解代码执行）	高（要画依赖图）	高（需命中率评估）
变现/训练营	易做"延迟优化"课	适合代码型 Agent 课	适合架构师课	前沿、适合高阶课

并行扇出发生在三个完全不同的层，混淆它们是一切误读的源头。第一式是 OpenAI 的参数开关：自 gpt-4-turbo 起，chat completions 允许在一条 assistant 消息里吐出多个 tool_calls 条目，runtime 用 asyncio.gather 并发派发，结果按 tool_call_id 配对回灌。截至 openai-agents==0.9.0，max_tool_concurrency 默认 8。第二式是 Claude 的程序化工具调用：模型生成一个代码块，在块内直接调用 20+ 工具，这消除了 19 轮以上的模型推理往返——这是真正"消灭推理延迟"的打法，而非只是并发执行。第三式是 LangGraph/Auton 框架的 DAG 编排：把工具调用建模为有向无环图，调度器按拓扑序分波执行。三式的本质差异在于：参数开关把"是否并行"的决策权交给模型瞬时判断（最易出错），代码块让依赖在变量层面显式（较稳），DAG 则把依赖前置为编译期事实（最稳）。选哪式取决于你对依赖结构的确定性有多高。

二、依赖图：2026 的核心抽象是 DAG 不是扁平列表

今年生产架构最关键的认知转变是：工具调用不是扁平列表，而是 DAG。以一个定价研究 Agent 为例，它要：①抓竞品定价、②抓自家毛利、③搜市场新闻、④算建议价（依赖①②）、⑤起草备忘（依赖③④）。①②③彼此独立可全并行，④必须等①②，⑤必须等③④。朴素串行跑 5 批，依赖感知调度跑 3"波"。实现正确的 Plan-and-Execute 架构相比串行 ReAct 可达 3.6 倍加速，多步任务完成率逼近 92%。陷阱在于：推理模型（如 o3 系列）做思维链规划时，往往天然产出"必须串行"的调用序列——因为每步真的依赖上一步。把并行性强加给依赖调用，比老老实实串行更糟：拿到的是错误结果或被丢弃的计算。所以第一性原则是：先建模依赖结构，再谈并行，而不是反过来。

三、延迟账本与 Amdahl 天花板

延迟数学很诱人：n 个独立调用各耗时 T，串行成本 n×T，并行约等于 T（最长那次加调度开销）。对 3–5 个调用，这意味着 60–80% 的纯执行延迟下降。fintech 案例从 45 秒到 12 秒就是这条曲线。但 Amdahl 定律冷酷地给出了上限：若工作流 30% 本质串行（需要前序输出、人工审核、依赖中间态的决策），则无论加多少并行，理论最大加速约 1.4 倍。实践中 Agent 工作流的可并行比例通常只有 30–50%，对应最大可达加速 2–3 倍，而非一个数量级。那些测出 1.6–2.2 倍延迟改善的团队，数字是真的，但也正卡在 Amdahl 天花板上。代价是：获得这点加速需要付出 1.7–2.6 倍的 token 消耗。在每月 10 万次执行的规模下，一个设计糟糕的并行流水线能把成本从 500 美元推到 5 万美元——你是在用 token 税换延迟红利，这笔账必须算清。

四、p99 陷阱：方差相乘法则

并行扇出最阴险的副作用不是均值变慢，而是方差相乘。tianpan.co 记录了一个典型事故：把工作拆给 5 个并行子 Agent 后 p50 下降了，三天后值班告警炸了——p99 从 4 秒爬到 22 秒。原因是编排层在等最慢的那一个，而它撞上了只发生 1% 的检索抖动；但一旦某个请求同时触达全部 5 条路径，这 1% 就会被放大。概率论证很直接：若每个并行分支有 1% 概率变慢，则"至少一个变慢"的概率约 5%——是单 Agent 的五倍。当端到端延迟被最慢分支封顶，每条分支里的每个方差源都直接贡献到你的尾延迟。在每日百万用户规模下，p99=10 秒意味着每天有 1 万人在等超过 10 秒。把 p50 从 2.5 秒压到 1.8 秒帮不到任何已经走快路径的人；把 p99 从 6 秒推到 22 秒却会每天毁掉一批用户的体验。串行流水线每步只有一个尾方差源，扇出有 N 个——这是并行在尾延迟上常输给串行的根本原因。

五、浪费调用税：宣传 60%，实测 18%

CallSphere 在生产 booking Agent 上的实测给了最狠的一记耳光：在 gpt-4o-2024-08-06 上裸开 parallel_tool_calls=true，浪费调用率从 0.3% 飙到 7.1%，而 p50 延迟只降了 18%（不是宣传的 60%）。所谓浪费调用，指那些结果被丢弃或忽略的工具调用。最经典的失败模式：模型对 get_doctor_calendar 和 book_appointment 同时发起并行调用，给后者传了一个从用户消息"周二 3 点"猜出来的 slot_id，而不是等日历查询返回。预约对着一个陈旧的 slot 成功了，用户拿到确认，预约却是错的。更糟的是，最终答案评估给这次运行打 1.0 分（"assistant 说已预订"）——只有工具轨迹评估才能抓到。修复不是改一个 flag，是上一套四指标评估：延迟 p50/p95、单任务 token 成本（≤基线+5%）、最终答案正确率（≥0.95）、浪费并行调用（≤1.0%）。那个被几乎没人测的"浪费调用率"，才是"免费延迟红利"营销话术与"依赖调用上的沉默成本回退"现实之间的分水岭。

# 从 LangSmith 轨迹计算浪费调用率：结果未出现在下一步推理中的调用即"浪费"
def wasted_parallel_calls(run, example):
    tool_calls = [c for c in run.child_runs if c.run_type == "tool"]
    used = set()
    for step in run.child_runs:
        if step.run_type != "llm":
            continue
        for tc in tool_calls:
            if tc.outputs and any(str(v) in str(step.inputs) for v in tc.outputs.values()):
                used.add(tc.id)
    wasted = [tc for tc in tool_calls if tc.id not in used]
    return {"key": "wasted_parallel_calls",
            "score": 1.0 - (len(wasted) / max(len(tool_calls), 1))}

六、聚合塌方：tool_call_id、去重与部分失败一致性

扇出易，聚合难，难在四项协调税。第一是上下文合并：并行分支各自产出要喂给下游，必须缝合进连贯上下文，这步要么耗一次额外 LLM 调用、要么是一次非平凡的 reduce。一个四路扇出用 29000 token 完成单 Agent 10000 token 的活，并非多跑了 2.9 倍推理，而是把同样推理裹进了近 3 倍的协调胶水。第二是结果去重：并行 Agent 做相关子任务常产出重叠信息，不去重则下游被矛盾/冗余信号搞乱；去重又引入新的延迟且可能误并——把本该不同的结果压成一样，或漏掉需要裁决的冲突。第三是错误聚合延迟：串行管道里第二步出错立即中止；扇出里一条分支出错不会拦住其他分支跑完，编排器必须等所有分支结束（或超时）才能决定如何处理部分结果集——这段等待在任何单分支轨迹里不可见，却在端到端延迟里扎眼。第四是逐步协调开销：每次任务派发、结果收集、路由的协调动作加 50–200 毫秒；在一个实测的四 Agent 管道里，总协调开销 950 毫秒，而实际并行处理只花了 500 毫秒——协调开销几乎是它所协调的工作量的两倍。叠加效应是：生产基准上，单 Agent 在 64% 的评估任务上追平或胜过多 Agent 管道。

七、推测执行：借自 CPU 微架构的 2026 新层

今年冒出的最激进技术是推测执行（speculative execution），直接把 CPU 微架构的概念搬进 Agent 管道。思路是：当一个工具调用正在执行时，模型同步生成对该工具可能输出的预测，并基于这个预测开始计算下一步推理。当真实结果到达，系统校验预测：命中则白赚一整段提前计算；偏离则回滚并用真实结果重算。这是在"已知独立的并行"之外又榨一层延迟。它跟参数开关的区别在于：参数开关并发的是真实工具调用，推测执行并发的是"工具执行"与"基于预测的下游推理"，两者可叠加。代价是预测本身的推理开销加上回滚时的浪费——命中率低时反而更慢。它最适合工具输出分布集中、可预测性强的场景（如固定 schema 的查询、缓存友好的只读查找），对输出长尾、强随机性的工具（如开放搜索、生成式检索）则收益可疑。这是高阶工程，不是默认该开的开关。

八、决策框架：何时开并行、何时彻底关掉

落到可执行的默认值。全关并行的三类场景：一是语音 Agent 且 VAD（话音活动检测）窗口紧——当端到端预算低于 800 毫秒，并发派发对共享上游服务的方差比平均节省更致命，CallSphere 在其语音平台直接 parallel_tool_calls=false 配激进步缓存；二是纯变更工具集——若 Agent 装载的每个工具都写库，并行零收益且隐患大（竞态、部分失败）；三是工具数少于三个——模型本就很少选并行，strict schema 加 prompt 规则的臃肿成本不划算。混合场景的正确默认是"并行默认开 + 按工具 opt-out"：对 6+ 只读查找（日历、定价、档案、资格、历史、位置）配 1–2 个写操作（预订、取消）的医疗/房产预约 Agent，给写工具打 parallelizable=False，SDK 会把它串行化并在 schema 描述里植入模型可见提示（"此工具必须单独调用"），在 gpt-4.1 上把依赖并行错误从 7.1% 压到 0.4%。再配 strict=True 的 Pydantic schema（消灭"模型凭空编造 slot_id"那类幻觉）和一条 ~30 token 的显式 prompt 规则——A/B 测试显示没有这条规则，即便声明了 parallelizable=False，依赖并行率仍有 2.3%。

@function_tool(strict=True, parallelizable=False)   # 写工具永不并行
async def book_appointment(args: BookRequest) -> dict:
    return await booking_client.create(args)        # 依赖前序 lookup，必须串行

agent = Agent(
    model="gpt-4.1-2025-04-14",
    instructions="仅在调用间无共享输入时用并行；绝不在同一轮里既 lookup 又 book。",
    tools=[get_doctor_calendar, get_user_payment_method, book_appointment],
    parallel_tool_calls=True,
)
result = await Runner.run(agent, user_input, max_tool_concurrency=4)

DAG 波次执行与聚合校验架构

flowchart TB
    U[用户请求] --> P[Plan: 依赖图构建]
    P --> W1[波次 1: 并发扇出]
    W1 --> A1[① 抓竞品定价]
    W1 --> A2[② 抓自家毛利]
    W1 --> A3[③ 搜市场新闻]
    A1 --> AGG[聚合/去重 + tool_call_id 配对]
    A2 --> AGG
    A3 --> AGG
    AGG --> CHK{结果校验<br/>是否全部成功?}
    CHK -->|部分失败| PART[部分失败策略<br/>重试/降级/裁决]
    PART --> W2
    CHK -->|全部成功| W2[波次 2: 依赖调用]
    W2 --> B1[④ 算建议价<br/>依赖①②]
    B1 --> W3[波次 3]
    W3 --> C1[⑤ 起草备忘<br/>依赖③④]
    C1 --> OUT[最终答案]
    style W1 fill:#cfc
    style CHK fill:#fee
    style PART fill:#fed

图示要点：①②③ 构成第一波全并行（绿色），但必须经过聚合、去重与 tool_call_id 配对，并做部分失败校验（红色）后才能进入依赖波次。校验失败时触发部分失败策略——重试、降级或裁决，而非让最慢分支封顶 p99。这正是"扇出易、聚合难"的工程具象化：并行执行只占三个绿框，而把结果缝合回可继续推理的状态的那段管道（聚合→去重→配对→校验→部分失败处理）才是真正的工程量与失败高发区。

推荐方案

轻量只读 Agent（≤3 个独立工具）：直接用 OpenAI parallel_tool_calls=true 裸开即可，依赖少、浪费调用风险低，靠参数开关拿到接近 n×T → T 的延迟红利，无需上 DAG。

混合读写 Agent（6+ 只读 + 1–2 写，如预约/客服）：默认"并行开 + 写工具 parallelizable=False + strict schema + prompt 规则"，并强制上四指标评估，尤其监控浪费调用率 ≤1.0%。这是回报最高、也最该做成训练营案例的形态。

复杂多步研究/分析 Agent（依赖链深、波次多）：上 LangGraph 类 DAG 编排，用 Plan-and-Execute 把依赖前置为编译期事实，目标 3.6 倍加速；同时接受 1.7–2.6 倍 token 税，并明确这是用成本换延迟的主动决策。

超低延迟语音/实时 Agent（<800ms 预算）：关并行，转缓存 + 推测执行预取，避免 p99 方差相乘击穿 SLA。

变现与训练营评估：并行工具调用是天然的"性能优化"卖点课——延迟账本、Amdahl 天花板、浪费调用税、四指标评估都是可量化、可演示的硬核内容，适合做成"Agent 延迟优化实战"中阶课；推测执行与 DAG 波次编排则适合架构师高阶课。但核心警示必须贯穿：先建依赖图、先跑评估、再开开关，否则 60% 的营销红利会缩水成 18% 的实测，还附赠 7.1% 的沉默成本回退。