一位社區開發者(Claudio Drews)今天發布了 Memory OS,一個 MIT 授權的 6 層記憶棧,坐落在 NousResearch 的 Hermes Agent 框架之上。層級映射到不同的記憶用途:workspace 檔案(MEMORY.md、USER.md、CREATIVE.md 注入到 system prompt)、會話歷史(SQLite + FTS5 全文搜尋)、結構化事實(SQLite + HRR + 帶回饋循環的 trust scoring)、Fabric(LLM 驅動的會話提取,從 Icarus Plugin 分叉)、向量資料庫(Qdrant 帶 4096 維餘弦向量加 BM25 稀疏搜尋),以及一個自動策劃的 LLM Wiki,會重新攝入回 Qdrant。一切透過 Docker 在本地執行(Qdrant + Redis + ARQ Worker + Python 3.11+);LLM 呼叫仍然去 Hermes 支援的任何提供商(OpenRouter、OpenAI、Anthropic、Ollama)。
架構是一個級聯檢索系統。在 pre_llm_call 時,四個源(Fabric、Qdrant、Sessions、Facts)首先用混合搜尋查詢,然後是密集向量,然後是詞彙搜尋,然後 SQLite 作為後備。按會話去重阻止相同上下文在一個窗口中出現兩次,相關性閾值在任何東西到達模型之前過濾。在 post_llm_call 和 on_session_end 時,捕獲寫回層。遺忘是明確的:每週衰減掃描器使過時條目老化,語義去重在餘弦相似度超過 0.92 時合併近乎相同的記憶。Trust scoring(第 3 層)維護一個回饋循環,隨時間調整源的可信度。缺少的東西很重要:沒有發布的關於召回品質、延遲或 token 節省的基準,也沒有針對多 agent 一致性的正式寫衝突解決方案。儲存庫在 github.com/ClaudioDrews/memory-os,剛剛出生,提交很少,單個開發者。當作分層想法的早期階段腳手架,而不是生產強化元件。
兩個生態線索。首先,該架構是社區建構的明確表述,說明了大多數 agent builders 最終臨時組裝的東西:一個分層記憶管道,其中不同的目的(系統上下文、會話召回、事實儲存、語義搜尋、結構化提取、知識累積)獲得不同的機制,而不是被摺疊成單一的「向量 DB 和祈禱」模式。這種分層是即使你從不直接接觸 Memory OS 也值得帶走的設計教訓。其次,定位:Memory OS 通過完全本地化明確地將自己與 mem0、Zep 和 Letta 等雲服務進行對比。這適合更廣泛的浪潮:「我想要我的 agent 記憶在我的磁碟上,而不是在別人的資料庫中,」這對於隱私敏感或氣隙建構來說是一個合理的立場。權衡是操作性的:帶 Qdrant + Redis + ARQ Worker 的 Docker 棧比透過 API 呼叫 mem0 多基礎設施。對於在雲管理和自託管記憶之間決定的 builders,這在分類帳的本地一側放置了一個真正的選項,儘管是框架綁定到 Hermes。
週一早上,如果你已經在 Hermes Agent 上建構:Memory OS 值得作為 Hermes 原生記憶的下拉升級來嘗試,特別是如果你的 agent 受益於跨長歷史的語義召回。在押注之前對召回品質和 token 使用進行你自己的評估;沒有發布的基準意味著你就是基準。如果你不在 Hermes 上,6 層分解是要點,而不是程式碼:workspace + 會話 + 事實 + 提取 + 向量 + 策劃的 wiki 映射到你可能已經需要的不同目的,在你所在的任何 stack 中分別存在。如果你部署一個隱私敏感或氣隙的 agent,並且不想要雲記憶提供商,這是一個新鮮的選項來對抗已建立的替代品進行評估。單個開發者加上 few-commits-old 意味著小心地依靠它;現在的價值是作為文件的架構,而不是作為經過實戰檢驗的依賴項的程式碼。