# 独立核验：插件"省了多少"这个数字怎么来的、可不可信

> 2026-10-12。起因：维护者质疑"6 亿"这个结论是怎么比对出来的。
> 结论：**我上一轮报的"6 亿"是错的**（那是单次运行的值）。下面是严格重算与独立 A/B。

## 一、原来的错在哪

`~/.dsh-entry-shaper.log` 的 `proxy-shape` 行有两种数字：

```
proxy-shape #1700 chars=995144→357644（本次 −64.1%；累计 1541682622→940... = −39.0%）
                          ↑本次                ↑累计（插件内存里，**每次重启归零**）
```

- **"本次"** = 这一次出网的省幅 ✓
- **"累计"** = **自插件启动以来**的累计，**重启即归零** ✗

我上一轮直接引用了日志尾部的 `600664739`，那是 **10-11 那次运行的累计值**，不是全历史。
把它当成"总共省了 6 亿"是错的。

## 二、严格重算（按重启切段，逐段相加）

`diag-total.mjs` / `diag-crosscheck.mjs`：按"累计变小 = 插件重启"切段，各段取末值再相加。

| 段 | 起始 | 发送字符 | 少发字符 | 省幅 |
|---|---|---|---|---|
| 1 | 09-24 09:47 | 39,899,721 | 18,573,554 | 46.6% |
| 2 | 09-24 16:05 | 3,229,176 | 1,503,844 | 46.6% |
| 3 | 09-29 15:25 | 240,117,806 | 102,483,575 | 42.7% |
| 4 | 10-04 10:25 | 84,599,407 | 33,547,747 | 39.7% |
| 5 | 10-06 13:21 | 4,560,734 | 1,739,081 | 38.1% |
| 6 | 10-09 14:47 | 162,265,643 | 26,290,206 | 16.2% |
| 7 | 10-11 05:31 | 1,541,682,622 | 600,664,739 | 39.0% |
| 8 | 10-12 15:30 | 15,176,041 | 4,168,271 | 27.5% |
| **合计** | | **2,091,531,150** | **788,971,017** | **37.7%** |

⇒ 正确说法是 **7.89 亿字符**（不是 6 亿）。而且这仍然是**插件自报**，口径是它自己的
`measure()`（只累加 content 块的 `text` / `arguments`，忽略 JSON 结构开销）。

## 三、独立比对（不依赖插件自报）

### 3.1 先确认"出网 payload 里到底有什么"

harness 源码 `packages/core/session/src/surface.ts:deriveEventMessage()` 是关键：

```ts
case 'assistant/message': {
  if (event.data.message.content.length === 0) return null
  return event.data.message      // ← 原样返回：推理块**留在 payload 里**
}
```

⇒ **历史 assistant 消息里的 reasoning 块会随之后每一次请求重复出网**（不是只发一次）。
这解释了为什么"单次省幅 ≈ 30%"而"会话累计少发"能到几亿：同一条推理在后续每一步都重复发。

### 3.2 出网 payload 的真实构成（`diag-payload.mjs`）

口径与插件 `measure()` 完全相同，统计"产生消息"的三类事件（`user/message`、
`assistant/message`、`tool/result`）：

| 会话 | 推理字符 | 文本字符 | 工具结果字符 | 推理占比 |
|---|---|---|---|---|
| acde5be7 | 5,090,107 | 1,896,766 | 8,072,112 | 33.8% |
| d5dce281 | 5,068,134 | 550,903 | 9,113,268 | 34.4% |
| da7f1bfb | 250,893 | 198,160 | 791,305 | 20.2% |
| d4d42e8c | 193,035 | 52,379 | 999,218 | 15.5% |
| **合计** | **10,824,507** | **2,771,058** | **19,518,395** | **32.7%** |

### 3.3 推理压缩率（`diag-split.mjs` / `diag-impact.mjs`）

把 5,015 个真实推理块喂给插件真实的 `OPS.extract`（maxChars=240）：

```
原文 10,756,672 字符  →  塑形后 861,310 字符  ⇒  压缩率 91.99%
```

### 3.4 交叉验证

```
理论单次省幅 = 推理占比 32.7% × 压缩率 92.0% = 30.1%
插件实际报告 = 中位 38.2% / 均值 35.0%
```

同一量级，差值来自两个口径的差异（插件按**每次出网**计权，后期步数 payload 更大、推理占比更高）。
**⇒ 两个互不依赖的口径互相印证，插件没有虚报。**

## 四、我尝试过但**失败**的重放（诚实记录）

`diag-ab.mjs` / `diag-ab2.mjs` 想"重建每次出网的 messages 再塑形比对"，得到 **45%~81%**，
**远高于**插件的 38%。原因是我没有正确实现 harness 的表面折叠语义：

- 会话日志里有 **147 次 `replace`**（压缩/剪枝遮蔽旧节点，`acde5be7` 覆盖约 395 万 seq）；
- 我只做了 append-only 近似 ⇒ 把**已被遮蔽（根本不会出网）**的历史也算进了 payload；
- 被遮蔽的往往是巨大的旧工具结果 ⇒ 我的分母虚高 ⇒ 省幅虚高。

⇒ 这两个脚本的重放数字**不可用**，已在文件头标注。正确做法是完整实现
`Session.deriveMessages()` 的 fold（含 replace 遮蔽），或直接用**出网抓包插件**
抓真实出网请求再核对。

## 五、可信 vs 不可信（结论）

| 数字 | 可信度 |
|---|---|
| 单次省幅 ≈ 30%~38% | ✅ 两个独立口径吻合 |
| 推理压缩率 ≈ 92% | ✅ 5000+ 真实块直接实测 |
| 推理占出网 payload ≈ 33% | ✅ 与插件 measure 同口径实测 |
| 累计少发 **7.89 亿**字符 | ⚠️ 插件自报，已按重启切段严格重算 |
| 我上一轮的"6 亿" | ❌ **错的**（单次运行的值） |
| 重放得到的 45%~81% | ❌ **错的**（未处理 surface replace） |

## 六、复现

```powershell
cd 'D:\DSH Desktop\.research'
node diag-crosscheck.mjs    # 严格重算累计（按重启切段）
node diag-payload.mjs       # 出网 payload 真实构成
node diag-split.mjs         # 推理压缩率 + 逐会话占比
node diag-impact.mjs        # 修复前后对照
node diag-total.mjs         # 分段累计
```

`zstd-lib.mjs` 提供 `readZstdFrames()` —— **session.jsonl.zstd 是追加写的多帧 zstd**
（`acde5be7` 有 75,357 帧），`zstdDecompressSync` 只解第一帧（41MB→1 行），
必须按 magic `28 b5 2f fd` 切帧逐帧解压（正确结果：104.9MB 文本 / 111,986 行）。