Mnemo 本地记忆层：给 Ollama 和自建 LLM 留一份可迁移记忆

Mnemo 这个搜索词背后，通常不是“怎么让本地 LLM 回答更聪明”这么简单。很多人已经把 Ollama 跑起来了，也能用 OpenAI-compatible API 接进自己的脚本；麻烦出在下一步：模型每次会话结束后就丢掉项目决定、用户偏好、接口约束和上次排障结论。你可以把这些都塞进 prompt，但 prompt 会越来越长，旧信息还会和新信息打架。

Mnemo 值得看的地方在这个缝隙里。它把长期记忆放在本机，底层用 SQLite 和图关系保存实体、文本块与检索结果，再把召回到的上下文交给 Ollama、OpenAI、Anthropic 或其他兼容后端。它不会让模型“天生记住”你，也不是万能知识库；更像一个可替换、可备份、可审计的本地记忆服务。

Mnemo 先解决哪一层记忆

很多本地 LLM 工作流分成三层：模型负责生成，应用负责流程，记忆层负责把跨会话的信息找回来。Ollama 解决的是第一层，它让模型能在本机跑起来；RAG 通常解决“从文档里找相似段落”；Mnemo 瞄准的是更细的跨会话记忆。

一个很典型的场景是本地编程助手。今天你让它记住“这个项目暂时不用 LangChain，API 层保持 FastAPI + SQLite”，明天换一个会话再问“新功能怎么接检索”，它应该能把这个决定找回来，而不是重新建议一套完全不同的栈。

方案	适合保存什么	容易出的问题
长 prompt	少量固定偏好、项目规则	越写越长，旧规则难更新
Markdown 记忆	人能直接读的决策和笔记	自动召回弱，结构关系靠人工维护
向量库 RAG	文档、FAQ、知识库片段	相似不等于有效，新旧事实难处理
Mnemo 这类记忆层	实体、关系、会话事实、检索上下文	需要治理，错误记忆会污染后续回答

所以它适合放在 Ollama API 调用之后。先让模型稳定回答，再考虑把哪些信息沉淀成记忆；顺序反过来，很容易把一个还没跑稳的 demo 做成难排查的状态机。

架构拆开看：Rust API、SQLite 和图遍历

Mnemo README 里把仓库拆成四个 Rust crate：mnemo-core 管实体抽取、图操作、检索引擎和数据库层；mnemo-api 提供 Axum REST API；mnemo-cli 是命令行工具；mnemo-bench 放性能基准。这个拆法对本地工具很重要，至少说明它不是只靠一段 prompt 做“记忆总结”。

SQLite 管持久化，图关系管线索

普通记忆系统常见做法是把每轮对话切块，生成 embedding，再按相似度召回。这样能用，但读者很快会遇到两个问题：同一个人、项目、决策在不同会话里重复出现；两个事实互相冲突时，向量相似度不会自动告诉你该信哪一个。

Mnemo 的公开说明更强调 entity deduplication 和 graph-first retrieval。简单说，它会把文本里的实体抽出来，和已有实体合并，再通过关系边做多跳检索。比如“API 网关”“鉴权中间件”“FastAPI 服务”分别在不同会话出现，图关系能让它们在查询时连起来。

这类图扩展不该无限放大。README 里提到图扩展结果会以较低权重参与评分，直接命中的内容仍然排得更靠前。这个取舍比较稳：图关系负责补线索，不能抢走明确命中的证据。

性能数字只当项目基准看

README 的 benchmark 表写得很细：Apple M2、SQLite WAL、内存中的 petgraph，debug build 下完整检索流水线约 4.2 ms，并说明 release build 会更快。这个数字能说明作者在认真测本地路径，但它不是第三方评测。你的实际速度会受数据量、模型抽取、磁盘、API 后端和检索策略影响。

我更建议看三件事：写入记忆是否可回放，检索结果能不能解释来源，错误记忆能不能删除或修正。速度慢一点还能优化；记忆错了还说不清来源，后面的 Agent 会越来越难信。

用 Docker + Ollama 跑一遍最小链路

第一次试 Mnemo，不要急着接进自己的主项目。先在一个临时目录跑通官方 README 的 Docker + Ollama 路径，再决定是否进入应用集成。

git clone https://github.com/zaydmulani09/mnemo
cd mnemo
docker compose up -d

# 第一次拉模型，README 示例使用 llama3
docker exec mnemo-ollama ollama pull llama3

# 检查 API 服务
curl http://localhost:8080/health

如果你已经读过 Ollama 入门，这段流程应该不陌生。差别在于，Mnemo 同时启动了记忆 API 和 Ollama 容器，应用以后访问的是记忆层暴露的接口，而不是直接把所有历史塞进模型上下文。

用 Python SDK 做一条烟雾测试

README 也给了 Python SDK 的最小用法。这个测试只验证一件事：写入一条记忆，再用自然语言查询是否能召回。

from mnemo import MnemoClient

client = MnemoClient()

client.ingest("我正在做一个 Rust 向量数据库，项目名叫 vecdb")
print(client.get_context("我现在在做哪个数据库项目？"))

跑这个测试时，不要只看模型回答像不像。还要看服务日志、数据库文件、API 返回结构，以及记忆是否能在重启后保留。长期记忆的最低门槛不是“回答漂亮”，而是“状态可持续、可检查、可恢复”。

二进制路径适合已有 Ollama 服务

如果你的机器上已经有 Ollama，README 还提供二进制路径：

cargo install --path crates/mnemo-api
export MNEMO_LLM_BASE_URL=http://localhost:11434/v1
mnemo-api

这条路更适合已有本地 LLM 环境的人。你可以继续沿用自己的模型、端口和监控方式，把 Mnemo 当成一个单独服务接进来。若后面要切到云端后端，再配置 OpenAI-compatible base URL、API key、model 和 provider。

接入前先看适配表

Mnemo README 里有一句边界说得直接：如果你已经在用一个托管 agent harness，并且它已经处理好记忆，你可能不需要 Mnemo。这个提醒很有用。记忆系统不是越多越好，重复的记忆层会制造隐性状态。

你的场景	建议
本地 Ollama 脚本，每次都要手动粘贴项目背景	可以试 Mnemo
自建客服或代码 Agent，需要跨会话保存偏好和决策	值得做小规模试点
只想对一批文档做问答	先用 Ollama Embedding + RAG
已用成熟平台记忆，并能导出、纠错、审计	暂时别叠第二层
团队资料权限复杂，还没有访问控制方案	先做权限边界，再接记忆

本地优先的价值很明确：数据留在机器上，SQLite 文件容易备份，也不会把所有项目对话交给云服务。但本地优先不自动等于安全。你仍然要考虑谁能读数据库文件、备份放在哪里、日志里有没有 API key、错误记忆怎么清理。

记忆层要守住三条线

长期记忆听起来很诱人，做坏了会拖累每一次回答。接 Mnemo 前，我会先把三条线写进项目规则。

第一条：每条记忆都要能回到来源

记忆最好不要只剩一句摘要。至少要知道它从哪轮对话、哪个文件、哪次任务里来。一个 Agent 说“项目用 FastAPI”，你应该能追到来源，而不是只能相信它。

这也是 AI Agent 记忆管理里反复强调的点：长期记忆不是更大的剪贴板。没有来源、时间和有效期，记忆越多，越容易把旧结论包装成新事实。

第二条：召回结果要有预算

本地服务很快，也不能无限注入。每次给模型的记忆应该少而准，比如 5 到 15 条高相关上下文，并附上来源。模型如果需要更多信息，再让它查，而不是一次塞进几十条“可能相关”的片段。

这个规则能减少上下文腐烂。很多 agent 手里资料不少，却被过期决定、相似片段和互相冲突的备注拖慢。记忆层应该帮模型过滤噪音，再把少量证据送进 prompt。

第三条：错误记忆要能撤回

最危险的记忆不是缺失，而是错误。比如你曾经让模型记住“线上数据库可以直接改 schema”，后来团队改成必须走 migration review。旧记忆如果还在，Agent 迟早会拿它做错误建议。

所以试点时要设计撤回动作：删除某条记忆、把某条标为过期、重新抽取某个项目、清空某个用户空间。没有这些动作，长期记忆会慢慢变成债务。

常见排障清单

Mnemo 这类工具的问题通常不在“模型不会回答”，而在本地服务、模型后端和记忆检索之间的连接。可以按这个顺序查：

• curl http://localhost:8080/health 不通：先看 Docker 容器是否启动、端口是否被占用。
• Ollama 拉模型失败：进入容器执行 ollama list，确认模型是否存在；网络慢时先换更小模型做测试。
• API 调用卡住：检查 MNEMO_LLM_BASE_URL 是否指向 OpenAI-compatible endpoint，Ollama 默认端口通常是 11434。
• 回答没带记忆：先确认 ingest 是否成功，再查检索接口返回的 context，而不是只看最终回答。
• 重启后记忆丢失：检查 SQLite 数据路径是否挂载到持久卷，容器重建时临时目录可能被清掉。
• 结果越来越乱：减少召回条数，清理重复实体，把过期项目决策标记为失效。

这些检查比一上来改 prompt 更有用。prompt 只能影响模型怎么说话，解决不了服务没启动、模型没拉完、数据库没持久化这类硬问题。

下一步阅读和试点路径

如果你还没跑过本地模型，先从 Ollama 入门开始。已经能稳定调用模型，再看 Ollama API 调用和 Ollama Embedding 实战。Mnemo 更适合放在这些基础之后，作为 agent 记忆层试点。

一个稳妥的 7 天试点可以这样做：

1. 只选一个项目，不接全盘资料。
2. 写入 30 到 50 条真实记忆，覆盖项目栈、禁用方案、常见错误和接口约束。
3. 每天用同一组 10 个问题回放，记录召回准确率和误召回。
4. 把错误记忆删除或标过期，观察下一轮回答是否改变。
5. 重启容器和机器，确认记忆仍在。
6. 把数据库备份、权限、敏感词扫描补上。
7. 再决定是否接入主力 Agent。

Mnemo 的价值不在“让 LLM 永远记住一切”。更实际的目标是：把少量重要上下文稳定地带回下一次任务，并且在人类需要时能看见、修改、备份和撤回。能做到这一层，本地 LLM 才开始从一次性聊天变成可持续工具。