并行调用工具可显著降低响应时延

工具调用一多，最让人崩溃的往往不是模型“想得慢”，而是它像排队买咖啡一样：先查一项，再等结果，再查下一项。明明几个信息互不依赖，却被串成了长队。对用户而言，这段等待没有任何价值；对系统而言，它还会把后续判断全部堵在路上。

我更愿意把并行调用理解成“缩短关键路径”，而不是单纯追求同时发更多请求。比如一个任务既要查询信息、检查状态，又要准备后续所需的数据，只要这些动作彼此不依赖，就可以一起发起，等结果陆续回来后再进入下一轮判断。原本需要逐个等待的时间，会被压缩到其中最慢的那一步，响应体感往往会立刻好很多。

但并行不是越猛越好。外部工具可能有资源限制，也可能偶尔失败；一口气放出太多调用，反而会带来拥塞、重试和更长的尾部等待。比较稳妥的做法，是先把工具按依赖关系拆开：必须拿到前一步结果才能继续的，保持串行；可以独立完成的，再交给运行环境并发调度。Harness 这类能够处理工具与执行循环的环境，价值就在于让这条链路更容易被看见和调整。

另一个容易忽略的问题是重复调用。工具描述不清、返回内容太散，智能体就可能反复试探，甚至已经拿到答案还再查一次。并行只能加快有效动作，不能拯救无效动作。先让工具职责明确、结果紧凑，再给任务设定退出条件，才能避免“跑得更快，但跑错更多”。

我会先记录每次任务里各个工具的耗时、调用轮数和重试情况，再决定哪里该并行。别一上来就改一堆配置：如果真正慢的是某个外部工具，调整模型推理强度并不会解决问题。把独立等待重叠起来，把无效步骤砍掉，响应变快通常没那么玄学。