一位社区开发者(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 意味着小心地依靠它;现在的价值是作为文档的架构,而不是作为经过实战检验的依赖项的代码。