本地AI记忆中间层：SQLite+向量混合检索与MCP协议实战

1. 先想清楚「本地 AI 记忆」到底要做成什么1.1 这个项目的本质不是聊天机器人而是记忆中间层很多人一听「本地 AI 记忆」第一反应是做一个离线版 ChatGPT。方向偏了。聊天只是最表层的交互形式真正有价值的部分是记忆的采集、存储、检索和注入这一整套链路。换句话说你要做的是一个跑在本地、能被各种 AI 客户端调用的记忆中间层而不是又一个对话框。我自己的理解是这个项目要解决的核心痛点是现在大部分 AI 工具都是「金鱼记忆」每次对话结束上下文就丢了。用户想让它记住自己的偏好、项目背景、历史决策要么手动粘贴要么依赖云端服务。而云端服务又涉及隐私顾虑和数据锁定。本地 AI 记忆的价值就在于数据在自己机器上记忆可以跨会话、跨工具复用而且格式开放不被某一家平台绑架。从技术上看这个中间层至少要干四件事第一从对话流里抽取值得记住的信息第二把这些信息结构化存储第三在需要的时候按相关性检索出来第四以标准协议把记忆注入到 AI 的上下文里。这四件事里最容易被低估的是第一件和第四件。抽取做不好存进去全是噪音注入做不好检索再准也白搭。1.2 为什么现在做这件事的时机比较成熟两年前做本地记忆最大的障碍是模型能力不够抽取和摘要质量很差存进去的东西自己都不想看。现在情况变了本地能跑的小模型在信息抽取、分类、摘要这些任务上已经够用。同时MCPModel Context Protocol这类协议的出现让「记忆服务」可以标准化地暴露给不同的 AI 客户端不用为每个工具单独写适配。另一个变化是用户习惯。越来越多的人同时用多个 AI 工具写代码用一个写文档用一个查资料用一个。如果记忆不能跨工具共享那本地记忆的价值就砍了一半。MCP 正好解决这个问题——你实现一个记忆服务任何支持 MCP 的客户端都能接进来。这也是为什么我在标题里把 MCP 列为关键词它不是可选项而是这个项目能不能做大的关键。1.3 适合什么样的合伙人一起做找技术合伙人最怕的是两个人对「做什么」的理解不在一个层面上。我的建议是在动手之前先把下面这几个问题聊透记忆的粒度是什么是记住整段对话还是抽取成事实条目记忆的所有权归谁用户能不能导出、编辑、删除检索策略是纯向量还是向量加关键词混合要不要支持多用户还是只做单机个人使用商业化路径是什么开源加赞助还是做付费增强版这些问题没有标准答案但两个人如果答案差太远后面一定会吵架。我见过太多项目死在「以为对方想的一样」上。2. 核心技术选型别一上来就堆最贵的方案2.1 存储层SQLite 加向量扩展是性价比最高的起点存储层最容易犯的错是过度设计。一上来就上 PostgreSQL 加 pgvector或者搞一套独立的向量数据库结果本地部署复杂度飙升用户装都装不上。对于本地 AI 记忆这种场景我的强烈建议是SQLite 打底。原因很直接SQLite 是单文件、零配置、跨平台用户备份就是复制一个文件。而且现在 SQLite 有成熟的向量扩展方案可以在同一个文件里同时存结构化数据和向量。对于个人使用场景几万到几十万条记忆完全扛得住。具体来说表结构可以这样设计CREATE TABLE memories ( id INTEGER PRIMARY KEY AUTOINCREMENT, content TEXT NOT NULL, summary TEXT, embedding BLOB, source TEXT, tags TEXT, created_at INTEGER, updated_at INTEGER, access_count INTEGER DEFAULT 0, last_accessed INTEGER ); CREATE TABLE memory_links ( from_id INTEGER, to_id INTEGER, relation TEXT, weight REAL );memory_links这张表是很多人会忽略的。记忆不是孤立的点事实之间有关联。比如「用户在做本地 AI 记忆项目」和「用户关注 MCP 协议」这两条记忆是相关的。有了关联表检索的时候可以做图扩展把相关记忆一起捞出来效果比纯向量检索好很多。注意向量维度不要选太大。768 维在本地场景下已经够用1536 维会让存储和检索成本翻倍收益却不成比例。选嵌入模型的时候优先看它在中文上的表现很多英文榜单靠前的模型中文其实一般。2.2 嵌入模型本地跑得动比榜单排名重要嵌入模型的选择直接决定检索质量。我的经验是别迷信榜单要看你实际的数据分布。本地 AI 记忆的内容通常是中英混合、口语化、带大量专有名词通用榜单上的模型未必适配。几个实际测下来比较稳的方向参数量在 1B 以下的专用嵌入模型量化后能在消费级显卡甚至 CPU 上跑支持中英双语的模型优先纯英文模型在中文记忆上召回率会明显下降一定要做本地缓存同一段文本不要重复计算嵌入这里有个实操细节嵌入计算是异步的。用户写入一条记忆不应该阻塞等待嵌入完成。正确的做法是先落库标记embedding为空后台任务慢慢补。检索的时候如果发现某条记忆还没嵌入可以降级用关键词匹配兜底。2.3 检索策略混合检索是标配不是加分项纯向量检索有个致命问题它对精确匹配不敏感。用户问「我上次说的那个 MCP 配置」向量检索可能召回一堆语义相近但完全不相关的记忆。而关键词检索又抓不住语义。所以混合检索是必须的。我的做法是两路并行向量路用嵌入做语义相似度取 Top K关键词路用全文索引做 BM25 或类似算法取 Top K融合用 RRFReciprocal Rank Fusion把两路结果合并RRF 的好处是不需要调权重对两路分数的量纲不敏感。公式很简单score(d) Σ 1 / (k rank_i(d))其中 k 通常取 60。这个方案我在多个项目里用过稳定且效果好比费劲调权重靠谱得多。2.4 协议层MCP 是连接一切的胶水MCP 的价值在于它把「工具」和「模型」解耦了。你的记忆服务实现成一个 MCP Server暴露几个工具remember、recall、forget、list_memories。任何支持 MCP 的客户端都能调用。这里有个设计决策要想清楚记忆的注入是主动还是被动主动是指 AI 在需要的时候自己调用recall被动是指你在每次对话开始前自动把相关记忆塞进上下文。我的建议是两者都支持但默认走被动因为很多模型并不擅长判断「什么时候该回忆」。MCP Server 的实现语言选你团队最熟的就行Python 和 TypeScript 都有成熟的 SDK。关键是工具的描述要写清楚模型能不能正确调用很大程度上取决于工具描述的质量。3. 记忆的抽取与组织这是最容易被做烂的环节3.1 抽取什么事实、偏好、决策、关系不是所有对话内容都值得记住。如果什么都存检索质量会迅速下降。我的分类是四类值得记事实用户的身份、项目背景、技术栈、环境配置偏好用户喜欢什么风格、讨厌什么做法、有什么习惯决策用户做过什么选择为什么这么选关系谁和谁相关什么和什么关联抽取的时机也有讲究。不要每轮对话都抽那样噪音太大。我的做法是对话告一段落时抽一次或者用户显式说「记住这个」时抽。抽取用本地小模型就够给它一个结构化的 prompt让它输出 JSON。EXTRACT_PROMPT 从以下对话中抽取值得长期记忆的信息。 只抽取事实、偏好、决策、关系四类。 输出 JSON 数组每项包含 type、content、confidence。 confidence 低于 0.6 的不要输出。 对话 {dialogue} 3.2 去重与合并不做这一步记忆库会变成垃圾场用户会反复说同一件事只是措辞不同。如果不去重记忆库里会有大量重复条目检索时全是冗余结果。去重的策略是新记忆写入前先做一次相似度检索如果找到高度相似的已有记忆就走合并逻辑而不是新增。合并的逻辑要小心。简单覆盖会丢失信息简单追加会产生矛盾。我的做法是如果新记忆是旧记忆的补充追加到旧记忆的content里如果新记忆和旧记忆矛盾标记冲突让用户裁决如果新记忆只是措辞不同更新updated_at和access_count内容不动提示冲突检测不要用模型自动裁决很容易出错。标记出来让用户决定既安全又省事。3.3 记忆的衰减与归档记忆不是越多越好。时间久、访问少的记忆应该降权甚至归档。我设计了一个简单的衰减公式weight base_weight * exp(-λ * days_since_access) access_bonus其中 λ 取 0.01 左右access_bonus 根据访问次数累加。检索的时候按 weight 排序低权重的记忆排后面。归档不是删除而是移到单独的冷存储表需要的时候还能捞回来。这个机制的好处是记忆库会自然新陈代谢重要的记忆越来越突出不重要的慢慢沉底。用户不用手动清理体验好很多。4. 实操落地从零搭一个能跑的原型4.1 环境准备与依赖选择原型阶段不要追求完美能跑起来最重要。我的建议是 Python 起步生态成熟调试方便。核心依赖就几个pip install sqlite-vec sentence-transformers mcp fastapi uvicornsqlite-vec是 SQLite 的向量扩展sentence-transformers用来算嵌入mcp是官方 SDK。FastAPI 和 uvicorn 用来起一个本地 HTTP 服务方便调试。硬件方面有张 8G 显存的显卡就够跑嵌入模型。没有显卡纯 CPU 也能跑就是慢一点原型阶段可以接受。4.2 数据库初始化与向量索引初始化脚本要一次性把表和索引建好import sqlite3 import sqlite_vec def init_db(path): db sqlite3.connect(path) db.enable_load_extension(True) sqlite_vec.load(db) db.enable_load_extension(False) db.executescript( CREATE TABLE IF NOT EXISTS memories ( id INTEGER PRIMARY KEY AUTOINCREMENT, content TEXT NOT NULL, summary TEXT, source TEXT, tags TEXT, created_at INTEGER, updated_at INTEGER, access_count INTEGER DEFAULT 0, last_accessed INTEGER, weight REAL DEFAULT 1.0 ); CREATE VIRTUAL TABLE IF NOT EXISTS memory_vectors USING vec0( memory_id INTEGER PRIMARY KEY, embedding FLOAT[768] ); CREATE VIRTUAL TABLE IF NOT EXISTS memory_fts USING fts5( content, contentmemories, content_rowidid ); ) return db这里用了两个虚拟表memory_vectors存向量memory_fts存全文索引。两者都指向memories主表检索的时候分别查最后融合。4.3 写入流程落库、嵌入、索引三步走写入一条记忆的完整流程def remember(db, content, sourceNone, tagsNone): now int(time.time()) cur db.execute( INSERT INTO memories (content, source, tags, created_at, updated_at) VALUES (?, ?, ?, ?, ?), (content, source, tags, now, now) ) memory_id cur.lastrowid db.commit() # 异步补嵌入和全文索引 schedule_embedding(memory_id, content) return memory_idschedule_embedding是个后台任务算完嵌入后写入memory_vectors同时把内容写入memory_fts。这样写入路径很快用户体验好。4.4 检索流程混合检索加权重排序检索是核心代码要写清楚def recall(db, query, top_k10): # 向量路 query_vec embed(query) vec_results db.execute( SELECT memory_id, distance FROM memory_vectors WHERE embedding MATCH ? ORDER BY distance LIMIT ? , (query_vec, top_k * 2)).fetchall() # 关键词路 fts_results db.execute( SELECT rowid, rank FROM memory_fts WHERE content MATCH ? ORDER BY rank LIMIT ? , (query, top_k * 2)).fetchall() # RRF 融合 scores {} for rank, (mid, _) in enumerate(vec_results): scores[mid] scores.get(mid, 0) 1 / (60 rank) for rank, (mid, _) in enumerate(fts_results): scores[mid] scores.get(mid, 0) 1 / (60 rank) # 按权重调整 ranked sorted(scores.items(), keylambda x: -x[1]) results [] for mid, score in ranked[:top_k]: row db.execute(SELECT * FROM memories WHERE id ?, (mid,)).fetchone() results.append((row, score * row[weight])) # 更新访问计数 for mid, _ in ranked[:top_k]: db.execute( UPDATE memories SET access_count access_count 1, last_accessed ? WHERE id ? , (int(time.time()), mid)) db.commit() return results这段代码有几个细节值得说。第一两路都取top_k * 2给融合留余量。第二RRF 的 k 取 60 是经验值不用改。第三检索完更新访问计数这是衰减机制的数据来源。4.5 MCP Server 封装让任何客户端都能用最后一步是把这些能力通过 MCP 暴露出去from mcp.server import Server from mcp.types import Tool, TextContent server Server(local-memory) server.list_tools() async def list_tools(): return [ Tool( nameremember, description记住一条信息用于长期存储, inputSchema{ type: object, properties: { content: {type: string, description: 要记住的内容}, tags: {type: array, items: {type: string}} }, required: [content] } ), Tool( namerecall, description根据查询检索相关记忆, inputSchema{ type: object, properties: { query: {type: string}, top_k: {type: integer, default: 5} }, required: [query] } ) ] server.call_tool() async def call_tool(name, arguments): if name remember: mid remember(db, arguments[content], tagsarguments.get(tags)) return [TextContent(typetext, textf已记住ID: {mid})] elif name recall: results recall(db, arguments[query], arguments.get(top_k, 5)) text \n.join([f- {r[0][content]} for r in results]) return [TextContent(typetext, texttext)]工具描述要写得让模型一看就懂。remember的描述里强调「长期存储」recall强调「根据查询检索」这样模型在需要的时候更容易正确调用。5. 常见问题与排查技巧实录5.1 检索结果不相关怎么办这是最常见的问题。排查顺序是先看嵌入模型是否适配你的数据。拿几条典型记忆手动算一下相似度看看排序是否符合直觉。再看是不是纯向量检索的问题。加上关键词路用混合检索对比效果。最后看记忆本身的质量。如果存进去的都是噪音检索再准也没用。我踩过的一个坑是嵌入模型对短文本效果差。用户说「记住我用 Vim」这条记忆很短嵌入后语义信息不足检索时经常被忽略。解决办法是在嵌入前给短文本补充上下文比如拼上来源和标签。5.2 记忆冲突怎么处理用户今天说「我用 Python」明天说「我改用 Rust 了」。这两条记忆是冲突的。我的处理方式是检测到冲突时不自动覆盖而是把新记忆标记为pending在检索时如果同时召回冲突记忆把冲突信息一起返回让 AI 或用户裁决提供一个resolve_conflict工具让用户显式选择保留哪条注意不要用时间戳简单覆盖。用户可能只是在不同项目里用不同语言简单覆盖会丢失信息。5.3 性能瓶颈在哪里原型阶段性能一般不是问题但记忆量上去后会遇到瓶颈。常见的瓶颈点瓶颈点表现解决思路嵌入计算写入变慢批量计算异步处理向量检索召回变慢加 IVF 索引限制候选集全文检索查询变慢定期优化 FTS 索引融合排序结果变慢限制两路候选数量我的经验是十万条记忆以内SQLite 方案完全够用。超过这个量级再考虑迁移到专门的向量数据库。5.4 隐私与数据安全本地记忆的核心卖点就是隐私。所以有几条红线不能碰嵌入计算必须在本地不能调用云端 API数据库文件要支持加密至少提供选项导出功能必须完整用户能随时拿走自己的数据删除要彻底不能留残留这几点看起来是技术问题其实是产品信任问题。用户把最私密的记忆交给你任何一点疏忽都会毁掉信任。6. 找技术合伙人的几个实操建议6.1 先做原型再找人别反过来我见过太多人拿着一个想法去找合伙人结果聊了半天发现对方理解的和自己想的完全不一样。正确的顺序是自己先花两周做个能跑的原型哪怕很粗糙。有了原型沟通成本会大幅下降你也能更清楚地知道自己需要什么样的合伙人。原型不需要完美能演示「写入记忆、检索记忆、通过 MCP 调用」这条链路就行。有了这个你找合伙人的时候就不是在讲想法而是在讲一个已经存在的东西。6.2 分工要按能力边界切不要按工作量切技术合伙人之间最容易出的问题是分工模糊。我的建议是按能力边界切一个人负责记忆的抽取和检索算法一个人负责协议层、客户端适配和工程化存储和基础设施谁有空谁做但要有一个明确的 owner不要按「你写前端我写后端」这种切法本地 AI 记忆这个项目前端很薄重点在中间层。按能力边界切每个人都能在自己的领域做深。6.3 提前约定好开源与商业化边界这个问题不提前聊后面一定出问题。我的建议是核心记忆引擎开源建立社区和信任增强功能比如多设备同步、团队共享、高级检索做付费版明确贡献者协议避免后面因为代码归属扯皮开源不是做慈善是获客手段。本地记忆这个领域信任比功能更重要开源是建立信任最快的方式。6.4 用 MCP 生态做杠杆别自己造轮子MCP 生态正在快速扩张各种客户端和工具都在接入。你的记忆服务只要实现好 MCP 协议就能被这些客户端直接使用不用一个个去适配。这是巨大的杠杆。我的建议是把精力集中在记忆的质量上协议层尽量用标准实现。工具描述、错误处理、超时重试这些细节做好用户体验就不会差。至于客户端适配交给生态去解决。7. 这个项目后续可以怎么扩展原型跑通之后有几个方向值得探索。第一个是记忆的可视化让用户能看到自己的记忆网络手动编辑和整理。第二个是跨设备同步用端到端加密的方式让多台机器共享记忆。第三个是记忆的市场用户可以分享某些记忆模板比如「Python 开发环境配置」这种通用记忆。还有一个我觉得很有潜力的方向是记忆的主动整理。现在的记忆库是被动增长的用户不整理就会乱。可以做一个后台任务定期对记忆做聚类、合并、摘要生成更高层的「元记忆」。这样检索的时候可以先查元记忆再下钻到具体条目效率和体验都会好很多。这些扩展不用一开始就做但架构上要留好口子。比如记忆表里预留parent_id字段为后面的层级结构做准备。数据库 schema 一旦定下来改起来很麻烦前期多想一步后面省很多事。我个人在实际操作中的体会是本地 AI 记忆这个项目技术难度不算高难的是产品判断和持续迭代。找合伙人找的不是写代码最快的人而是对「记忆应该怎么组织」有自己想法、愿意长期打磨的人。这个领域没有现成的答案需要两个人一起摸索。