akitaonrails/ai-memory

解决什么问题

现在各家编程 Agent 都有自己的记忆，但记忆被锁死了：绑定一个 Agent、一台机器、一个人。一个任务在 Claude Code 里做了一半，换到 Codex，或者换台笔记本继续同一个仓库，架构、试错的方案、还没解决的问题全要重新讲一遍。ai-memory 把采集、存储、检索放到一个自建服务后面，同一项目里所有 harness 读同一份记忆。

有什么不同

现有路线大致三类：按轮抽取事实（Mem0/LangMem 一类）、时序知识图谱（Zep、Graphiti），以及文件优先的 markdown 工具（basic-memory）。ai-memory 站在文件优先这一边并往前推了一步：真相源是 git 托管的普通 .md 页面组成的 wiki，数据库只是可随时重建的派生索引，没有向量库也没有二进制黑盒。在此基础上它做了两件别家不常做的事：一是通过生命周期 hook 从一长串 harness 自动采集，二是 Agent 之间有带类型、只能被认领一次的交接协议。记忆老化（衰减、去重、矛盾标记）默认零 LLM 调用，并且可逆——原文留在 git 里，能恢复版本；LLM 参与的整理是可选开关，默认关闭。这套设计是否真比按轮存事实更好，取决于你更看重可编辑的页面还是原子事实行。

适合谁

经常在多个编程 Agent 或几台机器之间切换同一个仓库的开发者，以及想要一份带个人归属的共享项目记忆的小团队，并且愿意自己跑一个服务（笔记本或 homelab 都行）。如果你只用单一 Agent、它自带的记忆够用，或者你想要开箱即用的托管服务，这个项目不合适——它是自建基础设施。期待一个久经考验的成熟产品的人也应该再等等。

上手成本

需要 Rust 1.95+ 构建，要长期跑一个服务端进程，还要给每个 harness 注册 hook 或 MCP。支持矩阵很长但不均匀：部分 Agent 只支持 hooks 或只支持 MCP，原生 Windows 是实验状态，稳定路径是 WSL2。零 LLM 默认路径成本很低，但 README 对运维细节讲得不多，除了自报的写入上限外没有性能数据；老化、dreaming 这些功能要调参才有意义。MIT 协议、单二进制、没有付费分层，锁定风险小。真正的成本是成熟度：项目很新，文档基本就是唯一的信息来源。

点评

「跨 Agent、文件优先、LLM 可选」的记忆方案确实有区分度，也瞄准了 Agent 厂商各自为政、互相不兼容的真实痛点。热度是真的但也很年轻：约五个月拿到 13.2k star，单周 +3,449，但既没上过趋势榜日榜，也没有 Hacker News 讨论佐证，更像是自然关注叠加一次集中爆发，还不足以说明用户基本盘已经稳定。如果你本来就在多个 harness 之间切换、也能接受自建服务和早期文档，值得先试；否则先收藏，等运维和文档的叙事稳定下来再看。