别再用向量数据库存Agent记忆了：一个ZIP文件就够了

给 AI Agent 配记忆，很多人的第一反应是：起一个向量数据库服务，再接一个 Embedding API。其实一个几百 KB 的本地文件就能干这件事，还快得多。

先说结论

Agent 记忆这个场景，托管向量数据库是杀鸡用牛刀。

一个叫 Wax 的开源项目证明：一个本地 .wax 文件（标题里说的"ZIP 文件"就是这个意思，它实际上是个自定义格式的单文件），就能装下文本搜索 + 向量检索全套能力。

实测数据：混合召回 p95 延迟 6.1 毫秒。你调一次云端向量库 API，网络往返都不止这个数。

Wax 目前 797 Star、Apache 2.0 协议、纯 Swift 写的，跑在 Apple Silicon 上。Claude Code、Codex、Cursor、Grok、OpenClaw 都能共用同一个记忆文件。

Agent 记忆是怎么被做复杂的

先看大多数人现在的做法：

环节	典型方案	代价
存储	Pinecone / 托管 Qdrant	按量付费，数据在别人服务器上
Embedding	OpenAI / 云厂商 API	每条记忆都要花钱、走网络
检索	REST API 调用	网络延迟几十到几百毫秒
记忆提取	LLM 总结再入库	又一层 API 调用和费用

写一条"用户喜欢深色模式"这种事实，要过两道网络、花两笔钱。

更要命的是碎片化：Claude Code 的记忆在 CLAUDE.md，Codex 的在它自己的目录，Cursor 又是另一套。你换一个工具，之前的记忆全部作废。

Wax 的答案：把整个记忆层压进一个文件

Wax 的核心思路一句话：记忆不需要服务，只需要一个文件。

1
2
3
4
5
Claude Code ─┐
Codex ───────┤
Cursor ──────┼─ MCP ─→ 一个本地文件 ~/.wax/memory.wax
Grok ────────┤
OpenClaw ────┘

一个 .wax 文件里塞了这些东西：

组件	干什么用
LZ4 压缩数据帧	存原始记忆文本和元数据
SQLite FTS5	全文文本检索（BM25 打分）
Metal 加速 HNSW	向量检索，1 万条以上自动启用
WAL + 双头页	写一半崩了也不丢数据
TOC 目录	索引所有帧和父子关系

文件本身一般就几 MB，装几千条记忆没问题。

同步到另一台设备？iCloud、AirDrop、U 盘随便拷。备份就是复制文件，迁移就是移动文件。

两个反直觉的设计

第一，remember 不调 LLM。

大多数记忆产品会先让 LLM 从对话里"提取事实"再存。Wax 不来这套：你存什么句子，它就存什么句子，靠混合搜索找回来。

好处是零 API 成本、零幻觉（提取环节最容易编造事实）。代价是记忆质量取决于你怎么写——这其实更可控。

第二，向量检索是可选的，不是必须的。

没跑 Embedding 模型时它就是纯文本搜索，照样能用。Apple Silicon 上自动加载内置 MiniLM 模型，语义检索无缝开启。

性能到底怎么样

官方在 Apple Silicon 上跑过基准（2026-03-06 数据）：

指标	数值
混合召回 p95	6.1 ms
混合召回 p99	6.5 ms
冷启动打开 p95	9.2 ms

对比一下：一次云端向量库 API 调用，光网络往返通常 50-200ms，还没算排队和限流。

6.1ms 意味着 Agent 每轮对话都能顺手查一遍记忆，几乎零成本。这也是"本地单文件"方案最实际的优势——不是省那点 API 钱，是延迟低到可以随便调。

怎么接入

一条命令装好 MCP 服务：

1
npx -y waxmcp@latest install

各工具的接法：

工具	接入方式
Claude Code	stdio 直连 + 安装 wax skill
Codex / Cursor / Grok / OpenClaw	配置 MCP 地址 `http://127.0.0.1:3000/mcp`
Hermes	原生 `wax-memory` provider，无需 MCP
iOS / Mac 应用	Swift SDK， Foundation Models 直接挂 waxRemember / waxRecall 工具

有个细节值得说：多个工具共用记忆时，只能有一个写入进程。两个 MCP 进程同时打开同一个 .wax 文件会锁冲突，所以官方方案是起一个本地 HTTP 服务，所有工具都指向它。

这其实是 SQLite 单文件方案的经典取舍——简单换来的并发限制，但对个人 Agent 记忆场景完全够用。

它替代不了什么

Wax 官方很克制，没吹自己是万能方案：

时序知识图谱：需要 Neo4j/Postgres 那种多实体关系推理，Wax 不干这个
多人共享记忆：它就是给本机单用户设计的
跨机器实时同步：拷文件是快照式的，不是实时

另外注意平台限制：Metal 向量加速和 npm 安装器针对 Apple Silicon，Intel Mac 要自己源码编译，Linux 可跑引擎（README 平台徽章包含 Linux）。

方案类型	代表	存储	是否要服务	记忆提取
托管记忆 API	Mem0 / SuperMemory	云端	要	LLM 提取
Markdown 记忆 MCP	Basic Memory 等	Markdown 文件	不要	手写/半自动
Markdown+索引	agent-memory	Markdown 为真相源+SQLite 索引	不要	本地排序检索
单文件 RAG	Memvid（.mv2）	单文件	不要	无
单文件记忆层	Wax（.wax）	单文件	不要	不提取，直接存

国内环境怎么用

Wax 本体完全本地运行，不依赖任何境外服务，装好后离线可用。只有首次 npm install 拉二进制需要网络。

如果想要国内成熟度更高的方案，这几个可以对照看：

方案	定位	数据
MemOS	记忆操作系统，混合检索+跨任务技能复用，宣称省 35% token	11.4k Star，Apache 2.0
memU	多 Agent 共享个人记忆	14.4k Star，自定义协议
自建 SQLite FTS5	最朴素：一张 FTS5 虚拟表 + sqlite3 命令行就够	零依赖

认真说一句：如果你的记忆量在一万条以下，自建 SQLite FTS5 的投入产出比可能最高。建一张表、写两段 SQL，半小时搞定，没有任何外部依赖。

Wax 的价值在于它把这套东西产品化了：MCP 协议、多工具共享、崩溃恢复、向量扩展全都处理好了，开箱即用。

我的看法

Agent 记忆这个领域，2026 年有个明显的风向转变：从"云端服务"往"本地文件"回涌。

原因不复杂——记忆是高度个人化的数据，用户凭什么要把它传到别人服务器上？而且 Agent 记忆的检索模式很固定：存进去、按相关度找出来。这个场景真的不需要一个分布式向量数据库。

Wax 的 6.1ms 给了一个参照系：记忆检索应该快到 Agent 意识不到它的存在。达不到这个标准的方案，都值得重新想想架构。

下次给 Agent 配记忆，先问问自己：我真的需要一个服务吗？还是一个文件就够了？

参考资料：

Wax 仓库：https://github.com/christopherkarani/Wax
性能基准报告：Resources/docs/benchmarks/2026-03-06-performance-results.md
agent-memory：https://github.com/tigerless-labs/agent-memory
MemOS：https://github.com/MemTensor/MemOS