[Analysis] 桌面端「用一阵子新开对话就卡死、重启才恢复」：会话被永久 promote 成常驻 Agent + 每会话 100ms 技能 watcher（Windows 唤醒后放大）

[liukjx]

TL;DR

Windows 桌面版 0.2.1-rc.2 上，「用一阵子 → 新建对话半天不动 → 重启才恢复」可以在不改任何插件的前提下用三个叠加因素解释：

1. 每个被打开过的会话都会被永久 promote 成常驻 live Agent，而 RPC 面没有 session/close、拆除只绑在宿主根 ctx —— 宿主进程活着就永不回收；
2. 每个 Agent 各自挂一套 skill-filesystem 监视器（watchFile({interval: 100}) 10 Hz 轮询 + chokidar），并且每次新建会话都会全量重扫技能目录（技能 collect 缓存 key 含每会话新 scope，必然 miss）；
3. cordis 全局单张监听表，每次 emit 都线性遍历全部监听 → 单次事件成本随「本次运行打开过的会话数」增长；renderer 的会话列表快照也是 O(会话数) 全量重建。

于是「新建会话」这条链路会随运行时间变慢，直到某一次（尤其 Windows Modern Standby 睡眠唤醒之后）彻底卡住：宿主已经把会话建出来了，UI 没有切过去，用户继续点，就累积出一串空白壳。重启之所以有效，是因为它把上面三样东西一起清零了。

English summary

On DSH Desktop 0.2.1-rc.2 (Windows), "after some uptime, creating a new conversation hangs for minutes; restarting fixes it" is explained by three compounding factors: (1) every session that was ever opened is permanently promoted to a live Agent — there is no session/close in the RPC surface and teardown is bound to the host root context, so nothing is reclaimed while the host lives; (2) each Agent mounts its own skill-filesystem watcher (watchFile at 100 ms + chokidar) and every new session re-scans all skill roots because the collect cache key includes the per-session scope chain (guaranteed miss); (3) cordis dispatches every event over one global listener table linearly, so per-event cost grows with the number of sessions opened in this process. A Modern Standby/wake cycle then turns the accumulated cost into a multi-minute hang. Related existing threads: #10827, #10683, #9392, #9264, #10336.

环境

• DSH Desktop 0.2.1-rc.2（Windows 11，Modern Standby 可用）
• 会话库：219 个会话 / 90.4 MB；D:\杂 工作区 108 个会话；工作区 3 个 MCP（rea / pico-dev-knowledge / 12306）为 profile 级单例常驻
• 桌面 profile 装了 dsh-pet、dsh-plugin-wallpaper-engine、dshmarket、dsh-ops（后文会说明它们是放大器，不是根因）
• 下列行号取自随包发布的 app.asar 内 0.2.1-rc.2 的 bundle，不是源码仓库推断

现场 A：Modern Standby 唤醒后的创建风暴

时间	事件
19:32	实例启动
23:00:38	系统进入 Modern Standby
00:28:26	键盘唤醒
00:29:27–00:29:34	7 秒内连续创建 5 个会话，其中 3 个 createdAt 是同一毫秒 1793291374606；4 个永久停在 317–321 B 的 header-only
00:29:27 → 00:35:09	5 分 42 秒无任何可见响应（点一次没反应 → 再点 → 又建一个）
00:35:09	用户重启
00:35:28 / 00:35:47	重启后补写事件，首条 LLM 回复 3.63 s，恢复正常

卡死期间那 4 个会话解压后的完整内容是 191 B 的 header（isSeeded:false），一行事件都没有 —— 这与 @PerryLink 在 #9392 里的更正一致：header-only 本身是「新建但从未打开」的正常形态，真正的问题是宿主建好了、UI 没有切过去，用户于是重复点击。也就是说症状不落在「创建失败」，而落在「创建 + 切过去的这条 UI 链路被拖到不可用」。

现场 B：健康实例上的对照数字

同一个实例、4 个并发 agent 的情况下，新建会话到 turn/start 只要 2.9–3.6 s；同一台机器上：

• 219 个会话头全读：328 ms；projcache 263 个 JSON / 4.6 MB 全量加载：52–58 ms；写一条 projcache：2–7 ms
• D:\杂 58,855 文件 / 5,830 目录 / 2.1 GB 全量递归 + 逐文件 stat：1.16 s（PowerShell Get-ChildItem 口径 7.7 s）
• 内存不是主因：64 GB 物理内存空闲 30 GB；10 分钟内 4 次采样宿主 WS 405→369→353→348 MB、句柄 704→674→713→675，没有单调泄漏；无崩溃、无 GPU 进程重启、无 Crashpad 记录
• D:\杂 根目录不是 git 仓库（git rev-parse 报 not a git repository），所以 workspace-changes 的 git 快照不参与

⇒ 磁盘/内存/历史规模都只能给出「秒」级代价，给不出 30 s 以上、且重启即消失的卡顿。只剩「进程内累积」这一解释。

机制（0.2.1-rc.2 asar 行号）

M1（主因候选）打开过的会话永久变常驻 live Agent，没有任何回收路径

• 新建链路：dsh-client-ui-workspace/lib/client.js:1499 startSession → :1403 connectBlank → :1406/1437 sessions.create → dsh-api-session-controller/lib/index.js:755 create → :765 agents.createSession → :264/:508/:517 ctx.agents.create → dsh-agent-loop/lib/index.js:1893 createAgent → :1865 persistence.create（写 session.v4.jsonl.zstd）→ :1681 prepare() → presets.mount 挂 ptc preset（约 30 个插件实例）→ :1794 agents.announce
• 紧接着客户端 follow()（:1510）→ :1586-1593 promote() 把这个会话在后台 resume 成常驻 live Agent；
• RPC 面（dsh-api-session-controller/lib/typert.host.js:1426-1955）没有任何 session/close，全包搜不到 demote / evict / idle 回收；teardown 只绑在根 ctx（dsh-agent-loop/lib/index.js:1749）⇒ 宿主存活期内不释放；
• resume 会把整条日志读进内存（dsh-agent-loop/lib/index.js:1989 read(0, void 0)、:1995 seed: [...persisted]），并持有日志写句柄 + flock（dsh-session-persistence/lib/…:621-639，close 在 dsh-agent-loop:1726）。

⇒ 内存 / 句柄 / watcher / 事件监听，都随「本次运行打开过的会话数」线性增长，重启清零。

M2（放大器）全局监听表 + O(n) dispatch

cordis/lib/index.js:230,258-264：全应用共用一张 _hooks，每次 emit 都对该事件的全部监听做 .filter(scope).map(bind)；监听只在 dispose 时移除。每个 agent 插件还会注册 session/event、fs/observed 等，打开会话时再追加 2–3 个 {global:true}（:1529,1537,1546）⇒ 单次事件成本 O(存活会话数)。

M3（每次新建的固定成本）技能全量重扫且缓存必 miss

dsh-skill/lib/index.js:270,299：技能 collect 的缓存 key 含 scopeChain，新会话 = 新 scope ⇒ 必然 miss ⇒ 逐 root readdir + 读 + 解析 SKILL.md（dsh-skill-filesystem/lib/index.js:92-107,584-617）。本机 3 个技能根合计约 150 个技能（~/.dsh/skills 26、~/.agents/skills 49、内置若干）。

附：每个 Agent 一套 100 ms 技能 watcher

dsh-skill-filesystem/lib/index.js:26,36-41,341-348 使用 watchFile 轮询、:370-383 使用 chokidar；watchMaxProjects = 128 对单个 workspace 永不淘汰。N 个打开过的会话 = N 套 10 Hz 轮询 + N 套目录监听。

附：renderer 侧 O(会话数)

dsh-client-ui-workspace/lib/client.js:3585-3618 buildListSnapshot、:3622 applyMutation 是 O(会话数) 全量重建；projectionStores 只在 remove 时删除（:3521）。

为什么完全符合「刚启动不卡 → 越用越卡 → 重启恢复」

• 刚启动：live Agent 数 ≈ 0，watcher / 监听 / 技能缓存都很小，新建会话 3 s 左右；
• 用一阵子：每打开一个会话就永久 +1 个 live Agent（+约 30 个插件实例、+1 套 10 Hz watcher、+整条日志常驻内存）；O(n) dispatch 与 O(n) 列表重建让每次交互的固定成本抬高；
• 睡眠唤醒：定时器补偿、chokidar 句柄失效、host↔renderer 与 MCP 子进程的连接状态一起进入异常态，于是某次新建会话就卡在「已落盘、未切换」的中间态；
• 重启：以上全部清零 → 立刻恢复（文件、会话、缓存重启后都还在，唯独进程内累积消失）。

这与 #10827（用着用着卡死/新建没反应/重启恢复/归档后好一点）、#10683（宿主已建会话但 UI 无反馈、同毫秒多个会话、activation ladder +0.055 s → +64.4 s）在现象与数字上完全对得上；#9264（open() 对老会话 O(N) 扫全库，p50 1167 ms @ N≈1830）与 #10336（workspace-changes 每会话 scratch 目录在 TEMP 里不 dispose，60 GB）属于同一类「没有回收路径」的问题。

用户侧临时缓解（不改代码）

1. 少点开旧会话，用完就关 / 归档——直接压低 live Agent 数量，是唯一不重启就能把曲线压回去的动作；
2. 在 ptc preset 里给 skill-filesystem 加 { watch: false }（Settings → General 的 preset 编辑器，或覆写 cordis.patch.yml 的 preset 层）——砍掉每会话一套 10 Hz watcher；代价是技能文件改动不再热更新，重启后生效；
3. 睡眠前退出 DSH；唤醒后先缓 20–30 s 再操作；已经卡住就重启（目前没有别的清零手段）；
4. 关掉纯外观类常驻插件做对照：本机上 dsh-pet 另起整套 Electron（5 进程、380–500 MB、持续约 16% 单核），wallpaper-engine 让 GPU 进程长期 100%+ 单核——它们不制造这个 bug，但显著放大卡死时的体感；
5. 调大 session-projection-cache 的 writeEveryEvents / writeIntervalMs，减少每步写盘。

建议的修复方向

1. 给会话生命周期一个真正的回收路径：session/close（客户端可显式关闭）+ 空闲 LRU 上限（例如同时 live 的 Agent 数 / 总内存阈值），而不是把 teardown 绑在宿主根 ctx；
2. skill-filesystem 的 watcher 全局共享或按需启停，不要每个 Agent 一套 100 ms 轮询；技能 collect 缓存 key 不要含 scopeChain（或给跨会话共享的稳定 key）；
3. cordis 的全局 dispatch 改成按事件/scope 分桶，避免每次 emit 线性扫全部监听；
4. 新建会话的「创建成功但导航被 abort」要有可见反馈，并复用已有的空白会话（Session 创建被静默吞掉：宿主已建会话但 UI 无任何反馈（ui-workspace 0.2.1-rc.2） #10683 已列出 4 处锚点）；
5. DSH 目前完全不写运行日志（%APPDATA%\@deepseek-ai\dsh-desktop\logs 为空），社区只能靠会话文件的 zstd 时间戳反推现场，建议加可开关的文件日志（至少记录 create/follow/promote 的耗时）。

如何验证 M1（约 10 分钟）

1. 依次点开 10 个旧会话、一个字都不发；
2. 同时观察宿主进程（DeepSeek Harness.exe 中带 dsh-desktop-host 的那个）的 Working Set / Handles：预期每打开一个上涨一截且不回落；
3. 再对一次新建会话做宿主 CPU profile，看 cordis 的 dispatch 与 skill 扫描在火焰图里的占比是否随已打开会话数上升；
4. 网络监视侧可同时看到 session/added、follow、promote 三段耗时（Session 创建被静默吞掉：宿主已建会话但 UI 无任何反馈（ui-workspace 0.2.1-rc.2） #10683 的 activation ladder 就是这条链路）。

---

补充说明：M1–M3 是 0.2.1-rc.2 代码库的静态分析（行号来自 asar 实包），尚无 CPU profile 坐实；时间线、会话文件大小、磁盘/内存排除项、进程与 CPU 数据均为实测。欢迎直接用上面的验证步骤打脸或补充。