稀饭

zvec-ai 全景：从达摩院 Proxima 内核，到一个装进 App 进程的向量数据库

拆开 github.com/zvec-ai 这十个仓库：C++ 内核 alibaba/zvec（15.7k star）六种索引、原生 FTS、WAL，一个 faiss 都没引；五种语言绑定加 Android/iOS 预编译 SDK；Roadmap 上下一步要接 SQLite 与 DuckDB。对做端侧和游戏的人，向量检索第一次变成一个 22 MB 的动态库。

  • AI
  • 向量数据库
  • zvec
  • RAG
  • 端侧
  • Flutter
  • 开源项目

昨天写了 zvec-grep,今天把镜头拉远:github.com/zvec-ai 这个组织本身值得看。 它只有 10 个公开仓库、合计约 2.3k star、0 个公开成员, 但它背后那个 alibaba/zvec 有 15.7k star—— 一个 C++ 写的进程内向量数据库。

把这两处一起读完(组织的仓库列表、core 的 thirdparty/ 清单、挂在 issue 上的 Roadmap、 八个版本的 release notes),能看清一支团队完整的盘算。它做的事情其实很激进:把向量检索从"要部署的服务"变成"应用程序里的一个库"。 这件事对做后端的人是个选项,对做端侧、客户端、游戏的人是个前提—— 你没法要求玩家先起一个数据库容器。

一、全景:一个内核,九个卫星

先摆事实:

  • 引擎不在 org 里。zvec-ai 组织 2026 年 1 月 13 日建号,联系邮箱[email protected],没有认证、没有公开成员;而 C++ 内核住在alibaba/zvec(2025 年 12 月 5 日建库,15,739 star / 989 fork / 60 open issue,最后 push 就是今天)。 也就是说 org 不负责写引擎,org 负责把引擎递出去;
  • 递出去的方式是"每种生态一份包装":Python 绑定直接住在 core 仓库的 python/ 里, 另外四个语言各占一个仓库——Node(C++,2 月)、Go(4 月)、Rust(4 月)、Dart/Flutter(4 月);
  • 再往外是工具与入口:zvec-web(zvec.org 文档站)、zvec-studio(可视化管理)、zvec-agent-skills、zvec-mcp-server;
  • 最外面才是产品:zvec-grep 以 2.2k star 断层是第一(第二名 studio 96 star), 2026 年 7 月 10 日才建库。它是这个矩阵里第一个"用户不需要知道向量数据库存在"的东西。 (第十个仓库是 .github,只放组织主页。)
一个 C++ 内核,九个卫星仓库虚线框 = 半年没动过 · 2026-09-04 快照alibaba/zvecC++ 内核 · 15.7k★ · 989 fork2025-12 建库 · 月度发版v0.7.0 · Apache-2.0语言绑定 · 同一个动态库的不同包装Python · pip install zvec绑定就在 core 仓库的 python/ 里zvec-node · 12★2026-02 · npm @zvec/zvec · C++zvec-go · 25★2026-04 · Gozvec-rust · 23★2026-04 · crates.io zvec-rustzvec-dart · 4★2026-04 · Flutter, dart:ffi 直达工具、入口与产品zvec-grep · 2.2k★2026-07 · 唯一面向终端用户的产品本地优先搜索 CLI + MCPzvec-studio · 96★2026-05 · 可视化管理工具pip 起 127.0.0.1:7860 + 桌面安装包zvec-agent-skills · 16★2026-03 · 4 月后没再动zvec-mcp-server · 9★2026-03 · 17 个工具,同样停更zvec-web · MDX2026-01 · zvec.org 文档门户org 本身不写引擎:引擎在 alibaba/zvec,zvec-ai 做的是「把同一个 .so 递到更多人手里」九个仓库合计约 2.3k★ · 组织建号 2026-01-13 · 无公开成员、未认证 · 邮箱 [email protected]唯一一条红色连线是 zvec-grep——矩阵里第一个「不用懂向量数据库也能用上」的产品
图 1 · zvec-ai 的矩阵结构:内核在 alibaba 名下,org 做语言绑定、GUI、Agent 入口与面向用户的产品

一个能说明节奏的细节:core 从 2025 年 12 月 31 日的 v0.1.0 到 2026 年 8 月 24 日的 v0.7.0,八个月发了 11 个版本,最近八个是 v0.2.1(3/18)、v0.3.0(4/3)、v0.3.1(4/17)、 v0.4.0(5/9)、v0.5.0(6/12)、v0.5.1(6/24)、v0.6.0(7/20)、v0.7.0(8/24)——基本一月一版,小步快修。 而 zvec-grep 的 package.json 里依赖写的正是 @zvec/zvec ^0.7.0—— 上层的包是紧跟着 core 的最新版本走的。

二、zvec 到底是什么:「向量检索界的 SQLite」不是比喻

官方定义一句话:开源的嵌入式(进程内)向量数据库,轻量、极速,可直接嵌入应用程序。 拆开看它承诺的东西:

  • 无需服务器、无需配置:装完就能 create_and_open(path, schema), 纯本地跑。Notebook、CLI 工具、边缘设备、手机 App 都算合法宿主;
  • 六种向量索引:Flat(暴力)、HNSW、HNSW-RaBitQ、DiskANN(磁盘)、IVF、IVF-RaBitQ—— 从纯内存到超出 RAM 的磁盘方案都在;
  • 稠密 + 稀疏 + 多向量查询,加原生全文检索(FTS);混合检索是"单次查询里融合向量语义、关键词与标量过滤",不是拼三次的结果;
  • WAL 预写日志:进程崩溃或断电不丢数据。这条是"数据库"和"一个索引文件"的分水岭;
  • 并发语义写得很坦白:多进程可以同时读同一个 Collection,写入是单进程独占。

平台覆盖是它最不像玩具的地方:Linux(x86_64 与 ARM64,glibc 和 musl 都支持,所以 Alpine 能用)、 macOS(ARM64 / x86_64)、Windows(x86_64),而且每次发版自动给出 Android 与 iOS 的预编译 SDK。 v0.7.0 还专门瘦身了动态库——macOS arm64 的 C API 库从 37 MB 到 22 MB(−40%)。 会去抠"库文件多大"的团队,目标场景一定不是数据中心,而是要装进用户设备的东西。

v0.7.0 的其余内容也能看出取向:DiskANN 生产化(补上 Linux/macOS ARM64,并加io_uring 异步 I/O 后端,自动回退到当前机器最优的 I/O 方案,用户零配置)、 新增 IVF-RaBitQ 索引与 PQ-INT8 量化器、 RaBitQ 支持运行时 AVX2 / AVX512 指令集动态分发(同一套二进制在不同 CPU 上自选路径)、 新增 DocIterator 全量流式遍历、FTS 补上N-gram 分词器(明确说更适合短语、代码、短文本)。

三、把 thirdparty 目录摊开:它凭什么不是 faiss 的包装

这是我最喜欢的检查动作——不看 README 的形容词,看 .gitmodules。zvec 引了 17 个第三方件, 全部是"零件",没有一个是现成的 ANN 引擎:

thirdparty/ 目录摊开:一个 ANN 库都没引thirdparty/ 里 17 个第三方件 · 全是「零件」不是「引擎」① 查询与词法面 —— 让它像个数据库,而不是一个距离函数antlr4 · cppjieba + limonp · snowball · utf8proc + Unicode 17.0 UCD过滤/表达式语法有真 parser;中文走结巴分词、英文走词干化、通用文本按 Unicode 词切分;N-gram 分词器 0.7.0 才加上② 倒排与压缩 —— FTS 和标量过滤为什么能跟向量共存CRoaring · FastPFORroaring bitmap 做 posting list / 位图索引,FastPFOR 用 SIMD 解压缩整数流——倒排要快,靠的是这两件③ 索引与量化 —— 这一层是自己的代码RaBitQ-Library (VectorDB-NTU) · libaio + io_uring · lz4量化借学术界新实现的 RaBitQ,磁盘索引靠异步 I/O 栈;HNSW / IVF / Flat / DiskANN 的图与簇结构自己写④ 存储与列式 —— 数据到底落在哪rocksdb 8.1.1 · apache-arrow 21.0 · sparsehash · magic_enum · gflags · glog · yaml-cppLSM 做持久化底座(所以有 WAL、断电不丢),Arrow 做列式与零拷贝,再加一层进程内工具库结论:「用别人的零件,搭自己的引擎」——不是 faiss 的包装层README 的 topics 里写着 faiss、hnsw,那只是给人搜的关键词;thirdparty/ 里没有它们,src/ 下是 ailego、turbo、core、db、binding 五个自己的模块
图 2 · zvec 的第三方依赖分层:词法、倒排压缩、索引量化、存储——每层借的都是学术新实现或基础库,ANN 本体自己写

几个细节挺说明投入方向的:

  • FTS 是认真做的。antlr4 意味着过滤/查询表达式有自己的语法和 parser;cppjieba + limonp 是中文分词,snowball 是英文词干化,utf8proc 加生成的 Unicode 17.0.0 词切分表(NOTICE 里点名来自 WordBreakProperty.txt / emoji-data.txt / LineBreak.txt / Scripts.txt)。 中文开发者看到 jieba 应该会有感觉——这不是"支持多语言"的口头承诺;
  • 倒排有专门优化:CRoaring(位图索引)+ FastPFOR(SIMD 整数压缩), 这两个是搜索引擎倒排链的经典搭档。它把这套搬进一个库文件里,和向量索引放同一个进程;
  • 量化走学术界新路线:RaBitQ-Library 来自 VectorDB-NTU, 不是默认的 PQ/IVF-PQ 组合;libaio(yugabyte 维护的 fork)+ io_uring 服务磁盘索引;
  • 存储底座是 RocksDB 8.1.1 + Apache Arrow 21.0:LSM 给持久化与 WAL,Arrow 给列式与零拷贝。 看 src/ 的目录结构也能印证它想当数据库——src/db/index/column/fts_column/tokenizer/…, FTS 是长在"列"下面的。

仓库 src/ 下是 ailego/(基础库:algorithm / buffer / container / encoding / hash / io / logger / math / math_batch / parallel / pattern)、turbo/、core/、db/、binding/。ANN 的图与簇结构就在这些自己写的模块里,不在任何依赖里。 顺带一句:topics 里写着 faiss、hnsw,那只是给人搜到用的关键词。

四、血统:Proxima 是什么来头

zvec-agent-skills 的 README 里有句话写得很直:Zvec is an open-source, high-performance, lightweight in-process vector databasebuilt on Alibaba's Proxima engine。

alibaba/proxima 是那个来头——426 star、C++、最后一次 push 停在 2023 年 3 月, 看起来像个"开源版本早就没人管"的老仓库。但它的自述是这样的:

Proxima 是阿里巴巴达摩院系统 AI 实验室自研的向量检索内核。目前其核心能力广泛应用于阿里巴巴和蚂蚁集团内众多业务, 如淘宝搜索和推荐、蚂蚁人脸支付、优酷视频搜索、阿里妈妈广告检索等。 同时 Proxima 还深度集成在各式各类的大数据和数据库产品中,如阿里云 Hologres、搜索引擎 Elastic Search 和 ZSearch、 离线引擎 MaxCompute (ODPS) 等。

也就是说:这是一个在淘宝搜推、人脸支付、广告检索这类量级上跑过多年的内部内核, zvec 是它的开源化 + 产品化,而不是从零写一个 hobby project。 不过要讲清楚证据边界:zvec 的 NOTICE 和 submodule 清单里没有引任何 Proxima 代码,proxima 公开仓库的目录结构(admin / agent / index / server,一个服务化引擎)也和 zvec 完全不同。 共同的痕迹是 ailego 这个基础库名。 所以准确的说法是:血统和人是同一批,代码是重写的—— 一个服务化的引擎(BE)和一个进程内的库,是两个不同的产品形态,后者才是"SQLite 路线"。

五、Roadmap 读法:Toward Zvec 1.0

他们的路线图不是文档,是一个 issue(#309 "🌟 Roadmap: Toward Zvec 1.0", 配套 #310 讨论区),用 checklist 勾进度。这本身就是一个我很想抄的做法: 路线图可评论、可追溯、勾没勾一目了然。里面三条主线是storage scalability、mobile ecosystem maturity、deeper integration with the AI landscape。

已经勾掉的:

  • Full Mobile Support(iOS 编译支持 + Android / iOS 地道 SDK 与完整示例);
  • Broader Language Bindings(Go、Rust、Dart/Flutter);
  • Disk-Based Indexing(DiskANN 风格算法,支持超出 RAM 的数据集);
  • RaBitQ Enhancements;Full-Text Search(关键词检索与向量并存)。

还没勾掉的,恰恰是最有信息量的部分:

  • Database Extensions:探索与 SQLite 和 DuckDB 集成—— "向量检索界的 SQLite"这条路线走到终点,就是在 SQLite 里挂一个向量扩展。这一条如果落地, 大多数"给 SQLite 加向量列"的第三方扩展都会感到压力;
  • Memory Governance:给 CreateIndex 加严格内存上限,为了"资源受限环境下的系统稳定性"。 又是一个只有做嵌入式/端侧才会写进行事历的条目;
  • ARM-Specific Tuning:移动端与 Graviton 的专门性能画像;
  • Benchmarking:持续参加 ANN-Benchmarks——这条要划重点:说明现在还没有第三方口径的性能数据;
  • 写吞吐与 Optimize 流水线、测试覆盖率、回归 CI 效率。

关于性能宣称,文档里的口径也是自陈式的:用 VectorDBBench, 数据集是 Cohere 1M(100 万 × 768 维)与 Cohere 10M,机器是阿里云 ECS g9i.4xlarge(16 vCPU / 64 GiB / Ubuntu 24.04),并发档 12/14/16/18/20,量化用 int8, HNSW 分别配 m=50, ef-search=118 与 m=15, ef-search=180(后者带 refiner), 指标是 QPS / Recall / 建索引时长。方法可复现、命令都贴了,但同图里没有和任何对手对比—— 看这篇的读者不要把它读成"实测比 faiss 快 N 倍"。

六、Agent 面:先做了 MCP 和 skills,然后把力气挪到 zg

这个 org 对 Agent 的布局有两个早期仓库,和一个后期产品,顺序很值得琢磨。

  • zvec-agent-skills(3 月建):Agent Skills 形式的一册"Zvec 开发说明书", 安装命令是 npx skills add github:zvec-ai/zvec-agent-skills --skill "zvec",覆盖 Python 与 Node.js 两条路;
  • zvec-mcp-server(3 月建):MCP 服务器,17 个工具覆盖 collection 管理、CRUD、向量与多向量检索(带 re-rank)、索引管理(FLAT / HNSW / IVF)、 Pydantic v2 全量入参校验、JSON 与 Markdown 两种响应格式、内置 OpenAI embedding;
  • 然后就是 7 月的 zvec-grep——默认 MCP 工具集只暴露一个搜索工具。

这里有个真实的时间线信号:这两个 Agent 仓库最后一次 push 分别停在 4 月 9 日和 4 月 15 日, 而 core 每周都在动。17 个工具的 MCP server 与一个搜索工具的 zg,是两个世代的判断。 前者的假设是"Agent 需要一整套数据库 API 去操作向量库",后者的假设是"Agent 只需要证据,不需要知道数据库存在"。 他们显然把筹码挪到了后者身上——这也和昨天那篇的结论一致:对代理有用的不是能力面宽度,是选错工具的概率。

另外一条集成也值得记:v0.7.0 里 zvec 成了 ReMe(Agent 记忆管理套件,3.4k star)的文件存储后端,提供进程内 HNSW 检索。 "Agent 的记忆"这件事的技术底座,正在从"托管向量服务"下沉到"进程内一个文件"。

七、对我在做的事意味着什么:端侧与游戏

这个站点的主赛道是 AI + 游戏,所以我最在意的是 zvec-dart 那个仓库。它写得很清楚:

Brings Zvec to Flutter and Dart via dart:ffi — no servers, no IPC, just a single dynamic library running in your app's process. Native speed: direct FFI calls into a battle-tested C++ engine;no method-channel hops, no isolate marshalling.

几个决定成败的实现细节:预编译库覆盖 Android(arm64-v8a,Gradle 任务 downloadZvecNativeLibs 拉取)、 iOS、macOS、Linux、Windows,构建时从 GitHub Releases 自动下载,pub 包本身保持瘦; API 是同步的、异常式错误处理、强类型 schema;能力上 HNSW / IVF / Flat / Inverted 索引、混合过滤、 top-k 与 group-by,以及 WAL + atomic flush 保证跨重启持久。

"没有 method channel 往返"这句很关键——做过 Flutter 原生插件的人都知道,向量检索这种要连续调用、 又要把候选数组传来传去的活,走平台通道会被序列化开销吃掉一半。而"进程内 + WAL"对游戏尤其合用: 存档、玩家数据、UGC 内容必须和游戏状态一起原子落盘,一个需要单独进程/容器的检索服务在这里是纯负担。

我能立刻想到的用法:

  • NPC 记忆:把对话和事件写进一个 Collection,按语义召回"玩家上次在这说过什么"。 几千条规模的集合,Flat 暴力检索完全够,不要为了时髦上 HNSW(召回还会掉);
  • 图鉴 / 攻略 / 物品名的模糊查找:玩家手打的错别字、简称,语义召回比 LIKE 好用得多, 再叠 FTS 保住精确名;
  • UGC 与素材去重:相似封面、相似关卡、相似建图,提交时算一次相似度;
  • 离线可用:整个向量库是设备上的一个文件,飞行模式也能跑,这对主机和手游是硬需求。

代价也要说清:包体会大一圈(官方在抠的那 22 MB 就是这个数量级的东西,虽然他们在往下压)、 量化会拿召回换内存、写入单进程独占意味着它不能当联机服务器的共享数据库用、 以及移动端多架构预编译库要按 ABI 仔细裁(roadmap 里 ARM 调优至今没勾)。

八、诚实的提醒

  • 还没到 1.0。v0.x、issue 标题就叫 "Toward Zvec 1.0",API 兼容性、内存治理、写吞吐都挂在未完成里; core 建库到现在九个月,org 八个月;
  • 性能数字全是自家口径:参与 ANN-Benchmarks 还是未勾选项,benchmark 页只有它自己的 QPS/Recall 曲线, 没有同机同数据集的对手;
  • 组织页几乎没有身份信息:不认证、成员为 0、没有 location,团队归属只能从[email protected]、core 挂在 alibaba 名下、以及 Proxima 的说法推断; 中文社区主要靠钉钉/微信群,Discord 和 X 也在;
  • 移动端是"有预编译 SDK"级别的支持。Dart 侧的 iOS 只写了 arm64 device,没提模拟器, 真上手接项目前请先跑一次冒烟——这一条我不敢替他们担保;
  • 两个 Agent 仓库半年没动,如果你的项目正依赖 zvec-mcp-server, 要么接受它可能就这样了,要么迁去 zg;
  • Proxima 的血统声明无法从公开仓库验证(NOTICE 里没有 Proxima 代码), 我按"人与内核同源、代码新写"来理解,不要把"built on Proxima"读成"fork 了 Proxima";
  • 它解决不了"要不要云端向量库"这个决策。需要跨进程并发写、需要多人共享、需要托管弹性的场景, 服务化的向量数据库仍然是对的答案;zvec 的立场是"另一种场景",不是替代所有场景。

我的收获

  1. "进程内 vs 服务化"会被迫重演一遍,而这次的答案很可能是进程内。 RAG 时代默认"向量库 = 一个要部署的服务",但端侧推理、Agent 本地记忆、游戏与离线场景里, 多一个常驻服务就多一个失败点。zvec 押的是 SQLite 那条路——库文件即数据库。
  2. 看一个基础设施项目靠不靠谱,去翻它的依赖清单。一个 ANN 库都没引、 却把 antlr4 / cppjieba / snowball / CRoaring / FastPFOR / rocksdb / arrow / RaBitQ 摆成四层的人, 是在做数据库;只依赖 faiss 再包一层 API 的,是在做 SDK。
  3. Roadmap 放 issue 里用 checklist 维护,是个便宜的好实践。 它逼着团队把"已完成"和"待办"分开写(于是我们就看到了"参加 ANN-Benchmarks 仍是待办"), 而且任何人都能在 #310 下面顶需求。这比一页永远在改的 Notion 诚实得多。
  4. 生态位比 star 数更能说明问题。这个 org 十个仓库合计不到 2.5k star, 但"5 种语言 + 桌面 GUI + MCP + Skills + 文档站 + 一个终端产品"这套形状,是按"要被别的项目依赖"来布的, 不是按爆款来布的。判断一个开源项目值不值得押,我会多看这种结构,少看曲线。
  5. 给 Agent 的能力面,收缩比扩张更快。三月份做 17 个工具的 MCP server,七月份做只暴露 1 个工具的 zg—— 同一个团队,半年内换世代。做 Agent 工具的人应该把这条当信号:你现在铺的工具面,可能正是下一个版本要砍掉的东西。
  6. 做游戏的人今年该把「本地向量检索」当基础设施看一眼。NPC 记忆、模糊搜索、UGC 去重这些需求, 以前因为"要装个向量数据库"而做不成,现在它就是一个 22 MB 的动态库和一个文件。 下一步我会拿一个小号工程试试 flutter pub add zvec,看看真机上包体和首帧建库的代价。

想跟进:内核看 alibaba/zvec 与zvec.org 中文文档(有性能报告 和Roadmap issue); 应用层看 zvec-grep、zvec-studio、zvec-dart。 如果你也在做端侧或游戏里的语义检索,建议先只用 Flat 索引跑通一遍—— 多数时候,你根本还没到需要 HNSW 的规模。