ARTICLE · 1325396
每日AI小知识|并行工具调用:模型一次就把三件事都交给你了
每日AI小知识|并行工具调用:模型一次就把三件事都交给你了每日 AI 小知识 · 第 039 期 并行工具调用：模型一次就把三件事都交给你了 为什么你的 Agent 明明能同时查三个接口，却还是一个一个排队 2026-11-04 | 阅读 7 分钟 | 难度 ★★★☆☆ 11 月 2 日，腾讯混元发布 AI 科研系统 Hyra 2.0。技术说明里有一段不起眼的话，把规模化 Agent 的调度骨架说得很清楚：「任务进入持久化队列后，调度系统根据优先级、依赖关系和资源上限启动 Worker。某项任务在等待训练结果或人工审批时，其他任务仍可继续。」队列、依赖、资源上限、等待期不空转——这四件事，正好就是「并行工具调用」的全部内容。今天就讲清楚：为什么绝大多数 Agent 的「并行」，其实是假的。 一、并行是默认状态，串行才是你加的 先说一个容易被忽略的事实：模型那边早就是并行的。一次响应里它可以返回多个工具调用，每个带独立的 id——OpenAI 的接口里有个 parallel_tool_calls 开关（默认允许），Anthropic 的一次回复里也可以有多个 tool_use 块。你给它三个独立的问题，它就会一次把三个调用都递过来。 关键在于：它递出这一批调用的时候，一个结果都还没看到。它给的不是「查完 A 再查 B」的计划，而是「这三件事看上去互不相干，你一起办了吧」的请求。而这个「看上去互不相干」是它的猜测，不是校验。 于是执行器要做两件相反的事 认出能并发的：三个只读查询、四个不同城市的天气、五份互不引用的文档摘要——该同时发就别排队。拦住不能并发的：模型偶尔会在一批里塞进「先建表、再插数据」这种有前后依赖的调用。它的规划里没有依赖图，你的执行器必须有。 所以「并行工具调用」真正要写的代码，不是 while 循环里改成 gather 那一下，而是把「谁依赖谁」这件事显式地写下来。 二、延迟账：收益上限由依赖图决定，不由决心决定 串行的耗时是各项相加，并发的耗时是最慢那个——这是中学算术。真正被忽略的是它的上限：如果 A 的输出是 B 的输入，那 A、B 之间那条边就锁死了，无论你开多少并发都跨不过去。 T_p ≥ max( W / p , C ) W 是总工作量（所有调用耗时之和），p 是并发度，C 是关键路径（依赖图上最长的那条链）。前一项说「人不够」，后一项说「顺序不允许」。工程上真正卡人的几乎总是后一项。 拿一个具体的 Agent 任务算一遍：三个独立查询（查文档 0.8s、查库存 0.6s、查物流 1.2s），外加一个依赖库存结果的报价（0.9s）。 
注意那个 0.60s。分层的写法是「等这一层全部完成，再开下一层」，于是第一层里查物流要 1.2s，查库存 0.6s 就完事了却得陪着等，报价明明可以 0.6s 就出发，硬是拖到 1.2s。这 0.60s 就是栅栏税，占理论最优解的 40%。只要把「按层同步」换成「谁的前置完成谁就走」，这笔税就没了——代价是你得写一个依赖图，而不是一个嵌套的 gather。 三、三种执行方式 + 一张四问决策表 ① 串行 await —— 3.50s 一个 for 循环挨个等。实现最简单、日志最好读、出错最好定位。强依赖链、需要人看每一步、写操作就该这么干。它不是「落后写法」。 ② 分层 gather —— 2.10s 拓扑分层，同层 gather。代码短、容易讲清楚，但每层要等同层最慢的。四五个调用、层数只有两三层时，它已经能拿到八成效用。 ③ 就绪即跑 —— 1.50s 维护一个「剩余前置数」，谁归零谁立刻进队列。没有栅栏，只有依赖。代价是要自己管完成回调和并发上限——也正是后面那两个代码块要做的事。 但「能并发」只是第一关。上线前还有三关要过，四个问题按顺序问下来，能挡掉九成的翻车： A · 能不能并发？看依赖。B 的入参来自 A 的输出，就不能。B · 该不该并发？看副作用。只读、探测、带幂等键的写，可以；改同一条记录、写同一个文件，不行。C · 允许多大？看下游配额。并发度由限流反推，不由工具个数决定。D · 值不值得？看上下文成本。并行结果是一次性回填的，8 个结果各 2000 token，就是一口气塞 16K 进去，模型还要在这堆东西里找关联。 这四个问题里，A 是正确性，B 是正确性，C 是稳定性，只有 D 是性能。而绝大多数人是从 D 开始想的。 四、五个坑，一个比一个安静 ① 按到达顺序回填。gather 返回的列表顺序和完成顺序无关，但很多人拿 zip(names, results) 就配上了。更隐蔽的写法是按 asyncio.as_completed 的产出顺序追加——谁先回来谁排前面，于是「天气」的结果被填进了「库存」的位置。永远按 tool_call_id 回填。 ② 一个失败就当全批失败。默认的 gather 是「一个抛异常，整体抛异常」——另外两个白跑，钱白花。但 all-or-nothing 只在真有事务语义时才成立；查三个独立数据源，挂一个不该让另外两个作废。 ③ 写操作并发。同一份配置文件被两个 patch 同时改，后写的覆盖先写的，而且两条日志都显示「成功」。写操作要么串行，要么带版本号做乐观锁，要么按资源分片——没有第三条路。 ④ 超时预算没按批重算。串行时五个调用各 10s 超时，最坏 50s；并发后整批仍然是 10s。这个变化本身是好事，但反过来——预算只剩 0.8s 时，就别再发那个需要 0.9s 的调用。并发让「注定失败还要发」变得特别伤：一次批量重试就能把配额打穿。 ⑤ 并发度直接等于工具数。p 从 1 写到 8，QPS 立刻变 8 倍，429 一来，重试再乘一遍——第 036 期讲过的「重试放大」在这里有个天然的温床。并发度必须由下游配额反推。 五、开发实践：两个能直接抄的骨架 第一段：分层调度器。信号量管并发上限，按 tool_call_id 回填，依赖成环直接报错而不是死循环。 
第二段：部分失败与预算重算。return_exceptions=True 让失败变成数据，然后看剩余预算决定下一个调用还发不发。 
上线前对照这 8 条 1. 每个工具标注「只读 / 幂等写 / 非幂等写」2. 依赖关系显式成图，不靠注释口头约定3. 结果按 tool_call_id 回填，不按列表下标4. 并发度由下游配额反推，默认不超过配额的 1/25. 整批一个 deadline，单次超时 = 剩余预算6. return_exceptions=True，失败降级为数据7. 非幂等写一律串行，或带版本号做乐观锁8. 并行结果进上下文前先截断/摘要，别整块塞 六、今日 AI 快讯 11 月 2 日 · 腾讯混元 Hyra 2.0：把调度写进论文 Overall / Mission / Worker 三层分工，任务进持久化队列，调度器按优先级、依赖与资源上限启动 Worker；等训练结果或人工审批时，其他任务继续跑；需要独立验证时另起一个 Review Worker，让它先看原始问题与证据，避免被执行者的结论带偏。——和我们今天讲的完全是同一套东西，只是规模大了一个量级：并行研究的瓶颈从来不在「能不能同时跑」，而在「知道谁依赖谁、谁该复核谁」。 11 月 2 日 · 月之暗面 Kimi 发布游戏开发方案 基于 Kimi K3.1 系列模型、Kimi Code 与 Kimi Work，接入 Unity、虚幻引擎、Blender 等插件，可直接操作编辑器里的现有工程，交付可继续编辑的文件与操作记录；官方称一次演示中模型无人工干预连续工作 20 小时。——工具调用一旦从「调一次接口」变成「连续改二十小时工程」，并发与依赖管理就从优化项变成了必需品。 11 月 3 日 · 优必选发布具身智能仿真平台 Thinker-Sim 以 Real2Sim2Real 为核心，覆盖真实场景数字化、仿真数据合成与机器人能力评测；数据环节支持多节点并行仿真，评测时随机调整光照、纹理、材质以检验鲁棒性。——这条放在第三条是有意的：并行不只是应用层的调度技巧，在数据与训练层，它就是产能本身。 七、30 秒自测 1. 模型一次返回三个 tool_call，它知道这三个之间有没有依赖吗？2. 加速比的天花板由什么决定？为什么加机器没用？3. 「按层 gather」和「就绪即跑」差的到底是什么？4. 为什么 gather 的结果不能按列表下标回填？5. 并发度提高后，单次调用的超时应该怎么设？答案：1. 不知道，它只是猜这些调用互不相干，依赖校验必须由执行器做。2. 由关键路径决定，即 T ≥ max(W/p, C)；链上的先后关系不因加机器而缩短。3. 差的是一道栅栏：层内要等同层最慢的，本例白等 0.60s，占最优解 40%。4. 完成顺序与提交顺序无关，错位后结果会被填进别人的位置，且日志看不出异常。5. 不能再给固定值，要用「整批 deadline − 已耗时」作为剩余预算，不够就不要发。 ONE THING TO REMEMBER 并行的上限不是模型给了几个 tool_call，而是你的依赖图有多短；加速比真正的敌人也不是串行，是那道「等整层一起过」的栅栏。 明日预告：背压与排队论为什么机器加了 3 倍，P99 反而更慢了 每日 AI 小知识 · 每天 5 分钟，基础 · 开发 · 资讯第 039 期 · 2026-11-04 撰稿 · 审校：杨同学 本文由 AI 辅助创作，经人工审校后发布。内容仅供参考，请自行核实。
