模式矩阵 /模式白皮书/M1

文档状态：本页为公开评审稿。模式定义与分类可供讨论和引用；未附来源链接的数字与应用示例只用于说明机制，不作为行业基准。

问题

Agent 每次启动要"想起"的信息作用范围完全不同：公司安全政策对全员永久有效，用户偏好只跟着这个人，会话进度只在这次有效，工具结果一轮就过期。把它们全堆进同一个 prompt 会同时撞上两堵墙：token 爆掉，或者关键信息被噪声淹没。

分层保留把这些信息按作用域切成多层，每层有自己的存储位置、过期时间和加载策略。Agent 启动时从粗到细加载，需要时按层往下查。它解决的核心问题不是"存什么"，而是"分什么层"——没有分层的记忆系统会随时间退化成一个翻不到东西的仓库。

分类依据：记忆 × 层级

• 纵轴 · 记忆：它管的是 agent 跨会话、跨用户、跨项目存什么，对应经典的 working / session / long-term 三层记忆划分，是记忆模块的地基模式。
• 横轴 · 层级：多层之间是从属关系，外层设定是内层的默认值，内层可以覆盖外层。数据在 hot / warm / cold 之间升降流动，是天然的层级化存储结构，不是链式也不是循环。

解决方案与机制

1. 按作用域分层：分层的首要依据是"谁该看到这条信息"，不是"内容类型"。典型四层是用户级（跨所有会话不变）、项目级（项目内共享）、会话级（当次有效）、临时级（一轮过期）。作用域决定一条信息该放哪层。
2. 每层独立选型：每层的存储后端按访问模式单独选。用户层高频读、低频写、永久，适合带索引的关系库；项目层适合文件系统加 git 管理；会话层高频读写、有 TTL，适合 Redis；临时层就是内存字典。四层用同一个后端是新手实现的标志。
3. 从粗到细加载：会话启动时按作用域从粗到细组装 prompt，每层有独立的 token 预算。层级化的好处之一就是会话再长也不会把用户层挤掉。
4. 升降级与淘汰：成熟实现会按访问模式让记忆自动流动——被频繁引用的记忆升层，长期不访问的降层，过期的按 retention policy 清除。这把静态 schema 变成了动态 working set。

适用条件

• 跨会话、跨用户、跨项目复用的 agent：编程教练、长期助手、企业内部 agent，需要记得"这个用户是谁、这个项目在干嘛、上次聊到哪"。
• 多租户 SaaS agent：作用域分层天然带来隔离，用户 A 的偏好不会污染用户 B 的会话，项目 X 的规则不会带到项目 Y。金融、医疗、合同审阅这类不能容忍租户串数据的场景尤其依赖这一点。
• 企业级开发者 agent：Claude Code 的多层 CLAUDE.md 就是这个模式，写 CLAUDE.md 的人本身在做记忆架构师，把安全规则、个人偏好、项目规则分别放在不同层。

已知失效方式

• 层数照抄不照需：上来就抄 CoALA 三层（working / episodic / semantic），但产品其实只需要两层，结果代码里多出一堆没东西可放的空架子。层数应该跟产品的作用域种类数一致。
• 用户层不做 schema：让 agent 自由文本写"小李会装饰器"，半年后同一概念十种写法，retrieval 命中率断崖。高频字段必须 typed schema 化。
• 全部按启动注入设计：用户层和项目层是启动注入，会话层是渐进读取，临时层是实时拼装。三种 access pattern 混成一种，会话层积累几十轮后 token 会爆炸。
• 完全无状态的场景强行分层：单次问答、一次性 ETL 转换不需要跨会话记忆。
• eviction 不留 reason log：合规（GDPR right-to-be-forgotten）和 debug 都要求能证明"删了什么、为什么删、什么时候删"，没有日志就证明不了。

验证指标

• Working set 命中率（健康区 ≥ 80%）：agent 推理时真正需要的记忆是否都在 prompt 里。低于 30% 说明分层没起作用，再漂亮的 schema 也白搭。这是判断分层做对没的首要指标。
• 每层 token 占比（按预算分配）：各层加载到 prompt 的 token 是否在预算内。某层持续超预算，说明该层需要截断或下沉到按需加载。
• 跨层污染率（健康区接近 0）：是否出现用户层被单次会话的偶然信息污染、租户之间串数据。多租户场景这是生死线指标。
• 启动 token 总量（对照基线衡量）：相比"全 history dump"省了多少。分层做对通常能省 70-80% 启动 token。

参考实现

定义层级（作用域从粗到细）：
    USER    → 永久 / 高频读 / 强 schema / 关系库
    PROJECT → 永久 / 团队共享 / 文件系统 + git
    SESSION → TTL 24h / 高频读写 / Redis
    TURN    → TTL 5min / 极高频 / 内存字典

写入：按层选 backend，记 last_modified
读取：从细到粗查，内层命中即返回（内层覆盖外层）
组装：启动时从粗到细拼 prompt，每层按 token_budget 截断
淘汰：过期内容清除并记 reason log（合规 + debug）

工程落地四个要点：每层的存储后端要真做不同选型；组装时按 token budget 截断而非全量塞入；写入做"写入路由"（小模型或规则决定写哪层）；eviction 必须留 reason log。

应用示例

某薪酬 SaaS 的执行型智能体把记忆做成三层。L1 是当前意识流——这一刻该看到的最小必要集，只放推进眼前这一步真正用得上的信息，保持极简。L2 是进行中的里程碑日志——记着任务做到哪、刚完成了什么，跨回合维持任务上下文。L3 是跨回合可复用经验——把这类任务上沉淀下来的判断和做法留作长期资产。三层各管一个时间尺度：L1 管"现在",L2 管"本任务",L3 管"跨任务"。这套分层让 agent 在长流程里既不会被无关历史淹没（L1 始终精简），又不会在回合之间失忆（L2 持续维护），还能随使用越来越熟练（L3 持续累积）。配套工程决策包括每层独立 token 预算、L1 实时拼装而非预加载、L3 写入前做信任校验避免单次偶然信息污染长期经验。

相关模式

• 进度追踪（M3）：M3 是分层里最 hot 的那一层。Todo list 是 agent 的寄存器，频繁更新、每次推理都加载，本质是会话层里专门管"做到哪了"的部分。
• RAG（M2）：分层解决"长期已知的记忆怎么按作用域加载"，RAG 解决"作用域装不下的海量知识怎么现查现用"。分层管已知，RAG 管外挂。
• 失败日记（M4）/ 程序性记忆（M5）：这两者是长期记忆层里的专门分区——M4 存失败案例，M5 存成功招式。分层是容器，它们是容器里的内容。
• 语义压缩（感知模块）：会话层 token 满了触发语义压缩瘦身，是分层在单层内部的配套机制。

设计结论

分层保留的本质不是数据库 schema 设计，而是给 agent 装一个 working set 管理器——它决定哪些记忆常驻 RAM、哪些按需 swap in、哪些长期 swap out。

企业证据

当前没有与本模式绑定的公开评审案例。模式定义不因此视为已经获得企业验证。

案例收录要求说明业务约束、实现结构、已知失败和迁移边界。参见 贡献与评审规则。