一句话：并行工具调用（Parallel Tool Calling）指模型在一次回复里同时发出多个工具调用请求，而不是等上一个调用返回结果再发下一个。
它省的是什么
模型自己不执行任何工具，它只输出“要调天气接口，参数是北京”“要调汇率接口，参数是 USD/CNY”这样的请求，真正执行的是外面的 Agent 运行时。
打个比方：把模型当成项目经理，一次把三张工单同时派给三个人，而不是派一张、等回来、再派下一张。总耗时约等于最慢的那一张，不是三张相加。
要点在于：省的是墙钟时间（延迟），不是上下文。恰恰相反——每次调用的请求和结果都要进对话历史，n 个并行调用通常比串行更费 token，因为结果会一股脑塞回来。
什么时候不能并行
前提是这些调用互不依赖。先查订单号、再凭订单号查物流，就只能串行。模型偶尔会判断失误，把有依赖的调用并行发出去，第二个调用只能拿到它自己编的参数；有些运行时会做依赖校验，把这类调用挡回来重排。
| 维度 | 串行调用 | 并行调用 |
|---|---|---|
| 端到端耗时 | 各步相加 | 约等于最慢的一步 |
| 上下文占用 | 通常更省 | 通常更费 |
| 前提 | 无 | 调用之间互不依赖 |
| 失败影响 | 一步失败，后续不执行 | 可能只挂掉其中一部分 |
失败了怎么收场
并行最容易被忽略的一点：它不是“全成或全败”的事务。三个调用里两个成功、一个超时，是常态。常见做法：
1. 把错误当结果返回。不要直接抛异常中断流程，而是把错误信息作为该次调用的返回内容交回模型，让它自己决定重试、换参数还是放弃。
2. 按调用 ID 一一对应。结果归位不能靠顺序去猜。
3. 工具尽量幂等。超时重试会重复触发副作用，写操作被重发两次就是两单。读操作可以放心重试，写操作要么带幂等键，要么别并行。
4. 设并发上限和单次超时。外部接口有速率限制，几十个并发砸过去，本来不失败也会被打成失败。
5. 部分成功时的整体语义——继续、降级还是回滚——通常由应用层决定，模型给不了事务保证。
和相邻概念的区别
并行工具调用是模型在一次回复里发多个调用；批量请求（batching）是应用层把多个请求打包并发出去，模型不参与决策；多智能体并行则是多个 agent 同时干活，粒度和协调方式都不同。
实际意义
对做 Agent 的人，这是低垂的果实：不改模型，光是让运行时支持一次回复多调用、把结果按 ID 归位，就能把“查三家供应商报价”这类任务的等待时间砍掉大半。代价是上下文更贵、错误处理更麻烦、工具得幂等。
对普通职场人，体感就是 agent 变快了——但前提是它派出去的活儿真的互不相干。看到 agent 同时提交三个互相依赖的操作，那通常是 bug，不是效率。
各家模型和框架对并行的支持程度与接口细节，以官方页面为准。