"金鱼模式"是我给 AI Agent 失忆现象起的名字：每次新对话，它都像刚出生的金鱼，对你做过的事一无所知。你上周告诉它的偏好、项目背景、踩过的坑——全部归零。
长期记忆不是 nice-to-have，是 AI 从"工具"变成"协作者"的分水岭。
记忆中枢的选型
我对比过几种方案：
- 向量数据库（独立部署）：检索强，但人类不可读，调试痛苦
- 纯文件系统：简单可靠，人类可直接编辑，AI 也能读
- Obsidian vault：本质是 markdown 文件夹，但自带双链、图谱、插件生态
最终选了 Obsidian。核心理由：记忆必须对人类可读可改。AI 记错了东西，我要能打开文件直接改；AI 漏记了重要信息，我要能手写进去。纯向量库做不到这一点——你没法"编辑"一个 float 数组的语义。
目录结构即架构
vault 的目录结构就是记忆的分层架构：
memory/
├── 00-MemoryProtocol.md # 协议本身：所有 Agent 必读
├── 10-GlobalRules.md # 全局规则（跨项目生效）
├── 20-UserProfile.md # 用户画像（偏好、身份）
├── 30-Projects/ # 项目记忆（每个项目一个文件）
│ └── _index.md # 项目索引
├── 40-Decisions.md # 重要决策及理由
├── 50-Workflow.md # 工作流与操作手册
└── inbox/ # 各 Agent 的待消化条目
├── x99-hermes.md
└── n7-hermes.md
关键设计：inbox 是单向追加区。每个 Agent 任务结束后，把新产生的重要信息 append 到自己在 inbox 的文件里。只追加不删除——删旧条目是"消化"环节的职责，不是写入环节的职责。
记忆协议：三句话的契约
所有接入的 AI（无论 Hermes、prime-agent 还是 opencode），全局规则文件里都有同一段协议：
任务前：先读
10-GlobalRules.md、20-UserProfile.md、30-Projects/_index.md及任务相关项目文档。任务后：新增重要信息（规则/偏好/事实/决策/工作流）按格式追加到
memory/inbox/<设备>-<AI名>.md，只 append 不删旧条目。冲突时：你的原生 memory 只是缓存；与 vault 冲突时以 vault 最新有效版本为准。
三句话，覆盖读、写、冲突解决。简单到任何 LLM 都能遵守——协议的复杂度必须低于执行者的能力下限。
跨设备同步：一个容易翻车的细节
我的环境是双机：x99（工作电脑，晚上关机）+ n7（家用服务器，常年开机）。vault 以 x99 为生产主库，n7 通过 rsync 每小时镜像。
这里有个隐蔽的坑：n7 上的 Agent 如果直接写 vault 镜像，写入会在下次 rsync --delete 时被覆盖丢失。
解决方案是引入"暂存区"：n7 上的 AI 统一写到本机 ~/.memory-inbox/pending.md（rsync 范围之外），由每日复盘任务在 x99 在线时把 pending 条目合并进主库。
写路径必须避开同步方向的反向流。 这条教训值我四天失忆。
消化：从 inbox 到长期记忆
inbox 里的条目是"生肉"，需要定期消化成结构化知识：
- 每日复盘（cron）：读取当天所有 inbox 新条目，去重、归类
- 归位：规则进
10-GlobalRules，偏好进20-UserProfile，项目事实进对应项目文件 - 归档：已消化的 inbox 条目标记处理日期，保留原文可追溯
消化环节由一个专门的 Agent 执行（我的是 n7 上的 Hermes，因为它常驻）。它的工作不是"总结"，而是分类归档——判断每条信息属于哪个层级。
效果
运行两周后的真实体验：
- 新开的对话里，AI 知道我的项目结构、命名偏好、服务器拓扑
- "上次那个同步问题怎么解决的？"——它能从
40-Decisions.md找到完整记录 - 我手改了一条规则，所有 Agent 下次任务前读到的是新版本
记忆让 AI 的输出变得可预期。 这是从"每次开盲盒"到"稳定的协作者"的质变。
结语
个人知识管理的终极形态，不是更漂亮的笔记软件，而是人类和 AI 共享同一套记忆系统。Obsidian 提供载体，协议提供秩序，复盘提供新陈代谢。
金鱼模式结束的那天，AI 才算真正住进了你的数字生活。