主题
第 3 章 形态与成熟度：L1–L4 分级
同一个「我们上了 AI 记忆」的说法，可能指三件完全不同的事：把用户画像拼进 prompt、让 Agent 自主维护记忆块、以及在多个系统之间共享受治理的语义层。三者的工程投入差一个数量级，失效后果也差一个数量级，但在需求文档里它们常常被写成同一行。
分级的目的不是给系统贴标签，而是给投入找一个可辩护的刻度。一个团队应该用多少预算建记忆，取决于它要让记忆承担什么级别的责任，而不是取决于同行在做什么。分级讲清楚之后，「要不要上哈希链」「要不要做级联删除」这类问题就会从「要不要」变成「在哪一级才需要」。
本章先给出 L1–L4 的定义与判据，再说明每一级的典型架构与失效模式，然后讨论自主度作为可调参数如何与分级配合，最后给出从低级别演进到高级别的路径与代价。
3.1 四级成熟度的定义
3.1.1 分级的两个轴
成熟度不能只用一个轴衡量。常见做法是按「自主性」排序，但自主性高不等于成熟度高——一个全自动的记忆系统可能完全没有审计能力。
本书用两个轴：记忆承担的责任与可验证的程度。
责任轴决定「错了会怎样」：错了只是体验下降，还是会导致合规问题。可验证轴决定「错了能不能发现」：只能靠用户投诉，还是能靠脚本定期检出。
两个轴交叉出四个象限，对应 L1–L4。
| 级别 | 记忆承担的责任 | 可验证程度 | 典型形态 |
|---|---|---|---|
| L1 辅助注入 | 提升体验 | 靠人工观察 | 画像拼接、few-shot 示例 |
| L2 受控持久化 | 支撑跨会话连续性 | 有日志，可回溯单条 | 显式写入 + 检索接口 |
| L3 受治理记忆 | 支撑审计与合规 | 可定期脚本校验 | 审计链 + 级联删除 + 作用域隔离 |
| L4 语义基础设施 | 支撑多系统共享事实 | 可跨系统复算 | 语义层 + 冲突仲裁 + 来源追溯 |
表 3-1 记忆系统的四级成熟度
这张表的关键不在级别高低，而在最后一行与第一行之间的差距：L1 与 L4 的工程投入差距通常是十人月量级。用 L4 的标准要求一个 L1 场景，是资源浪费；用 L1 的实现去承担 L3 的责任，是事故预备。
3.1.2 L1：辅助注入
L1 的记忆不是「存储」，而是「上下文的一部分」。典型实现是把用户偏好、历史摘要或几个示例拼进 prompt，每次调用重新生成，不追求跨会话一致。
判据：记忆错了，后果是这一轮回答不够贴合；记忆没了，功能仍然可用。
这一级的常见误区是把「用户画像」当成「记忆系统」。用户画像是一个可编辑的字段集合，它的正确性由维护者保证；记忆系统的正确性由抽取与裁决机制保证。两者可以共存，但不能互相替代——画像不会告诉你「用户上周说过要改用另一种方案」。
L1 的合理投入是零到数十行代码。任何超出这个量级的投入，都应该先问清楚：这个场景是否真的需要跨会话连续性。
3.1.3 L2：受控持久化
L2 引入了显式写入与检索接口：写入有明确的触发点（用户说了什么、任务完成了什么），检索有明确的调用点（回答前查一次）。记忆成为独立组件，可以被单独观测与测试。
判据：记忆错了，后果是跨会话体验断裂；系统能回答「这条记忆是什么时候写进来的」。
L2 需要的最小能力集是：写入幂等、作用域隔离、检索相关性下限、单条删除。这四项缺任何一项，系统在多人或长期使用下都会出问题。
L2 的典型失效是把「写入」当成「保存对话」。原始对话不是记忆——它没有经过筛选，没有类型，没有来源标注，直接检索原始对话等于把信噪比问题推给模型。L2 与 L1 的分水岭就在这里：L2 要求写入前有一次结构化加工。
3.1.4 L3：受治理记忆
L3 的记忆开始承担合规责任，因此需要三样 L2 没有的东西：不可否认的审计证据、可验证的删除、物理隔离。
判据：记忆错了，后果可能进入合同或监管范畴；系统能向审计方证明「这条记录未被篡改」且「这次删除已级联处理」。
L3 的工程门槛集中在两处。第一处是审计链：SHA-256 哈希链要求每条记录链接前一条，这带来写入串行化与校验开销，链越长校验越慢。第二处是级联删除：删除一条记忆需要处理源记录、派生结论、检索缓存、依赖摘要四个层次，且必须在预发环境用真实数据规模验证，否则 dry_run 的输出与生产实际不符。
L3 的常见误区是「有日志就算审计」。日志可以被删除或修改而不留痕迹，哈希链不能——后者能定位到具体哪一条被改。两者的差别在事故复盘时非常具体：有日志只能知道「当时发生了什么」，有哈希链才能证明「记录没有被事后修改」。
3.1.5 L4：语义基础设施
L4 的记忆不再是单个应用的内部组件，而是多个系统共享的事实来源。它需要解决 L3 没有的问题：不同来源的事实冲突如何仲裁、跨系统的事实如何追溯来源、语义定义如何版本化。
判据：记忆错了，后果是多个系统同时给出错误结论；系统能跨系统复算某个结论的依据。
截至 2026 年 10 月，L4 在工业界仍是少数。图数据库与本体建模提供了表达手段，但跨系统的冲突仲裁与权限模型仍缺少成熟方案——权限模型的复杂度会随 Agent 数量与共享范围爆炸。第 23 章会把这一点列为未解问题。
3.2 每一级的典型架构与失效
3.2.1 L1 与 L2 之间的跳跃最容易被低估
从 L1 到 L2，代码量可能只增加几百行，但需要新增的纪律很多：写入触发点要设计、作用域要规划、检索阈值要调、删除语义要定义。这些纪律不会写在代码里，只会体现在事故里。
一个具体的例子：某团队把用户偏好从「每次重新生成」改为「写入数据库后复用」，功能上线后一周内出现用户投诉「它记着我三个月前的口味，但我早改了」。这不是 bug，是 L2 缺少冲突裁决机制的必然结果——系统有写入，没有失效。
因此从 L1 升到 L2 时，冲突处理不能延后。最小可行方案是给每条记忆加 observation_date 与 superseded 标记，检索时优先返回未失效且时间较新的条目。这比完整的六类冲突判定简单得多，但能挡住大部分「旧事实压新事实」的问题。
3.2.2 L2 与 L3 之间的跳跃是成本跳跃
L2 到 L3 的成本主要不在功能开发，而在验证体系的建立。审计链、级联删除、隔离验证这三项，每一项都需要可执行的验收脚本，否则无法证明其有效。
以隔离验证为例：物理隔离的实现只要把作用域派生对路径就够了，但要证明「确实不交叉」，需要一个跨租户读取测试——用 A 的凭据尝试读 B 的数据，期望得到空结果而不是报错。这个测试写起来只要几十行，但很少有团队在 L2 阶段就建立它。
L3 的另一个成本是写入路径的串行化。哈希链要求顺序，顺序要求锁或单写者。在高并发写入场景下，这会成为吞吐瓶颈。缓解方式是分区账本或批量提交，代价是校验时需要合并分区结果。
3.2.3 L3 与 L4 之间的跳跃是组织跳跃
L3 到 L4 不是技术问题，而是权责问题。当多个系统共享同一份记忆时，谁有权写入、谁有权删除、冲突由谁仲裁，这些问题的答案不在代码里，在组织架构里。
技术上可行的路径是：定义统一的语义模型（对象、关系、规则）、为每个写入方分配作用域、在共享层做冲突检测与人工仲裁。但这套机制的运营成本很高——它需要一个持续维护语义模型的角色，而这个角色在多数组织里不存在。
因此 L4 的实践建议是：先做共享读、后做共享写。多个系统可以读同一份受治理的记忆，写入仍各自隔离。这样既获得了事实一致性，又避免了写冲突仲裁的复杂度。代价是共享层需要定期合并各写入方的数据，存在延迟。
3.3 自主度：与分级正交的参数
3.3.1 自主度不是成熟度
一个系统可以做到 L3 的治理水平，同时保持很低的自主度：所有写入由调用方显式触发，Agent 不自行决定记什么。反过来，一个 L2 的系统也可能给 Agent 很高的自主度：让模型自己决定何时写入。
把自主度与成熟度混为一谈，会导致两种错误决策：为了「更先进」而提高自主度，结果失去可解释性；为了「更可控」而压低成熟度，结果无法满足合规。
正确的做法是把自主度当作独立参数，按任务风险调节。
| 自主度 | 写入由谁决定 | 适用任务 | 主要风险 |
|---|---|---|---|
| 低 | 调用方显式触发 | 合规敏感、需要复现 | 需要设计记忆策略，Agent 无法自适应 |
| 中 | 调用方触发 + 后台整理 | 长周期任务、经验积累 | 后台整理的结果需要可审查 |
| 高 | Agent 自主编辑记忆块 | 个人助理、研究型 Agent | 决策黑盒，排查成本高 |
表 3-2 自主度的三档与适用任务
3.3.2 高自主度的代价必须被设计进去
高自主度的核心问题是可观测性。当 Agent 自行决定归档某段上下文，排查「它为什么忘了」需要逐层追溯：从最终回答回到检索结果，从检索结果回到记忆条目，从记忆条目回到写入时的决策。
这个追溯链在低自主度系统里是天然的——写入是显式的，有调用栈可查。在高自主度系统里必须专门建设：每次自主决策要记录决策依据、影响范围、可回滚点。
Mnemosyne 在这一维度上的选择是低自主度加高可观测：写入由显式工具调用触发，每次操作写入审计账本，memory_trace 沿指针链回溯到具体消息。代价是调用方要承担记忆策略设计责任——系统不会替你决定「什么值得记」。
3.3.3 混合形态会长期存在
实践中很少出现纯低自主度或纯高自主度的系统。更常见的形态是分层：用户偏好这类稳定信息用低自主度（显式写入、人工可编辑），任务经验这类易变信息用中自主度（任务结束后由后台整理，但结果可审查）。
这种混合形态的工程要求是：两类记忆必须能被区分。如果它们混在同一张表里，检索时无法判断「这条是用户确认过的偏好，还是模型推断的经验」，也就无法给出不同的置信度与不同的删除策略。
3.4 演进路径与代价
3.4.1 从 L1 到 L2 的最小改动集
四项改动，按优先级排序：
- 给记忆加
observation_date与来源标记，让「何时发生」与「从哪来」可查 - 把作用域从「一个全局库」改为「按用户/Agent 派生」，先做逻辑隔离，为物理隔离留出接口
- 在检索路径上加入相关性下限，宁可少返回
- 定义单条删除语义，哪怕只是标记删除
这四项做完，系统就有了 L2 的骨架。它们都不需要更换存储引擎。
3.4.2 从 L2 到 L3 的最小改动集
三项改动，每一项都伴随验证成本：
- 引入审计账本（哈希链），并把写入、更新、删除、导出、导入全部纳入
- 把删除升级为级联删除，并提供
dry_run预览依赖项 - 建立隔离验证与完整性验证两个可执行脚本
第二项是最容易做错的。级联删除需要先定义「派生关系」：哪些结论是由这条记忆推导出来的、哪些摘要引用了它、哪些缓存条目对应它。这层关系如果不在写入时建立，删除时只能靠扫描推断，准确率无法保证。
3.4.3 升级的时机判据
不要按「同行都在做」决定升级时机。三个具体判据：
出现第一个合规问题：客户或审计方开始要求删除证明或篡改证明时，L2 已经不够。
出现第一次跨租户风险：当用户数超过团队能人工核对的规模，逻辑隔离的遗漏风险开始不可接受。
出现第一次「记错但查不出」：当事故复盘无法定位到具体记忆条目时，说明缺少可观测性，需要向 L3 演进。
反之，如果三个信号都没有出现，把资源投在 L3 上通常是浪费——那些资源放在检索质量与用户体验上收益更高。
3.4.4 降级不是失败
一个已经建成 L3 能力的系统，在业务收缩时降级到 L2 是合理决策。降级的正确做法是保留数据结构，关闭验证流程：审计账本继续写入但不再定期校验，级联删除保留 dry_run 但简化审批。
这样做的原因是：数据结构一旦丢失，重新建立需要历史数据回填，而历史数据往往已经不可得。关闭流程的成本则低得多。
3.5 本章小结
本章确立了四条判断。
第一，成熟度要用两个轴衡量。 记忆承担的责任决定「错了会怎样」，可验证程度决定「错了能不能发现」。只按自主性排序会得出错误结论——全自动的记忆系统可能完全没有审计能力。
第二，每一次级别跃迁的成本性质不同。 L1 到 L2 是纪律成本（写入触发点、作用域、阈值、删除语义），L2 到 L3 是验证成本（审计链、级联删除、隔离测试），L3 到 L4 是组织成本（语义模型维护角色、跨系统仲裁权责）。用错成本类型做规划，会导致预算投在错误的地方。
第三，自主度是与成熟度正交的参数。 高自主度换来灵活，代价是可观测性；低自主度换来可解释，代价是调用方要承担策略设计责任。混合形态会长期存在，前提是两类记忆能被区分。
第四，升级时机应由信号触发，而不是由趋势触发。 第一个合规问题、第一次跨租户风险、第一次「记错但查不出」，是三个具体判据。三个信号都没出现时，把资源投向 L3 的收益低于投向检索质量。
分级给了投入一个刻度，但没有给实现细节。从第 4 章开始进入构建篇，逐层拆解写入、存储、检索、接入四个环节的工程做法，以及每一处做法的代价。