Gentleman-Programming/engram

解决什么问题

每次开新会话，agent 都是白纸一张。架构、约定、上周二已经拍板的方案，你得再讲一遍；它昨天刚改坏的东西，今天照样不知道。上下文窗口确实大了，但那是会话级的，不是项目级的。Engram 的做法是把这些观察写进本地 SQLite，用全文检索建索引，再通过 MCP 交给 agent，让上一次学到的东西能在下一次被召回。

有什么不同

常见路线有两条：一是用某个厂商自带的记忆机制（Claude Code 的项目文件、Cursor 的 rules），二是自己拼一套 RAG。Engram 走第三条路——单个 Go 二进制，不需要 Node、Python 或 Docker，底层是 SQLite + FTS5，通过 MCP、CLI、HTTP API 和 TUI 对外，不绑定具体 agent。真正让它区分开的只有两点：数据就是一个普通文件，你能自己打开、自己备份，这对不愿把项目记忆托管到别人云上的团队很关键；读取默认按项目隔离，跨项目读取要显式开启。跨机器共享靠 Git Sync 和可选的 Cloud。需要注意的是，README 花在 Windows 临时目录、Codex 写入前要校验哪个 health capability 这类边角语义上的篇幅，远多于「记忆怎么写入、怎么召回」，所以关于核心行为我们能拿到的信息比功能列表薄。

适合谁

手里有一两个支持 MCP 的编程 agent、长期在同一个真实仓库里干活、受够了每次重新介绍项目的人。也适合希望记忆留在本地、以文件形式管理的开发者，以及愿意用 Git 或托管层在团队内同步这份文件的团队。如果你大多在临时小仓库里工作、用的 agent 不支持 MCP，或者你需要一个跨非编程场景共享的记忆层，那就不合适——它明确是给编程 agent 用的。

上手成本

要跑一个二进制，并逐个注册到你用的 agent 上；README 给了 14 个目标的配置说明，也就是 14 处可能慢慢走样的配置。MIT 协议，运行时开销可以忽略。真正的成本在运维层面：一个会不断变大的 SQLite 记忆文件需要备份和定期清理；可选的 Cloud 层有自己一套 upgrade/repair/bootstrap 流程和故障排查文档；接口面大到已经出现版本间的兼容性开关（Codex 那个 health capability 检查就是一个）。README 里没有任何基准数据，所以记忆召回的质量比简单方案好多少，这里看不出来。

点评

按当前身份算，Engram 只有 250 天，但势头不弱：追踪当月 Go 榜 +833、月榜第 10，总星 7.6k。对一个 HN 上只有一条 1 分帖子的工具来说，这个涨幅算真 spike，说明热度另有来源；文档里密集的兼容性注意事项也暗示代码库迭代很快。如果你已经在大型代码库里同时用几个 MCP agent，值得挑一个仓库试一下；如果你想要的是稳定、无聊的记忆层，建议等版本节奏稳下来，并且自己验证召回效果，而不是相信徽章。