RTFM：给 coding agent 的本地多域检索层
AI coding agent 现在已经很会读本地仓库，但它仍然容易卡在另一类问题上：项目里的关键上下文并不总在源码里。架构决策可能写在 Markdown，需求和监管依据可能在 PDF 或 XML，研究笔记可能在 Obsidian，上一轮会话整理出的结论可能散在 memory 文件里。模型如果只反复 grep 代码，就会漏掉真正能回答问题的那一段。
今天推荐的 roomi-fields/rtfm 正在补这个缺口。RTFM 的全名是 “Retrieve The Forgotten Memory”，定位是给 AI agent 用的 open retrieval layer。它把一个项目里的代码、文档、PDF、法律/监管文本、研究资料、数据和记忆文件索引到本地 SQLite，然后通过 CLI 和 MCP server 提供搜索、展开和历史查询，让 agent 先拿到小块、可继续追溯的上下文，而不是把整个目录塞进提示词。
按 GitHub repository page、README、Releases、Tags、LICENSE、pyproject.toml、公开 git history 和 changelog 在 2026-07-25 能核验的信息，roomi-fields/rtfm 当前有 20 stars、5 forks。GitHub 页面和项目元数据都指向主要语言 Python，许可证为 MIT。GitHub 页面嵌入数据里的仓库创建时间是 2026-02-20 21:37:42 UTC；公开 git history 的首个提交是 2025-12-31 15:03:14 UTC，提交信息为 Initial commit: biblirag v0.1.0。当前默认分支最新提交是 af82038，提交时间 2026-07-25 09:00:45 UTC，提交信息为 Merge feat/single-supervisor: mutualised worker (0.25.0)。GitHub Releases 和 Tags 顶部版本都是 v0.25.0，发布时间 2026-07-25 09:01:49 UTC。pyproject.toml 显示 PyPI 包名为 rtfm-ai，版本 0.25.0，要求 Python 3.10+。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | roomi-fields/rtfm |
| 定位 | 给 AI agent 使用的本地多域检索层 |
| Stars | 20 |
| Forks | 5 |
| 主要语言 | Python |
| 许可证 | MIT |
| GitHub 创建时间 | 2026-02-20 21:37:42 UTC |
| 首个公开提交 | 2025-12-31 15:03:14 UTC，Initial commit: biblirag v0.1.0 |
| 当前 main 提交 | af82038，2026-07-25 09:00:45 UTC |
| 最新 release | v0.25.0，2026-07-25 09:01:49 UTC |
| PyPI 包 | rtfm-ai 0.25.0 |
| Python 要求 | 3.10+ |
| 关键词 | MCP、local-first、SQLite、FTS5、semantic search、knowledge graph |
它不是只给代码建索引
RTFM 的有趣点，是它把 “agent 找不到上下文” 这个问题从代码搜索里拆出来。README 里反复强调：项目不只是代码，还包括 specs、PR、architecture decisions、research papers、PDF、regulations、vault notes。这些东西经常决定代码该怎么改，但普通 code indexer 很容易看不见。
它的做法是把项目资料切成可检索的 chunk，并维护到一个本地 .rtfm/library.db 里。默认可以做全文检索，也可以按需安装 embeddings 做 semantic/hybrid search；agent 先看到少量 metadata，再用 rtfm_expand 之类的工具展开真正相关的段落。这个 progressive disclosure 很适合 agent 工作流：先用 300 tokens 判断方向，再读精确区域，而不是一次性把文件全文倒进去。
README 里列出的格式范围也很宽。代码和 Markdown 是基础，PDF、LaTeX、EPUB、DOCX、ODT、RTF、XLSX、MOBI、XML/法规文本等可以通过可选依赖或 parser 系统接入。对只写 Web app 的小项目来说这可能显得重，但对 LegalTech、FinTech、HealthTech、研究型项目或文档很多的企业仓库，这正是痛点。
接入方式偏本地和 MCP
RTFM 有两条主要入口。最简单的是用 Claude Code plugin：
/plugin marketplace add roomi-fields/claude-plugins
/plugin install rtfm@roomi-fieldsREADME 说 plugin 会在项目首次使用时创建 .rtfm/library.db，注入搜索说明，预授权 MCP tools，并在首次提示时索引项目，之后增量更新。对不使用 Claude Code plugin 的工具，也可以手动安装：
pip install rtfm-ai
cd /path/to/your-project
rtfm init然后把 MCP client 指向 rtfm-serve。这让 RTFM 不只是一个 CLI 搜索器，而是 agent 可以直接调用的本地上下文服务。它强调 no cloud、no API costs，索引文件也在本机，这对不能把资料发到外部检索服务的团队很重要。
适合哪些场景
第一类是文档和代码强绑定的项目。比如一个税务、医疗、金融、合规系统，需求依据可能来自法规 PDF、XML 条文、内部决策文档和代码实现。agent 如果只看源码，很容易补出不符合依据的实现。RTFM 的价值，是让 agent 可以先搜到那段法规或设计说明，再回到代码里改。
第二类是长期项目记忆。RTFM 提供 memory 模式，可以把 Claude Code 的 memory 文件跨项目索引进 ~/.rtfm/memory.db，并保留版本历史。对多项目、多会话的 agent 使用者来说，这比靠一个越来越长的备注文件更可控：想找 “OAuth 当时为什么这样定” 时，可以直接搜到过去会话整理过的结论。
第三类是个人知识库和 NotebookLM 结果复用。README 里有 Obsidian vault 模式，也提到和 notebooklm-mcp 的配合：把 citation-backed Q&A 写成 Markdown 和 JSON sidecar 后，由 RTFM 本地索引，之后离线检索。这个角度比较小众，但很适合把 agent、PKM 和项目资料放在同一套本地检索层里。
v0.25.0 的信号
今天的最新 release v0.25.0 不是一个只改文档的版本。changelog 说它把过去的 per-project daemon fleet 改成一个 shared supervisor：单个进程服务多个已注册项目，用 bounded thread pool 排队，并保证同一个项目不会同时跑两个 job。release notes 里明确提到旧模型会带来 DB corruption、load spikes，以及多个进程各自加载 embedding model 的问题。
这个改动说明项目作者已经遇到真实的本地索引运行问题，而不是只做 README demo。对一个围绕 SQLite 和 background indexing 的工具来说，worker 模型、单写者约束、DB quick_check、corrupt DB quarantine、log rotation 这些细节很关键。它还很早期，但维护方向是工程化的。
需要注意的地方
第一，项目仍处在 alpha。pyproject.toml 的 classifier 标成 Development Status :: 3 - Alpha，star 数也很低。它值得试，但不适合无验证地放进生产关键链路。
第二，复杂格式依赖可选安装。核心 plugin 可以 dependency-free，但 PDF、embeddings、Office、EPUB 等能力会带来额外依赖和体积。README 里也写到 pdf-full 可能涉及约 1.5 GB 的 CPU-only torch 安装。团队接入前要先确认哪些 parser 真的需要。
第三，本地索引会执行项目侧的 parser 代码。项目支持 .rtfm/parsers/*.py 这类 project-local parser，灵活性很高，但信任边界也更接近“运行仓库自己的代码”。在不可信仓库里直接启用要谨慎。
第四，小项目可能不需要它。README 的 benchmark 也承认，在小于 1000 个文件的代码仓库里，普通 grep 往往够用。RTFM 更适合上下文分散、文档重、法规/研究资料多、会话记忆需要长期复用的项目。
总结
roomi-fields/rtfm 有意思的地方，是它没有把 agent 的问题简单归因给模型不够聪明，而是抓住了检索层缺失这件事。很多时候 agent 不是不会推理，而是没有先找到正确的段落、正确的文档和正确的历史决策。
如果你的项目只有代码，rg、IDE search 和普通 code indexer 可能已经够了。但如果你的 agent 经常需要在源码、规格、PDF、法规文本、研究资料、Obsidian、NotebookLM 结果和会话记忆之间来回找证据，RTFM 值得放进观察列表。它还年轻，但方向很明确：把被遗忘的项目上下文放回 agent 的工作路径里。