Recall：把散落的 AI coding session 变成本地索引
AI coding 工具用多了之后，一个很现实的问题会出现：上下文不是消失了，而是散在太多地方。
今天用 Codex 修了一个测试，明天在 Claude Code 里排查部署脚本，周末又用 Cursor 或 OpenCode 试了另一条方案。每个工具都有自己的会话文件、历史格式和恢复入口。等你想找“上次为什么没有改这个模块”或者“那条失败命令在哪一轮出现过”时，搜索范围已经变成一堆互不相通的本地目录。
今天想记下的 samzong/Recall，处理的就是这种 AI coding session 的碎片化。它不是聊天机器人，也不是云端记忆服务，而是一个 Rust 写的 local-first search across AI coding sessions：把 Claude Code、Codex、OpenCode、Cursor、Gemini、Cline、Kiro、Copilot CLI、Antigravity 等工具的本地记录同步进同一个索引，再提供 TUI、语义搜索、用量统计、JSONL 导出和 resume 入口。
按 GitHub repository API、repository page、README、release page、commits page、LICENSE、Cargo.toml 和 Git history 在 2026-07-08 能看到的公开信息，samzong/Recall 当前有 50 stars、9 forks。仓库主语言是 Rust，GitHub 语言统计中 Rust 约 97.4%，许可证是 MIT。仓库创建于 2026-04-09 09:43:56 UTC，最近 push 时间是 2026-07-07 15:59:32 UTC。默认分支是 main，最新 release 是 v0.2.10，发布时间为 2026-07-06 19:41:56 UTC。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | samzong/Recall |
| 定位 | 本机 AI coding session 搜索、用量统计、导出和恢复入口 |
| Stars | 50 |
| Forks | 9 |
| 主语言 | Rust |
| 许可证 | MIT |
| 仓库创建时间 | 2026-04-09 09:43:56 UTC |
| 最近 push | 2026-07-07 15:59:32 UTC |
| 最新版本 | v0.2.10 |
| 版本发布时间 | 2026-07-06 19:41:56 UTC |
| 核心接口 | recall sync、TUI、semantic search、usage dashboard、JSONL import/export、session resume |
它先解决“会话在哪”
很多 agent memory 工具关心的是把知识抽出来，Recall 更低一层：先把本机上真实发生过的 AI coding session 找回来。
README 里的用法很直接。recall sync 做增量同步，recall 打开 TUI，recall usage 看用量面板，recall export 和 recall import --dry-run 处理 JSONL 迁移，recall session list 给脚本列会话，recall session share 可以发布选中的 session。它还提供 recall skill install，用来自动检测 agent 并安装配套 skill。
这个方向比“再建一个笔记库”更贴近日常开发。你不是先决定哪些内容值得沉淀，而是先让工具知道本机有哪些 session、属于哪个 agent、能不能全文或语义搜索、能不能跳回原来的 CLI 继续看。
同一个索引比多个历史目录好用
AI coding 的历史记录有两个麻烦。
第一，格式不统一。Claude Code、Codex、OpenCode、Cursor、Cline、Gemini 这些工具的 session 记录位置和结构都不一样。开发者当然可以用 grep，但跨工具搜索时很快会碰到 JSONL、Markdown、数据库和自定义目录的差异。
第二，问题往往不是关键词。你可能记得“有一次我们决定绕开某个迁移”，但不记得当时写的是 migration、schema 还是 rollout。Recall 的 README 把 semantic search、full-index、incremental sync 放在同一个表里，就是想让这些跨 session 线索更容易找。
它底层也比较符合 local-first 的直觉：README 致谢里提到 SQLite FTS5、sqlite-vec、Candle、Hugging Face 和 intfloat/multilingual-e5-small。也就是说，文本检索和向量检索都尽量留在本机，不需要先把会话历史发给外部服务。
适合 Codex 重度用户的地方
我觉得 Recall 的有趣点在于，它把“继续工作”当成搜索结果的一部分。
很多日志搜索只能回答“那段话在哪里”。对 coding agent 来说，更有价值的是：这段 session 属于哪个工具，能不能回到原来的上下文，能不能导出给另一个流程，能不能统计 token 或用量。README 的支持矩阵里，Codex、Claude Code、OpenCode、Pi、Gemini 等都覆盖 discovery、full-index、incremental-sync、semantic-search、export、resume 和 usage 里的多项能力。
这让 Recall 更像一个本机 agent history console。它不会替你判断哪条结论是真的，也不会把旧上下文自动塞进下一轮 prompt。但当你需要追溯一次 agent 操作、交接给另一个工具、或者回看某个项目的历史 session 时，它能把入口集中起来。
需要注意的地方
第一，项目还很新。仓库创建于 2026-04-09，最新 release 是 2026-07-06 的 v0.2.10，README 也只有约 65 行。它适合试用和个人工作流，不适合未经验证就当成团队审计系统。
第二，它索引的是本机会话，不等于长期知识库。搜索结果仍然可能包含错误尝试、过期假设或 agent 的中间推理。真正要写进项目规则、部署文档或安全策略的内容，仍然需要人工确认。
第三，多 agent 支持会带来适配成本。README 表格显示不同工具在 resume、usage 等能力上并不完全一致。采用前最好先用一两个常用 agent 跑通 sync、搜索和恢复流程。
第四，本机索引也需要隐私边界。Recall 的价值在于把历史留在本地，但 session 本身可能包含密钥片段、客户信息或内部路径。导出和 share 功能要像处理日志一样谨慎。
小结
Recall 关注的不是“让 agent 永久记住你”，而是一个更朴素的问题：你自己的机器上已经有很多 AI coding 历史，为什么还这么难找？
它把这些历史统一成一个本地索引，再补上 TUI、语义搜索、用量统计、导出和恢复入口。对于每天在多个 coding agent 之间切换的人，这个工具的价值很具体：少翻目录，少猜关键词，更快找回上一轮工作真正发生了什么。