我给 AI Agent 加了本地记忆，中文搜索快了 10 倍

桜木花道_

15人浏览 · 2026-07-25 17:28:59

桜木花道_ · 2026-07-25 17:28:59 发布

我给 AI Agent 加了本地记忆，中文搜索快了 10 倍

GitHub: https://github.com/P1M0U/SinoMem | Gitee: https://gitee.com/P1M0U/SinoMem | v0.7.0

每次对话都要重新介绍自己，我受够了

你有没有遇到过这种情况：

早上跟 AI Agent 聊了半小时，交代了项目背景、技术选型、个人偏好。下午再开一个新对话，它什么都不记得了。你又得从头讲一遍。

这不是 Bug，是 LLM 的本质限制 —— 它是无状态的。每次对话都是一张白纸。

“那就用记忆功能啊”——市面上的方案要么依赖云 API（按 token 收费），要么中文搜索烂得一塌糊涂（把"分布式系统"切成"分布式"+“系统”，搜"分布式"反而搜不到），要么部署复杂得像搭一个微服务。

我折腾了一圈，最后选了一个全本地、零费用、中文搜索 10ms 内返回的方案。下面把选型逻辑、接入方式、实际效果都讲清楚。

现有方案，为什么都不太行

方案	中文支持	离线可用	部署复杂度	搜索速度	费用
Mem0（官方云）	一般	❌ 需联网	低	看网络	按 token 计费
Mem0（自部署）	一般	✅	中（需 Docker）	中	零
ChromaDB + 自己封装	需手动配分词	✅	高	中	零
向量数据库云服务	看供应商	❌	低	看网络	按量计费
SinoMem	✅ jieba 定制	✅	低（pip install）	10ms 级	零

核心问题就三个：

中文分词：大多数方案用默认分词器，中文切词质量差，搜"自然语言处理"可能命中不了"中文 NLP 处理"
部署成本：要么依赖云 API 有费用，要么需要 Docker + 向量数据库，对个人开发者太重
搜索速度：调外部 API 做语义搜索，网络延迟 + API 处理，一次搜索几百毫秒起步

我选的方案：SinoMem

SinoMem 是一个轻量级中文记忆系统，核心卖点就三个：全本地、中文好、零费用。

技术栈：

存储层：SQLite（单文件，可复制备份）
搜索层：FTS5 全文索引（BM25 排序）
分词层：jieba 精确模式 + bigram 扩展 + 自定义技术词典
嵌入层：ONNX 本地推理（bge-small-zh-v1.5，~24MB）
融合层：RRF（倒数排名融合）自动平衡关键词和语义两路结果

为什么选它而不是其他方案：

中文分词是第一优先级：jieba 是目前最成熟的中文分词库，SinoMem 在此基础上加了 bigram 扩展（“分布式系统"→ 同时索引"分布式"和"式系”），召回率比纯 jieba 高不少
FTS5 是 SQLite 自带的：不需要额外装 Elasticsearch 或向量数据库，一个 .db 文件搞定
ONNX 嵌入模型可选安装：不装也能用关键词搜索，装了之后支持语义搜索和混合搜索，模型才 24MB

5 分钟跑通

安装

# 一键安装（国内推荐 Gitee）
curl -fsSL https://gitee.com/P1M0U/SinoMem/raw/main/install.sh | bash

# 安装后刷新环境变量
source ~/.bashrc

或者手动：

git clone --depth 1 https://gitee.com/P1M0U/SinoMem.git ~/.local/share/sinomem
cd ~/.local/share/sinomem
python3 -m venv .venv
.venv/bin/pip install -e .

存一条记忆

sinomem store "用户偏好用 Docker 部署服务" -c user_pref -t "docker,偏好"
sinomem store "项目使用 FastAPI + Vue3 技术栈" -c project -t "fastapi,vue3"
sinomem store "服务器内网 IP 是 192.168.0.31" -c infra -t "网络,服务器"

搜索

# 关键词搜索（BM25）
sinomem search "Docker"
# 输出:
# #1  user_pref  [docker,偏好]  score=0.28
#    用户偏好用 Docker 部署服务

# 混合搜索（关键词 + 语义，RRF 融合）
sinomem search "容器部署方案" -m hybrid
# 输出:
# #1  user_pref  [docker,偏好]  score=0.42
#    用户偏好用 Docker 部署服务

注意看：搜"容器部署方案"能命中"用 Docker 部署服务"——这就是 jieba 分词 + bigram 扩展 + RRF 融合的效果。纯关键词搜索可能搜不到，但混合搜索通过语义向量补充了关联。

查看统计

sinomem stats
# 输出:
# total: 3
#   user_pref: 1
#   project: 1
#   infra: 1
# vectors: disabled

中文搜索为什么难，SinoMem 怎么解决的

中文搜索和英文完全不同。英文天然有空格分词（“distributed system” 直接按空格切），中文没有。

问题 1：切词质量

“分布式系统监控” 用 jieba 精确模式切出来是 ["分布式", "系统", "监控"]。

如果你搜"分布式监控"，用 AND 模式匹配，三个 token 都要命中。但"分布式监控"切出来是 ["分布式", "监控"]，少了"系统"，匹配不上。

SinoMem 的方案：对 3 字以上的中文 token 做内部 bigram 扩展。“分布式系统” → 同时生成 “分布式” + “布式系” + “式系统”。这样搜"分布式"或搜"系统"都能命中。

问题 2：写入和查询的分词一致性

很多方案写入时用一种分词器，查询时用另一种，导致 token 对不上。

SinoMem 的 FTS5 tokenizer 是自定义的：写入和查询走同一套 jieba 分词逻辑，token 完全对齐。

问题 3：语义搜索的中文模型

英文 embedding 模型（如 all-MiniLM-L6-v2）处理中文效果很差。

SinoMem 默认用 bge-small-zh-v1.5（BAAI 出品，专门针对中文优化的 embedding 模型），512 维，CLS 池化，ONNX 量化后只有 ~24MB，CPU 推理足够快。

搜索延迟实测

在我的服务器上（Intel Xeon，无 GPU），1 万条中文记忆：

搜索模式	平均延迟
keyword（BM25）	~8ms
semantic（ONNX）	~45ms
hybrid（RRF 融合）	~50ms

对比调 OpenAI embedding API 做一次语义搜索：网络往返 + API 处理，通常 200-500ms。本地 ONNX 推理快了一个数量级。

接入 Claude Code / Hermes

SinoMem 提供三种接入方式：钩子插件、MCP Server、Hermes 插件。

方式一：Claude Code 钩子插件（推荐，自动同步）

SinoMem 内置了三个 Claude Code 钩子脚本，安装后完全无感：

bash ~/.local/share/sinomem/installers/install_claude_code.sh

三个钩子各司其职：

钩子	触发时机	作用
`inject_memory.py`	UserPromptSubmit	对话前自动注入相关记忆上下文
`capture_write.py`	PostToolUse	工具调用后自动捕获值得记忆的信息
`persist_session.py`	Stop	会话结束时自动持久化到 SQLite

安装后 Claude Code 会自动在每次对话前检索相关记忆注入 prompt，对话后自动存储新记忆。不需要手动调用任何命令，完全无感。

加 --global 参数可全局安装（所有项目生效）：

bash ~/.local/share/sinomem/installers/install_claude_code.sh --global

方式二：MCP Server（备选，适用于其他 MCP 兼容 Agent）

如果你用的 Agent 不支持钩子但支持 MCP（如 Cursor、Cline），可以走 MCP：

{
  "mcpServers": {
    "sinomem": {
      "command": "~/.local/share/sinomem/.venv/bin/python",
      "args": ["-m", "sinomem.entrypoints.mcp_server"]
    }
  }
}

MCP 方式提供 14 个记忆工具，Agent 需要主动调用，不如钩子方式自动化。

方式三：Hermes Memory Provider 插件（推荐 Hermes 用户）

ln -s ~/.local/share/sinomem/hermes_plugin/ ~/.hermes/plugins/sinomem

一行命令。Hermes 自动用 SinoMem 替换内置 memory 工具，对话中自动存取，跨会话不丢。

多 Agent 共享同一份记忆

三种方式共享同一个 SQLite 文件（默认 ~/.sinomem/memory.db）。Claude Code 钩子存的记忆，Hermes 能搜到；反之亦然。一份记忆，多个 Agent 共用，不需要同步逻辑。

适用场景判断

推荐使用：

个人开发者，用 Claude Code / Cursor / Hermes 等 AI 编程助手
中文场景为主，对分词质量有要求
不想为 Embedding API 付费
数据不能上云（合规要求）
多个 AI 工具之间需要共享长期记忆

不推荐：

需要百万级数据量的场景（SQLite 单文件有上限，但对个人记忆绰绰有余）
团队协作场景（单文件不适合多写者并发）
已有成熟向量数据库基础设施的团队

快速参考

项目	信息
GitHub	https://github.com/P1M0U/SinoMem
Gitee	https://gitee.com/P1M0U/SinoMem
版本	v0.7.0
Python	≥ 3.11
CLI 命令	15 个
MCP 工具	14 个
插件	Claude Code ✅ / Hermes ✅ / LangChain ✅
中文分词	jieba 精确模式 + bigram 扩展 + 自定义技术词典
嵌入模型	bge-small-zh-v1.5（512维，~24MB ONNX）
搜索模式	keyword(BM25) / semantic(ONNX) / hybrid(RRF)
License	Apache 2.0