[Feature] 存储生命周期：归档区出口 + 审计表保留（容量治理议题）

[heptaspirit]

使用场景

近期用下来我注意到记忆库增长得比较快，做了一轮审计后觉得有一定无序膨胀的风险，于是回头核实了一遍现有代码，并在 #164 的基础上提出这个想法。

我心里的目标形态是：活跃的保持数百条、持续有用；归档是数千条这个量级；有长期价值的记忆应该沉淀成文档留下来，库里只留索引，而不是被切碎摊在记忆库中。既有效、又不至于把自己撑大，说的就是这个。

有点意思的是，本机这份库数字上刚好落在这个区间（活跃 260、归档约 2,400），但数字对上不代表形态对了。审计之后发现内容上的问题还很大：归档区里积着大量同主题的条目没整理过——0.90 阈值下近重复对约 2,800 对、最大单主题簇 207 行，而活跃侧同期重复为 0。去重确实落在归档侧，缺的是把它收掉的出口。

这个区间只看数字也维持不住：按现在的速度，大约四天就会越过三千。现在还没坏，缺的是撑着这个形态的机制。

这是议题，不是成品方案。我估计得分成几步做，没法一口气吃完；更想先确认问题切得对不对，以及有没有比「加一层回收」更根本的解法。

已查现状声明

读过 README、CHANGELOG、路线图与现有全部 issue。有几项已经被现有开关覆盖，本议题不重造：

• 逐回合自动唤回 = autoInject；空闲期蒸馏 = autoSummarize + autoDream
• 写入侧有质量闸（memoryQualityFilter.enabled，默认开），归档侧有理由护栏（长保留类型须带「重复/过时」理由）
• 审计表已有保留期范式（deleteOldLlmAudits / deleteOldFailures），而 dream_runs 没有
• 向量解析已有 cache-first（getParsedEmbedding）

另外，已关闭的 #202（由他人提出）在处置表里列了「清理 dream_runs 历史（待做）」，而关闭它的 PR #203 只做了检索路径三处固定成本，没有碰 dream_runs。

本机活库只读实测：

口径	值	说明
活跃 archived=0	260	连续两日不变，由默认开启的 autoDream 维持
归档 archived=1	约 2,400	约 +143 条/天，且没有任何周期性动作
库文件	53 MB	freelist = 0（从没删过行）
dream_runs payload	15.6 MB	占全库 payload 50%，最大的一张表

读源码还能确认三条：setArchived 只翻标志位、不清向量；检索 SQL 恒带 archived = 0，而归档行仍带向量（约 4 MB 按定义不可达）；全仓没有 VACUUM / PRAGMA optimize。

期望的行为变化

1. 归档之后空间能真的被回收，而不只是「检索时看不见」——现在归档行的向量和不可达占用一直留着。
2. dream_runs 这类审计表有保留期：run 的骨架与决策结果保留，可重建的输入快照不必长期留存（它占该表约 83%）。
3. 升格（[Feature] document 型记忆：agent 产出的长文档入库——注册校验、摘要+指针落库、supersede 记账 #230）吸收的 evidence 记忆随之退出活跃面。现在 document.js 只在 type: "document" 的行里找被取代目标，所以一次升格吸收了 20 条，库里是 21 行不是 1 行。
4. 归档区有周期性的处理动作，而不是线性只增。
5. 这些动作的实际效果可观察：建议在 聊几个我觉得值得做的方向 #164 已有的四指标上再加一个「归档净增速率 + 可压掉行数」。

我不主张设「最大条数」硬门槛，也不主张按热度或价值阈值自动删——真删应当由人显式确认。

急迫性

不拿「今天检索变慢」当选理由：活跃侧自稳、归档行不可达，当前的性能问题不在归档区。真正的问题是修补成本会随库增长。

1. dream_runs 是 payload 第一名（50%），每天仍在增加，而缺陷已被记录却未落地（见上一节）。
2. 第一次真正的删除还没发生过（freelist 为 0）。一开始回收，页回收、VACUUM 的耗时与并发影响、历史引用链的完整性，全是第一次面对；VACUUM 代价是 O(库大小)，现在便宜、以后贵。
3. 合并与升格的裁决成本随「结构」增长，不只是条数：归档侧已经出现 207 行一个主题的簇（见上一节），簇一多，每簇都要先理解主题才能判断该不该升格。

与 #164 的关系

#164 已对齐的议案	这里补什么
「对话接近尾声提醒整理」	触发源：从周期性提醒换成确定性信号（水位 / 新增条数 / 会话收敛）；AI 做裁决者
「压缩边缘抢救工作状态」	出口：边缘产出的连续性记忆没有出口，只会变成归档区里第 N 条同主题条目
失败判据与四指标	判据「批量把历史塞进上下文」的存储侧形态就是归档区无出口（见上「期望的行为变化」第 5 条）
#231 的「AI 什么时候调用整理接口」	回答：把「何时」从 AI 判断里拿出来，交给确定性信号

可能的做法（仅供讨论，不是方案）

如果方向认可，我看到的落点有三个，都还没开始做：

落点	大概能回收	为什么说它零损失
dream_runs 裁列：输入快照置空，保留 run 骨架与决策	约 13 MB	输入快照是当时的记忆快照，可由记忆库重建；决策与结果不可重建
清掉归档行的向量	约 4 MB	检索按定义不可达
向量改二进制存储	省约 80%	位级等价，顺带消掉检索路径的 JSON.parse

合计约本机的 38%，一条记忆不减、一次价值判断不做。有个配套关系得提前说明：freelist 为 0 时只改列文件不会变小，得配一次 VACUUM，两步要一起。

顺序上我猜是「先回收 → 再修升格出口 → 最后做归档区的跨窗口聚类」，其中第三步强调「跨窗口」是因为现有 dream 候选取的是最近 N 条，而重复项的时间是分散的，同一主题永远进不了同一个窗口。

想请你拍板的

1. 归档区的出口形态：批量归档 / 只清不可达向量 / 直接删？分步还是一次到位？
2. dreamMinIntervalMinutes（默认 0）与 dreamMaxArchivePerRun（默认 8）要不要联合整定？现在的组合约等于「一天分二十几次做掉一百多条」。
3. dream_runs 的保留策略：裁列（输入快照置空）可以接受吗？
4. entity_attrs / entity_relations（本机约 2.2 万行，行数第一名）要不要随归档失效？
5. 升格（[Feature] document 型记忆：agent 产出的长文档入库——注册校验、摘要+指针落库、supersede 记账 #230）吸收的 evidence 记忆要不要一并归档？这关系到 [Feature] document 型记忆：agent 产出的长文档入库——注册校验、摘要+指针落库、supersede 记账 #230 的验收口径。

还想请你指个方向：上面是不是把问题切小了？如果记忆库容量有更根本的解法（比如不靠归档，或者另设一层冷存），我更想听。

@modusensus

_{数据来源：本机活库只读探测 + src/ 源码核实；单库样本，不代表全部用户。毫秒级差异不作结论，10 万条级别延迟是线性外推。}

[heptaspirit]

回顾最初在 #164 里提出的 容量水位遥测与默认生命周期 议题，融合上面的提案，再提出几个想法：

1. 容量水位和整理行为也可以做成一套由 AI 自己调用的工具，水位遥测达到预设的某个阈值或者呈现出预设的一些特征时，在 [Feature] 注入形态：能力说明 + 指针 + 分时机注入（设计提案） #249 里提及的注入指令中告知 AI 已经达到阈值，可以采取整理措施。同时这一遥测信号也应该对用户是可见的，形式上可能类似 [Feature] 注入可观测性：让用户看见「此刻注入了什么」 #179 中的注入信息，提醒用户出现了可能需要主动整理的信号，届时用户也可以自行提醒 AI 对内容进行整理
2. 但 AI 进行整理的话又会涉及另一个问题，在配置了 scope 隔离的环境下，AI 是否只能整理当前所在工作区的内容？是否需要分 scope 发出该信号？这可能会让整个问题变得复杂起来。
3. 默认生命周期达到是否和归档区的出口形态一起考虑设计？

以上只是一些针对该议题回顾后的思考，如果有其他想法也请一起讨论。

[modusensus]

先回应「想请你指个方向」：问题切对了，不需要另设冷存层。归档区本身就是冷存，缺的只是冷存自己的回收出口——把这一层补上，比新开一层的结构成本低得多。写入侧的增速控制另有正解：#254（写入准入）已立项自留，是本议题的上下游，不重复。这个议题真正的价值不在「回收 38%」，而是把「归档区无出口」这个结构缺陷用数据立住了。

五个拍板项

1. 归档区出口形态：分步，第一批只做无损回收。
你表里的三个落点（dream_runs 裁列、清归档行向量、向量二进制存储）全收进第一批——零价值判断、零行数变化、可机械校验，正好落在「真删由人显式确认」的安全侧。物理删除与归档区周期性处理放第二批单独立项：第一次真删要面对 freelist、VACUUM、并发窗口三个「第一次」，值得自己的设计与回归，不与无损回收混车。
VACUUM 拍板：不自动跑，也不开 auto_vacuum（常驻开销换一次性回收不划算，且存量库改 auto_vacuum 本来就要 VACUUM 重建）。给手动触发命令 + 文档写明代价 O(库大小) 与锁库窗口；第一批裁列落地后先手动跑一次实测代价，数字进文档，后续要不要周期化再议。

2. dreamMinIntervalMinutes / dreamMaxArchivePerRun：联合整定要，但数字等遥测。
你的数据说明问题在频率（0 间隔 × 8/次 ≈ 一天二十几趟）不在单次量。方向上 interval 默认从 0 提到非零、per-run 8 不动，但具体档位不拍脑袋——第一批第五指标（归档净增速率）落地后拿真实分布校准，结论写进 issue 再改 schema 默认值。

3. dream_runs 保留策略：裁列同意，删行不同意。
输入快照可由记忆库重建，置空合理。但 dream_runs 整行有回执链语义——#231 的 organize apply 必须指回真实 dryRun 的 run_id（#267 的硬规则 2），删行直接断链。口径：输入快照置空，骨架 + 决策 + receipt 永不删行；保留期键（照 llmAudit.retentionDays 范式）只对快照内容生效，不对行生效。

4. entity_attrs / entity_relations：第一批不动，挂第二批看数据。
2.2 万行不是 payload 大头（15.6 MB 的 dream_runs 才是），「随归档失效」的语义（过滤还是删行、跨 scope 怎么算）没定义清楚之前不动。第一批落地后看实测占比，真要动再立项。

5. 升格吸收的 evidence 随之归档：要，这是 #230 验收口径的补丁。
已核 document.js：supersede 只给 loser 行加 [superseded by] 指针 + content_history 记账，evidence_kept 行原样活跃——「21 行不是 1 行」属实。口径：registerDocument 成功后同一事务把 absorbed 的 evidence 行翻 archived（可恢复，审计全留），带 opt-out 参数；pinned 类型（constraint/preference）永不自动归档——那是 #249 第一批刚立的逐字保真池，升格不能绕过它。supersede 的 loser 行同样翻 archived。

第五指标：同意，「归档净增速率 + 可压掉行数」进状态面，与既有四指标同位。

@heptaspirit 三点

1. 水位遥测 → AI 调用整理工具：方向对，接缝也都是现成的——feat(organize): agent 主动整理接口 dryRun -> apply（issue #231） #267 的 organize 就是那个工具，[Feature] 注入形态：能力说明 + 指针 + 分时机注入（设计提案） #249 第一批的注入通道就是提醒的载体。但按本议题的结论，触发信号必须是确定性水位（遥测），不是 AI 自判；提醒用一句话注入形态，判断权留给 agent。遥测先行，提醒随后。
2. scope：不用怕复杂化——feat(organize): agent 主动整理接口 dryRun -> apply（issue #231） #267 的 dryRun 比对面已按同类型同 scope 隔离，AI 天然只能整理本 scope。水位信号同样按 scope 独立计算、分 scope 提醒，不做跨 scope 汇总。这条写进立项验收。
3. 默认生命周期与出口一起设计：同意，进与出是一对。立项合并为一个「存储生命周期」主 issue 带分批验收（第一批无损回收、第二批出口与周期处理），不拆散。

---

立项我随后开出（第一批 + 第二批两个 issue），连同 #249 那边欠的两个一起，开完回链。

最后感谢这份审计：本机活库只读实测 + 源码逐条核实，setArchived 只翻标志位、全树无 VACUUM、#203 没碰 dream_runs 都复核属实，单库样本的局限也标注得干净。这是把「容量治理」从感觉变成数据的第一份工作。

[heptaspirit]

@modusensus 按上一条里那句「第一批落地后先手动跑一次实测代价」：我在只读副本上把三个落点各模拟了一遍，两个无损落点合计省 27.06 MB（−48.6%），一行未删（生产库未改动，memories 与 dream_runs 行数一行未变）。

基线：副本 55.68 MB（memories 2484 行、dream_runs 292 行）。

步	动作	体积	耗时
A	dream_runs 裁列（input 置空；骨架 + decisions + receipt 保留）	55.68 → 31.82 MB（省 23.85 MB）	写 129 ms + VACUUM 792 ms
B	清归档行向量（archived=1 的 embedding 置空）	31.82 → 28.61 MB（省 3.21 MB）	写 42 ms + VACUUM 829 ms
A+B	实测合计	省 27.06 MB（−48.6%）	两处 VACUUM 合计约 1.6 s
C	向量二进制（只估算，未落盘）	文本 3.47 MB → 二进制约 0.66 MB（省 81%；维度 512、剩 337 行带向量）	未测

与决策相关的三点：

1. A 省下的比 input 列本身多：该列文本 15.93 MB，置空后体积降了 23.85 MB。差值是 VACUUM 顺带回收的行溢出页与索引，所以「裁列加一次 VACUUM」的收益要按体积量，不能按列字节估。
2. 两处 VACUUM 各约 0.8 秒（55 MB 副本、单进程）。这与「O(库大小)、现在便宜以后贵」的判断一致。
3. B 与 C 有重叠：清掉归档向量后，二进制化能作用的只剩 337 行活跃向量（3.47 MB）。两项要一起算，不宜把 48.6% 与 81% 相乘。

另附一个与归档出口相关的观察（单库样本）：归档区仍在长同事实条目，同一事实换标题被反复重记、又被质量过滤赶进归档。实测某类型下有 127 个「同 type 且标题高度相似」的家族共 743 行，最大一族 37 行；活跃侧同类家族为 0。出口应当能止住库的膨胀，但不阻止同一事实继续被写进去，后者落在写入准入那条线上。

数字只作参考，怎么用你定。