聊几个我觉得值得做的方向

[heptaspirit]

我自己最近一直在用 mneme 做日常记忆。
下面这几件事是用下来觉得可以再想一想的。如果其中有已经做了、只是我们没找到的，麻烦指正。想先听听你们的判断：哪些已经在规划里、哪些你们不打算做，不打算做的我们就不碰了。

A. 记忆的上限与安全

• 记忆的裁剪与淘汰：目前看下来，容量默认是没有上限的，淘汰相关的选项似乎要手动打开（如果理解错了请指正）。到量之后怎么取舍、怎么保住重要的，想听听你们的打算；
• 写入前有没有考虑过扫一遍密钥/隐私信息（手机号、身份证、私钥这类）；
• 面板手改、命令行删、外部 API 写这些改动，能不能有一处统一可查的记录。

这三件我们放在一起，是因为它们都属于"用久了才显形"的问题——记忆是长期资产，越晚处理越麻烦。

B. 时间与范围

• 时间检索：比如我们试过问"上个月讨论的那个决定"这类问题，没得到答案。记忆里似乎只有"什么时候写进来的"，没有"事情什么时候发生"，给目前的记忆块加上一套更完善的时间戳机制——这个方向你们怎么看？
• 跨项目、跨 agent 的隔离与共享：已经在推进这条线，等 0.8 之后看看还有什么边界能帮上。

C. 记忆自己的判断力

• 两条记忆冲突时，理解现在是保留一方、删掉另一方。如果改成让证据说话——败的一方降置信度但仍保留、反复出现的证据加分——会不会更合适？
• 写入时如果就能发现"这条和已有的很像"，应该能少一批重复和矛盾（我们理解现在主要是标题级去重，语义上的判断要等后台整理，不知道对不对）；
• 还有一件属于"想有"而不是"缺"：需要的时候能把多条记忆综合成一次回答，而不是一条条列出来。

召回那块（多路分数怎么合、注入预算分级、结果带上"为什么召回到它"）我们在 #24 里提过，这里不再重复。

另外说明一个前提：这些能力现在大多是"默认关、按需开启"，我们理解这是刻意的保守，这个取舍我们也认同——所以这里讨论的不是改默认值，而是这些能力要补到什么程度才算真的可用。

[modusensus]

先说感谢：你是我们把「日常真实使用」反馈回来的深度用户之一，#131 的运行时自管方案已经落地（#132/#133），#22 的图谱讨论也直接推动了 0.8.0 图谱批次的设计。这份帖子的质量同样很高——每一条都指向「记忆作为长期资产」的真实维护成本，值得逐条认真回。

下面逐条对账（按你邀请的方式：已落地的给出处，有缺口的认领，不打算做的说明）。

A. 记忆的上限与安全

裁剪与淘汰：大半已有，但你的观察也对。现有机制：Sleep Mode（空闲分层压缩——降摘要、降归档、置信分层，opt-in 默认关，你说的"要手动打开"属实）+ heat 衰减与 sleep 降级联合判定 + 质量过滤自动归档（默认开）。真正的缺口是：容量水位遥测与默认生命周期——"到量主动触发"而不是靠用户记得开睡眠。认领进路线图。

写入前密钥/隐私扫描：全新，采纳。在写入边界（memory_save / autoSummarize / dream 输出）做 PII 与密钥检测，默认仅告警、拦截 opt-in——与本项目 local-first 的姿态契合，排进 0.8.x。谢谢提出，这个越晚做越贵。

统一审计：大半已有——dream_runs / receipt_chain / failure_memories / recall_runs / llm_audit_logs 五套审计表，mirror 的 content_history 让人工编辑可追溯，状态页工作台已有活动流。你的点落在跨通道聚合（面板手改 / CLI / 外部 API 一处可查）——认领为增量（聚合视图 + 查询端点），不是从零建。

B. 时间与范围

时间检索：地基刚随 v0.8.0 落地——memories 新增 occurred_at（事件发生时间，独立于 created_at 入库时间），occurred_from/to 闭区间过滤贯通 memory_search / memory_list / 搜索融合池（#155）。诚实承认缺口：occurred_at 目前依赖写入方显式提供，存量与自动写入回退 created_at——"从会话自动推断事件发生时间"是明确的后续工作，正是你点出来的那半。

隔离与共享：正是刚发的批次 A——agent/workspace 双维标注 + 检索加权 + opt-in 的 strictScope 硬过滤 + 面板开关（#153/#155/#156/#157）。剩余边界（subagent 继承、默认作用域、mirror 分域）在 #17 线程跟踪。欢迎在 0.8.0 上实测，边界问题继续提。

C. 记忆自己的判断力

冲突让证据说话：部分已有——败者是归档（可恢复）且带溯源注释，并非物理删除；#126 之后有 supersede（注记写败者侧、胜者正文零污染）与 differentiate（双保留、各追加差异注记）；另刚补了人工集中确认队列（#166）。「败者降置信度仍保留、反复出现的证据加分」是真正的新方向——与现有 epistemic 信任分层（observation > inferred > subjective）天然衔接，认领评估。

写入时语义去重：你的判断基本准确。#127 的语义去重（vector 档，minSim 0.92 / 24h 窗口）已在 summarize 路径落地为 opt-in 配置；memory_save 工具路径默认标题级是刻意保守。"vector 档是否提为默认"我们内部讨论后回你。

按需综合多条：未做，进 backlog。现成近似物是 dream 总览（常驻综合摘要），但"需要时把多条记忆综合成一次回答"是不同的能力，值得单独设计。

召回/注入部分你自己在 #22 提过，0.8.0 图谱批次（锚定、权重演化、注入预算）落地时已参考，不再重复。

---

关于你最后说的前提——「默认关、按需开启」确实是刻意的保守（记忆是用户的资产，行为变更必须可回滚），我们认同这个取舍。这份帖子里：B2 已发、B1 地基已发、A3/C1/C2 有既有基础，新认领的是 A1 容量生命周期、A2 密钥扫描、C1 降置信保留、C3 按需综合——都会记入路线图并在这里回帖进度。欢迎继续用、继续挑刺。

[modusensus]

进度同步（上轮逐条对账的 follow-up）：v0.8.0 已发布（npm 0.8.0 / Release），上次认领的几项有了第一块落地：

• B2 隔离与共享：整批发布——agent/workspace 双维标注 + 检索加权 + opt-in strictScope 四路硬过滤（fail-closed）+ 面板开关。欢迎实测，边界问题（subagent 继承、默认作用域等）继续提。
• B1 时间检索：occurred_at（事件发生时间）+ occurred_from/to 过滤已贯通搜索与列表——地基已发，「自动推断事件时间」仍是后续工作。
• 新增（上轮没提到的）：冻结冲突的人工出口——状态页冲突队列，并排对比 + 一键裁决（保留 A / 保留 B / 仅标记），处理路径全审计。这与 C1「让证据说话」同一条线。
• 另：[Bug] 注入边界花括号转义在 0.7.32 已丢失（v0.7.4 曾修复）：hot memory 带进会话原文里的 {{.Server.Version}} 让整轮永久失败 #162 报告的「{{.Server.Version}} 卡死会话」回归已修复随本版上线（转义恢复 + hot memory 跳过 reasoning）。

A1（容量生命周期）、A2（密钥/隐私扫描）、C1（降置信保留）、C3（按需综合）保持认领，按使用反馈排期——继续用、继续挑刺。

[heptaspirit]

我最近又对 agent 记忆相关论文做了一些调研工作，对照之前的建议和你的回复，做了些总结。

两条和这批认领直接相关的读后观察：

1. C2 和 C1 之间的次序：2606.24535（Governed Shared Memory for Multi-Agent LLM Systems）记录了一个同构的生产事故——同步的近重复门抢在异步的矛盾检测之前生效，本应被裁决的矛盾写入被去重门直接拒掉，文中四个失效模式之一就是「矛盾滞留」。所以「vector 档是否提为默认」这个内部讨论里，去重门与矛盾检测的生效次序可能值得一并看；如果提默认，去重门「只标记疑似、不拒绝写入」的口径也许能把两边都保住。（mneme 侧的对应面是我们自己按代码与论文描述比对的，可能有偏差，仅供参考。）

2. C1/A1 的度量与默认值：2608.19652（Can Agent Memory Systems Track Evolving State?）把「被取代的值」单独计分、配 anti-update probes，是文献里唯一能把「冲突裁决/遗忘做没做对」单独量出来的靶子，正对着这两项认领。A1 的三个默认值（触发水位、淘汰顺序、衰减曲线）也有现成参照：2601.18642（幂律衰减优于指数，避免早期重要记忆撞悬崖）、2604.02280（免疫规则 + 软裁剪）、2604.00131（遗忘 = 降可及性可复活，而非删除）。

scope 这批我们会在日常使用里继续验，边界问题按 #17/#170 线程走。

最后附几篇觉得值得看的：

• 2603.07670 · Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers — 综述，write–manage–read 框架，「管理侧才是真正短板」的出处
• 2606.24535 · Governed Shared Memory for Multi-Agent LLM Systems — 上面第 1 点的生产事故记录
• 2608.19652 · Can Agent Memory Systems Track Evolving State? — 被取代值单独计分的状态演化评测
• 2604.00131 · Oblivion: Self-Adaptive Agentic Memory Control through Decay-Driven Activation — 遗忘 = 降可及性可复活，而非删除
• 2601.18642 · FadeMem: Biologically-Inspired Forgetting for Efficient Agent Memory — 差分衰减率，幂律优于指数
• 2604.02280 · Novel Memory Forgetting Techniques for Autonomous AI Agents: Balancing Relevance and Efficiency — 容量裁剪的免疫规则 + 软裁剪

[modusensus]

六篇全部读过了（摘要级核对完毕，其中两处标注在正文的结论——FadeMem 的幂律对比、2604.02280 的免疫规则/软裁剪——待读全文后引用），这组调研把 #164 的三个讨论点从"方向"推进到了"有靶子的工程决策"，质量很高。逐条对账 + 排期如下：

A1（容量裁剪/生命周期）——采纳，且按你给的顺序走最快落实路径：

1. heat（热度衰减）立项：三篇遗忘论文正好是立论材料——2604.00131 的"遗忘=降可及性可复活"与我们 archived/forgotten 两列的既有设计同构（等于被顶会背书），2601.18642 的差分衰减给"衰减率受访问频率调制"提供依据，2604.02280 的预算化评分对应容量水位。实现路径刻意保守：opt-in 开关 → 真实负载数据 → 对照论文假设找偏差，而非一步到位的"理论最优"。
2. 数据地基先行：[Feature] 记忆复用率仪表盘：召回 Top-N / 僵尸记忆率 / 注入命中率可见化 #217（记忆复用率仪表盘）已发——heat 需要的"访问频率"信号源正是它的产出，两者是上下游关系。[Feature] 记忆复用率仪表盘：召回 Top-N / 僵尸记忆率 / 注入命中率可见化 #217 已挂 help wanted 求认领，无人认领则我们自己排。
3. 容量水位遥测与默认生命周期：按上轮对账认领，排在 heat 之后（heat 的衰减曲线本身就是容量决策的输入）。

C2（语义去重提默认的次序问题）——采纳 2606.24535 的教训，先落设计约束：

现有实现（#127，opt-in）的命中动作是"并入，不拒绝写入"，恰好避开了论文里"同步去重门抢先拒绝矛盾性写入"的事故模式。但你的提醒成立：提为默认之前，必须先明确它与矛盾检测的生效次序。我会把这条写进设计注记（去重只做标记与并入、裁决权留给冲突管线；次序未定前不提默认），引用 2606.24535 作为依据。

C1（冲突降置信保留）——先建靶子，再谈机制：

StateMemBench 的"被取代值单独计分"给了现成评测思路：给现有 supersede/冲突队列建一个小型"旧值引用"回归测试集（多轮修改场景 → 断言检索与注入返回当前值而非被取代旧值）。靶子建好之后，"降置信保留 + 反复证据加分"的机制设计就有了可衡量的验收标准。这块邀请你共同设计。

创新线（你说的"实现层反哺理论"）：同意，而且我们手里有论文作者没有的东西——第一手数据（dream_runs 全量决策、recall 回执、未来的 heat 曲线、多写入者溯源）。计划按"论文假设 → 我们的实测 → 偏差解释"三段式记录成研究笔记，偏差大的地方就是新方法的候选位置。heat 会是第一个实验对象。

A2（密钥扫描）与 B1（事件时间自动推断）维持上轮排期不变。heat 的立项 issue 我来起，草稿会先引这六篇；你如果想认领 heat 或 #217，照惯例说一声即可。

[heptaspirit]

补一条观察角度的。我们这边此前有一段时间同时跑着另一个记忆系统（名字就不提了），对两边的行为差异做了一些使用者视角的观察。先说前提：作为重度用户（也是 fork 维护者），我们认为「记忆的完整度」这个方向的能力是值得补上的——它不太影响单条记忆的质量，但很影响 agent 回答「这个项目进展到哪了」这类问题的能力。

观察到的差异主要在三点：

1. 注入与检索给的是全文还是片段。那个系统 recall 默认返回完整内容；mneme 这边我们本机粗略统计，活跃且达到注入门槛的记忆里约六成内容超过 300 字符的注入截断线，agent 平时看到的多数是被截断的头部。读全文的工具（memory_get）是有的，缺的是把这条链路接上：截断上限可配，注入/检索时提示「可读全文」。这块应该也能和 图谱增强：把图从展示变成检索信号（discussion #22 追踪） #24 里说的注入预算分级接上。

2. 有没有一层「叙述性」的大颗粒记忆。那个系统里每项工作收尾都会沉淀一篇完整的叙述文档，另有一个常驻的状态投影，读起来是一段一段的完整上下文；mneme 这边的聚合产物目前只有 dream 维护的单行总览（我们库里那条 306 字符），pattern 合成默认是关的。碎条本身不是问题——原子条的查询与去重都好用——缺的是「把这个项目/主题讲一遍」的那一层。

3. 写入是慎重还是高频。那个系统写入极少（大约每天一两条），每条都是宿主模型有意识决定写的；mneme 是每轮自动蒸馏拆条，我们本机一天几百条的量级、九成以上最终被归档。防碎阀门（autoSummarize 每个 turn/end 都触发且无产出上限——建议新增节流、条数上限与同会话主题抑制（实测单会话日铸 198 条） #127）已经在了，默认值的事等你们 C2/A1 那条线的数据就好。

如果要接现有计划，我们觉得第 2 点最值得先聊：C3 的「按需综合」和「落库的叙述条」其实是一对能力——查当下用查询时综合，存认知用落库的 per-topic 叙述条。dream 总览已经是雏形（单行、每 run 整体替换），往「按主题的多条叙述条」延伸就自然长出这一层；原子条不动，叙述条作为附加视图，检索和去重也天然复用现有基建。第 1 点则是很小的改动就能补上的链路。

以上观察来自单机使用样本和另一个系统的使用者视角比对，没有做受控评测；哪些值得做的判断是我们的主观看法。

[modusensus]

三条观察都核实过了（inject.js 的 300 字符截断、dream 总览的单行整体替换语义），全部成立——而且这组对比的视角很值钱：这是「完整度」维度的缺口，不冲击单条记忆质量，但直接决定 agent 能不能回答"这个项目进展到哪了"。

逐条回：

① 片段 vs 全文——采纳，我们随 0.8.4 修。小改动三件套：截断上限可配、注入块对被截断条目加「内容已截断，可用 memory_get 读全文」的显式提示、与 #24 的注入预算分级衔接。这个链路确实不该断着——agent 不知道自己看到的是残篇，比截断本身更伤。

② 叙述性大颗粒——进入设计讨论，这是三条里最有分量的。同意你定的生长路径：dream 总览（单行、每 run 整体替换）是雏形，延伸为「按主题的多条叙述条」，原子条不动、叙述条作为附加视图，检索与去重复用现有基建；C3 的"按需综合"与"落库叙述条"确认为一对能力（查当下=查询时综合，存认知=按主题落库）。

设计前想先钉三个问题，欢迎在讨论里继续对齐（或直接起草设计稿，我们配合评审）：

1. 引用关系：叙述条与原子条是同一内容的两种视图——必须定义清楚叙述条是引用原子条聚合生成，还是独立正文。双视图各自演化会漂移（我们在蒸馏采集场景踩过同款双视图重复的坑）；
2. 更新语义：项目推进时叙述条是整体替换（现 dream 总览语义）、supersede 链、还是追加修订段？倾向 supersede，与 sleep 侧对齐；
3. 注入策略：叙述条进常驻层（占用注入槽位但信息密度高）还是纯按需（memory_get / 检索时综合）？倾向按需为主、常驻层只留一两条"当前项目状态"级叙述。

③ 写入慎重 vs 高频——同意默认值等数据。防碎阀门（#127）已在，heat（#218）落地后写入频率与归档率的平衡点就有实测依据了；「九成归档」在我们的口径里一部分是质量过滤在正确工作，但"高频拆条的聚合损耗"这个观察值得单独度量。

顺带说明：你同时运行另一套系统做对照这件事，本身就是最有价值的研究方法——欢迎继续把这类差异观察带回来，完整度这个方向记入 backlog 了。

[heptaspirit]

三个问题对一下我们的立场（这边此前已经按这个方向起过一版草案）：

1. 引用关系：倾向「引用聚合生成 + evidence 回链」，不做独立正文。 叙述条的正文是聚合时新生成的，但必须携带 evidence 原子条 id 列表（写入前与候选集求交，防模型捏造）；面板和检索都能从叙述条跳回原子条。漂移的规避口径是把叙述条当「生成时快照」：原子条后续更新不自动同步，由更新语义兜底。

2. 更新语义：同意 supersede，与 sleep 侧对齐。 项目推进 → 新条 supersede 旧条，旧条进 content_history 可追溯，被取代条在检索/注入侧按冲突队列现有语义处理，降权系数留给实测校准。比整体替换多留演进轨迹，比追加修订段简单；修订段模式可以作为后续增强，第一版先统一 supersede。

3. 注入策略：同意按需为主，常驻只留一条「当前项目状态」级叙述。 常驻多了挤占原子条槽位；常驻那条可以走现有 summary 的 0 档位（或紧邻），随 dream 每 run 刷新；其余 per-topic 叙述条纯按需（memory_get / 检索）。

C1 的靶子我们也想一起设计：我们正在筹备给真实库建一套检索回归基线（自建题集、结果落 recall_evals），「旧值引用回归集」可以并进去当一类题——多轮修改场景断言检索与注入返回当前值而非被取代旧值，和题集是同一套跑法。

另外 heat（#218）和 #217 我们都认领了，各自 issue 里留了说明。heat 的设计源头其实是我们 8 月在讨论 #21 里提的兴趣漂移方向，这次算是转回来了。

[modusensus]

三个设计问题全部对齐，其中两处比我们给的版本更完整，直接采纳：

1. 引用聚合生成 + evidence 回链——比「引用还是独立正文」的二选一更好：叙述条正文是聚合时新生成的（不是原子条拼接），但强制携带 evidence 原子条 id 列表、写入前与候选集求交——这一手把「模型捏造」也防掉了。「生成时快照 + 更新语义兜底」的双保险口径，就这么定。
2. supersede 第一版统一——同意：新条取代旧条，旧条进 content_history 可追溯，被取代条按冲突队列现有语义处理，降权系数留给实测校准；修订段模式记为后续增强。
3. 常驻只留一条「当前项目状态」级叙述、走 summary 0 档位——同意，复用现有 summary 优先级位最省机制，随 dream 每 run 刷新；其余 per-topic 叙述条纯按需。

C1 靶子不另起炉灶，并入你们的 recall_evals 框架：「旧值引用」作为一类题型纳入（多轮修改场景 → 断言检索与注入返回当前值而非被取代旧值），与你们的检索回归基线同一套跑法。你们 fork 里 recall_runs / recall_evals 的留痕基建成熟后，欢迎把仪表盘与评测题集的口径一起提上来——upstream 正好缺这一层，#217 的三个信号也是同一数据面。

认领确认：#217 与 #218 归你们，照惯例 PR 见，验收时我们按老规矩过。

#21 的出处补记很感谢——heat 的设计源头确实是你们 8 月的兴趣漂移调研在前，#218 立项时我们并不知道这条线。两边在互不知情的情况下收敛到同一形态，这比谁先谁后更有意思，也说明这个方向是问题本身长出来的。我会在 #218 补一条出处说明。

[heptaspirit]

三问的设计稿整理出来了，把我们这边的草案和两个新想法一起放上来。

三问的立场（成稿）：①聚合产物一律带 evidence 回链，引用的原子条必须真实存在，注册时做存在性校验，校验不过就拒绝或标 degraded；②更新走 supersede + content_history，旧版本可追溯；③注入按需为主，常驻只留一条 current-project 摘要。

产物分两型。轻的一型是 dream 产的 digest 行：聚合叙述落库、带 evidence、走注入次优先档。重的一型是 document 文件：标准化 md 落盘，记忆库里只存摘要 + 路径指针 + evidence，全文按需读。写入权我们倾向分开——document 内容归 agent，管线不生成也不改写全文，只管结构化引用（注册校验、摘要落库、比对去重、supersede 记账）；出新版就是新摘要行 supersede 旧行，旧文件不删。查询时按需合成（C3 那条）和 digest 是一对：「查当下」用前者，「存认知」用后者，期望合成一个设计推进。

触发想加第三条腿。dream 自动和查询按需之外，想提供一个由 agent 自己决定调用的整理接口：长段工作完成或 agent 觉得需要时主动触发，此时它可以调用子代理整理当前上下文并与已有记忆比对去重（筛除进归档不删），产出就是上面那种 document。先 dryRun 出比对报告、agent 判断后再 apply，调用留审计。查过现在 9 个工具和命令面，这类入口是空白。

几条觉得值得借鉴的做法（此前对比过共存的另一款记忆插件，加上自己的使用体验）：

1. 它在上下文压缩前有个专门阶段，只保存「关键连续性」。对应到我们：约定上下文即将大幅精简前先做一次整理——正在进行的任务状态恰恰是蒸馏管线覆盖不到的部分，它只管已发生的。
2. 它给集成定了两条失败判据：记忆变成聊天记录的转储、或批量把历史塞进上下文。拿这个当注入和蒸馏演化的判据很锋利——回头看我们现在的每 turn 强制蒸馏，在这个标准下确实有 dump 倾向。
3. 它的会话开头只让「库可见」（规模、怎么查），不注入内容。注入块可以加一行库可见性提示，agent 从被动消费者变成主动查询者。
4. 它把「什么时候该 recall、什么时候该写、什么时候什么都不做」写成一份独立的判断指引（一个类似于 skill 的 guide 文档），runtime 没有 hook 位时降级成持久规则。我们现在的工具只有参数说明、没有判断指引，这块值得补。

设计稿全文在手边，哪部分想细看或者要调方向我们随时可以跟帖。

[modusensus]

设计稿评审完毕，逐条对账。先回你上一条的补充：

子代理执行——采纳。整理接口的比对与 document 注册放子代理执行，主进程只收结论，dryRun 报告同样不阻断主会话；「整理动作不阻断主进程」写进 #231 验收。

两型产物：

• 轻型 digest：与落地现状对一下账——feat(dream): dream 总览升级常驻状态条——状态叙述 + 快照口径（#164 对齐） #227/feat(dream): 叙述条——按主题合成叙述 + evidence 证据链（#164 对齐） #228 已落地的形态是：current-project 状态条常驻一条（feat(dream): dream 总览升级常驻状态条——状态叙述 + 快照口径（#164 对齐） #227，随 dream 每 run 刷新）+ per-topic 叙述条按需检索（feat(dream): 叙述条——按主题合成叙述 + evidence 证据链（#164 对齐） #228，dreamNarrativeEnabled opt-in 默认关、lightMode 强制关、source=narrative、evidence 与簇成员求交、交空回落全簇）。与你稿的三处对齐：evidence 回链 ✅、supersede 走 content_history ✅、current-project 常驻一条 ✅；有出入的只有一处——你稿的「digest 行走注入次优先档」现行未落（per-topic 现为纯按需）。这个档位建议与 document 摘要行的注入预算合并成一次设计（[Feature] document 型记忆：agent 产出的长文档入库——注册校验、摘要+指针落库、supersede 记账 #230 内拍），避免注入层先动一次、document 落地再动一次。
• 重型 document：写入权分离口径采纳，已切 [Feature] document 型记忆：agent 产出的长文档入库——注册校验、摘要+指针落库、supersede 记账 #230——注册校验（evidence 存在性求交 + 路径合法）、摘要 + doc_path 落库、比对去重复用 C2 vector 档语义、supersede 记账旧文件不删。你稿的分型表与验收清单作为 [Feature] document 型记忆：agent 产出的长文档入库——注册校验、摘要+指针落库、supersede 记账 #230 的口径基线。

第三腿——已切 #231。工具面先 A 后 B 采纳（A 的 apply 内部 = B 的原子操作序列，共享校验与审计内核）；flag 默认关三处落 + 频控（分钟级间隔 + 单会话次数上限）写进验收。去重次序红线照单全收：C2 批量比对只对近重复、矛盾检测先行、agent 主动调用不豁免——这条在 #230/#231 都是硬线。

四条借鉴：

1. 关键连续性：两档触发形态（宿主精简前事件钩子 / 持久规则兜底）采纳，产物 = 会话连续性类记忆或刷新 current-project 摘要；约束/偏好保真与压缩悬崖（2608.22752）同源，作为蒸馏管线的独立题目跟进。
2. 失败判据要可测：四个观测指标里，单日入库条数、来源分布、条均长度三项 [Feature] 记忆复用率仪表盘：召回 Top-N / 僵尸记忆率 / 注入命中率可见化 #217 的统计端点顺带产出，注入块历史占比第四项靠 mode='inject' 留痕（[Feature] 记忆复用率仪表盘：召回 Top-N / 僵尸记忆率 / 注入命中率可见化 #217 口径已确认）——判据与数据面对上了。
3. 库可见性：与 [Feature] 注入可观测性：让用户看见「此刻注入了什么」 #179 合并设计，注入块头部一行的轻形态采纳。
4. 判断指引：采纳，承载位 = 工具描述 + 持久规则，优先序如稿（当前用户指令与仓库事实 > 陈旧记忆）。

type 扩展面：digest 无需新 type——复用 #228 已落地的 source=narrative 形态；document 型需要新 type，你数的 12 处清单作为 #230 的 PR 自查表。

自进化回路（反复命中 → 候选升格 → review 盖章 → 常驻）与「投影而非框架」收进设计注记；review 盖章位与现有冲突队列的面板语义保持同款。#230/#231 都挂了 help wanted，你若认领照惯例说一声；C3 按需综合与 digest 的成对关系已写进两条 issue 共用的设计注记，不会各长各的。

[heptaspirit]

顺着一处范围问题：你在评审里采纳的两条（库可见性、判断指引），落地时其实还牵出一件没有立项的事，我们建议单独立 issue 跟踪——这里说结论与我们的先后建议。

缺口：agent 侧现在只有参数级工具说明，没有「何时查 / 何时写 / 何时什么都不做 / 冲突时信谁」的指引；每轮注入是若干条截断碎片，agent 不知道库的规模和本项目还有什么。接着我们的调研，我觉得应该让 agent 能按需取得一份接口说明（每个工具做什么、何时用或跳过、优先序），上下文只带指针或极简摘要、需要时自己去读；注入块头部给一行库可见性。两件合起来，注入形态就从「每轮塞内容」部分转向「说明 + 指针 + 按需拉取」，这意味着改变了现有的注入形态。所以我们的判断是：它是新的功能需求，不是 #230 的附属，建议单开 issue 综合评估。

与相关功能的先后（我们的看法）：

• [Feature] 注入可观测性：让用户看见「此刻注入了什么」 #179（用户侧注入可观测性）：受众不同——[Feature] 注入可观测性：让用户看见「此刻注入了什么」 #179 让用户看见注入了什么，这条让 agent 知道库在哪、怎么用。两者只在这条要用的注入块头部上有交集（所以我们同意库可见性跟 [Feature] 注入可观测性：让用户看见「此刻注入了什么」 #179 合并设计）；但接口说明不宜塞进 [Feature] 注入可观测性：让用户看见「此刻注入了什么」 #179，否则会把它从「可观测性」扩成「注入层重设计」。
• [Feature] document 型记忆：agent 产出的长文档入库——注册校验、摘要+指针落库、supersede 记账 #230（document 型）：机制同构（摘要 + 指针 + 按需读全文），建议 [Feature] document 型记忆：agent 产出的长文档入库——注册校验、摘要+指针落库、supersede 记账 #230 先行，接口说明将来可复用其注册与按需读取机制；但评估独立，别让 [Feature] document 型记忆：agent 产出的长文档入库——注册校验、摘要+指针落库、supersede 记账 #230 的验收被这条拖住。
• [Feature] agent 主动整理接口：dryRun 比对报告 → agent 判断 → apply，全留审计 #231（整理接口）：无依赖，可并行。
• 顺序建议：[Feature] document 型记忆：agent 产出的长文档入库——注册校验、摘要+指针落库、supersede 记账 #230 → [Feature] agent 主动整理接口：dryRun 比对报告 → agent 判断 → apply，全留审计 #231 按现排期；这条排在它们之后、与 [Feature] 注入可观测性：让用户看见「此刻注入了什么」 #179（含 [Feature] 面板标注「极简模式下注入按宿主设计关闭」 #182 的极简标注）一起做，因为它动的是注入预算怎么分配——属于注入层一次设计的第二步。

我们建议单开一个 issue 跟踪，范围可以参考以上面几条，实现方案由综合评估最终确定。

[heptaspirit]

补一份框架级的想法，承接上面「接口说明 + 注入形态」那条。我们把它整理成四个问题：什么时候注入、注入什么、什么格式、DSH 里能挂在哪。骨架如下——细节和出处在我们手头的报告里，需要的话可以整理成附件放上来。

一、什么时候注入（时机语义至少分四类，不该只有一个）

1. 会话开头：一次性给「能力说明 + 库可见性」，之后不再重复；
2. 每轮装配：只留轻量索引或提醒（一句），不复读大段说明；
3. 对话接近尾声——我们觉得这条最值得考虑：turn 结束、会话空闲下来时注入一句「这轮有没有值得整理的」，判断权留给 agent。它比压缩边界再抢救从容（上下文还完整），也不打断工作；DSH 上现成的落点是 agent/turn-stopping，其后加延迟即可；
4. 压缩边界：上下文即将精简前，抢救「正在进行的任务状态」，避免只留下压缩摘要（可在 agent/pre-step 上按阈值自判）。

二、注入什么——按性质分三类，别混在一个块里：①能力说明（怎么用记忆：工具通则、库可见性、优先序）②记忆内容（你知道什么：摘要优先、正文按需取）③状态与提醒（现在该做什么：任务进展、整理提醒、压缩提示）。其中①的第一承载位其实是工具描述——把「什么时候不该用」写进 description 比另起一份文档更省，也天然按需。

三、格式可以参考：结构化字段清单（若做「会话连续性」，三五个字段就够：正在做什么 / 下一步 / 未决问题）；严格长度上限 + 统一前缀，便于机械校验；指针优先（标题 + 摘要 + 路径或 id，全文按需读）；同一段文本未变则不重复注入。

四、DSH 现成挂载点：systemPrompt.section（一次性说明段）· systemPrompt.context（每轮内容块，现在 mneme 用的这个）· agent/pre-step（每步前注入提醒或按阈值自判）· agent/turn-stopping（接近尾声触发整理）· system-prompt/assemble（装配期整段替换）· tools.register / commands.register（按需与手动）。都能用，不需要宿主改协议；用哪几个、用几个，取舍在你。

两点前提：这只是调研结论不是改造方案，现有默认行为不必动、新形态都可以 opt-in；另外内容常驻系统提示会让前缀随内容变化（缓存与轮换都受影响），这点在既有的实现里也没有人这么做。

我们手头有更完整的报告（每条结论都带 DSH 侧源码出处与对照），需要的话后期整理成附件放上来。

[modusensus]

单独立项同意。这个面塞进 #179 会把可观测性议题变成接口改造，并进 #230 会搅浑 document 型的验收；排期同意等 #230 PR 落了再起 issue，注入块头部的库可见性行到时候和 #179 一起做。

四问题框架没意见，前提三条（先调研非改造方案、默认行为不动、新形态全 opt-in）照此执行。两点补充：

• 能力说明第一承载位=工具描述本身，同意——这是唯一零注入通道成本的位子；
• 常驻系统提示影响前缀缓存，建议写进 issue 验收：能挂 hook 的不进常驻段。

文献这边把注入形态相关的过了一遍，给方向补几条依据（出处+分析）：

• 「不是每个请求都值得检索」：TARG（arXiv:2511.09803）免训练门控，Always 检索在多个基准输给 Never 还多付延迟——「何时查/何时 no-op」的判断指引有直接收益，不是锦上添花。
• 被动注入 vs 主动管理：Cognitive Workspace（arXiv:2508.13171）对 RAG 的六条批判（被动/碎片化/无状态），与「库可见性+指针+按需拉取」是同一主张。
• 完美回忆防不住再发现：SIx Harness（arXiv:2609.05510）的运行记录里有连续三个会话各自重新提议一个已存在（休眠）的子系统，设计文档就注入在上下文里——最后起作用的是强制查阅的清单+指针。这是「上下文只放指针、注入块带库可见性行」最硬的实证。
• NOOP 是一等动作：MEMCON（arXiv:2607.13591）把「本步不碰记忆」学成合法策略，与「没变不重复注入」同构。
• 整理触发需要外部脚手架：Focus（arXiv:2601.07190）里模型不会自发压缩上下文，周期性系统提醒是必要条件——支持尾声挂 agent/turn-stopping 问一句。
• 将来任何注入预算/命中率声明记得报实际值而非名义目标（arXiv:2607.24010 的预算评测协议）。

你那份带源码出处的完整报告，起 issue 时整理成附件传上来吧，直接引用省得从头论证。

[heptaspirit]

Feature提案已落 #249

[heptaspirit]

在今天的开发过程中，我们对先前提到的 A1 问题“记忆容量治理”另外做了专项研究，撰写了一份研究报告可供参考
2026-09-19 mneme-容量调研与观察.md