docs(plan): 记录更新前后全面压测结果与部署前置条件

两版隔离实例实测（规模 3 = 288 条输入），核心差异是**处理数**而非耗时：
旧版 openai.lua 缺 stream_index 透传 ⇒ 多个分片并到槽 0、参数混拼 ⇒
工具一个都没真跑，却因为「少干活」而耗时更短。

    !slowbatch8   旧 0.220s / 0 个  →  新 0.409s / 8 个
    并发 vs 强制串行（新版内部）      N=8 加速 3.88×
    调度器轰炸 288 输入             两版均 100% 通过
    连续稳定性 20 轮                两版均无错误、内核无 panic

规模 1（32 条）与规模 3（288 条）结果完全一致 ⇒ 可复现。

同时记录部署前置条件：生产是 -tags=onnxruntime 构建（strip 后 75MB vs
普通构建 28MB），package-linux.sh:139 会显式拒绝非 onnxruntime 构建。
本次改动未触及任何 ONNX 路径，故压测结论对生产成立，但必须走
deploy/packaging/build.sh 才能部署。

docs/zh/toolcall-parallel-execution-plan.md

@@ -327,3 +327,65 @@ P3 落地时暴露的**真实缺陷**（不是新需求）：
 4. **期望值由独立来源算出**，不引用被测代码。
 5. **每阶段结束跑全包** `go test ./internal/agent/core/ -count=1`，
    并检查存量插件 smoke 无新增 FAIL。
+
+---
+
+## 附：更新前后全面压测结果（2026-09-27）
+
+方法：两版内核（旧 `85e3d66` / 新 `d3eaff4`）在**隔离 netns** 内各起一个实例，
+共用同一个 mock LLM（保证 LLM 行为完全一致，消除变量），驱动脚本
+`scripts/kernel-stress/cmp.py`。规模 3 = 24 连接 × 12 输入 = 288 条。
+
+### 批内工具调用（核心差异）
+
+| 场景 | 旧版 中位/工具数 | 新版 中位/工具数 |
+|---|---|---|
+| `!slowbatch2` | 0.221s / **0 个** | 0.380s / **2 个** |
+| `!slowbatch4` | 0.222s / **0 个** | 0.399s / **4 个** |
+| `!slowbatch8` | 0.220s / **0 个** | 0.409s / **8 个** |
+
+★ **旧版"更快"是假的**：它的 `openai.lua` 缺 `stream_index` 透传，多个分片
+并到槽 0、argsRaw 混拼 ⇒ 每个工具报「参数不是合法 JSON」而**一个都没真跑**。
+这正是「只看耗时会被骗」的典型，所以 cmp.py 每轮都记录**处理数**并把它当作
+通过条件之一。
+
+### 并发 vs 强制串行（新版内部对照）
+
+`!slowbatchN`（全部 ParallelSafe ⇒ 并发）vs `!serialbatchN`（混入
+`knowledge_create` ⇒ 整批降级）：
+
+| N | 并发 | 强制串行 | 加速 |
+|---|---|---|---|
+| 2 | 0.378s | 0.532s | 1.41× |
+| 4 | 0.389s | 0.864s | 2.22× |
+| 8 | 0.409s | 1.585s | **3.88×** |
+
+并发批耗时**几乎不随 N 增长**，串行批严格线性 ⇒ N 越大加速比越贴近上限。
+
+### 通过率与稳定性
+
+| 维度 | 旧版 | 新版 |
+|---|---|---|
+| 调度器并发轰炸（288 输入） | 288/288 **100%** | 288/288 **100%** |
+| 连续稳定性（20 轮无错误） | 20/20 | 20/20 |
+| 内核队列 / 拒绝 / panic | 空 / 0 / 无 | 空 / 0 / 无 |
+
+规模 1（32 输入）与规模 3（288 输入）结果**完全一致** ⇒ 可复现，非偶然。
+
+### 本次改动与 ONNX 无关
+
+79 个改动文件全部集中在：内核并发调度（22）、seq 插件（15）、Lua 适配器（17）、
+压测脚本（4）、SDK（3）、io（3）、cmd 插件（2）。**未触及** `distill.go` /
+`onnx.go` / `nlp`，而工具调用路径本身不经过 ONNX ⇒ 上面的结论对生产成立。
+
+### ⚠ 部署前置条件（未完成）
+
+生产二进制是 **`-tags=onnxruntime`** 构建（strip 后 75MB、`.rodata` 62.5MB），
+普通 `go build` 只有 28MB。`deploy/packaging/package-linux.sh:139` 会显式拒绝
+非 onnxruntime 构建：
+
+    if ! go version -m "$homed_bin" | grep -Eq 'build[[:space:]]+-tags=.*onnxruntime'; then
+        echo "ERROR: homed 不是 onnxruntime 构建，拒绝打 server/full 包" >&2
+
+⇒ **必须走 `deploy/packaging/build.sh`（需 `libonnxruntime.so` 与
+`CHINESECLIP_BUNDLE_DIR` 资产）才能部署**，否则依存句法分析与多模态向量化失效。