会话历史加载成本：assistant/message 的 stream 字段重复存储占 80.7%，交付窗口固定 50 条且客户端无持久缓存

[TommeyChang]

Summary

长会话的历史加载有三个互相放大的问题，合起来让「查看历史」几乎不可用：

1. 存储冗余：assistant/message 的 data.stream 是模型输出的逐块流式日志，而 data.message 已经存了同一份组装后的最终内容。实测 stream 占该会话总字节的 80.7%，体积是 message 的 4.4 倍（小块各自带 time/index/blockType 包装的膨胀）。
2. 交付窗口极小且不可配置：服务端 paginate() 从会话末尾反向取，DEFAULT_MAX_MESSAGES = 50。一个 3,672 step / 约 1 万条消息的会话，翻到顶部需要点击「加载更多」两百来次。
3. 客户端无持久缓存：没有 IndexedDB / Service Worker / Cache API；历史窗口只存在于内存（resumeCursor，「重连时保留已发布窗口」），页面一刷新即全部丢弃并重新拉取。

三者叠加的结果：用户为一份重复存储的数据付出等待，却仍被限制在每页 50 条地翻页。

Reproduction

被测会话（生产环境，单个 agent 会话）：

session-97da8efd-a72f-4db0-96aa-895265aeef7b
压缩后 23.9 MB（session.v3.jsonl.zstd）
解压后 77.2 MB，21,290 行，平均 3,803 B/行

按事件类型的字节与行数分布：

类型	总字节	占比	行数	单行最大
assistant/message	55.18 MB	71.5%	3,671	183.6 KB
tool/result	8.64 MB	11.2%	3,654	70.7 KB
tool/call	5.70 MB	7.4%	3,635	33.1 KB
user/message	3.23 MB	4.2%	719	21.9 KB
agent/inbox/spliced	2.86 MB	3.7%	1,240	18.4 KB
request/header	0.67 MB	0.9%	24	28.7 KB
step/start + step/end	0.58 MB	0.8%	3,672 ×2	0.1 KB

规模来自回合数而非畸形单条：3,672 个 step，77.2 MB ÷ 3,672 ≈ 21 KB/step，完全线性累积。

继续拆 assistant/message（3,671 条，合计 56.6 MB）的 data 各字段：

字段	占用	占比
stream	45.70 MB	80.7%
message	10.49 MB	18.5%
usage	0.40 MB	0.7%
turn / step	0.02 MB	0.0%

一条 73 KB 样本的内部构成：

stream   60.1 KB  [{"type":"chunk","time":1790761881060,
                    "chunk":{"type":"block-start","index":0,"blockType":"reasoning", ...}}, ...]
message  14.5 KB  {"role":"assistant","content":[{"type":"reasoning","text":"The historical pattern is clear: ..."}]}
usage     0.1 KB  {"inputTokens":7399,"outputTokens":4345,"totalTokens":61152,
                   "cacheReadTokens":49408,"reasoningTokens":4345}

stream 与 message 承载同一段推理正文；stream 因被切成大量小块、每块重复 type/time/index/blockType，膨胀到 4.4 倍。

分页行为（dsh-api-session-controller/lib/index.js）：

function paginate(events, beforeSeq, maxMessages, throughSeq, turnWindow) {
    const end = SessionLogOffset(Math.min(throughSeq + 1, beforeSeq ?? throughSeq + 1));
    let count = 0, turns = 0, cut = SessionLogOffset(0);
    for (let index = end - 1; index >= 0; index--) {
        const event = events[index];
        if (turnWindow !== void 0 && event.type === "turn/start") { ... }
        if (!MESSAGE_TYPES$1.has(event.type) || !isAppendSurfaceEvent(event)) continue;
        count++;
        ...
        if (count >= maxMessages) { ... }

调用处：

const page = paginate(events, void 0, request.maxMessages ?? DEFAULT_MAX_MESSAGES, cursor, request.turnWindow);

其中 DEFAULT_MAX_MESSAGES = 50。

服务端迁移成本（对照组，非病灶）：同会话 v3→v4 迁移实测

解压               0.55 秒
解压 + 逐行 JSON 解析  1.69 秒  (21,290 行)
解析 + 重新序列化      3.49 秒  (输出 78 MB)

即迁移是一次性、封顶约 3.5 秒，不是历史慢的主因。

传输：会话经 SSH 隧道跨机访问，隧道未开压缩。同一 10.4 MB 客户端资源：

无压缩: 7.65 秒  (1,390 KB/s)
带 -C:  3.62 秒  (2,941 KB/s)

Current behavior

1. 重复持久化：每条 assistant 消息把流式 chunk 序列（含每 chunk 的时间戳与索引）与组装后的 message 一并落盘。这是纯粹的冗余——message 已足以重建内容，stream 仅对「逐字回放」有意义，但代价是全部历史的 80.7%。同一段推理正文存两遍，且 reasoningEffort: high 下单步 reasoningTokens 达 4,345 / 5,624，冗余量随推理深度线性放大。

2. 窗口不可配置：DEFAULT_MAX_MESSAGES = 50 是硬编码常量，不是 Cordis 配置项。协议层是开放的——wire contract 里 maxMessages?: number 与 turnWindow?: {minMessages, minTurns} 都是 optional 请求字段，客户端也实现了 loadOlder() / loadThrough(seq)——但 dsh-client-ui-chat 对用户只暴露 performanceUsage 与 transcriptView，没有任何控制历史窗口的设置。

3. 客户端不缓存：对客户端 bundle 全文检索，indexedDB 0 处、serviceWorker 0 处、caches 0 处。localStorage 有 33 处，但只存界面状态（侧栏宽度、快捷键、每会话的 conversation store、待发请求），且其约 5 MB 配额本就装不下这类历史。唯一近似缓存的是内存中的已发布窗口，注释自述「The domain retains its published window during reconnection」——只在 WebSocket 重连时续传，页面刷新即失效。

4. 服务端另有 dsh-session-projection-cache，但它只省服务端重复计算，不减少传往客户端的字节。

Expected behavior

建议按收益排序：

1. 消除 stream 重复（收益最大、改动最局部）。若仅传/存 message，本会话由 77.2 MB 降至约 31.5 MB（−59%）。可选路径：默认不持久化 chunk 日志；或只在可回放窗口内保留并定期压实；或对 stream 使用紧凑编码（chunk 边界增量而非每块重复 type/time/index）。
2. 让窗口可配置。协议已经支持 maxMessages / turnWindow，缺的只是暴露：给 ui-chat 增加一个窗口设置，或把 DEFAULT_MAX_MESSAGES 提为可配置常量。当前 50 条对万级消息的会话实际不可用。
3. 加客户端持久缓存。服务端是权威源，客户端可做按 asOfSeq 校验的 IndexedDB 缓存：命中则只拉增量，未命中才全量。这能把「刷新即重拉」消除，且对上述两条是正交增益。

运输层加压缩（ssh -C）能缓解 2.1 倍，但那只是掩盖前两条——真正的问题是根本不该传这么多。

Environment

• @deepseek-ai/dsh 0.1.7-rc.2（dsh-api-session-controller、dsh-session-format-v3-to-v4、dsh-client-ui-chat 同版本）
• Linux（Ubuntu 24.04）、Node v22.23.2
• 服务由 systemd 托管；浏览器在另一台机器，经 SSH 隧道（未开压缩）访问远程 dsh web
• 该会话由 0.1.7-rc.2 从已发布 V3 恢复（dsh-session-format-v3-to-v4），迁移成本实测封顶 3.5 秒，与本文问题独立
• 会话为长周期 agent 任务（3,672 step），非人为构造

[TommeyChang]

补充交付路径上的两个问题，并更正我自己一处数据。

0. 先更正我自己的一个数字

报告正文里"同一 10.4 MB 客户端资源"是未压缩测量值——当时 curl 没带 Accept-Encoding。真实浏览器收到的是压缩后的（见第 3 节）。这不影响隧道 A/B 的结论（同一对象、同一条件对比），但引用绝对体积时应使用压缩值，我在下面更正。

1. 带内容哈希的资源没有缓存头

GET /plugins/??<60 个客户端模块>
HTTP/1.1 200 OK
cache-control: public, max-age=31536000, immutable
Vary: Accept-Encoding

GET /assets/index-Q6zc2uHV.js
HTTP/1.1 200 OK
content-type: text/javascript; charset=utf-8
Vary: Accept-Encoding
Date: ...
Connection: keep-alive
Keep-Alive: timeout=5

GET /            （HTML 外壳）
（同上：无 Cache-Control、无 ETag、无 Last-Modified）

plugins/?? 那条是正确的：immutable + 一年。但 assets/* 的文件名本身带内容哈希，是 immutable 的天然候选，却完全没有缓存头——没有 ETag 或 Last-Modified 时连 304 都省不了，每次加载都必须完整取回。

字节量不大（第 3 节合计约 0.5 MB），但这是纯粹的浪费，而且与同项目内 plugins/?? 的做法自相矛盾。附带一个用户可见的后果：硬刷新会绕过 plugins/?? 的一年缓存，一次多付 5.11 MB；普通刷新才是缓存命中。

2. 会话历史在应用层不压缩

WebSocket 握手（客户端主动请求了 permessage-deflate）：

> GET /api/remote.mux
> Sec-WebSocket-Extensions: permessage-deflate

< HTTP/1.1 101 Switching Protocols
< Upgrade: websocket
< Connection: Upgrade
< Sec-WebSocket-Accept: <...>
（无 Sec-WebSocket-Extensions —— 未协商）

会话历史正是走这条通道，因此在应用层完全不压缩。这直接放大了本报告的核心问题：一个 32 MB 解压后的 transcript 会以 32 MB 过线，只可能被传输层压缩缓解（SSH -C、VPN 等）。

我实测了传输层压缩的效果，供判断该由哪一层负责：

指标	无压缩	带 -C
小请求往返（20 次中位）	0.0719 s	0.0718 s
同一批量下载	13.88 s	3.59 s（3.9×）

即：传输层压缩对交互延迟无损，对批量载荷收益显著——但它不该是这条路上唯一的压缩。

3. 更正后的体积对照

资源	应用层未压缩	实际传输（gzip/br）
plugins/??（60 个客户端模块）	10.38 MB	5.11 MB
assets/index-*.js	0.63 MB	0.23 MB
assets/vendor-*.js	0.74 MB	0.20 MB

HTTP 路径上的压缩是有效的（约 2×）。缺的是两处：哈希资源的缓存头、以及 WS 通道的压缩。

建议

1. 给 assets/* 与 HTML 外壳补上与 plugins/?? 一致的缓存策略：带哈希的用 immutable，HTML 用 no-cache + ETag。
2. 为 /api/remote.mux 启用 permessage-deflate，或对历史帧施加与 HTTP 同等的压缩——尤其是这类体积随会话长度线性增长的载荷。这一点与第 1 节（stream 重复存储）叠加后才是完整的成本：既要少存，也要压缩着传。

[TommeyChang]

本贴暂无回应，补一条可能有助于排期的信息：它与 #8846、#8849 是同一主题的第三种形态，而那个主题在 #8849 里已由 PerryLink 归纳为一条原则——「局部失效必须被局部化：不得升级为进程退出或整体视图失败」。

三份报告是同一条原则的三种违反

帖	局部坏状态	升级成
#8846	历史里一个孤立代理项	该会话永久 400，整个会话不可用
#8849	一个子代理结算时读不到投影	整个 dsh 进程退出，服务下线
本贴	assistant/message 里一份重复存储的 stream	历史交付整体劣化：窗口被迫缩到 50 条、翻页数百次

前两条是"局部坏状态 → 整体不可用"，本条是"局部冗余 → 整体体验劣化"——同一个设计取向的三种表现：局部问题没有被局部化，而是由全局承担。

一条独立复核（第二台机器，同一构建）

同一构建 0.2.0-rc.2、另一台机器（macOS / Node 26）上，stream 与 message 的重复比例与原报告几乎完全一致：

环境	stream 占比	message 占比
原报告（Linux，单会话 3,671 条 assistant/message）	80.7%	18.5%
复核（macOS，另两个会话）	79.4% / 79.7%	19.9%

⇒ 这不是某个特定会话的偶发现象，而是该字段的固定结构开销：stream 恒为 message 的约 4 倍。所以"消除 stream 重复"的收益（本会话 77.2 MB → 约 31.5 MB，−59%）对任意长会话都成立，可预期、可验收。

请求

1. 若维护者认为这三条值得当一次结构性修复排期（PerryLink 在 [Bug] 子代理结算时 projection registration 失效会让整个进程致命退出（fatal load failure / exit 1） #8849 里表达过这个倾向），本条可并入该组；
2. 本贴的三条诉求按收益排序：消除 stream 重复（−59%，改动最局部）→ 历史窗口可配置（协议已支持 maxMessages/turnWindow，只缺暴露）→ 客户端 IndexedDB 缓存（消除刷新重拉）；
3. "−59%" 这个数已经是可验收的差值，不是估算：该会话解压后总量 77.2 MB，其中 assistant/message.data.stream 占 45.70 MB ⇒ 剔除后约 31.5 MB。验证方式很直接——对同一份日志做一次"跳过 stream 字段"的重序列化，比较字节数即可。

边界

第 2 节的两组数字来自两台不同机器、不同会话，所以它证明的是比例的稳定性，不是逐字节一致；端口/协议侧我仍无法从外部读到客户端的实际请求参数（maxMessages 取值），那部分仍是推断——这一点原报告已标注。