先看跑出来的效果

别急着看代码，先看结果。下面这段是我真实跑出来的，DeepSeek 模型。输出一字没动：

语言"
read read read
def main:
print
fn main { println!，}
console.log;三个文件的内容和语言如下：…其实，a.rs 是 Rust，b.py 是 Python。c.ts 是 TypeScript…

使用者痛点：同一个 里出现了三个 调用。模型一次性发出，却因为旧实现的串行循环，需要来回三轮才完成，这让等待时间从几秒膨胀到十五秒。

我盯着日志看了两遍，注意到两件事：

• 同一个 里冒出了三个 ——模型一次请求就甩了三个调用过来我们接住了一起跑。换上一章那个串行循环做一样的事，得来回三轮。而且有些模型甚至保守到一轮只能一个。
• 的顺序和 不对齐。说起来，调用是 a、b、c 的次序，结果回来 b.py 却排在最前面。我第一反应是 bug，查了半天才发现不是：并发嘛。 谁先跑完谁先返回，乱序才是真实的信号。记住这个“乱序”——后面你会看到。它只能出现在一个地方，换个别的地方乱序就是事故。

整章目标

整章跑完，你会拿到这样一个循环：准备阶段串行、执行阶段并行、结果按原始次序回填、遇到危险工具自动退回串行、还支持工具主动结束。

瓶颈一直在我们这边

使用者痛点：并行不需要模型配合——协议本身已经支持一次发送多个 tool_calls。真正卡住的是我们自己的实现，用 for...of + await 把所有工具强制串行。

for {
const result = await executeOne;// ← 一个 await 完才轮到下一个
messages.push;按理说，}

User Pain Point: 当工具是轻量的 read 时影响不大。但如果是耗时五秒的 bash 命令，串行会导致明显的 UI 卡顿和无意义的等待。

至于第一刀，Promise.all

最直接的改法。把 for...ofPROMISE.ALL

const results = await Promise.all(
assistant.tool_calls.map => {
const tool = opts.tools.find => t.name === tc.name);await emit，const r = await runOne;await emit，return r;})
)，for {
messages.push;其实，}