补充 A 组（受控对照）的数据：39 分钟 100% 可用

用户要求停掉智能体，所以 A/B 对照只跑完了 A 组就收尾。
A 组数据（quic 8 + h2 2）是迄今最好的一段：

    可用率  142/142 = 100.00%
    耗时    最小 878  中位 1270  P90 2375  P99 4010  最大 8119 ms

P99 从 2 小时长测的 14242ms 降到 4010ms。

同时段连接数（36 个采样点）：
    QUIC:   最低 5  最高 8  平均 7.2
            分布 {8条:21, 7条:8, 6条:1, 5条:6}
    HTTP/2: 最低 2  最高 2
    QUIC 塌陷（<=2 条）: 0 次

**结论：QUIC 塌陷是间歇性的，不是每小时必发生。**
20:30~21:09 这段一次没塌；早些时候那 1 小时 44 分里塌了 2 次
（17:31、17:57）。这解释了短样本看到 100% 的原因 ——
不是数据好看，是那段确实没遇到链路抖动。

B 组（quic 6 + h2 4）没跑成，所以"要不要把 h2 提到 4 条"
这个问题本轮没有答案。但已有的证据（塌陷时 h2=2 从没掉到 0）
说明当前配置的兜底是够的。

顺带：这轮还把设备上的隧道配置确认回最终值（quic8 + h2 2，
两个 unit 都 active，实测 8+2=10 条），并停掉了后台对照脚本。

docs/优化实测数据.md

@@ -115,7 +115,24 @@ QUIC 建连要 6+ 个包往返；TCP 的 SYN 只有 3 个包、内核还按 1s/2
 | 时段 | 样本 | 可用率 | 中位 | P90 | P99 |
 |---|---|---|---|---|---|
 | 25 分钟（双协议初测） | 50 | **100%** | 1505 | 3218 | 14245 |
-| **1 小时 44 分（2 小时长测）** | **361** | **98.61%** | **1280** | **2386** | **14242** |
+| **39 分钟（受控 A 组：quic 8 + h2 2）** | **142** | **100.00%** | **1270** | **2375** | **4010** |
+| 1 小时 44 分（2 小时长测） | 361 | **98.61%** | 1280 | 2386 | 14242 |
+
+**A 组那 39 分钟是迄今最好的一段**：142 次请求全 200，
+P99 从上一次的 14242ms 降到 **4010ms**。
+
+同时段的连接数（36 个采样点）：
+
+```
+QUIC:   最低 5  最高 8  平均 7.2     分布 {8条:21, 7条:8, 6条:1, 5条:6}
+HTTP/2: 最低 2  最高 2
+QUIC 塌陷（<=2 条）: 0 次
+```
+
+**也就是说：QUIC 塌陷是间歇性的，不是每小时必发生。**
+20:30~21:09 这一段一次都没塌；而当天早些时候那 1 小时 44 分里塌了 2 次
+（17:31、17:57）。这解释了为什么短样本的可用率会看到 100% ——
+不是"数据好看"，是那一段确实没遇到链路抖动。
 
 > 长测原定 2 小时，实际跑到 1 小时 44 分就停了 ——
 > 设备在 19:11 换了网段（`192.168.10.105` → `192.168.2.156`），