Mnemo 本地记忆层：Ollama 长期记忆、部署与治理

你的 Ollama 模型已经能回答问题了，但每次对话都从零开始。昨天聊过的项目决策、今天设置的偏好，明天全忘了。

这就是本地 LLM 的记忆缺失问题。Ollama 提供的是”能回答”的模型服务，但回答什么、记不记得你之前的约束，完全靠你每次手动复述。

Mnemo 不是再做一个 RAG。它用知识图谱 + 实体提取来管理长期记忆，让你的本地 LLM 能记住项目决策、实体关系，而不是每次都问你”这个 API 是做什么的”。

1. Mnemo 是什么：定位与核心能力

1.1 定位词解读

“local-first AI memory layer” 的关键在两个词：

• local-first：数据存你本地，不上云，可迁移，不依赖某个 SaaS 的生死
• memory layer：不是再做一个 RAG，也不是再做一个 agent 框架。它只负责”记忆”这件事 —— 实体提取、图谱构建、语义检索

举个例子：你问”这个项目的 API 基地址是什么”，纯向量搜索会返回一堆”API”相关的文档片段，但不知道你具体指哪个项目。图谱检索会追踪”项目 → API → baseUrl”的关系链，直接返回你之前设置的配置值。

但前提是实体提取正确。如果 LLM 把”API 基地址”误识别成两个实体（“API”和”基地址”），图谱会分裂，检索会断链。这是噪声积累的根源。

定位清楚了，下面看核心能力。

1.2 核心能力矩阵

Mnemo 的 README 列了四个核心能力：

1. persistent knowledge graph（持久化知识图谱）

   • 实体、关系存 SQLite，不是一次性向量
   • 图谱结构可查询、可导出、可迁移

2. entity extraction（实体提取）

   • 从对话里自动识别实体（人名、项目名、API 名、决策）
   • 不是纯向量检索，而是把”这个 API 的用途是什么”变成可查询的实体-关系结构
   • 实体提取的质量取决于 LLM 的理解能力。本地 LLM（如 llama3）在复杂对话中可能误识别，噪声积累是个持续风险。README 没给自动清理方案，你需要定期检查图谱质量

3. semantic retrieval（语义检索）

   • 当前检索管线组合全文 chunk 搜索、实体名搜索、图扩展、关系过滤与评分排序
   • 图扩展结果会降权，直接命中的内容优先于推断关系，减少无边界的上下文扩张

4. graph-first vs pure vector search

纯向量搜索是”查相似”，图谱检索是”查关系”。前者会返回一堆语义相似但无关的噪声，后者能追踪实体间的关系链。

对比一下会更清楚：

维度	纯向量搜索	Mnemo 知识图谱
检索逻辑	相似度排序	实体-关系追踪
噪声风险	高（相似但无关）	低（有实体锚定）
可解释性	低（黑盒向量）	高（可见图谱）
可迁移性	向量难导出	SQLite 可导出
适用场景	文档检索	项目记忆、实体关系

1.3 技术栈与许可证

技术栈：

• Rust（四个 crates，见下一节）
• SQLite（本地存储，WAL 模式）
• petgraph（内存图谱）
• OpenAI / Ollama / Anthropic API（LLM 后端）

许可证：MIT License（可用、可改、可分发）

风险提醒：

• 早期项目（2026-06-05 GitHub README）
• API、架构可能变化
• 没有大规模生产验证
• README 性能数据是自测，不是独立证明

2. 架构组成：四个 Rust crates

Mnemo 用 Rust 写成，拆成四个 crates，职责清楚：

mnemo-core：核心逻辑

• 实体提取、图谱构建、检索逻辑
• 不依赖具体 LLM 后端，只定义接口

mnemo-api：服务端

• 提供 HTTP API（默认端口 8080）
• 接收对话、调用 core、返回结果
• 健康检查：curl http://localhost:8080/health

mnemo-cli：命令行工具

• 调试、管理、查询
• 通过 HTTP 调用 Mnemo API，便于从终端写入、检索、查看实体和清空记忆

mnemo-bench：性能测试

• README 的 122 Rust tests、21 Python tests、12 benchmarks 都在这里
• 自测数据来源

拆成四个 crate 的好处：

• core 可以单独测试，不依赖 API
• cli 方便本地调试，不需要起服务
• bench 独立，不影响生产代码

不好的地方：

• 需要完整 Rust 工具链才能编译（除非用 Docker）
• crate 间 API 变化时，可能要同步改多处

3. 安装部署：三种路径

Mnemo 提供三种部署方式，按复杂度排序：

3.1 Docker + Ollama（最快上手）

前提：已安装 Docker、Ollama。

# 1. clone 项目
git clone https://github.com/zaydmulani09/mnemo.git
cd mnemo

# 2. 启动 Docker
docker compose up -d

# 3. 拉模型（在 Docker 内）
docker exec mnemo-ollama ollama pull llama3

# 4. 健康检查
curl http://localhost:8080/health

注意：命令可能变化，请以 GitHub README 为准。

说明：Docker compose 会启动两个容器——mnemo-api（服务端）和 mnemo-ollama（Ollama）。后者是可选的。如果你本地已经有 Ollama 运行，可以只用 mnemo-api 容器，通过 MNEMO_LLM_BASE_URL=http://host.docker.internal:11434/v1 连接本地 Ollama。

验证 LLM 连接：健康检查返回 {"status":"ok"} 时，说明 API 已启动，但还没验证 LLM 连接。用 curl 发一个测试请求：

curl -X POST http://localhost:8080/ingest \
  -H "Content-Type: application/json" \
  -d '{"content":"项目 Atlas 的 API 基地址是 https://api.example.test","source":"chat","session_id":"mnemo-trial"}'

如果写入成功，再调用 /retrieve 验证召回：

curl -X POST http://localhost:8080/retrieve \
  -H "Content-Type: application/json" \
  -d '{"text":"Atlas 的 API 基地址是什么？","session_id":"mnemo-trial"}'

返回包含相关实体、记忆块或 context_prompt，才说明 LLM 提取与检索链路都正常。

优点：

• 不需要 Rust 工具链
• Docker 自动处理依赖
• Ollama 和 Mnemo 在同一个 compose 网络，网络配置简单

缺点：

• Docker 占用资源
• 调试麻烦（要进容器查 SQLite）
• 日志分散在两个容器

3.2 Binary（本地编译）

前提：已安装 Rust 工具链（cargo, rustc）、Ollama。

# 1. clone 项目
git clone https://github.com/zaydmulani09/mnemo.git
cd mnemo

# 2. 编译 API crate
cargo install --path crates/mnemo-api

# 3. 配置 Ollama 地址
export MNEMO_LLM_BASE_URL=http://localhost:11434/v1

# 4. 启动服务
mnemo-api

注意：命令可能变化，请以 GitHub README 为准；这条路径需要 Rust 工具链。

说明：编译时间取决于硬件和 Cargo 缓存。编译成功后，mnemo-api 默认使用当前目录下的 mnemo.db；数据库路径也可以通过 MNEMO_DB_PATH 或 TOML 配置调整。

验证 Ollama 连接：启动前，先确认 Ollama 运行在 localhost:11434，并已拉取模型（ollama pull llama3）。启动后，用 curl 测试：

curl -X POST http://localhost:8080/ingest \
  -H "Content-Type: application/json" \
  -d '{"content":"测试 Mnemo 实体提取","source":"cli-check"}'

优点：

• 不依赖 Docker
• 调试方便（本地进程，日志在同一终端）
• 可以直接用 mnemo-cli 操作本地 SQLite
• 可以自定义端口、数据库路径（通过环境变量）

缺点：

• 需要完整 Rust 工具链
• 编译时间长（首次）
• 依赖管理可能出问题（cargo.lock 可能过期）

3.3 OpenAI-compatible（云端 LLM）

前提：有 OpenAI / Anthropic / 其他 OpenAI-compatible API key。

环境变量清单（按 2026-06 GitHub README 核验）：

export MNEMO_LLM_BASE_URL=https://api.openai.com/v1
export MNEMO_LLM_API_KEY=sk-...
export MNEMO_LLM_MODEL=gpt-4o-mini
export MNEMO_LLM_PROVIDER=openai

然后启动：

mnemo-api

注意：环境变量名可能变化，请以 GitHub README 为准。

适用场景：

• 本地算力不够，用云端 LLM
• 已有 OpenAI API 额度
• 不介意数据上传到云端（注意：用云端 LLM 时，对话内容会上传到云端 API，local-first 的隐私优势只对本地存储有效）

三种路径，按你的实际情况选一种。下面看一下性能数据。

4. 性能表现：README 自测数据

Mnemo 的 README 列了性能自测数据（截至 2026-07-17 核验）：

测试条件：

• Apple M2（debug build）
• SQLite WAL 模式
• petgraph 在内存

性能数据：

• 完整检索管线：约 4.2 ms
• Release build 声称快 3-5 倍（约 0.8-1.4 ms）

注意：这是 README 自测，不是独立证明；性能会随硬件、数据量和 LLM 后端变化。

解读这些数字：

• 4.2 ms 是”检索”时间，不含 LLM 推理（LLM 推理才是瓶颈）
• SQLite WAL + 内存图谱的组合，检索确实快
• 但这只是检索环节，不是”对话速度”

实际体验会取决于：

• LLM 推理时间（比检索慢得多）
• 对话内容长度（实体提取需要 LLM 推理）
• 数据量（图谱越大，检索越慢）

建议：在目标硬件上跑 mnemo-bench，看实际数据。README 的数字只能当参考，不能当承诺。

5. Local-first 特性与边界

5.1 Local-first 优势

Local-first 的核心：数据在你本地，不上云。

具体优势：

1. 隐私保护

   • 对话内容、实体、关系都存本地 SQLite
   • 不上传到第三方 SaaS（前提是用本地 LLM）

2. 数据可控

   • SQLite 文件可导出、备份、迁移
   • 不依赖某个 SaaS 的生死（服务商倒闭，你的数据还在）

3. 可迁移性

   • 换机器时，复制 SQLite 文件即可
   • 不需要重新”训练”记忆

4. 可调试

   • SQLite 是标准格式，可用任何 SQLite 工具查看
   • 图谱结构可见，不是黑盒向量

5.2 潜在风险与边界

Local-first 有优势，但也有风险：

1. 噪声积累

   • 实体提取不完美，会误识别
   • 误识别的实体会影响后续检索
   • 需要定期清理（但 Mnemo 没给自动清理方案）
   • 噪声积累不是 Mnemo 独有的问题，是所有自动记忆系统的通病。区别在于：Mnemo 的图谱可见，你可以看到噪声实体、错误关系；向量系统的噪声藏在向量里，你看不到。这是图谱的优势，也是负担——你需要主动维护

2. 撤回与恢复边界

   • 当前 API 支持删除单个实体、删除单个记忆块，也支持带确认头的全量 /wipe
   • 但它没有“撤销上一次写入”或按业务决策整体回滚的高层事务接口
   • 如果错误决策已经扩散成多个实体和关系，仍需要按来源或 session 定位影响范围，再逐项删除或从备份恢复
   • 建议：在关键决策存入前记录 source、session_id 和外部审计标识，并先在测试环境验证实体提取

3. hidden state

   • 图谱结构复杂，可能存了你看不到的关系
   • 检索时可能返回你不知道为什么返回的结果

4. 适用边界

   • 数据量大时，SQLite + 内存图谱会有压力
   • 多 agent 共享时还要自行补齐权限、多租户隔离和运维策略

5.3 适用 vs 不适用场景判断表

场景	适用性	原因
个人项目、小团队	✓ 适用	数据量小、隐私要求高、可迁移性好
大数据量（GB级）	✗ 不适用	SQLite + 内存图谱压力、噪声积累
团队协作（多人写）	⚠ 有条件	可通过同一 API 服务共享，但需自行验证权限、隔离和并发行为
强隐私要求	✓ 适用	数据不上云（前提是用本地 LLM）
需要全局共享记忆	✗ 不适用	local-first 是本地独占，不共享
已有 Ollama 环境	✓ 适用	直接集成，学习成本低
没有 Rust 工具链	有条件	用 Docker 路径，但调试麻烦

判断：如果你的场景是”个人项目、隐私要求高、已有 Ollama、数据量不大”，Mnemo 可以尝试。如果是”数据量大、团队协作、需要全局共享”，建议等 Mnemo 成熟或考虑其他方案。

具体建议：

• 先在测试环境跑一遍 Docker 路径，看图谱结构、实体提取质量和检索效果
• 用测试对话验证噪声风险，故意说一些无关内容，看 Mnemo 是否误识别
• 准备清理方案，提前用 SQLite 工具熟悉图谱结构，知道怎么手动删错误实体
• 关注 README 更新。早期项目的 API 和架构可能变化，部署命令也可能过期

6. 下一步：系列文章导航

如果你还没看过 Ollama 本地 LLM 系列的前面几篇，建议按顺序读：

1. Ollama 入门：本地运行大语言模型的第一步

   • 如果还没装 Ollama，从这里开始

2. Ollama API 调用：从 curl 到 OpenAI SDK 兼容接口

   • Mnemo 用 OpenAI-compatible API，需要了解 Ollama 的 API 接口

3. Ollama Embedding 实战：本地向量检索与 RAG 搭建

   • 用这篇对照纯向量检索与 Mnemo 的全文检索、实体搜索和图扩展管线

4. AI Agent 记忆管理：长期记忆与知识治理实战

   • Mnemo 是记忆层工具，这篇讲 Agent 记忆的治理思路

读完这四篇，再装 Mnemo，理解会更完整。下一步：在本地跑一遍 Mnemo 的 Docker 路径，看看知识图谱长什么样。