分享我一直在用的一套 AI 记忆系统方案

我换过好几个 AI 编程助手。Kimi Code 用了一阵，换 Claude Code，后来又试了 Codex。每次换的时候有个很直观的感受——之前的协作上下文全没了。

Claude 里讨论过的方案细节，Kimi 不知道。Kimi 里记着的任务进度，Claude 接不上。Agent 换一个，记忆清零。不是这些工具没有记忆功能，是它们的记忆跟着 Agent 走，不跟着我走。

这让我开始想一个问题：我跟 AI 的协作记忆，凭什么绑死在 Agent 上？

厂商的记忆和我要的记忆不是一回事

各家都在做 memory。用了一段时间发现，厂商做的记忆和我需要的记忆，差得远。

厂商的记忆是"聊天记忆"——记你说过什么，聊过什么话题，喜欢什么回答风格。这些它确实记得，但我要的不是这个。

我要的是"工作记忆"。这个任务干到哪了，关键决策定了什么，下一步做什么，上次为什么否掉了某个方案。这些不是聊天记录的复述，是工程上下文的接力。你跟一个同事合作，他不会只记得你们聊过什么，他得记得活儿干到哪了。AI 也一样。

还有一点：厂商的记忆是短期的。隔几天就淡了，换个会话可能就没了。我要的是长期记忆——有些东西可能很久不用，冷却在那，但不能丢。三个月前某个任务的决策记录，今天碰到类似问题翻出来就能用。短期记忆解决不了这个。

再说敏感信息。我的记忆系统里有一篇"关于我"的笔记，写了我的出生年份、家乡、教育背景、职业经历、技术方向、兴趣爱好，还有我云主机的配置和自托管服务清单。这些东西我需要让 AI 知道——不了解你，它给的建议就是泛泛的。但我不会把这些交给第三方平台。

不是信不过谁，是这类信息的粒度太细、太私人。交给谁都不踏实。但不给 AI 这些上下文，协作质量就上不去。自建系统是唯一能同时满足"给 AI 足够上下文"和"数据在自己手里"的解法。

这里面我有一条红线：公司业务信息绝对不上云。个人画像、个人基础设施配置可以放进去，公司业务细节一条不写。这个分级不是随意定的，是想过的。大多数人用 AI 的时候要么什么都往上扔——包括公司代码、内部数据，要么什么都不敢放——怕泄露，结果 AI 永远不了解你。我的做法是给够上下文，守好底线。这个粒度只有自己能把控。厂商的记忆系统不会帮你区分哪些能存哪些不能，更不会替你守红线。

记忆长度也是个问题。我希望它记住几乎所有会话的关键信息，需要的时候能提取出来。厂商的记忆有长度限制，而且你不知道它记了什么、忘了什么。有时候它记得你三天前聊的一句闲话，却忘了你昨天定的核心方案。这个不可控。自己的系统，存多少自己说了算，结构怎么组织自己定。

还有不绑定。Kimi、Claude、Codex 我都在用。不同 Agent 各有各的长处，今天可能用这个，明天可能换那个。记忆不应该跟着 Agent 走，应该跟着我走。换 Agent 不应该失忆。

这件事说白了就是解耦

后来我想明白了一件事。

把"记忆"从 Agent 里抽出来做成独立系统，跟软件架构里"数据层独立于应用层"是同一个道理。数据库不会绑死在某个应用上，应用换了，数据还在。我的记忆系统就是我的数据层，Agent 是应用层，两者不该耦合。

大多数人的直觉是 Agent 给什么记忆就用什么。Claude 的 memory 就用 Claude 的，ChatGPT 的 memory 就用 ChatGPT 的。我的判断相反——记忆是我的数据层，Agent 是可替换的应用层。数据层应该独立存在。

前面说的那几个问题——不绑定、敏感信息自主、记忆长度可控——不是几个独立的理由，是同一个解耦决策的不同收益。做了"记忆独立于 Agent"这个判断之后，这些好处自然就来了。

我也是用了好几个 Agent 之后才想到这层的。之前不觉得记忆是个问题，换 Agent 失忆了几次才意识到。

先用 git 试的，能用，但重

我不是一开始就用 Trilium 的。最早是用 git 仓库加 Markdown 文件做的。

方案不复杂：一个 bare 仓库放在云主机上当远程中枢，每台机器 clone 一份。记忆按任务分文件，配一个 INDEX 做索引。每次会话开始先 pull 拉取最新记忆，结束的时候更新笔记再 push。

听起来挺干净。用起来就知道重在哪了。

每台机器要装 git 环境、配 SSH key、装 hooks 脚本。在公司电脑上配好了一套，换到个人电脑上还得再来一遍。hooks 脚本要管理安装、更新、卸载，还得做 statusline 显示同步状态。为了让"每次会话自动拉取记忆"这一件事可靠工作，我写了一整套脚本——SessionStart 钩子、同步状态兜底文件、双 CLI 状态栏适配。光同步机制本身的维护量就快赶上一个小项目了。

会话开始要手动拉取，结束要手动推送。忘了就不同步。两个 Agent 同时改还有冲突——git merge 冲突处理起来不复杂，但很烦。你本来在写代码或者讨论方案，突然要停下来解决记忆文件的冲突，注意力就断了。

跨平台也是坑。macOS 的 bash 3.2 有个问题：变量后面紧跟中文字符，会把中文字符的首字节当成变量名的一部分，报 unbound variable。每个 shell 脚本改完都要 grep 复查一遍。

这些问题单个都不大，叠在一起，维护记忆系统的精力快赶上维护一个项目了。我开始觉得不对——我是在做记忆系统，还是在做 git 运维？

换到 Trilium

经过权衡，我把整个记忆系统从 git 迁到了 Trilium。

Trilium 是一个自托管的笔记应用，支持树状层级、全文搜索、属性标签，提供 ETAPI 接口。通过 MCP 协议，AI Agent 可以直接用 search_notes、get_note 这些工具读写记忆。不需要 clone 仓库，不需要装钩子，不需要手动同步。

最直观的变化是：Agent 想读什么就直接查，想写什么就直接写。没有了"先 pull 再干活、干完再 push"这套流程。Agent 任何时候打开会话，读到的都是最新的。

树状结构比平铺文件好导航。我的记忆系统现在有几个一级节点：任务索引、进行中任务、知识库、系统说明、归档。任务索引是 AI 的唯一入口，每次会话先读它，定位当前在做什么任务，按索引导航到对应的任务笔记。知识库下面又分内容创作、前端约束规范、开源项目、基础设施这些子节点。Agent 需要什么信息，先看树再钻进去，比在一堆平铺的 Markdown 文件里 grep 要快。

自托管意味着数据主权和 git 一样在自己手里。但比 git 多了 API 和结构化查询。Trilium 部署在我的云主机上，备份、升级都是我自己的事，这点跟 git 仓库一样——数据在谁手里，谁负责。

Agent 接入也轻量。不管用哪个 Agent，注册一个 Trilium MCP server 就行。Claude Code、Kimi Code、Codex，配置方式略有不同，核心就是填一个 ETAPI 地址和 token。配完之后 Agent 就能读写记忆了。不需要在每台机器上 clone 仓库和装钩子。

现在的样子

整个系统的结构不复杂。

任务索引是 AI 每次会话的起点。它是一个任务清单加导航地图，列着所有进行中的任务和各区域的入口。AI 进来先读这个，知道当前在做什么，该去哪找上下文。

进行中任务下每个任务一个笔记，里面记录现状、关键决策、下一步。任务完结了就移到归档。知识库存的是跨任务复用的东西——写作习惯、前端约束规范、开源项目索引、架构成长路线图。系统说明里有几篇元信息：关于我、关键决策、Agent 协作规则、集成指南。

两条核心规则：开工先读任务索引定位上下文，收工更新任务笔记和索引。重要决策补记到"关键决策"里。

我日常用 AI 做四类事：讨论历史哲学、代码开发和运维、写文章、搞量化。两台 Mac——公司一台、个人一台，加上三台云主机。三个 Agent——Kimi Code、Claude Code、Codex。记忆系统让这些场景之间不断档。公司电脑上讨论到一半的代码思路，回家个人电脑上接着干。Claude 里聊过的文章选题，到 Kimi 里也能接着往下写。AI 每次进来都知道我是谁、在做什么、上次到哪了。

用起来什么感觉

最明显的感受是 AI 越来越懂我了。

写作习惯那篇笔记是最好的例子。它不是我一次写出来的。最开始就几条基本规则——不说教、不指点别人、用自己的语气。每次 AI 写的东西我不满意，纠正完就加一条进去。觉得它用了 AI 口癖，加一条"不用'恰恰''本质上''值得注意的是'这些词"。发现它案例领域选得不合适，加一条"投资案例用 A 股不用美股，运动案例用爬山游泳羽毛球"。写得长了，加一条"超过 40 字的句子考虑拆"。

每加一条，下次 AI 就少犯一个错。这个笔记现在有二十多条规则，从语气风格到案例领域到格式约束到发布前检查清单。AI 写出来的东西越来越像我写的。这个过程厂商的记忆系统做不到那个粒度——它记的是"你聊过什么"，不是"你上次纠正了我哪句话"。

"关于我"那篇笔记带来的针对性也很实在。AI 知道我学什么专业出身、当过兵、现在做什么技术方向、有哪些爱好。它提建议的时候就知道我是什么水平、关心什么、熟悉什么领域。我聊服务器部署的时候它不需要从"什么是 Docker"讲起，我聊量化策略的时候它知道我有技术背景能看懂代码。不是泛泛地给方案，是给适合我的方案。

另一个感受是省事。我的记忆系统里存了云主机的配置清单——哪台机器在哪个区、什么配置、跑了什么服务。AI 需要在某台机器上操作的时候，直接读记忆就知道该连哪台、端口多少、服务在哪，不用我每次都把上下文和操作路径重新交代一遍。效率拉满。

写这篇文章本身也是个例子。文章里提到的 git 同步方案、bash 3.2 的变量问题、根目录从 11 项收敛到 7 项，这些都不是我现想的，是从记忆系统里翻出来的。当时记的时候没想过以后写文章会用，就是顺手记了。写的时候需要用，一搜就出来了。要是让我自己回忆这些细节，大概率想不全，或者得翻半天聊天记录。记忆系统帮我把这些自动记录和更新下来了，写的时候在合适的地方引用就行。

这种针对性需要长期记忆的养成。不是一次对话能建立的，是 AI 反复读你的画像、读你的决策记录、读你的写作习惯，慢慢攒出来的。

代价和误区

说了这么多好处，也得说说代价。

维护成本跑不掉。记忆系统不是建好就完了。结构要整理——我自己就做过一次根目录从 11 项收敛到 7 项的调整。笔记要更新，过时信息要清理。知识库越攒越大，信噪比会下降。我的"关键决策"笔记已经有三万字了，得定期看看哪些该归档、哪些该精简。记太多和记太少一样有害，噪音大了 AI 反而找不到有用的信息。

纪律要求也不低。"开工读索引、收工更新"这条协议，你不执行它就是个摆设。AI 不会主动提醒你收工要更新笔记。漏了几次，记忆就跟不上现实，AI 开始基于过时信息干活，还干得挺自信——因为它以为它了解你。红线原则也是一样，每次往记忆里写东西都要过一遍：这段内容有没有碰到公司信息？会不会间接暴露业务细节？这个判断只能人来做，AI 帮不了你。

自托管的运维负担也得认。Trilium 装在自己的云主机上，备份、升级、安全加固都是自己的事。子路径反代的 cookie 问题、MCP 端点的权限配置、HTTPS 证书续期，这些坑我都踩过。用 git 的时候同步机制要维护，换到 Trilium 变成了基础设施要维护。换了种维护方式，维护这件事没消失。

还有个误区得提一句：记忆系统不等于让 AI 变聪明。它给的是上下文，不是智力。你的笔记写得乱、写得不准，AI 一样会犯错，只是犯得更"自信"——因为它以为它了解你。上下文质量决定了 AI 输出的下限，但上限还是模型能力决定的。不要指望一个记忆系统能把一个笨模型变聪明，它只是让一个够用的模型在正确的上下文里工作。

最后

从 git 到 Trilium，载体换了一次，核心没变。任务索引、开工读收工写、记忆跟着我不跟着 Agent——这套协议从 git 时代就有了，迁到 Trilium 之后还在。如果明天又有个更好的工具，我大概率还会再迁一次。

工具可以换，协议是我自己的。