GNO：把本地文档、代码和笔记做成 agent 可用的检索层
很多人给 AI agent 喂上下文时，最后都会走到同一个尴尬点：资料不只在一个 Git repo 里。设计笔记在 Markdown，会议记录在文档里，旧项目说明在 PDF，运行手册在另一个文件夹，真正要改的代码又在一套源码树里。把这些东西临时复制进 prompt 不现实；全丢给云端 RAG，也不一定适合私有工作材料。
今天推荐的 gmickel/gno 是一个围绕这个问题做的本地知识引擎。它不是只搜代码，也不是只做笔记软件，而是把 notes、code、PDF、Office docs、meeting transcripts 和 reference material 收进本地 collection，再提供 BM25、向量搜索、hybrid retrieval、带引用的回答、Web UI、REST API、MCP server 和 Bun/TypeScript SDK。它适合的场景很直接：你想让 agent 查到“我实际工作中用的那些文件”，但不想先把所有资料搬到某个云服务。
按 GitHub repository page、README、Releases 页面/API、LICENSE、package.json、npm registry、公开 git history 和 scout 返回字段在 2026-07-21 能核验的信息，gmickel/gno 当前有 96 stars、9 forks。GitHub 显示主要语言为 TypeScript，许可证是 MIT。GitHub 页面嵌入数据里的仓库创建时间是 2025-12-16 15:58:15 UTC；公开 git history 的首个提交是 1345efe，提交时间 2025-12-16 15:58:26 UTC，提交信息为 Initial Commit。当前默认分支提交是 f02cecd，提交时间 2026-07-21 09:37:51 UTC，提交信息为 chore: bump to v1.12.2；scout 记录到的 latest pushed 时间是 2026-07-21 09:44:08 UTC。GitHub Releases 标记的 Latest 是 v1.12.2，发布时间 2026-07-21 09:57:53 UTC；npm 上 @gmickel/gno 的 latest 也是 1.12.2，发布时间 2026-07-21 09:46:50 UTC。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | gmickel/gno |
| 定位 | 本地知识引擎、文档/代码搜索、agent retrieval layer |
| Stars | 96 |
| Forks | 9 |
| 主要语言 | TypeScript |
| 许可证 | MIT |
| GitHub 创建时间 | 2025-12-16 15:58:15 UTC |
| 首个公开提交 | 1345efe，2025-12-16 15:58:26 UTC |
| 当前 main 提交 | f02cecd，2026-07-21 09:37:51 UTC |
| latest pushed | 2026-07-21 09:44:08 UTC |
| 最新 GitHub release | v1.12.2，2026-07-21 09:57:53 UTC |
| npm 版本 | @gmickel/gno 1.12.2，2026-07-21 09:46:50 UTC 发布 |
| 关键词 | local-first、BM25、vector search、MCP、REST API、SDK、notes、docs |
先把 collection 做扎实
gno 的 README 里最有用的部分不是“AI answer”，而是它如何让你把不同来源的资料明确放进 collection。示例里可以把 ~/notes、工作文档目录、项目源码目录分别加入，并给每个 collection 加 context。这样检索结果不只是命中文件，还带着“这是什么资料域”的框架。
这一点对 agent 很重要。很多失败的 agent workflow 不是模型不会写代码，而是它不知道某份文档是 RFC、runbook、个人笔记还是旧实现。gno context add 这种小功能看起来不起眼，但它把 retrieval 的解释权前移到索引层，而不是每次靠 prompt 临时说明。
搜索入口也分得比较清楚：gno search 做精确关键词，gno vsearch 做语义查找，gno query 做 hybrid retrieval，还能输出 score traces。你可以先让人类用 CLI 调试检索质量，再把同一套能力接给 agent。这个节奏比一上来就开一个黑盒 RAG server 更容易校准。
本地优先，但不是只有 CLI
gno 的定位是 local-first。README 明确说它给本地文件提供 fast keyword search、semantic retrieval、grounded answers with citations、wiki-style linking 和 workspace UI。安装路径也很轻：需要 Bun，bun install -g @gmickel/gno 之后就能初始化 collection、建索引、拉 embedding model、运行搜索或启动 daemon。
但它不是单一 CLI。项目提供 Web UI、REST API、MCP server 和 SDK。对日常使用来说，Web UI 方便浏览 collection、图谱、文档视图和 answer；对自动化来说，REST 和 SDK 方便嵌进自己的工具；对 Claude Code、Cursor、Zed 或其他 MCP client 来说，MCP server 是自然入口。
这也是它值得写进 Gumi 的原因。许多 “local knowledge” 工具会停在个人第二大脑，许多 code search 工具又只看源码。gno 试图把二者接起来：同一套 collection 可以放 notes、docs、PDF、Office 文件和代码，同一套检索结果可以服务人类 UI、CLI 和 agent。
对 agent 来说，引用比回答更重要
README 把 gno ask 和 grounded answers 放在显眼位置，但我更关心它的 retrieval surface。Agent 的答案是否流畅并不稀缺；真正稀缺的是它能不能指出“这个判断来自哪份本地文档或哪个文件片段”。
gno 的做法是把 raw retrieval 和 synthesis 分开。你可以只用 gno query --all --files 把文件上下文导出给 agent，也可以让它做带引用的回答。对工程工作流，这个选择很重要。修改代码前，agent 可能只需要几个相关文档和源码片段；写设计摘要时，带 citation 的 synthesis 更合适。
它还支持 daemon mode，让索引在后台跟着本地资料变动。对长期项目来说，这比每次手动重新打包上下文更实际。尤其是 runbook、会议纪要、设计草稿经常变化，agent 如果靠旧的静态 context bundle，很快就会偏离现实。
GNO 的小众点
这个项目现在 star 不多，但范围已经很完整。它有桌面 beta 资产，有 Web UI 截图，有 MCP 和 skills 文档，有 REST API 和 SDK，也有 embedding benchmark 相关内容。README 里甚至写到 Qwen3-Embedding-0.6B-GGUF 作为默认 embedding model，并有代码检索与多语言文档检索的 benchmark 说明。
有趣的是，这不是“再做一个聊天界面”。gno 更像是给本地工作资料补一个检索运行时：collection 管理、索引、embedding、query、daemon、UI、API、MCP 都围绕同一个本地知识层。对已经在用 Codex、Claude Code 或 Cursor 的人来说，它可以成为 agent 外接记忆的一部分，而不是替代 IDE。
另一个实际点是 publish 功能。README 提到可以把 note 或 collection 导出到 gno.sh reader，支持 public、secret、invite-only 和 locally encrypted before upload。这个功能和 local-first 听起来有张力，但如果它只是显式导出，而不是默认同步，对团队分享精选知识包反而有用。
需要注意的地方
第一，项目演进很快。GitHub Releases 最新已经到 v1.12.2，npm latest 也是 1.12.2，但 README 的 “What’s New” 小节仍写着 latest release v1.8.0。这说明文档局部可能滞后，写自动化脚本时要以 release/tag/package 元数据为准。
第二，它依赖 Bun，并且高级能力会涉及本地 embedding model、SQLite/向量检索和后台 daemon。README 里 macOS 还提示 vector search 需要 Homebrew SQLite。想在公司机器或 CI runner 上部署时，要先确认运行环境，不要只看 bun install -g 这一行。
第三，local-first 不等于无风险。它处理的正是 notes、docs、PDF 和 Office 文件这类可能包含敏感信息的资料。MCP、REST API、publish export 都很方便，但也意味着要认真设置哪些 collection 暴露给 agent，哪些内容可以导出。
第四，项目名字 gno 很短，和其他生态里的 Gno/Gnolang 等名词容易混淆。写脚本或文档时最好用完整包名 @gmickel/gno 或 GitHub repo gmickel/gno。
总结
gmickel/gno 值得记录，是因为它把 agent context 这个问题落在了本地文件和检索质量上，而不是再做一个聊天壳。它让你把笔记、代码、文档和 PDF 变成可搜索、可引用、可由 MCP/REST/SDK 访问的本地知识层。
如果你的 agent 经常需要查项目以外的资料，比如设计笔记、客户文档、旧会议记录、runbook 或跨 repo 的参考材料，gno 是一个值得试的小工具。它还年轻，文档也有局部滞后，但方向很清楚：先把本地知识整理成可靠的 retrieval surface，再让 agent 使用它。