如何讓 IM Bot、Cursor CLI、Gemini CLI、Codex 共用一份永久記憶
![]()
我這次做的,不是再造一個新的“云端記憶系統”,而是把幾種不同入口的 AI 助理,統一到同一份本地文件主記憶和同一套歸檔回查機制上。
這樣無論我和 IM Bot 對話,還是在本機里用 Cursor CLI、Gemini CLI、Codex 工作,它們都能盡量延續同一段上下文,而不是每換一個入口就像失憶一次。
對我來說,這件事的核心目標很簡單:讓這些入口在我的實際使用里都像同一個持續協作的助理系統,而不是四個互不相干的工具。
為什么要這么做
如果不同入口各自保留一套上下文,問題會很快出現:
- 在 IM Bot 里說過的話,到了終端里又要重講一遍。
- 我已經確認過的語氣、身份、偏好,在另一個入口里會丟失。
- 我剛修好的流程、剛定下的規則,下一次換個工具又會重復判斷。
所以我采用的做法不是“讓每個工具都自己記住一切”,而是給它們一個共同讀取、共同追加的記憶文件,并配上統一的身份和行為規則。
實現原則
把這套共享記憶機制建立在四個原則上:
- 同一份長期記憶只保留一個主文件,但允許把舊內容按年月歸檔。
- 所有入口只做追加,不回頭改寫舊記錄。
- 身份、語氣、核心規則與長期記憶分開存放。
- 共享記憶只保存跨會話上下文,不承擔工程知識庫的全部職責。
這四點看起來普通,但它們決定了這套方案是否穩定。
尤其是只追加這一點,非常關鍵。
只要多入口都可能同時讀寫,就盡量避免“覆蓋式寫入”,否則很容易互相踩掉內容。
如何區分“共享記憶”和“知識沉淀”
這是這套方案里另一個非常重要的點。
我不會把所有信息都寫進共享記憶。
否則過不了多久,這個文件就會變成一個混亂的流水賬。
我的分法是:
該寫進共享記憶的內容
- 用戶穩定偏好
- 助理身份和語氣約束
- 長期有效的協作規則
- 以后很可能再次提到的重要決定
- 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
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.