桌面端「新建会话 / 切换工作区要等 20 多秒」——试了若干办法都无效，想请教可行的缓解方案

[ZIye1208]

Desktop 0.2.0-rc.2 (Windows): clicking "New Session" or switching workspaces takes 20+ seconds. Sharing what I tried and what did NOT work — looking for a practical workaround.

环境

• Windows 10 x64，@deepseek-ai/dsh-desktop 0.2.0-rc.2（Electron 44 / Node 24）
• 7 个工作区，约 76 个会话，会话日志总量约 30 MB（v4 格式）
• 桌面端 profile，装了约 20 个第三方插件

现象

• 点「新建会话」后，要等 20 多秒界面才有反应
• 切换工作区、点开其他会话也有同样程度的卡顿
• 每个工作区都是「第一次慢、第二次快」：在同一工作区里连点两次，第二次几乎是秒开
• 界面不崩、不报错，就是卡住一段时间

试过的办法与结果

做法	结果
归档旧会话	❌ 无效。看起来归档只是改 workspace.json 里的一个 id 列表，磁盘文件一个不动，而列表扫描是按物理目录走的（后来在 #5961 看到完全相同的结论）
把 68 个旧格式会话全部迁移成当前格式	❌ 无效。见下方「一个顺带的观察」，最后旧格式归零（76/76 全是 v4），现象一点没变
禁用 @michengai/dsh-archive-manager	❌ 不可行。它的 patch 关掉了官方 workspace 与 session-projection-cache，再用自己的同名服务顶替，一禁工作区就空白
排查第三方插件高频轮询	❌ 没找到。逐个定时器看上下文，看到的那些小数字（100ms / 1000ms）其实都是 debounce，真实周期是 30 秒或 1 小时
重启客户端	🟡 只有一半效果。重启后空闲开销确实掉下来了，但点击时照样卡

一个顺带的观察（也许对排查有用）

点开一个旧格式的会话时，宿主会自动把它整份重写成当前格式，在同一个目录里生成 session.v4.jsonl.zstd，而旧的 session.jsonl.zstd / session.v3.jsonl.zstd 会留在原地不删。

我们就是借这个机制，把 68 个旧会话逐个点开、全部迁成了 v4（旧格式会话数从 68 降到 0）。格式是统一了，但卡顿完全没有改善——所以这个方向大概不是问题所在，仅供其他人参考：迁移旧格式会话不会带来性能收益。

实测到的情况

用进程计数器（0.2 秒粒度）观察宿主进程：

• 空闲时很健康：0–3% 单核，几乎不读盘。连续测 15 分钟，后 13.5 分钟总共只读了约 3 MB
• 一操作就爆：点几下之后，有一个 30 秒窗口内宿主占到 80% 单核、读了约 142 MB；那 90 秒里累计读了约 238 MB / 12 万次读
• 按 76 个会话换算，每个会话约 1,636 次读——远高于列表扫描的约 9.5 次/会话

所以看起来不只是「列表扫描」的问题，而是打开/切换会话时会把会话日志整份读一遍再解码。这也符合「第一次慢、第二次快」：第二次内容已经在内存里了。

想请教的问题

1. 除了「减少会话总数」，有没有别的可行缓解办法？（改配置、换持久化后端、用某个插件、加启动参数都行）
2. 「每个工作区第一次慢、第二次快」是设计如此，还是我这里哪里不对？
3. 有没有办法关掉冷打开时的全量日志解码，或者让它延迟/按需进行？

我已经读过 #7142、#5961、#8065、#8631、#1316、#6511 这些相关讨论，知道这是 O(sessions) 且没有缓存的老问题；主要想请教大家在等到修复之前是怎么让它变得可用的。

谢谢！

[Sivan757]

卸载全部插件再看看，我遇到过一些插件会导致会话加载卡慢，得逐个排查，最快的方式是开个新 profile，看看切工作区和会话还卡不卡。

[ZIye1208]

找到原因了（更新）——是第三方插件 @michengai/dsh-agency-agents。

在同一个 profile 里把它禁用之后：

• 新建会话不卡了
• 载入会话历史不卡了
• 之前那个持续几十秒的卡顿完全消失

用进程计数器复核，效果很明显（同样是点几次「新建会话」）：

	禁用前	禁用后
宿主峰值单次开销	1,843 ms CPU / 6,094 次读 / 11.4 MB	656 ms CPU / 1,154 次读 / 2.3 MB
20 秒窗口内宿主占单核	80%	8%
之前那个「每 0.2 秒 203 ms CPU + 约 720 次读」的持续形态	存在	消失

另外排除一个可能性：重启客户端本身没用。我中途重启过一次，卡顿照旧；只有禁用这个插件之后才变好。

这个插件为什么会造成这么大的开销

它看起来是「大量 agent 定义 + subagent 注入」型的插件：

• 插件包里带 648 个 agent / persona 定义文件（assets/agency-agents/<分类>/<名字>.md，分类包括 academic / company / design 等）
• package.json 的 dsh 字段里注入了 tools 和 subagents
• 它的客户端 client.js 有 1.29 MB，是我们装的 18 个第三方插件里最大的一个

这和我在这里读到的 #2606（"Subagent catalog cold reads replay full session logs and cause sustained high CPU"）描述的现象一致：会话的 subagentCatalog 投影在冷读时会重放整份会话日志。所以推测是：

这个插件注册了非常庞大的 subagent 目录 → 每次打开/列举会话时都要为每个会话处理 subagentCatalog → 重放日志 → 持续高 CPU + 海量读盘。

我实测每会话约 1,636 次读，远高于列表扫描本身的约 9.5 次/会话，量级上也支持这个推测。

结论：session/list 是 O(sessions) 无缓存这个老问题确实是底子，但在装了这类「大 subagent 目录」插件的环境下会被放大很多倍。所以遇到同样卡顿的人，可以先从「有没有装注册大量 subagent / agent 定义的插件」查起——比查会话数量见效快得多。

如果这个推测有哪里不对，或者有更准确的机制解释，非常欢迎指正。

[ZIye1208]

更新（2026-10-05）：根因已定位并完成最小复现 + CPU profile 取证

先更正本贴的一个方向：开头提到的「旧格式会话迁移」那条线已被证伪 ——
我们把 68 个旧格式会话全部迁移成 v4（旧格式归零），卡顿一点没变。
真正的原因是两个第三方插件冲突。

---

一、最小复现：必须两个插件同时启用

同一台机、同一份会话库、每次重启客户端，逐个开关验证：

启用组合	结果
只启用 @michengai/dsh-agency-agents	不卡
只启用 dsh-mcp-connector	不卡
两个同时启用	卡，稳定复现

⇒ 这是交互型问题，不是单插件问题。
单独装其中任何一个都复现不出来 —— 这也正是插件作者按「只装我一个」测试时无法复现的原因。

---

二、宿主进程的 CPU profile

项	值
采样	V8 CPU profiler，420 秒窗口，500 微秒间隔，733,834 样本
高占用窗口	第 51–110 秒，连续约 53 秒逐秒 1000 ms ＝ 满载一个核
其余时段	约 10 ms/秒（0.1%，健康）

自耗时占「忙」时间（52.6 秒）的比例：

占比	函数	归属
27.3%	structuredClone	Node 内核
11.4%	toJSON	schemastery（条目序列化）
9.9% / 6.6%	readFileUtf8 / existsSync	fs
7.9%	js-yaml 全家（解析 YAML）	内核
3.2%	applyEntryPatches + buildMap	dsh-app-boot（条目补丁）

而两个插件自己的代码合计只占 0.07%（约 37 ms）。
⇒ 它们不是耗 CPU 的人，是扣扳机的人；真正烧时间的是被触发出来的内核动作。

---

三、机制

把上面的构成串起来，那 53 秒里内核在反复做同一件事：

读 YAML 补丁（readFileUtf8 / existsSync / stat）
  → 解析 YAML（js-yaml）
  → 构建条目表（app-boot: buildMap / readProfileManifest）
  → 应用补丁、重算条目（app-boot: applyEntryPatches）
  → 序列化 + 深拷贝条目（schemastery.toJSON / Schema + structuredClone）
  → 再来一遍

applyEntryPatches / buildMap / toJSON / structuredClone / js-yaml 合计约占七成。

这与插件仓库里的 MichengAI/dsh-agency-agents#9（agency-agents 的惰性描述读取 ×
dsh-mcp-connector 的 tools/change 全量 schema 扫描 → 条目 re-patch → 不收敛）是同一类问题。
区别是：只有本插件时没人反复去读那个惰性 getter，所以不卡；加上 dsh-mcp-connector 才形成循环。

采集方式（供复现参考）：DSH 桌面端外壳自带 DSH_DESKTOP_HOST_INSPECT_PORT 开关，
可给宿主进程挂上 Node inspector，再用 CDP 的 Profiler 域采样。

---

四、处置建议

档	做法	效果
立即可行	停用其中一个（我们这里是卸载 @michengai/dsh-agency-agents）	卡顿立即消失
上游修复	把专家/工具描述改成静态（或按语言缓存），别让每次 tools.schemas() 扫描都走到 settings.describe()	根治
另一侧加固	tools/change 的 schema 扫描加去抖 + 缓存 + 值比较，并在「扫描本身导致条目变化」时中断再触发	根治

完整证据（含热点表、逐秒时间线、机制推演）已提交给该插件作者：
MichengAI/dsh-agency-agents#10

---

给后来人的一句话结论：
如果 DSH 出现「新建/打开会话卡十几秒、宿主满核」，先查是不是装了多个会扫描/注册大量条目的插件，
再逐个开关做 A/B —— 比查会话数量、清缓存、迁移会话格式见效快得多。