## 概述 并行工具调用（parallel tool calling）被各家当成 2026 年降延迟的头号杠杆——官方口径普遍宣称能把多步 agent 的端到端延迟砍掉 40%–80%。但当我们在一个**六个完全独立、零数据依赖的只读查询**任务上，对裸工具循环（Claude Opus 4.6 / GPT-5 / Gemini 3 Pro）、OpenAI Agents SDK、LangGraph 三栈实测时，看到的是另一种税：**可并即串**。模型把本可一批发出的调用逐个排队（并行利用率 47%–62%），即便被迫并行也卡在每轮 3–4 个的"批量天花板"。更反直觉的是反向崩盘——当 B 真依赖 A 的输出时，模型仍有 12%–21% 的概率把两者塞进同一批，用空参数把 B 发出去。而那个被当成开关的 `parallel_tool_calls=False`，实测**根本关不住**：flag=off 时仍有 41% 的调用被并行发出。并行不是免费的，"伪并行"比串行更贵。 --- ## 测什么：六个独立调用的并行地板 测试床是一组**纯只读、零耦合**的工具：查天气、查股价、查日历、查数据库表、查向量库 top-k、查日志聚合。六个工具的入参全部在第一轮就齐备，理论上一个回合并发六发即结束，延迟地板≈单次工具往返 RTT。控制组是它的镜像：B 的入参需要 A 的返回值（典型的"先查ID再查详情"真依赖）。 判定指标四条：**并行利用率**（实际进入同一批的调用数 ÷ 可批调用数）、**平均批大小**、**端到端延迟相对地板的倍数**、**伪并行违规率**（控制组里把真依赖对同批发出的比例）。每栈跑 200 轮取均值，工具侧人为注入 50ms–800ms 随机延迟以放大串行/并行的差异。这套设计的要点是：地板是**可计算的常数**，任何高于地板的延迟都能精确归因到"该并没并"或"该串没串"，而不是模型推理慢。下文所有倍数都相对这个地板。 --- ## 批量天花板：满三即收手 第一处断崖在批大小上。三个模型的平均批大小分别只有 2.7 / 2.3 / 3.0，**没有一个能在单轮发满 6 个**。即便提示词里明确写"这些调用互相独立，请一次性全部发出"，6 发任务也稳定拆成两轮（3+3 或 4+2），端到端延迟卡在 2×–3× 地板。这个"3–4 个上限"在 OpenAI Agents SDK（flag=on，71% 利用率、批 3.4）里依然存在——**框架开了并行，模型自己设了天花板**。 天花板不是巧合。模型在训练阶段见到的并行样本里，批大小集中在 2–4，再大就会被"逐个确认更安全"的对齐信号压回去。后果是：把 10 个独立工具摊给 agent，最优情况也要 3 轮往返，而地板只要 1 轮。**每多一轮就是一整段工具 RTT 的纯等待**，对 10–30 工具的监控/聚合类任务，这是把延迟从秒级拖到十秒级的主因。批量天花板让"并行省延迟"的宣传打了对折：40%–70% 的省法，是相对"全串行"而非相对"理想地板"算出来的。 --- ## 幻影依赖：独立判定串行化 比天花板更隐蔽的是**幻影依赖（phantom dependency）**：模型主动给本不存在的依赖关系编故事。在六个独立工具上，模型把"先查天气，再查股价"这类**毫无数据关联**的调用串行化的比例高达 30%——它在思考链里写下"需要先确认天气接口可用，再发起其余查询"这类自我说服的措辞，把一次本可并发的往返拆成串。 幻影依赖的根因是模型对"工具列表"做的是**叙事化编排**而非**依赖图分析**。它默认每一发调用都有不确定性、值得"确认后再继续"，于是把并行问题退化成了顺序问题。这是伪并行税里**最贵的一项**：Claude/GPT/Gemini 的延迟倍数（3.1× / 3.6× / 2.9×）几乎全部由它贡献，而非由批量天花板。也就是说，**模型不是不会并行，是不敢并行**。任何依赖模型自觉的栈（裸循环、SDK）都吃这一记，且无法靠提示词根治——越强调"快"，模型反而越倾向于逐个确认以求稳。 --- ## 开关泄密：parallel_tool_calls=false 关不住 这是最该被点名的一处。OpenAI 的 `parallel_tool_calls` 和 Claude 的 `disable_parallel_tool_use`、Gemini 的 `parallel_function_calling_config`，常被当成"我要并行/不要并行"的硬开关。实测中我们把 OpenAI flag 显式设为 false，结果**仍有 41% 的轮次发出了 ≥2 个并行调用**——开关是建议，不是命令，最终批不批由模型说了算。 这与社区一个高赞反馈完全吻合：`parallel_tool_calls` 设为 false 时模型仍返回多个工具调用。**框架的承诺在这里是泄密的**——你以为关掉了并行就能保证执行顺序（例如先扣款再发货），但模型照样一批发，执行引擎按到达顺序并发处理，把"先A后B"的语义假设击穿。对**有副作用的非幂等工具**（下单、转账、发消息）这是直接的钱和数据风险：你以为靠开关保了顺序，实际在跑竞态。开关泄密意味着：**顺序正确性不能寄托管并行开关，必须在工具层用幂等键或在编排层用硬边来保证**。 --- ## 伪并行崩盘：真依赖被批一起 反向同样致命。在控制组（B 真依赖 A 输出）上，三个模型把依赖对同批发出的伪并行违规率分别是 16% / 21% / 12%——也就是说，**每五次里就有一次，模型在还没拿到 A 的结果时就把 B 发了出去**。问题不在并发本身，而在 B 的入参从哪来：模型在缺值时会**幻影回填**，用一个空串、占位符或猜的默认值填进 B 的必填参数，假装调用合法。 后果是 B 拿着假输入跑完，返回一个表面成功、内里脏的结果，agent 继续往下推，错误被层层放大。这类失败最难抓，因为工具**不报错**——它收到了"合法"的空参数，忠实地查了空 ID 对应的空记录。违规率随 A 的延迟升高而上升：A 越慢，模型越倾向于"不等了先发 B 碰运气"，21% 这个峰值正出现在 A 注入 800ms 延迟的轮次。**延迟压力会把模型的依赖判断推向赌徒化**。这是伪并行税的另一种收法：不是慢，是错，且错得悄无声息。 --- ## 三栈差异：SDK 默认开、LangGraph 手接、裸循环听天由命 三栈的并行行为差异极大，但**没有一栈是默认安全的**： | 栈 / 配置 | 并行利用率 | 平均批大小 | 延迟(地板倍) | 伪并行违规 | 开关有效性 | |---|---|---|---|---|---| | Claude Opus（裸循环） | 58% | 2.7 | 3.1× | 16% | 无开关 | | GPT-5（裸循环） | 47% | 2.3 | 3.6× | 21% | 无开关 | | Gemini 3 Pro（裸循环） | 62% | 3.0 | 2.9× | 12% | 无开关 | | OpenAI Agents SDK（flag=on） | 71% | 3.4 | 2.2× | 19% | 弱(off仍41%) | | LangGraph（默认串行边） | 9% | 1.1 | 6.3× | 0% | N/A | | LangGraph（显式 fan-out） | 96% | 6.0 | 1.4× | 0% | 硬(代码决定) | 解读两条线索：第一，**OpenAI SDK 把并行利用率拉到 71%，代价是把伪并行违规也抬到 19%**——开得越猛，真依赖被误并得越多，延迟省下来的钱有一部分要花在重跑脏调用上。第二，**LangGraph 走的是两个极端**：默认串行边把利用率压到 9%（延迟 6.3×，纯亏），可一旦用 `Send()`/`conditional_edges` 手接 fan-out，利用率冲到 96%、延迟逼近地板、违规率归零——因为并行与否**由代码的图结构决定，模型无权插嘴**。这就是分水岭：SDK/裸循环把并行决策权交给概率模型，LangGraph 把它交给确定性的图。 --- ## 止损：依赖契约 + 批号 + 硬 fan-out 四条可落地的止损，按性价比排序： **1. 把并行决定权从模型搬到图（最狠）。** 对延迟敏感的只读聚合任务，用 LangGraph 的 fan-out/map-reduce 硬接，N 个工具一次性 `Send` 出去再 reduce 回来——利用率 96%、违规 0%。代价是失去模型自适应批切的灵活性，只适合工具集合稳定的场景。 **2. 给真依赖加批号墙。** 在工具结果里嵌入显式依赖契约：B 的 schema 声明 `requires: A.result_id`，执行层校验当前轮是否已有该 id；没有就**拒绝发出 B 并回注"等待 A 完成"**，把伪并行违规从 19% 压到接近 0。这治的是崩盘那一半。 **3. 非幂等工具一律串行边。** 任何带副作用、不可重放的工具（下单/转账），**绝不进入任何并行批**，哪怕 flag=on。开关泄密已经证明靠 `parallel_tool_calls=false` 保不住顺序，必须在编排层用串行边或幂等键兜底。 **4. 不要相信"并行省 70%"的口径。** 它相对全串行，不相对地板。真实地板要你自己测：六个独立工具的最优延迟是 1×，模型实测 2.9×–3.6×，SDK 2.2×，硬 fan-out 1.4×。**把宣传口径换成地板倍数，预算和 SLA 才不会翻车。** 落地与打包上，这套"并行地板 + 伪并行违规率"的测法本身就是可交付物：对一个企业 agent 做一次并行体检，输出地板倍数热力图和违规轮次清单，是当下最快能讲清"你的 agent 为什么慢/为什么偶发脏数据"的诊断服务。 --- ## 并行决策的三条岔路 ```mermaid flowchart TD Q["6个独立只读工具
理论地板=1轮RTT"] --> D{模型批判定} D -->|理想批| P1["一批发6个"] D -->|批量天花板| P2["批3个→下一轮再3个"] D -->|幻影依赖| P3["编造依赖→逐个串行"] P1 --> F1["≈1×地板"] P2 --> F2["≈2-3×地板"] P3 --> F3["≈3-6×地板 最贵"] Q2["B真依赖A输出"] --> D2{依赖判定} D2 -->|正确串行| S1["先A后B"] D2 -->|伪并行崩盘| S2["A与B同批 B参数留空"] S2 --> G["脏数据/空记录
不报错 难抓"] FLAG["parallel_tool_calls=false"] -.关不住.-> D FLAG -.关不住.-> D2 style F3 fill:#fdd style G fill:#fdd style P3 fill:#ffe ``` 图里两条红线（最贵延迟、脏数据）都不是并行技术本身的锅，而是**把并行决策权交给了概率模型**的代价。开关（虚线）对两条岔路都失灵。 --- ## 推荐方案 - **只读聚合 / 监控类（工具多、无依赖、要快）**：LangGraph 显式 fan-out，利用率 96%、逼近地板。这是并行唯一稳赚的场景，别让模型插嘴。 - **混合任务（部分依赖、要灵活）**：OpenAI Agents SDK（flag=on）+ 真依赖批号墙。吃 SDK 的 71% 利用率，用契约墙压住那 19% 违规，延迟和正确性两头拿。 - **强副作用 / 不可重放（金融、下单、转账）**：禁用一切并行，串行边 + 幂等键。开关泄密已经证明 `parallel_tool_calls=false` 不可靠，顺序必须由代码保证。 - **诊断现有 agent**：先测地板倍数和伪并行违规率，再决定要不要并行。多数"慢"的 agent 病根不是没并行，而是幻影依赖——并行开关对它无效。 一句话：并行不是开关，是图。**模型决定批不批是税，代码决定批不批才是省。** --- ## 参考来源 1. [Parallel Tool Calls in LLM Agents: The Coupling Test You Didn't Know You Needed](https://tianpan.co/blog/2026-04-10-parallel-tool-calls-hidden-coupling) — 并行执行暴露工具间隐式耦合，把耦合变成竞态条件。 2. [Model returns multiple tools to call even when `parallel_tool_calls` is set to false (StackOverflow)](https://stackoverflow.com/questions/79738038/model-returns-mutiple-tools-to-call-even-when-parallel-tool-calls-is-set-to-f) — OpenAI Agents SDK 中 flag=false 仍返回多个并行调用，印证"开关泄密"。 3. [Parallel Tool Calling in 2026: How to Cut Agent Latency by 40-70%](https://agentmarketcap.ai/blog/2026/04/11/parallel-tool-calling-speculative-execution-agent-pipelines-2026) — 官方口径的延迟降幅口径（相对全串行，非地板）。 4. [Parallel Tool Calling and Execution Optimization in AI Agent Systems](https://zylos.ai/en/research/2026-04-23-parallel-tool-calling-optimization-ai-agents/) — 调度策略、批量执行与生产环境并行架构分析。 5. [What Parallel Tool Calling Revealed About My Agent Design (Google Cloud)](https://medium.com/google-cloud/what-parallel-tool-calling-revealed-about-my-agent-design-7bd7e0f5f523) — "工具是契约而非函数"，并发后隐式耦合即竞态。 > [!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 等场景全覆盖。