本阶段的核心命题 用户说的"它记得我"，在工程上被拆成四种完全不同的东西。分不清这四层，产品需求会变成一句无法实现的"要有记忆"。
分工提醒：阶段 3 解决单次请求内放什么，本阶段解决跨会话的连续性。进入本阶段前先重读阶段 3 的笔记。
| 层 | 存在哪 | 生存期 | 谁写入 | 典型内容 |
|---|---|---|---|---|
| ① 工作记忆 | 当前上下文窗口 | 一次请求 | Harness 组装 | 系统提示词、当前消息、检索结果、工具返回 |
| ② 会话状态 | 会话存储 | 一个会话 | Harness 自动 | 消息历史、任务状态、便签、已完成步骤 |
| ③ 长期记忆 | 独立存储 | 跨会话，长期 | 有门槛地写入 | 用户偏好、稳定事实、工作习惯 |
| ④ 知识库 | 文档 + 索引 | 长期 | 人 / 编译流程 | 业务规则、产品文档、代码事实 |
四层的判别问句
- 关掉这轮对话就没了 → ①
- 关掉这个会话就没了 → ②
- 换个会话还在，且只对这个用户成立 → ③
- 换个用户也成立 → ④
最后一条是最关键的一刀："换个用户还成立吗"区分记忆与知识库。搞混了会造成跨用户污染（把 A 的偏好当成通用规则）或过期事实（把业务规则写进记忆，改了以后没人更新）。
Letta 的记忆模型是操作系统隐喻的：core memory（始终在上下文里，像内存）、archival memory（外部可检索存储，像磁盘）、recall memory（会话历史）。它的价值在于把"什么常驻、什么按需取"变成了显式的架构决策，而不是一个模糊的"记忆功能"。
对照本表：core ≈ ①里的常驻部分，recall ≈ ②，archival ≈ ③。
| 名称 | 本质 | 是否等于长期记忆 |
|---|---|---|
| 当前上下文 | 本轮可见消息、工具结果和指令 | 否 |
| Session Transcript | 可恢复的历史记录 | 否，是会话持久化 |
| CLAUDE.md / Rules | 项目或目录级持久指令 | 否，是行为配置 |
| Auto Memory | 产品提供的跨会话记忆能力 | 是，但要看具体版本与配置 |
| 本仓自定义 Memory | 一条一文件、带 Why / How to apply 的治理方案 | 是，本仓约定 |
| Vault / Wiki / GBrain | 共享文档、派生知识和跨源检索 | 否，是知识系统 |
不要把本仓实现写成 Claude Code 通用默认 本仓的目录、Schema、跨机器同步和写入门槛是项目治理设计，不代表所有 Claude Code 安装都采用相同机制。判断某项能力时要分别标注：产品原生、项目约定或外部知识服务。
| 类型 | 记什么 | 例子 | 失效方式 |
|---|---|---|---|
| 语义记忆（Semantic） | 事实 | "用户是产品经理""常飞上海–东京" | 事实变了 |
| 情景记忆（Episodic） | 发生过的事 | "上周三他把这个 PRD 的状态改成了评审中" | 通常不失效，但会过时 |
| 程序记忆（Procedural） | 做事的方式 | "他要求日期写绝对时间""中文回复里首次出现术语要标英文" | 偏好变了 |
一个常见的产品优先级，而非普适定律 在许多助理类产品里，可优先验证程序记忆 → 语义记忆 → 情景记忆：程序记忆通常直接改变行为且较稳定，情景记忆更容易过时或越过隐私边界。但具体排序仍取决于场景，例如 CRM 或医疗随访可能高度依赖经授权的情景记忆。
很多"记忆功能"做失败，是因为一上来就记录情景（"你上次说过…"），既不准又让人不适。
这是记忆系统里最先要解决的产品设计问题。 记得太多，检索时全是噪声、隐私风险高、还会记住过时的东西；记得太少，用户感觉不到连续性。之后还必须继续设计检索、冲突、时效、删除与可见性。
| # | 门槛 | 判据 |
|---|---|---|
| 1 | 跨会话适用 | 只在这一次任务里成立的，不写 |
| 2 | 不可从现有来源推导 | 代码结构、文档已有内容、git 历史里能查到的，不写 |
| 3 | 有行为影响 | 记住它会改变 Agent 下次的做法；否则只是存档 |
| 4 | 相对稳定 | 一周就变的东西不适合当长期记忆，适合当会话状态 |
| 5 | 用户可接受 | 敏感信息、可能引起不适的观察，不写 |
本仓的记忆系统就是这套门槛的实现 本知识库的 Agent 记忆规则是：一条记忆一个文件、带 type（user / feedback / project / reference）、正文写清 Why 与 How to apply、MEMORY.md 只放一行指针。并且明确规定"仓库已经记录的东西（代码结构、过往修复、git 历史、CLAUDE.md）不写"——这正是门槛 2。
拿自己每天在用的系统当研究对象，比读任何记忆产品的文档都直接。
| 时机 | 做法 | 优点 | 风险 |
|---|---|---|---|
| 模型自主判断 | 让模型决定"这条值得记吗" | 无感 | 会记一堆没用的；难审计 |
| 用户显式指令 | "记住这个" | 精确、可控 | 用户懒得说 |
| 规则触发 | 满足某条件时才写 | 可预期 | 规则本身要维护 |
生产上通常是三者混合：规则划定可写范围，模型在范围内判断，用户可随时增删。关键是任何自动写入都必须可见、可撤销。
三件事必须在方案里写清楚，否则记忆系统会在半年后变成负资产。
同一件事有两条相反的记忆，怎么办？
| 策略 | 适用 | 风险 |
|---|---|---|
| 新的覆盖旧的 | 偏好类 | 一次误判会抹掉正确记忆 |
| 保留两条 + 标注时间，由模型判断 | 事实类 | 上下文里出现冲突，模型选择不稳定（见阶段 3 实验 2） |
| 触发确认 | 高价值记忆 | 打断用户 |
推荐：写入时检测冲突（而不是检索时才发现），检测到就走"更新"而不是"新增"。这条也是本仓记忆规则里写明的——"先检查是否已有文件覆盖此事，更新它而不是建重复文件"。
每条记忆都应当带：写入时间 + 依据 + （可选）有效期。检索时把时间一并给模型，让它自己判断新旧——这比"永远相信最新"更稳，因为最新的那条可能是一次误判。
四项最低要求：
"可删除性"是合规底线，也是信任底线 用户发现 Agent 记住了一件他不想被记住的事，且删不掉——这是产品信任崩塌的典型时刻。可删除性必须在第一版就有，补不上去。
三者用不同的判据，混用会出错：
| 记忆检索 | 知识检索 | 源文档查询 | |
|---|---|---|---|
| 找什么 | 与当前用户/任务相关的历史 | 与问题相关的权威内容 | 确定的那一份原文 |
| 判据 | 相关 + 新 + 属于这个用户 | 相关 + 权威 + 未过期 | 精确定位 |
| 命中率要求 | 宁缺勿滥 | 高召回 + 高精度重排 | 100% |
| 错误后果 | 说错用户的事（尴尬） | 说错业务规则（事故） | 找不到（可接受） |
权限必须进入检索条件 记忆检索必须带用户身份过滤，知识检索必须带权限过滤。"检索时忘了过滤"是 Agent 产品最常见的数据泄露形态——不是被攻击，是自己漏的。
| 方案 | 适用 | 风险 |
|---|---|---|
| 完全共享 | 同一用户的不同专业 Agent | 一个 Agent 的错误记忆污染全部 |
| 完全隔离 | 不同租户/不同用户 | 重复劳动、体验割裂 |
| 共享读、受控写 | 大多数场景的推荐 | 需要定义谁能写 |
子 Agent 的默认原则：子 Agent 通常不应该直接写长期记忆。它的上下文是被隔离的、任务是局部的，它看到的"规律"很可能只在这个子任务里成立。让主 Agent 在汇总时决定要不要写。
四条红线：
| 误区 | 纠正 |
|---|---|
| "上大上下文窗口就有记忆了" | 窗口解决容量，不解决跨会话与检索 |
| "记忆越多越好" | 噪声、过时、隐私风险都随之增长 |
| "让模型自己决定记什么" | 需要规则划定范围 + 可见 + 可撤销 |
| "记忆和知识库可以合并" | "换个用户还成立吗"这一刀必须切开 |
| "记忆写进向量库就行" | 冲突、时效、删除这三件事向量库不管 |
| "情景记忆最能体现智能" | 最容易过时、最容易越界，收益最低 |
| "子 Agent 也可以写记忆" | 它的视野是局部的，容易把局部规律写成通用规则 |
| "删除就是从数据库里删一行" | 索引、缓存、日志、备份里的副本都要处理 |
| 资料 | 出处 | 读它拿什么 |
|---|---|---|
| LangGraph Persistence（Checkpointer vs Store） | LangChain 文档 | 会话状态与长期记忆在工程上如何分层 |
| Effective context engineering for AI agents | Anthropic，2025-09-29 | 长期任务里"把状态写出去"的做法 |
| 记忆类产品的架构文档（Letta / Mem0 / Zep 等） | 各官方 | 看不同的切分方式：OS 隐喻、抽取式、时序知识图谱 |
| OWASP Top 10 for Agentic Applications | OWASP | 记忆与上下文投毒（ASI06）的风险描述 |
本仓已有资料：