按场景注入 vs 隔离在存储层：两种记忆注入范式的本质差异

[szx-a]

按场景注入 vs 隔离在存储层：两种记忆注入范式的本质差异

本文讨论 LMA（Layered Memory Architecture）与"按场景注入"类记忆方案的根本区别。
核心论点：隔离到底该发生在上游（存储）还是下游（检索）。

---

一、按场景注入的机制（以 SGME 为例）

"按场景注入"类方案（如：SGME ）的典型流程是三步：

① Capture   —— 保存原始对话，存进一个统一的记忆库
② Distill   —— 从原始对话提炼出带标签的记忆（事实、偏好、项目状态、决策…）
③ Inject    —— 对话开始时，系统识别当前场景，按场景检索相关记忆注入

第 ③ 步是它的核心点：

• 系统判断"现在是闲聊 / 编码 / 工作"
• 闲聊 → 注入身份、近期状态
• 编码 → 注入技术栈、坑、开发习惯
• 工作 → 注入计划、进度

它的承诺是：只注入"场景相关"的记忆，不注入全量。

---

二、它的本质问题：隔离发生在检索层

"按场景注入"看似解决了"全量注入污染上下文"，但往本质上看一层，会发现一个更深的问题：

决定好场景之后，它依然要去一个「一锅乱炖」的记忆库里去检索出"有用的"，再注入到这个会话里。

换句话说：

• 记忆本身还是混在一个统一的库里，没有结构性区分（结构性不是标记）
• "场景"只是检索时的事后筛选——先识别场景，再去乱炖库里捞出"相关的"
• 隔离是检索补丁，不是存储结构

由此带来三个固有缺陷：

1. 场景识别存在一定不可靠性：真实对话的场景是模糊、重叠、动态的（边闲聊边写代码算哪个场景？）。分类器猜错，直接变成"记忆喂错"。
2. 场景枚举有限：预设场景（闲聊/编码/工作）是有限集，真实场景（科研、写作、面试…）覆盖不全，要么强行归类，要么漏掉。
3. 用户不可控：用户没法精确说"这个会话我只让它知道 A，别知道 B"；也看不到"系统为什么注入了这些"。

一句话：按场景注入，是在乱炖库里做聪明的检索——它没有消除"乱炖"，只是减少了"乱炖"带来的污染。

---

三、LMA 的路：隔离发生在存储层

LMA 把隔离的位置上移到了存储层：

• 记忆不是混在一个统一库里，而是按「体」（Memory Body）分开存放——每个体是独立的目录 + 独立的 JSONL
• 挂载（/mount /unmount）直接圈定范围：当前会话能访问哪些体
• 从源头就不乱炖，而不是检索时才想起来过滤

隔离是结构性的（存的时候就分开了），不是检索补丁。

---

四、本质对比

维度	按场景注入	LMA（隔离在存储层）
隔离发生的位置	检索层（事后筛选）	存储层（事前分开）
记忆怎么存	一个统一库，混在一起	多个独立体，结构性隔离
谁决定喂什么	系统猜场景	用户显式挂载
边界可验证吗	难（黑盒，判得对不对不知道）	能（挂载集明明白白）
污染风险	降低但没消除（靠算法猜）	结构性消除（范围圈定）

---

五、结论

按场景注入 = 在乱炖库里做聪明的检索
多体分层   = 从源头就不乱炖

一个在"事后补救"，一个在"事前隔离"。

架构的"干净"，就干净在隔离发生在上游（存储），而不是下游（检索）：

• 事后补救，永远有"猜错"的风险——场景分类器、检索相似度，都有误差，误差直接变成"记忆喂错"
• 事前隔离，把"喂错"的可能性从结构上消掉——体分开了，挂载圈定了，剩下的只是"在正确的范围内取正确的几条"

这不是说"按需检索"没用（LMA 同样靠 memory_search 按需取），而是说：检索做的是"在已隔离的范围内取对"，而按场景注入做的却是"靠检索去弥补没隔离"。前者是锦上添花，后者是检索的优化。

---

六、相关的文档

SGME 在描述其 "Unified search" 时，原文写道：

A single search endpoint recalls from the memory pool and the knowledge base at once: keyword + semantic + label triple fusion, every result traceable to its source. SGME memories, scenes, and knowledge base in one stop; agent-owned memory files are on the roadmap.

三个关键词，句句印证"隔离发生在检索层"：

原话	暴露的结构
memory pool（单数）	一个统一记忆池 = 一锅乱炖，非多体分开存
keyword + semantic + label triple fusion	三种方式在检索时融合筛选 = 隔离在检索层
in one stop	统一入口，无存储级分层隔离

还有：

agent-owned memory files are on the roadmap.

SGME 承认，"让 agent 拥有独立记忆文件"这个能力还在路线图里、尚未实现——而这恰恰是 LMA 的「体 = 独立目录 + 独立 JSONL」已经交付的东西。

---

七、更根本的一层：写入环节的三难困境

上面讨论的是「注入（检索）」环节——记忆怎么被取出来。但再往上游推一层，有一个更根本的问题：记忆是怎么「写入」库的？

任何记忆方案，写入无非三种路径，而三种都躲不开困境：

写入路径	后果
① 按平时会话自动积累（自动提炼）	还是乱炖——所有会话记忆混进一个 pool，标签是事后贴的补丁，不是结构性隔离
② 对会话记忆自动分类（如 15 维标签）	不准——分类器有误差，标签贴错 → 检索错 → 喂错
③ 初始记忆用户自己写	鸡肋——自动记忆方案的价值主张就是"自动帮你记"，要用户手动写，它"自动"的意义就没了

三种路径，要么乱炖、要么不准、要么鸡肋——没有一条能两全。

而 按场景（如sgme） 实际走的是 ① + ② 的组合（它绕开了 ③，因为"用户手写"和它"全自动"的价值主张矛盾）：

• Capture：对话自动存为原始 Markdown（L0 raw layer）——这是 ① 自动积累，原始对话混着存
• Distill：自动提炼 + 自动打 15 维标签 + 自动去重/合并/矛盾检测——这是 ② 自动分类，在混池里靠算法猜

所以 SGME 的写入 = "自动积累（乱炖）+ 自动分类（不准）"的双重叠加：它把最难的两条路一起走了。记忆在 Capture 那一刻就混着存，Distill 再靠分类器"亡羊补牢"，但分类器本身会猜错。

这暴露了一个比"检索层隔离"更本质的事实：

问题不在"存储怎么分"，而在"写入时是不是就乱了"。

记忆在写入那一刻就乱炖了，后面检索再聪明，也是在乱炖里捞。

LMA 的破法：双权威，在写入环节就分流

LMA 用「双权威」在写入那一刻就避开了这个三难：

	写入路径	权威标记	结果
用户记忆	/remember 用户显式写	user	准确、可控，且标记为"用户钦定，只读"
模型记忆	/summarize 模型总结	model	明确标记"模型提炼的经验，可能不准，可编辑可推翻"

关键区别：

• LMA 把两者从写入那一刻就分流：用户记忆是"钦定"（可信、只读），模型记忆是"经验"（可能不准、可编辑）——即使模型总结不准，也不会污染用户钦定的记忆。
  （LMA：https://github.com/szx-a/ds.git 还在改进，文中提到的具体的实现其本身是优秀的，本文只对事和观点而言）

---

附

本文基于其公开 README 的自述，"按场景注入"的机制描述以其自述为准；不影响本文的核心论点——因为论点的靶子是**"隔离发生在检索层"这一类设计**，而非某一个具体实现。这些实现本身是优秀的

[QIANLING-0831]

我最近在给 DSH 做记忆优化插件（dsh-memory，见本站另一篇帖 #3671），对这个话题有源码级的实践，补充一些经过验证的观察——"按场景注入 vs 隔离在存储层"不是选择题，而是由 DSH v0.1-rc.7 的扩展点现状决定的。

先看 DSH 当前能用的注入接缝（源码实证）

我逐一验证过三条路径：

路径	现状（v0.1-rc.7，代码实证）
agent/pre-step messages	会被 session.append("user/message", {surfaceOp:"append"}) 写进持久化日志——注入内容变成会话历史，每步重发，Token 反而膨胀
llm/stream 改 options.messages	请求在 buildRequest 被 deepFreeze，且 waterfall 默认闭包 () => adapterStream(options, prepared) 锁死原对象——替换/变更无效，且无任何插件监听过该事件
system-prompt section	可行，但非持久化内容只能进 system prompt（请求最前）；一旦内容变化，KV 前缀缓存从第一个被改的 token 起全部失效

关键结论：稳定性才是注入安全性的前提

所以"隔离在存储层（core 记忆）"在 v0.1 下不只是更优，而是唯一 KV 安全的选择——因为 core 记忆内容稳定（只在写入时变化），system-prompt section 的前缀字节保持不变，KV 缓存得以复用。

而"按场景注入（recall）"内容易变、命中率波动，在现有接缝下要么变成持久化历史（pre-step）、要么被 deepFreeze 拦死（llm/stream）、要么打断 KV 缓存（section 注入易变内容）——三条路都堵死。

我们因此采用的分层（Letta 式）

• core（隔离在存储层）：workspace 级持久事实，经稳定 section 注入，KV 安全，跨会话；
• recall（按需）：模型主动调用 memory_search 工具对旧内容做混合（词法+语义）召回，输出严格有界——不是自动注入，而是模型在需要细节时主动取。

实现见 https://github.com/QIANLING-0831/dsh-memory （dsh-memory-core / dsh-memory-tool，已真机验证）。

给官方的一点建议

如果 DSH 后续想支持"按场景自动注入"，最干净的方向是提供一个 "非持久化 + 请求尾部追加"的接缝——请求尾部追加不破坏前缀，非持久化不污染日志。有了这个接缝，recall 注入才能真正落地而不用担心 KV 和 Token 成本。

这个帖子很好，正好把两种范式的边界问清楚了。想听大家对自己的记忆框架选型的看法。

[weijiafu14]

补一个已经跑通的工程样本：Pi 生态的 pi-hermes-memory 通过 pi2dsh 可以直接挂到 DSH。我们做的验证不是同进程 mock，而是进程 A 写入一条用户事实并退出，进程 B 全新启动后从磁盘检索回同一事实。

dsh plugin --profile web add pi2dsh
dsh plugin --profile web add pi-hermes-memory

它把“显式写入/检索的长期事实”从会话日志中独立出来，适合作为你讨论的存储层路线的一个可运行工程样本；插件仍然保持 Pi 原包，DSH 只通过兼容层获得工具、命令和生命周期。实现与验证清单：https://github.com/weijiafu14/pi2dsh#what-actually-works-today