Memory 不是 Context

memory 不是 context。

context 是模型这一轮真正能看到的材料。memory 是外部保存、以后可能被取回的信息。

这个区分很重要。因为模型本身不天然拥有长期记忆。产品里看起来像“记得你”，通常是系统把某些历史、偏好、任务状态或经验存在外部，再在合适的时候取出来，放进当前 context。

也就是说：

memory -> retrieval -> context

memory 只有被取回并注入当前轮，才会影响这一次模型调用。

如果一个偏好存在 memory 里，但这一轮没有取出来，模型并不会自动知道它。如果一条旧经验被取出来但已经过期，它反而可能误导当前任务。

所以 memory 设计不是简单地“什么都记住”。

需要先问：什么东西值得记？

有些东西是用户偏好，例如喜欢简短回答、默认用中文、代码风格偏好。

有些东西是任务状态，例如这个项目当前做到哪一步、哪些问题还没解决。

有些东西是经验规则，例如某个 CLI 在这个环境里需要先设置特定 env。

有些东西是外部知识，例如项目文档、公司政策、API 说明。

这些东西的作用域、过期速度、可信度都不一样。用户偏好可能跨任务存在，某次 debugging 的中间状态任务结束后就该失效。代码库知识要绑定版本，网页信息可能需要重新验证。

memory 还要有写入策略。

不是每一轮对话都应该写进长期记忆。模型随口推断出来的东西，未经确认就写入 memory，会污染后续任务。更稳的做法是区分临时状态、已确认事实、用户明确偏好、可复用经验。

memory 也要有读取策略。

每轮都读所有 memory，会把 context 搞脏。完全不读，又会让系统像失忆。更好的方式是根据任务、用户、项目、时间和信息缺口来取回少量相关 memory，并保留来源和时间。

这和 context 管理 是一体的。memory 是候选材料池，context 是当前工作视图。取不取、取哪些、怎么排序、是否摘要、是否标注过期，都属于系统设计。

也可以把 RAG 和 memory 放在一起看。

RAG 更像从外部知识源按需取资料。memory 更像 agent 或产品持续积累的状态和经验。实现上它们可能共用检索系统，但语义上最好不要混成一坨“知识”。

因为来源不同，权限不同，过期规则不同，可信度也不同。

一个用户明确说过的偏好，和模型从一次对话里猜出来的偏好，不应该同等对待。

一个绑定到某个 commit 的代码总结，和当前仓库最新代码，也不应该同等对待。

所以 memory 不是“模型的脑子”。它更像一套外部笔记和索引系统。agent 需要决定什么时候写笔记，什么时候查笔记，什么时候相信笔记，什么时候回到 source of truth 重新确认。