07. 并行工具调用真的更快吗

本次只读任务需要获取当前路径并列出目录。Kimi 在第一轮同时发起两个 Bash 调用；Codex 则把两个读取动作组合进一条 Shell 命令。

从最终答案看，两者都完成了任务。但运行时面对的是三种不同策略：

理论上能节省多少时间

若两个独立工具耗时分别为 t1 和 t2，忽略调度开销：

串行时间 ≈ t1 + t2
并行时间 ≈ max(t1, t2)

但模型调用、权限检查、进程启动、结果序列化和限流都会增加固定开销。两个各耗时 8 毫秒的本地读取，即使并行，端到端差异也可能小于一次模型请求的波动。

只有没有依赖的动作才能并行

以下任务不能直接并发：

• 先创建目录，再向目录写文件。
• 先获取认证信息，再请求接口。
• 先读取配置，再根据配置选择目标。
• 两个调用修改同一资源。

依赖关系应由运行时或计划结构表示，不能只依靠模型在自然语言里记住。

部分失败是并行的主要成本

两个调用同时执行，可能出现一个完成、一个超时。运行时需要决定：

若把整个批次表示成“失败”，重试会重复已经完成的动作。对于发送消息、创建订单等操作，这种重复可能产生外部副作用。

并发还会放大资源压力

模型一次提出十个网络请求，不表示运行时应同时启动十个连接。执行器还要实施：

• 全局并发上限。
• 单工具并发上限。
• 单域名速率限制。
• 总运行时间与总输出上限。
• 取消信号和超时。

这些限制属于运行时配置，不应由模型参数自行覆盖。

怎样比较才有意义

我会选择三组工具：

1. 两个 10 毫秒的本地读取。
2. 两个 500 毫秒的独立网络模拟。
3. 一个成功、一个固定超时的组合。

每组分别运行串行、并行和命令合并 30 次，记录 P50 与 P95 延迟；P50 是一半样本低于该值，P95 是 95% 样本低于该值。同时记录工具调用数、部分失败恢复次数和重复副作用次数。

并行不是 Agent 能力的等级标志。它只适用于可以证明互不依赖、能够独立授权且结果可以正确归并的动作。运行时间缩短多少，要由端到端数据回答。