跨 session 没有 memory

AI 的'失忆症'是有意设计

一、原理：长期记忆为什么难

ChatGPT 用了一段时间后，OpenAI 推出"Memory"功能——ChatGPT 记得你之前说过的事。下次对话时，它知道"你是 PM、你在做 AI 产品、你用 Notion 管理项目"。

听起来很棒——AI 终于"认识你"了。但很多用户用了一阵就关掉这个功能。原因：AI 的"记忆"经常出错或越界。

具体问题：

问题 1：错误的记忆

ChatGPT 一周前你问"如何用 SQLite"——它记下"用户在用 SQLite"。但其实你只是问问、没真用。后来它一直假设你在用 SQLite，推荐相关的库——但你早改用 PostgreSQL 了。

错误记忆比没记忆更坑——它给你不相关的建议，你还以为是"AI 智能不够"。

问题 2：过期的记忆

半年前你提过"我喜欢 Vue"——AI 记下了。半年后你已经转 React 了——但 AI 还在按 Vue 的偏好回答。

记忆没"时间感"——所有记下来的事都同等重要。但实际上偏好会演化、项目会换、立场会变。

问题 3：隐私边界模糊

AI 记得"你前妻的事"、"你的工资"、"你心情不好时跟它说的"——这些信息你期望它忘记。但它记得太牢、跨 session 拿出来，让你觉得被监视。

问题 4：跨场景污染

你工作时跟 AI 聊代码、私人时跟 AI 聊情感——AI 把两个 context 混在一起。下次工作时它突然提你私人的事——尴尬。

问题 5：记忆机制不可控

AI 内部判断"什么该记什么不该记"——但这个判断不透明。用户不知道 AI 记了什么、为什么记。想删除？通常要专门进设置去删——但记忆的 metadata 已经影响了几次对话。

把这 5 个问题合起来——"AI 自动记忆"在产品体验上是个 minefield。

设计者的初衷是好的——让 AI 更懂你。但实际效果常常是负的——错误记忆、过期记忆、隐私问题让用户失去信任。

那 AI 不该有记忆吗？也不是。但记忆的方式很关键。

我们看几种思路：

思路 A：AI 自动记忆

AI 决定记什么、什么时候记、记多久。优点：用户不用操心。缺点：上面 5 个问题。

思路 B：用户显式管理

让用户自己写下"我的偏好"——AI 读用户写的。优点：用户控制、明确。缺点：用户要花时间。

思路 C：项目级记忆

在项目里放一个文件——AI 在该项目工作时看到。优点：scope 明确（项目级）、用户可控。缺点：跨项目时记忆不传。

思路 D：完全不记忆

每个 session 独立。AI 不"认识"用户。优点：极简、隐私好、没错误记忆。缺点：每次都要"重新介绍"。

opencode 的选择是 C + D 组合——项目级记忆（用 AGENTS.md / CLAUDE.md，4.3 章讲过）+ session 完全独立。

opencode 没有任何"自动跨 session 记忆"——这是个有意的设计。

我们看具体的设计判断。

二、案例：opencode 没有用户级跨 session memory

opencode 的 session 模型有几个具体特征。

特征 1：session 之间完全独立

每个 session 有自己的 messages 历史、自己的 context、自己的状态。两个 session 之间没有自动信息流动。

如果你在 session A 跟 AI 说"我喜欢 4 空格缩进"——session B 里 AI 不会知道。需要重新告诉它。

特征 2：没有 user profile

opencode 没有"用户偏好"的概念。没有内部数据库存"用户喜欢什么"、"用户在做什么项目"。每个 session 的 LLM 只看到当前 session 的内容。

特征 3：跨 session 持久的只有"项目文件"

唯一跨 session 持久的 context 是项目里的 AGENTS.md、CLAUDE.md 这些文件。但这些文件是用户显式写的——不是 AI 自动产生。

用户在文件里写"我喜欢 TypeScript"——所有 session 在这个项目里都能看到。但用户没写、AI 自己"学到"的偏好——下个 session 就忘了。

特征 4：session 是"工作单元"

opencode 的 session 不是"持续对话"——是"一次工作"。一个 session 是"修这个 bug"或"加这个 feature"——做完了 session 就归档。

下次想做新工作，开新 session。新 session 不带旧 session 的记忆。

特征 5：session 列表可查

历史 session 不会被删——它们存档在数据库。用户可以列出历史 session、看每个的内容、甚至"resume"一个旧 session 继续工作。

但这是用户主动操作——不是 AI 自动"想起"。AI 不会说"哦，根据你三个月前的 session，我记得你..."——除非用户显式 resume 那个 session 让 AI 看到。

这 5 个特征加起来，opencode 的 AI 是"健忘"的——每个 session 都是新认识。

这种健忘是缺点还是优点？取决于看法。

对比 ChatGPT Memory：

ChatGPT 觉得"用户希望 AI 越来越懂他"——所以加自动记忆。

opencode 觉得"用户希望 AI 在每个项目里用对的工作方式"——所以让用户写 AGENTS.md 控制。

两种判断对应不同用户场景：

• 用户日常聊天、问问题——ChatGPT 的自动记忆有用（不用每次说"我是 PM"）
• 用户做编程项目——opencode 的项目级记忆更好（不会跨项目混淆）

对于编程场景，opencode 的选择更合理。理由：

理由 1：项目差异大

一个用户可能同时维护 5 个项目——React 网站、Python 后端、Rust 工具链、Vue 老项目、TypeScript 库。每个项目的技术栈、风格、约定都不同。

如果 AI"自动学到"用户偏好——它学的是哪个项目的偏好？跨项目混淆是必然的。

显式的项目级 AGENTS.md 让 scope 清晰——每个项目自己的规则。

理由 2：偏好演化快

项目早期可能用方案 A，中期换方案 B，后期重构成方案 C。每次切换 AI 应该立即跟上。

如果 AI 自动记"用户用方案 A"——它会延续到方案 B 时代——错误指引。

让用户改 AGENTS.md 强制 AI 跟上——同步。

理由 3：可审计

用户能看到 AGENTS.md 内容——清楚知道"AI 看到了什么规则"。

如果 AI 自动记忆——用户不知道 AI 内部记了什么、记错了什么。出问题时不可 debug。

理由 4：可版本控制

AGENTS.md 是文件——可以 git commit。团队 review、版本演化、回滚都能做。

AI 自动记忆是内部状态——团队不能共享、不能 review。

理由 5：隐私边界清晰

项目里写的规则——在项目内部生效。跨项目不污染。

AI 自动记忆——边界不清，可能在不该用时拿出来。

把这 5 个理由合起来——opencode 的选择是为编程场景优化的。它牺牲了"AI 自动认识你"的体验，换来"AI 在每个项目里用对的方式"。

这是个明确的产品定位——opencode 是给开发者的工具，不是给"AI 朋友"用户的产品。两种用户期望不一样，opencode 服务前者。

三、设计启示：什么时候你该不做 memory

这一章的核心论点：自动跨 session 记忆是个看似有用实际危险的特性——慎用。

设计 AI 产品时关于"记忆"，下面几条原则有用：

1. 默认不做自动记忆

如果你做 AI 产品，default 是没有自动跨 session 记忆。每个 session 独立。

这是个保守姿态，但避免上面 5 个问题。

2. 让用户显式管理偏好

让用户写一个文件、填一个表单、配一个 profile——把"AI 应该记的偏好"显式化。

用户自己控制 → 没有错误记忆 → 没有过期记忆 → 隐私边界清晰。

3. scope 要清晰

明确"这条偏好在哪个 scope 适用"：

• 全局——所有场景
• 项目级——这个项目
• session 级——这次工作

opencode 用 ~/.opencode/AGENTS.md 全局 + 项目 AGENTS.md 项目级——清晰分层。

4. 用文件而非数据库

让用户管理的"偏好"放在文件里——而不是 AI 内部数据库。

文件优点：

• 用户能直接看到内容
• 可以 git 版本控制
• 可以备份 / 同步
• 跨工具复用

5. 跨 session 持久的"自动记忆"少做或不做

如果你确实想做（业务场景必需）——非常小心。

• 让用户能审查所有自动记忆
• 让用户能删除
• 给每条记忆加 timestamp 和 source
• 让 AI 引用记忆时显式说"基于你 X 时间说的"

6. session 历史可查但不自动用

让用户能 list 历史 session、resume、查看——但 AI 不主动翻历史 session。

如果用户想让 AI 看历史——他主动 resume / reference 那个 session。

7. 给"健忘"一个理由

如果你的产品选择 opencode 这种健忘——告诉用户为什么。

"每个 session 独立 → 隐私好"、"项目级 AGENTS.md → 跨项目不混淆"——用户理解后会接受这种设计。

不解释——用户会觉得"AI 怎么这么蠢"。

8. 监控用户的 frustration

如果用户经常要"重新告诉 AI 同样的事"——他们感觉到摩擦。

收集这种摩擦点——决定是否要加局部的"记忆"机制。但不要 jump to 自动全面记忆。

最后一个观察。"AI 应该记住用户"——这个直觉很强烈。但深入想：记住的代价是什么？

人类同事记住你——你能修正他（"我换了立场"）、能拒绝他（"别提那事了"）、能解释（"那时候情况特殊"）。人际记忆有协商空间。

AI 记住你——无法精确修正、无法明确拒绝、无法补充上下文。AI 的记忆是"硬数据"——你只能要么全删要么全留。

这种"硬记忆"在很多场景下是负担而非资产。

opencode 选择"健忘"——是承认 AI 的记忆机制不如人类灵活。与其做个差的自动记忆，不如不做、让用户显式管理。

这是个反直觉的产品姿态——但理解后你会觉得 opencode 团队判断准。

第 4 篇小结

第 4 篇我们看了 context 和 memory 的 8 章。核心论点贯穿全篇：

Context 是 AI 的"工作记忆"——管理它的方式决定产品质量。

围绕这个论点：

1. Context Window 物理特性（4.1）—— attention 偏好驱动 prompt 设计
2. 6 步拼装链（4.2）—— system prompt 是动态组装
3. AGENTS.md / CLAUDE.md（4.3）—— 用户显式管理项目级记忆
4. Context Epoch（4.4）—— 状态变化的时间标尺
5. Anchored Summary（4.5）—— 增量更新避免精度漂移
6. Mid-conversation 注入（4.6）—— 细粒度系统提醒
7. 隐性管理 vs 显性提示（4.7）—— 不戳穿"你是被框架的 AI"
8. 没有跨 session memory（4.8）—— 健忘是有意设计

这些机制有一个共同的产品哲学——LLM 应该聚焦"用户的任务"，不应该被"系统的运作"分心。所有机制都围绕这个目标——给 LLM 看必要的、隐藏不必要的。

读完第 4 篇你应该有了 AI Agent 的"记忆模型"——理解什么该记什么不该记、怎么管 context、怎么平衡显性和隐性。

接下来第 5 篇我们看 多 Agent 编排——单 Agent 不够时怎么让多个 AI 协作。这是 AI 产品工程的高阶话题。