Claude Code、Codex CLI 和 opencode 每次对话都会把调试过程写进本地文件——JSONL 日志、SQLite 数据库,几个月下来能堆到几个GB。这些文件里躺着不少"这个bug我上周刚修过"的答案,只是没人翻得动。开源项目 deja-vu 干的事很直接:给这几堆日志装一个搜索引擎,让代理下次撞见同样问题时,先查一下自己是不是早解决过。
项目用 MIT 许可证发布,核心是一个 Go 写的单文件二进制,不用额外下模型、不用起服务。它的价值不在发明新的记忆机制,而在用很低的部署成本盘活已经存在的本地记录。但代价也摆在那——纯关键词检索、只覆盖三款代理、隐私边界有限,这决定了它现在是个称手的开发者工具,离"通用记忆平台"还有距离。
把旧日志变成可查的记忆库
deja install --all 会把 MCP recall 工具接进 Claude Code、Codex CLI 和 opencode 的配置;加一个 --auto 参数,还能挂上 SessionStart 钩子,让相关记忆在会话开始前就出现在上下文里,不用专门去问。日常用法就是一句 deja "jwt refresh rotation"——命令行直接吐出哪次会话、哪个项目处理过这个问题,连带当时的修复方案。想给同事看某次调试过程,deja share 会先脱敏再打包;想把记忆搬到另一台机器,deja sync export/import 走共享文件夹或一条 ssh 命令就够。
作者公布的自测数据(未经第三方审计,仅供参考):在约1250个会话、3.3GB语料的测试集上,热搜索通常7-9毫秒,索引体积约为原始语料的2.4%,冷启动建一次索引大概10秒。往后索引是增量的,只重读变化过的文件。
- 结论.真正省下的不是搜索时间,是不用为"记忆"额外起服务、调模型的部署成本。
纯关键词搜索,支持范围也没铺开
deja-vu 和同类工具的路数不一样。项目自己拿 cass 做对比:cass 走"大而全"路线,支持22个提供商、Rust实现、可选语义嵌入,还带TUI。deja-vu 反着来,一个小体积Go二进制,纯词法匹配,只认三款代理,基本不用配置。再往上比,Mem0、Letta 这类"记忆平台"是主动采集型的——挂钩子、调API,从现在开始往前记;deja-vu 没有采集这一步,它做的是回溯,把安装它之前几个月的历史也翻出来。两种思路谈不上谁取代谁,更像在解决不同问题。
| 代理 | 支持状态 | 备注 |
|---|---|---|
| Claude Code | 已支持 | 读取本地 JSONL 会话记录 |
| Codex CLI | 已支持 | 读取本地会话与历史文件 |
| opencode | 已支持 | 需要系统自带 sqlite3 命令行工具 |
| aider / Gemini CLI | 计划中 | 尚无落地时间表 |
支持范围目前卡在三款代理,aider 和 Gemini CLI 还只是计划。opencode 这条线的索引要靠系统自带的 sqlite3 命令行工具,"零依赖"因此打了折扣。Windows 有构建版本、CI也跑测试,但项目方自己也承认 macOS 和 Linux 才是验证得比较扎实的环境。跨机器同步依赖系统自带的 ssh/scp,而且对端也要提前装好 deja 二进制,不是纯粹的文件搬运。
- 提醒.脱敏只覆盖已知格式(AWS密钥、JWT、私钥块、常见token前缀等),原始日志文件里的秘密不会被清除,只是不会进入deja的索引和导出。
谁会真的用起来
deja-vu 最适合的场景很窄:一个人同时开着 Claude Code、Codex CLI、opencode 换着用,或者同一个项目在两三台机器之间跑。对这类开发者,省下的是"跟AI助手重复解释一遍上周怎么修的bug"的时间。企业团队想批量接入,绕不开一个问题:索引和搜索确实不联网,但deja-vu要读的是同事完整的会话记录,里面可能有内部代码片段和讨论细节,脱敏规则再细,也未必覆盖公司自己在意的敏感信息。这道审查题,目前只能由使用团队自己回答。
deja-vu 卖的不是新记忆,是把旧记录翻出来用的效率。