Manifest V3 下做端侧 AI 扩展：把 1024 维向量检索塞进浏览器里

这篇文章不讲产品发布，只讲实现：当 Chrome 扩展全面切到 Manifest V3、Service Worker 随时可能被回收时，怎么在浏览器端跑起图片特征提取和向量检索，并且做到用户图片 0 上传。以下是我在 OmniPic 这个扩展上实践本地优先架构的记录。注：本文正文不放任何链接，项目名即是检索词。

一、先说约束：MV3 给端侧计算挖了哪些坑

1. Service Worker 无常驻：后台脚本会被浏览器回收，长任务、模型状态不能假设一直活着，需要做状态恢复和任务切分。
2. 内存与体积敏感：模型文件、索引数据都会和页面抢资源，冷启动慢一点，用户就能感知到。
3. 权限更严：跨域资源获取、下载、剪贴板等能力都要在 manifest 里明确声明，审核也更严。

结论：端侧 AI 不是把云端代码搬过来就行，必须按「短任务、可恢复、懒加载」重新设计。

二、向量检索链路：从一张图到相似结果

OmniPic 的以图搜图链路大致是：

图片资源 -> 特征提取（端侧模型） -> 1024 维向量 -> 本地索引入库
查询图片 -> 同样提取向量 -> 相似度计算 -> TopK 排序 -> 结果回显

几个关键取舍：

• 维度选 1024：维度太低，相似图区分度不够；太高，索引体积和计算量在端侧吃不消。1024 是我们实测后在精度和性能之间的平衡点。
• 索引放本地：用浏览器本地存储承载向量和元数据，查询不经过网络，这也是「0 字节上传」能成立的前提。
• 增量建索引：不要每次打开都全量重算，只对新增图片提取特征，老索引直接复用。

三、批量下原图：难点不在下载，在找对资源

页面上看到的图，经常是 CDN 按显示尺寸压缩过的版本。批量下载要解决的是：

1. 顺着 DOM、背景图、响应式 srcset 等线索定位更高清的原始资源
2. 对同一张图的多个尺寸版本去重，只保留最优的一份
3. 失败重试与命名规范，避免下回来一堆 hash 文件名

这部分没有黑科技，就是把各种站点结构耐心处理好。

四、同一套底座，长出六个工具

OmniSuite 不是六个孤立项目，端侧能力是共享的：

• OmniSense：端侧 AI 套件，语义记忆等能力复用本地推理链路
• OmniPost：创作者一键同步 8 大平台，坚持草稿优先、本地优先，发布前内容先在本地成型
• ResumeRadar：JD 解析与 ATS 关键词对齐，文本语义匹配同样在本地完成，简历不上传
• OmniVideo：纯前端扩展 + 100% 开源的本地私有化下载站（Mac & Win），把「本地」贯彻到自建服务
• OmniGame：160 款悬浮小游戏，算是这套严肃工具里留的一个轻松出口

五、踩过的坑

• 浏览器差异：Chrome、Edge、Firefox 对部分 API 的实现节奏不同，同一份代码要做兼容测试，不能只测 Chrome。
• 冷启动：模型首次加载的等待最容易流失用户，需要加载状态提示和按需加载，别让用户对着空白页猜。
• 别滥用权限：权限申请越多，商店审核和用户信任成本越高，只申请功能真正需要的。

六、总结

端侧 AI 的价值不只是「快」或者「省服务器钱」，更是数据主权：用户的图片、简历、草稿，天生就不该为了一个小功能被上传。如果你也在做扩展，欢迎在评论区交流实现细节。文中提到的 OmniPic、ResumeRadar、OmniGame 已上架 Chrome 商店，用名称即可搜到，其余工具在同名项目站上有直装包，搜 OmniSuite 即可，本文就不放链接了。