Deja-vu 实战：把散落的 Claude Code、Codex 会话变成可检索的本地记忆
AI 编程 Agent 最让人沮丧的时刻，往往不是它写错代码，而是它已经解决过同一个问题，却在新会话里从头再来一遍。JWT 刷新失败、迁移脚本的边界、某个文件为什么不能改——这些结论本来藏在 Claude Code、Codex 或 OpenCode 的本地会话日志里，但日志通常分散、体积很大，也没有一个统一入口。
Deja-vu 是一个 MIT 许可的 Go 单二进制工具，试图把这些既有日志转成一层本地记忆：先索引历史，再通过命令行或 MCP 提供检索、摘要和“这个文件当时为何这样改”的回溯。它不是新的 Agent 平台，也不要求把会话搬到云端；重点是利用各个工具已经写在本机上的记录。
本文基于项目 README 与 2026-07-19 发布的 v0.13.1 版本说明，梳理它适合解决的问题、最小接入路径，以及将“记忆”接入 Agent 时应保留的边界。
先分清：它索引什么，不索引什么
Deja-vu 支持读取多个 Agent 已存在的本地存储，包括 Claude Code、Codex CLI、OpenCode、aider、Gemini CLI、Cursor、Antigravity、Grok Build、Qwen Code 与 pi。不同工具的记录格式并不相同：有的是 JSONL，有的是 SQLite 或 IDE 数据库。Deja-vu 的职责是解析这些来源，将可搜索文本写进本地索引。
这带来一个重要取舍：它能“追认”过去数月的历史，而不必从今天开始重新埋点；但它也只知道那些本来就保存在本机的内容。团队协作、远端 Agent 或浏览器里的临时对话，并不会神奇地自动出现。
项目的默认设计是本地优先。索引和检索保存在 ~/.cache/deja；网络行为主要发生在用户主动运行更新检查、通过 SSH 同步时。它在入库阶段尝试识别并替换常见 API Key、Bearer Token、JWT、私钥块以及带用户名密码的 URL。这里的措辞要谨慎：这是一层降低二次泄漏风险的清洗，不等于原始 Agent 日志已经安全；原始日志仍由各自的 Agent 工具保存。
安装后先做“只读验证”
项目提供脚本、Go、npm 与 Homebrew 四种安装入口。对已安装 Go 的开发机，下面的方式最容易追溯来源；若只是临时试用，npx 也可直接执行查询。
go install github.com/vshulcz/deja-vu/cmd/deja@latest deja doctor --json deja sources deja warmup
deja doctor --json 用于报告存储解析、索引、MCP 接线和版本等状态；deja sources 列出发现的来源、大小与计数；deja warmup 则构建或刷新索引。建议先运行这三步，而不是一开始就让它改写 Agent 配置：这样能确认当前机器确实找到了会话文件，也能及时发现例如 OpenCode/Cursor 依赖本机 sqlite3 CLI 的情况。
初次索引之后，直接以一个真实故障场景检索即可：
deja "jwt refresh token" deja ctx "database migration" deja blame cmd/deja/main.go
第一条返回跨历史的匹配片段；ctx 将最佳结果压缩为适合放入提示词的 Markdown 摘要；blame 则按文件路径查找讨论过该文件的会话。后两者特别适合接手旧项目：先看过去的设计讨论和修复依据，再决定是否继续改。
两种接入方式：人主动查，或 Agent 按需回忆
最保守的用法是把检索结果显式放进一次对话。项目 README 给出的模式如下：
claude "Prior context: $(deja ctx 'database migration')"
这很适合敏感项目，因为开发者每次都能看到要注入的上下文。缺点也明显：人必须记得先查，并且查询词决定了召回质量。
如果希望 Agent 自己调用记忆，可以让 Deja-vu 配置 MCP：
deja install --all deja install --auto
install --all 会为检测到的客户端配置 MCP recall；--auto 在支持的环境中额外启用会话开始时的自动召回。MCP 侧提供 recall、recall_context、blame 与 remember：前两个查找会话片段或摘要，blame 回溯文件相关决策，remember 用于保存一条明确的长期结论。
自动化不应等同于无条件灌入历史。Deja-vu 的默认 DEJA_RECALL=safe 以当前项目为范围、偏向最近 90 天、过滤弱匹配或重复项，并限制注入大小；项目也提供 aggressive 和 off。在生产仓库里，建议先保持默认的安全范围，观察几天误召回情况，再决定是否放宽跨项目搜索。
还应把“检索到历史”与“授权执行操作”明确分开。召回结果可能包含旧分支、过期依赖版本或当时仅适用于临时环境的绕过方案。尤其是涉及删除数据、轮换凭证、修改权限和发布配置的任务，应让 Agent 将历史内容视为待验证线索：先定位当前代码和文档，再给出差异与计划，最后才执行。这样，记忆层负责减少重复探索，不会悄悄扩大自动化的操作权限。
让“记忆”成为工作流，而非提示词垃圾场
一个可复用的团队约定是：在排障、重构或重新实现功能之前，先用项目名加症状检索；找到命中后，要求 Agent 标明它复用了哪条历史结论；真正稳定的决策再用 remember 写成短事实，而不是把长聊天全文当作知识库。
例如排查数据库迁移失败时，先运行 deja ctx "database migration"，将结果作为候选证据，再让 Agent 打开当前迁移和测试验证。历史只能缩短定位时间，不能替代对现有代码、配置和生产数据的核验。
跨机器同步也应按这个原则使用。deja sync export 与 deja sync import 传递的是追加式批次，项目将其描述为已清洗的 JSONL；它还支持通过 deja sync ssh 推送。即便如此，导出的会话摘要仍可能包含业务语义、路径或架构决策。把同步目录当成需要访问控制的工程资产，而不是普通缓存。
性能数字该如何看
README 给出了一个真实语料的测量：约 1,250 个会话、约 3.3GB 数据下，典型热查询约 12ms，首次冷索引约 10 秒，索引体积约为原始语料的 2.4%。另外，项目的可复现实验用合成任务链比较了摘要召回与完整历史重放，报告相同事实覆盖下中位 token 更少。
这些数字说明本地倒排索引适合解决“在大量日志里找到已解决问题”的速度问题，但不应被理解为任何代码库都能获得同样的 token 节省或答案正确率。项目自己也说明该基准的 token 是按字节近似、覆盖指标依赖生成器定义。实际使用时，更值得关注的是：你的查询是否命中正确项目、摘要是否遗漏关键限制、以及历史结论是否已被新版本推翻。
适用边界
Deja-vu 适合拥有多个本地 Agent、会话积累很快、又希望保留数据控制权的个人开发者或小团队。它尤其适合作为“先查证据，再写代码”的前置步骤：让 Agent 少重复调试，而不是让它对旧记录盲目自信。
如果你的工作流主要在云端、需要统一的权限审计、或必须对记忆内容进行强合规治理，则还需要补充集中式存储、访问控制与审计系统。对本地工作流来说，最小可行实践是先索引、再手动 ctx 验证；确认召回质量后，才启用 MCP 与自动召回。这样既能利用过去的会话，也能把新会话的判断权留在开发者手里。
部署后可以把 deja doctor --json 加进周期性健康检查，并在 Agent 工具升级、会话目录迁移或索引结果异常时重新执行 deja warmup。但不要把健康检查的成功等同于知识正确：它只证明来源、解析和索引处于可用状态，不能证明被召回的方案仍适合当前仓库。
相关链接