现象环境Pink大模型Deepseek一直在同一个对话里干活跑着跑着编辑器就卡死。reopen 之后重新加载那个对话再跑一次又死。点 delete 想删掉它 —— 也死。最后只能强杀进程。图 1reason: ‘oom’ —— 内存耗尽不是普通报错三个人会误判的方向- 以为是对话太长、轮数太多 → 其实文件里只有 190 条记录。以为是内存泄漏、进程没释放 → 其实新开窗口内存立刻正常。以为是 delete 按钮有 bug → 其实 delete 也需要先把它读进内存。reopen 之后那个卡死的对话依然停在 SESSIONS 列表最上面点开就再崩一次图 2问题会话一直在 SESSIONS 里点进去就是重跑崩溃想删掉它右键里的 Delete 同样卡死图 3Delete 也得先加载会话内容所以一样会死真正的原因一条记录 212 MB那个会话文件.jsonl里有一条记录单独占了 212 MB整个文件 222 MB。来源很具体一次浏览器页面调试脚本把整张图集纹理的逐像素数组原样返回了 ——{0:0,1:0,2:0,...}一共 220 万项变成 169 MB 的 JSON 字符串再被写进会话文件。正常会话是 0.1~2 MB。这一条顶别人两百个。三个现象的对应关系现象解释跑着跑着就死那条记录被写进文件的瞬间内存直接被撑爆reopen 又死记录永久留在文件里打开会话就要整体反序列化 渲染delete 也死删除前同样要先把它加载出来关键点会话文件是打开即全量载入的。文件多大打开时就要吃多大的内存。所以一旦某条记录过大这个会话就永久变成了一个打开即死的雷。怎么解决的先定位按体积排序所有会话文件一眼就看出两个异常274 MB 和 222 MB。再隔离把超大会话整体移动到备份目录而不是删除 —— 文件不在原位PinK 就不会再加载它原内容也没丢。最后复查剩下全部会话合计只有 3 MB。图 4按体积排序直接看到两条异常备份后移除而非删除整个过程不需要重启也不需要手工去点那个卡死的标签页。怎么防单靠下次注意没有用得做成不需要记的机制第一层 · 自动约束仓库根放一个AGENTS.md每次新对话自动加载写死一条工具返回只给聚合数字计数/尺寸/fps/hash禁止逐像素数组、base64、整页 DOM、大段 JSON单次返回体 ≤ 100 KB超了就写临时文件再分段读截图只给路径。第二层 · 主动开局/安全开局命令开工前先读项目契约再带上这套返回上限约束。第三层 · 定期巡检tools/pink-session-guard.ps1扫描会话体积超过阈值自动归档-Report只查看-WhatIf预演不动文件-ThresholdMB 20真正归档-InstallTask装成计划任务每 20 分钟自动跑给别人的三条硬经验看会话文件体积别看对话轮数。正常 0.1~2 MB超过 20 MB 就该警觉。调试脚本的返回值必须自己收口。页面里return JSON.stringify({几个数字})永远不要把原始缓冲、像素、快照搬回上下文。崩溃的会话可以用移走文件救回来。备份目录是%APPDATA%\PinK\User\chat-backup\挪回workspaceStorage\id\对应子目录即可还原。代价AGENTS.md常驻约 500~700 tokens。一次正常任务 5 万~20 万 tokens占比不到 1%。换取的是不再有打开即死的会话 —— 很划算。
