如何让 IM Bot、Cursor CLI、Gemini CLI、Codex 共用一份永久记忆

打开网易新闻 查看精彩图片

我这次做的，不是再造一个新的“云端记忆系统”，而是把几种不同入口的 AI 助理，统一到同一份本地文件主记忆和同一套归档回查机制上。

这样无论我和 IM Bot 对话，还是在本机里用 Cursor CLI、Gemini CLI、Codex 工作，它们都能尽量延续同一段上下文，而不是每换一个入口就像失忆一次。

对我来说，这件事的核心目标很简单：让这些入口在我的实际使用里都像同一个持续协作的助理系统，而不是四个互不相干的工具。

为什么要这么做

如果不同入口各自保留一套上下文，问题会很快出现：

  • 在 IM Bot 里说过的话，到了终端里又要重讲一遍。
  • 我已经确认过的语气、身份、偏好，在另一个入口里会丢失。
  • 我刚修好的流程、刚定下的规则，下一次换个工具又会重复判断。

所以我采用的做法不是“让每个工具都自己记住一切”，而是给它们一个共同读取、共同追加的记忆文件，并配上统一的身份和行为规则。

实现原则

把这套共享记忆机制建立在四个原则上：

  1. 同一份长期记忆只保留一个主文件，但允许把旧内容按年月归档。
  2. 所有入口只做追加，不回头改写旧记录。
  3. 身份、语气、核心规则与长期记忆分开存放。
  4. 共享记忆只保存跨会话上下文，不承担工程知识库的全部职责。

这四点看起来普通，但它们决定了这套方案是否稳定。

尤其是只追加这一点，非常关键。

只要多入口都可能同时读写，就尽量避免“覆盖式写入”，否则很容易互相踩掉内容。

如何区分“共享记忆”和“知识沉淀”

这是这套方案里另一个非常重要的点。

我不会把所有信息都写进共享记忆。

否则过不了多久，这个文件就会变成一个混乱的流水账。

我的分法是：

该写进共享记忆的内容

  • 用户稳定偏好
  • 助理身份和语气约束
  • 长期有效的协作规则
  • 以后很可能再次提到的重要决定
该写进知识库的内容
  • bug 修复过程
  • 脚本、命令、工作流
  • 环境坑、依赖问题、排障经验
  • 以后别的代理复用时需要的工程细节

如果一件事同时具备两种价值，我会这样处理：

  • 在共享记忆里写一行结论
  • knowledge/*.md里写完整做法

这样上下文不会丢，工程细节也不会挤爆长期记忆文件。

如何快速使用？

我已经将方法总结并写了1个skill[1]，如果你和我一样，同时使用多个ai CLI工具，就可以试试这个skill，或者基于这个skill，让ai帮你改写为你自己的永久记忆系统。

最后的结论

如果我要用一句话总结这套方案，那就是：

我不是让 IM Bot、Cursor CLI、Gemini CLI、Codex 各自拥有一份记忆，而是让它们共同服从同一份长期记忆、同一份身份定义、同一份行为规则。

这样这些入口对我来说，才是真正同一个连续协作系统的不同入口。

这也是我认为目前最稳、最容易维护、最不容易失控的一种实现方式。

参考资料

skill: https://github.com/JobYu/shared-brain