先核实这条消息指向哪个具体的开源项目或产品：799 KB、零依赖、5 行代码这些特征很有辨识度。
实测报告来自阿里云开发者社区。为了确认这个包真实存在、版本对得上，我核一下 npm registry。
包已核到：npm @rsrsai/memlite 0.3.1，11 月 9 日发布，registry 记录解包体积 818,095 字节。这条实测报告的细节可以逐项对上。
标题：799 KB 的记忆引擎：5 行代码跑起来，3000 条查询 176 毫秒
一句话概括：memlite 不是一个 “AI 记忆系统”，而是一个能塞进宿主程序里的记忆内核 ——799 KB 左右、运行零依赖、5 行代码就能跑，代价是它只做词面检索、数据明文落盘、只支持单写者。阿里云开发者社区 11 月 12 日那篇实测把它的数字全摊开了：npm 包 @rsrsai/memlite 0.3.1 整个 node_modules 只有 818,724 字节、一个包，3000 条记忆占 1,179,427 字节（一条约 413 字节），单条查询 p50 176.1 毫秒、p95 270.1 毫秒；作为对照，同一台机器上一套带本地嵌入推理的方案跑 3437 条，同一条查询要 933 到 1195 毫秒。我顺手核了 npm registry：这个包 11 月 7 日首次发布，0.3.1 是 11 月 9 日上线，MIT 协议，官方描述是 “可嵌入的本地记忆引擎（TypeScript），与 Rust 版 respire-memlite 数据互通”，解包体积 818,095 字节。
为什么有人要做这么小的东西，起因很具体：只想给编辑器插件加一行 “记住上次的结论”，问了三家方案，一家要起常驻服务，一家要登录拿密钥，一家要先建向量库。为几十条判断搭一套基础设施，成本明显不划算。
| 维度 | memlite 的做法 |
|---|---|
| 形态 | npm 包 @rsrsai/memlite（TypeScript）+ Rust 单文件二进制 respire-memlite，两者读写同一份数据 |
| 存储 | 追加写的 memory.jsonl，一条记忆一行 |
| 检索 | BM25 词面匹配 + 用 parent_id 串起来的因果树 |
| 依赖 | 运行时零依赖，fs-ext 是可选件，装不上也能用 |
| 协议 | MIT，无云、无账号、无端口 |
| 版本 | 0.3.1，发布于 2026-11-09（首次发布 11-07） |
“轻” 这件事，得看四个不同的数，混着说就容易失真。
| 项 | 实测值 | 说明 |
|---|---|---|
| 包体积 | 818,724 字节（约 799 KB） | registry 记 818,095 字节，差在打包细节 |
| 运行时依赖 | 0 个 | fs-ext 可选，不装照用 |
| 主逻辑 index.js | 118 KB | 真正干活的就这一份 |
| sourcemap | 483 KB | 占了包体积一半多，运行时不加载 |
| 3000 条数据 | 1,179,427 字节，413 字节 / 条 | 明文 JSONL，记事本能直接打开 |
| 常驻内存 | 89.6 MB | 裸 node 是 29.4 MB，净增约 60 MB |
| 向量文件 | 无 | 默认档不产 emb.f32 |
冷启动也够快：import 21 到 27 毫秒，空库打开 10.9 毫秒，3000 条的库冷开 39 到 41 毫秒。但要注意 “一条查询端到端 376 到 429 毫秒” 这个数里，有 130 毫秒左右是 Node 自己启动的开销，当 CLI 用没问题，做常驻服务会更快。
检索速度是一条接近直线的曲线，这既是它的优点，也是它的天花板。
| 库规模 | p50 | p95 |
|---|---|---|
| 100 条 | 10.2 ms | 25.8 ms |
| 500 条 | 26.2 ms | 36.0 ms |
| 1000 条 | 55.7 ms | 80.3 ms |
| 2000 条 | 119.2 ms | 154.5 ms |
| 3000 条 | 176.1 ms | 270.1 ms |
三十倍的数据换来十七倍的延迟，基本是线性增长。作者从曲线形状推断原因是 “每次查询对全库重新分词、没有持久倒排”，并注明这条没跑 profiler—— 这个标注很重要，它意味着 “为什么慢” 目前只是合理推测。
上手确实是五行，185 个字符：
import { Memlite } from '@rsrsai/memlite';
const m = new Memlite({ dataDir: './data' });
m.open();
await m.remember('结论', { title: '标题' });
const r = await m.recall('结论', { limit: 5 });
dataDir 不传也能跑，它按 MEMLITE_DATA 环境变量、项目内 .memlite/、用户级目录、~/memlite-data 四层依次回退。写完之后立刻能查到，因为主路径是同步落盘、不等索引；这条很关键，意味着它放弃了索引带来的查询速度，换来了 “写完就能用” 的确定性。
几个设计细节，比体积更值得看。
- 因果树：remember(..., { parent }) 挂上因，show() 返回时直接带祖先和子孙，命中一条就知道它的前因后果，不用再发一轮请求。
- 乐观锁没省：两个实例指向同一个库，A 按 revision=0 写成功，B 还拿 0 去写会直接抛 STALE_VERSION 并带回当前版本号。
- 敏感信息默认拦住：写 “数据库密码是 xxx” 会被拒，提示改存位置指针；手机号、JWT 也拦得住，普通技术结论照过。
- 坏一行不炸库：手工塞一行非 JSON，bad_lines 记 1，其余记录照常可查。
- 自带 bench：20 条语料 × 20 条改写查询，hit@1 为 17/20、85%，升级版本后重跑就能看有没有退化。
用之前必须知道的三条边界，比参数更重要。
| 边界 | 具体表现 | 后果 |
|---|---|---|
| 明文落盘 | memory.jsonl 是纯文本，git 能同步、记事本能开 | 能读这台机器文件的人就能读你的记忆 |
| 查询靠词 | 19 条真实查询撞 8 条记忆，17 条命中；“gateway timeout”“TLS 握手失败” 漏了 | 换语言、换整句说法就找不到，除非宿主先把查询扩成同义词 |
| 单写者 | 两个进程各写 400 条能全落盘，但 lock_backend 是 in-process、cross_process=false，各进程读自己的索引快照 | 会有几十条滞后，一个库最好只交给一个进程写 |
对照一下就能看出它的位置。同一台机器、同一条查询，另一套带本地嵌入的方案在 3437 条上跑了 1195、971、933、904、906 毫秒。memlite 在 300 条档上比它快一个量级，但两者不是同一件事：对方那 933 毫秒里含本地嵌入推理，能按 “意思” 找；memlite 默认只按 “词” 找。要按意思找，它得显式开嵌入档，而这一档这次没测。
什么场合适合它，其实条件很窄也很清楚。
- 库规模在几千条以内，不是百万级知识库。
- 内容是技术结论、项目上下文、踩坑记录这类 “关键词打得出来” 的东西。
- 宿主会替你改写查询，或者用户本来就会用相近的词去问。
- 你确实需要明文和 git 同步，比如想让记忆跟着仓库走。
- 你只需要 “记住并召回”，不需要多租户、权限、加密、图谱推理。
反过来，这几种情况就别用它：要给团队共用一套带权限的记忆、要处理隐私数据、要做跨语言语义检索、要多进程高并发写。这些正是 respire 主线和加密方案在做的事。
几个容易传错的说法，单独纠一下。
| 常见说法 | 更准确的说法 |
|---|---|
| “799 KB 的记忆系统” | 799 KB 是 npm 包体积（registry 记 818,095 字节），不含 Rust 单文件二进制；包内 483 KB 还是不加载的 sourcemap |
| “零依赖” | 是运行时零依赖，但仍要求 Node ≥ 18；fs-ext 为可选；Rust 版才免 Node |
| “召回 1ms 级” | 实测 100 条约 10 毫秒、3000 条约 176 毫秒，官方这句宜改成 “毫秒级，随条数增长” |
| “5 行代码就能用” | 5 行 185 字符是最小示例，真实项目还要定数据目录、写入策略和查询改写 |
| “能替代向量库” | 默认纯 BM25 词面，语义近似、跨语言都会漏 |
| “支持多进程” | 官方口径是 single-writer，跨进程锁未启用，多进程写会有索引滞后 |
【常见问题】
问题 1：memlite 这个 799 KB 的记忆系统，和 mem0、Zep 那类方案差在哪？
回答 1：差在定位，不在功能多少。mem0、Zep 这类是 “记忆系统”，带向量库、抽取管线、服务端、账号体系；memlite 是 “记忆内核”，799 KB、零运行时依赖、无端口无账号，import 进来就能用，数据就是一个 memory.jsonl。它换来的是极低的接入成本和可携带性 —— 一个包、一个文件、git 能同步、Rust 和 TS 两端读同一份；放弃的是语义检索深度、多租户权限和加密。库到几千条、内容以技术结论为主，它够用；要到百万条、要按意思找，就得换方案。
问题 2：799 KB 这么小的记忆系统，检索性能靠什么撑住？
回答 2：靠 BM25 词面匹配加一棵 parent_id 因果树，没有向量索引，也没有持久倒排。实测 p50 是 100 条 10.2 毫秒、1000 条 55.7 毫秒、3000 条 176.1 毫秒，曲线接近线性，因为每次查询都要对全库重新分词。它的优势是 “写完立刻能查”，主路径同步落盘不等索引；劣势是条数上万后延迟会明显上去，那时要么加缓存，要么开嵌入档。所以 799 KB 买到的是 “够用且确定”，不是 “又快又全”。
问题 3：零依赖的 memlite，数据安全和隐私怎么处理？
回答 3：分两层，一层做了，一层没做。做了的是写入前的敏感扫描：密码、手机号、JWT 这类内容默认被拒，提示你改存 “位置指针”；还有乐观锁防并发覆盖，坏行不会炸库。没做的是静态加密 —— 数据就是明文 memory.jsonl，记事本能打开，本机能读文件的人都能读。所以它适合存 “技术结论、项目上下文” 这种不怕被看见的内容，不适合存凭证、客户隐私、医疗记录。要加密，得走 respire 主线那套加密库，或者自己在宿主侧加一层。
问题 4：什么样的人应该试 memlite，什么样的人不该试？
回答 4：给编辑器插件、CLI 工具、个人 agent 加一层 “记住上次结论” 的能力，库规模几百到几千条，查询里带得出关键词，这套很合适，5 行代码、一个文件就能收工。反过来，三种情况别碰：一是团队共用、需要按人隔离权限的记忆；二是要存敏感数据；三是要跨语言、按意思检索。还有一条容易被忽略 —— 多进程并发写，官方口径就是单写者，两个进程各写各的会出现几十条索引滞后。先用小库验证召回质量，再决定要不要上，比一上来就替换现有记忆层稳妥。
【参考资料】
[2026-11-12]（AI 记忆系统测试 799 KB、零依赖 5 行代码跑起来）阿里云开发者社区
[2026-11-09]（@rsrsai/memlite 0.3.1 版本发布与包元数据：解包体积 818,095 字节、MIT）npm Registry
[2026-11-07]（memlite 首次发布记录与仓库 risense-ai/memlite-js）npm Registry
【免责声明】
本文依据阿里云开发者社区 2026 年 11 月 12 日发布的单机实测报告，以及 npm Registry 上 @rsrsai/memlite 的公开包元数据整理。文中体积、延迟、内存等数字均来自该报告在 i5-1135G7 / 15.8 GB / Windows 11 / Node 22.23.2 环境下的测试，属单机单次样本，不代表其他硬件与数据分布下的表现；Rust 单文件版本（respire-memlite）作者未实机测试，相关描述为官方口径转述。“线性增长的原因” 为作者依据曲线形状的推断，未经 profiler 验证。包体积一处存在 818,724 与 818,095 字节的细微差异，已并列标注。本文为技术选型参考，不构成对任何产品的推荐或采购建议；涉及敏感数据存储的，请自行评估合规要求。