harness 进程内存随会话事件数持续增长，长批次约 8 小时后堆触顶 OOM 退出（附测量与采样归因）

[SxyLao1]

一句话结论：dsh web 的 harness 进程内存消耗与累计会话事件数成正比、与数据量基本无关，单个长会话批任务连续运行约 8 小时后 V8 堆触及默认上限（约 4 GB）崩溃退出；抽样与源码线索指向逐事件的投影/校验/冻结记账只增不减。

预期：长会话连续运行数天，harness 内存稳定在会话数据量的合理倍数以内。
实际：内存以约 4–5 MB/分钟的速率净增长（活跃回合期间），单批 7.9 小时触顶，FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory，进程以 exit code 134 退出。

环境

DSH Desktop 0.7.2（内嵌 @deepseek-ai/dsh 0.1.2-alpha.1，Node v24.9.0）· Windows 11 · 32 GB 内存 · web profile

关键事实

观察	数据
崩溃前最后一次 Mark-Compact	4125.7 → 4060.0 MB，仅回收 65 MB（活集真占用）
同期会话 jsonl 新增	约 13 MB（无单条大记录，工具结果平均 7 KB）
复测 10 分钟窗口	新增事件数据约 0.2 MB，heapUsed +46 MB（约 200 倍放大）
增速外推	4.6 MB/min × 7.9 h ≈ 2.2 GB + 基线，与实际触顶时间吻合

机制线索（源码阅读 + 10 分钟 HeapProfiler 采样归因，属分析判断而非定论）

1. dsh-session 的 Session.log 为 append-only 深冻结数组，含全部流式块（该批任务一夜产生 6500+ 条 assistant/chunk），进程存活期间从不裁剪；
2. 每条事件经 dsh-session-projection 的 drive() 被十余个投影单元（todos / goal / sessionStats / tokenUsage / contextBreakdown / subagent…）逐一折叠，whole-value 语义下每步重建整份状态并过 zod 校验；采样中 drive、zod parse、walkJsonValue 深冻结遍历均在分配榜前列；
3. projection cache 在每个 turn/end 与节流点对全部单元状态做整体 structuredClone；
4. 采样中约六成分配归为 native 字符串/缓冲（流式文本累积）。

影响

长批次任务必然触顶（默认堆上限下约 8 小时）；harness 死后桌面端停留在失败恢复界面直至手动重启，批次工作全部中断。

可选方向

投影状态历史裁剪或增量 checkpoint；空闲会话释放/冷存；流式块合并后再入账。

不在范围

桌面端 GPU/渲染问题；归档会话无恢复入口（见讨论 #40）；会话数据量本身（已排除）。

复现 / 观察方法

给 harness 进程加 --inspect=127.0.0.1:<port>，用 CDP Runtime.evaluate 读 process.memoryUsage() 每分钟采样，活跃回合期间可见约 4–5 MB/min 净增长；HeapProfiler.startSampling / stopSampling 可复现上述归因。

证据索引

harness.log 的 GC 段与崩溃行（可按要求提供完整片段）；采样 profile JSON（10 分钟窗口，16 KB 采样间隔，可附）。

[argszero]

你的采样归因非常扎实（尤其 10 分钟窗口 0.2MB 新增 → heapUsed +46MB 的约 200 倍放大、Mark-Compact 仅回收 65MB 的活集证据）。我给你补一个家族映射 + 精确到行的源级确认，帮你判断"这是不是 dsh 已知缺陷、修哪里"。

这是已知家族复发，根因在"客户端会话无空闲回收"（#5696）

我此前在 #5696（"Session lifecycle retention gap"，V8 OOM ~8h）已定位同一根因，现已在当前 master 复核，机制未变：

核心机制：packages/api/session-controller/src/client/sessions/manager.ts 的 get()（:288-292）是 lazy build —— 每次访问未实例化 session 都会 this.sessions.set(sessionId, session) 常驻，永不自动淘汰。真正的回收入口只有一个：

// manager.ts:245
async drop(sessionId: SessionId): Promise<void> {
  const session = this.sessions.get(sessionId)
  this.sessions.delete(sessionId)
  if (session !== undefined) await this.startSessionDisposal(session)
}

而 drop() 在整个包内唯一调用点是 service.ts:692（scope teardown，即会话被移除/关闭时）。没有 idle-timeout、没有 maxSessions/LRU、没有 retention cap（我在 packages/api/session-controller/src 全目录 grep idleTimeout/maxSessions/evict/retention，命中为零）。dispose()（:255-264）只在域关闭时清空，不是运行期回收。

这意味着：一个浏览器驱动的长会话，只要 scope 不被移除，它的 Session 实例 + 全量流式事件（session.ts:130 的 events stream、深冻结数组）就驻留内存到 OOM。这与你"约 4.6 MB/min × 7.9h ≈ 2.2GB 触顶"的速率完全吻合 —— 不是单条记录大，而是累计会话事件数线性增长、从不清剪。

你观察到的另外两个放大点，我逐个源级核对了

1. projection cache 的 turn/end 写回（session-projection-cache/src/index.ts:306-308）：turn/end 是 mandatory write point，触发 flushSoft → write → put → snapshotJsonValue(rows)（:380）对当前 checkpoint 全量做 detach 快照。每条事件还可能走若干投影单元整状态重建 + zod 校验（session-projection/src/index.ts 的 drive）。这是事件线性的另一个放大器，方向对。
2. 深冻结数组不裁剪：session-format-* / releasedV1SessionFormatCodec 读冻结 v1 行、releasedV2SessionFormatCodec 逐行解码，但客户端持有的活跃会话的全量事件数组在存活期从不 trim —— 6500+ 条 assistant/chunk 全在内存。

（注：你说的"projection cache 每个 turn/end 整体 structuredClone"—— 我用 structuredClone 在 session-projection-cache 里没查到直接调用；实际是 snapshotJsonValue 做 detach 快照。机制等价（都是整状态复制），但函数名要修正，避免后续引用错。）

插件可挂载面判定

明确无插件面，plugin 是受害者/旁观者 —— 这是 core 客户端会话生命周期 缺口：

• 回收策略（idle-timeout / 上限 / LRU）必须落在 manager.get()/drop() 的生命周期管理上，属 harness-core 的 session-controller 域；
• projection-cache 的全量快照、深冻结数组不裁剪，同样是 core（session-projection-cache / session-format）；
• 插件只能观察到结果（session/event、session/disposed 事件），无法在"何时淘汰一个常驻 Session 实例"上做决定。

所以对这条的正确归档是 core upstream-fix 候选（建议客户端会话保留策略：idle-timeout + 计数上限 + close 事件驱动 drop），与我 #5696 的结论一致。建议你把它和 #5696 合并追踪（同一 session-lifecycle-retention 家族），避免社区重复报。

一句话给作者

判读全对，且是已知家族（#5696 复发）。根因 = 客户端 manager.get() 常驻不淘汰 + 只有 scope teardown 触发 drop()；放大 = projection-cache turn/end 全量 detach + 深冻结事件数组不裁剪。修 = core 层加客户端会话保留策略，与 #5696 同源。你能给出 6500+ 条 chunk 的样本，正好可以补强 #5696 的"累计会话事件数"证据。