OmniSearch：把 Windows 上散落的工作痕迹收进一个本地启动器
桌面搜索这件事，真正烦人的地方不是“有没有搜索框”，而是工作痕迹被拆得太碎。
应用在开始菜单里，文件在 Explorer 里，浏览器页面躲在 history 里，剪贴板只留下最近几项，截图里的文字要靠 OCR，Git 提交和 TODO 又在另一个世界。等 AI agent、聊天记录和本地命令也进来之后，找东西这件事就越来越像在多个小数据库之间来回切换。
今天想记下的 PranshulSoni/omnisearch，切的是这个很具体的 Windows 日常摩擦：用一个本地优先的快捷启动器，把 PC 上已经存在的东西重新收进同一个键盘入口。
按 GitHub 仓库页、README 和 release 页面在 2026-07-03 能看到的公开信息，这个项目当前有 42 stars、3 forks。仓库主语言是 Rust，许可证是 MIT。仓库创建于 2026-06-22，最近一次公开代码推送是 2026-07-02。最新 release 是 v1.0.4，发布时间为 2026-07-01。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | PranshulSoni/omnisearch |
| 定位 | local-first Windows launcher / desktop search |
| Stars | 42 |
| Forks | 3 |
| 主语言 | Rust |
| 许可证 | MIT |
| 仓库创建时间 | 2026-06-22 |
| 最近公开代码推送 | 2026-07-02 |
| 最新版本 | v1.0.4 |
| 版本发布时间 | 2026-07-01 |
| 核心思路 | 用一个快捷键搜索应用、文件、内容、剪贴板、OCR、浏览器历史、Git 活动和 agent 记录 |
它的价值不是再做一个 app launcher，而是把“记得一点线索”变成入口
很多 launcher 的边界停在“打开应用”。这当然有用，但对真实工作流来说还不够。
你经常记得的不是应用名，而是某个模糊线索：
- 刚才复制过的一段错误信息；
- 上周打开过的一篇文档；
- 某个截图里出现过的订单号；
- 浏览器历史里一个只记得标题片段的页面；
- 最近在哪个 repo 里提交过某个 fix；
- 和 agent 聊过的一段任务上下文。
OmniSearch 的方向是把这些线索都变成同一个搜索入口。README 里列出的可检索来源包括应用、文件和文件内容、图片与截图 OCR、浏览器书签和历史、剪贴板、Git、Windows Settings、本地命令，以及 agent 和 agent chat。
这比“启动器”稍微往前多走了一步：它更像是一个面向 Windows 桌面的个人工作索引。
local-first 在这里不是装饰词
这个项目最值得注意的点之一，是它没有一上来把搜索框做成云端 AI 入口。
README 里强调 OmniSearch 的索引数据留在本机，运行时数据位于 %APPDATA%\omnisearch。本地数据库会保存索引元数据、可搜索文本、浏览器项、剪贴板历史、聊天、agent 和设置。实现上则用原生 Rust/Win32、SQLite FTS5、后台索引、OCR 和防抖输入来做响应速度。
这对桌面工具很关键。
因为它处理的是非常私人、非常杂的东西：剪贴板、浏览器历史、文件内容、截图 OCR、Git 活动。如果这类工具默认依赖远端服务，很多人根本不会把它放进日常工作流。local-first 至少把信任边界放在更合理的位置：先在本机把东西找回来，AI 和 agent 能力只是附加层。
剪贴板是一个容易被低估的入口
我比较喜欢 OmniSearch 把剪贴板做得很重，而不是只把它当成一个附带功能。
很多开发者每天真正重复找的东西，不是正式文件，而是刚刚经过手边的临时片段：
- 一条命令；
- 一个 URL；
- 一段日志；
- 一个 issue 编号；
- 一个 token 名称；
- 一张截图；
- 一小段要组合进回复里的文本。
OmniSearch 当前 README 里提到的剪贴板能力包括搜索历史、pin 重要项、多选、复制图片、编辑文本片段、顺序粘贴最近项目、粘贴最新截图、清理剪贴板内容，以及基于剪贴板文本询问 AI。
这类功能听起来不大，但如果做得顺手，会比一个宏大的“智能助手”更常用。因为它贴着真实键盘工作：你不是在等待 agent 理解整个世界，只是在找回刚刚滑过去的一小块上下文。
Git、OCR 和 browser recall 让它更像 programmer 工具
OmniSearch 不是纯粹面向通用办公用户。它把 Git 活动、代码内容、TODO/FIXME、OCR、agent chat 这些入口放进去之后，明显更偏 power user 和程序员。
这几个来源放在一起很合理。
程序员的“找东西”往往横跨多种介质：一段报错可能在截图里，一个修复线索可能在浏览器历史里，一个 TODO 可能在代码里，一个上下文可能在 agent chat 里。单独打开每个工具都能搜，但每次切换都会把注意力打断。
如果一个本地启动器能把这些来源统一到 Alt + Space 后面的一个搜索框里，它解决的就不是搜索算法本身，而是 搜索前的切换成本。
Hermes agent 支持要谨慎看，但方向有意思
README 里还有一层 Hermes agent 支持：可以从 launcher 里运行本地任务、执行经过批准的命令、管理 agent chat，并辅助控制 PC。
这部分我会先谨慎看。
把 agent 放进桌面启动器很容易滑向“什么都能做”的大而泛，也会立刻碰到权限、误操作和可解释性问题。但 OmniSearch 的切入点相对合理：它不是先把搜索框变成 chatbot，而是先把本地上下文和命令面板做好，再让 agent 能力接在这些本地入口之后。
换句话说，如果 agent 能从已经索引好的文件、剪贴板、Git 活动和设置入口里工作，它就更像是一个贴近桌面的操作层，而不是又一个孤立聊天窗口。
现在的风险：年轻、Windows-only、文档还粗糙
这个项目现在很小，而且非常新。仓库创建于 2026-06-22，到这篇文章记录时也就十来天。
这带来几个现实 caveat：
- 它是 Windows 工具，macOS/Linux 用户基本不是目标用户；
- README 里有一些重复段落，说明文档还在快速整理中；
- release 虽然已经到 v1.0.4，但最新说明主要是在修升级时的 self-update 和 lock 问题，这意味着安装和更新链路仍在打磨；
- 它收集的本地数据范围很宽，实际使用前应该认真看索引目录、数据位置和 agent/命令权限设置。
这些都不是否定它的理由，但会影响你是否应该马上把它放进主力桌面。
我更愿意把 OmniSearch 看成一个很有方向感的早期工具：如果你主要在 Windows 上工作，已经被开始菜单、Explorer、浏览器历史、剪贴板、截图和 Git 信息割裂得很烦，它值得试；如果你只是想要一个成熟稳定的跨平台启动器，那它现在还不是那个答案。
小结
PranshulSoni/omnisearch 吸引我的地方，是它没有只做“打开应用”的窄 launcher，也没有直接把桌面搜索包装成云端 AI 聊天框。
它选了一个更朴素但更贴近日常的方向：
把 Windows 上已经存在的工作痕迹先在本地索引起来，再用一个快捷键把它们找回来。
应用、文件、内容、OCR、剪贴板、浏览器历史、Git、设置和 agent chat，这些东西单看都普通；放到同一个低延迟入口里，价值就变得很具体。
对 Windows power user 来说，这类工具如果持续打磨，可能会比又一个“万能 AI 桌面助手”更耐用。