会话列表缓存 SolidiFact/dsh-session-list-cache

dsh-session-list-cache

一个很小的 DeepSeek Harness (dsh) Web 插件，让打开的 dsh 网页不再持续占用一截 CPU 核心。

来自 SolidiFact 的社区插件。不是 DeepSeek 官方产品。

问题

dsh 网页打开期间，每 5 秒刷新一次会话列表。每次刷新都会把你保留过的每个会话的列表行，从它存储的记录重新构建一遍，并重新校验每个存储的值。这些会话其实什么都没变，但工作照样重做一遍，而且你保留的会话越多，开销越大。

在一台存有 763 个会话的机器上实测（dsh 0.1.7-rc.2，Apple M4）：

| | 打开一个 dsh 页面、没有任务运行时的处理器占用 |
| 不用这个插件 | 单核的 15.2% |
| 用这个插件 | 单核的 8.1% |

每个数字都是 dsh Web 进程两分钟内的 CPU 时间，两次测量方式相同，连接的页面也相同。剩下那部分开销是 dsh 从磁盘读取会话头，这个插件不改动它。

它做什么

已存储（「冷」）会话的行由两部分构建：它的头和它在 dsh 投影缓存里的记录。dsh 从不原地修改已存储的记录；每次写入都存成新对象。所以只要头没变，记录的内容又和上次是同一批存储对象，行就不可能变，于是直接复用上次构建好的行。

三重保障：

- 任何行最多保留一分钟。 行的一部分由运行中的 dsh 算出，而不是来自存储的记录（图片上限，以及每个工具由哪个插件提供）。dsh 刚启动时，插件还在陆续就位，那时构建的行可能和之后的不一样。每分钟至少重建每行一次，就能把这种偏差限制住，同时仍然跳过每 12 次重建中的 11 次。
- 它会自查。 每 100 个复用的行里，有 1 个照样重建并比对。发现差异就计数，改用新构建的行，并记录前三次。每 100 次列表请求，它记录一行汇总。测试机器上的第一条是： [session-list-cache] 100 list requests, 76500 rows: 92% reused, 6108 built; 9034 spot-checked, 84 differed; 765 rows kept （抽查次数比平时多，因为测试时每一行都被检查了一分钟；84 处差异全部来自启动后的第一分钟，那时插件还在加载，之后对每一行做的一分钟检查没有发现任何差异）。
- 它安全失败。 它挂接 dsh 的一个内部类。如果 dsh 升级挪走了它需要的东西，它就记录一条警告，不动 dsh。读不了的记录永不缓存。已附加（打开且活跃）的会话永不缓存。

它和 @michengai/dsh-archive-manager 一起用或单独用都行，后者包装的是同一个投影缓存。

安装

已在 dsh 0.1.7-rc.2 上测试。
1. 把 index.mjs 复制到 dsh web 配置档文件夹，命名为 session-list-cache.mjs （例如 ~/.dsh/profiles/web/session-list-cache.mjs）。
2. 把它加进该配置档的 cordis.patch.yml：

- insert:
- id: session-list-cache
name: './session-list-cache.mjs'

3. 重启 dsh web。日志里应该出现 [session-list-cache] unchanged cold sessions reuse their session-list row。

要移除它，删掉这段 insert 再重启即可。

调优

createCache() 接受 checkEvery（默认 100）、reportEvery（100 次列表请求）和
maxAgeMs（60000）。上面的数字就是用这些默认值测出来的。

测试

node --test

测试覆盖了开发过程中弄坏过早期版本的几种情况：一张表每次读取都返回新的包装对象，以及一行数据的实时部分变了、存储的记录却没变。

许可证

Copyright 2026 SolidiFact. Licensed under the Apache License, Version 2.0; see LICENSE.