Llmem 是一个面向 AI 编程场景的本地持久化记忆工具解决的是 AI 编程助手“记不住”的问题核心做法是把项目记忆写到本地下次继续使用。最值得关注的设计点是它不需要 embeddings整个方案因此变得非常轻。实际用 AI 编程时最烦人的地方是每次开新会话都要重新交代背景技术栈、目录结构、接口约定、构建命令、哪些文件不能动。上下文窗口再大也扛不住这种从零开始的重复劳动。Llmem 走的是另一条路把项目事实、偏好、决策记录持久化到本地文件会话启动时自动读回来。它更适合正在尝试本地 AI 编程工作流、或者觉得向量数据库太重的人。下面按它的设计逻辑和落地方式拆一遍。1. 先搞清楚 Llmem 在解决 AI 编程里的哪个痛点1.1 AI 编程时“记不住”才是最大的上下文浪费最近 AI 编程工具迭代明显加快很多 AI coding agent 已经能同时操作多个文件、执行命令、跑测试但有一个问题始终绕不开它记不住。这里说的记不住不是模型能力差而是没有持久化的工作记忆。你在这个会话里告诉它的技术栈、文件路径、命名规范一旦会话结束或者上下文过长被截断它就忘了。下次再问同样的问题它又开始重新猜。这种浪费非常明显。第一是时间浪费每次都要重复交代项目背景。第二是上下文空间浪费同样的背景说明占据大量 token真正要紧的代码逻辑反而没有位置。第三是协同浪费多 Agent 协同工作时任务 A 已经得出的结论如果没有落到共享记忆任务 B 就要从头探索一遍。这三类浪费每天都在真实发生而且项目越复杂浪费越严重。Llmem 这种工具的价值就在这里把价值比较高的记忆从临时对话里拿出来变成持久化的、可复用的本地文件。它不是增强模型的推理能力而是给模型配一个长期工作记忆。从使用视角看它解决的不是“模型能不能写好代码”而是“模型下一次对话是否还知道这个项目长什么样”。我自己判断一个记忆方案是否适合本地 AI 编程一般先问三个问题记忆内容是什么类型是否需要语义相似度匹配我是否愿意为额外模型和数据库付出维护成本三个问题里有两个偏向简单就优先考虑无嵌入方案。1.2 无嵌入不是缺少功能而是一种更轻的取舍现在很多记忆系统默认要上 embeddings。文本先切块再用 embedding 模型转成向量存进向量数据库查询时做语义相似度匹配。这套链路在知识库场景里很成熟但在个人本地的 AI 编程场景里不一定划算。无嵌入方案就没有这一层。记忆内容直接以结构化文本或 JSON 的形式保存使用时按文件、按关键词、按规则加载。Llmem 选择 no embeddings本质上是把“记忆”从语义检索问题重新放回文件管理问题。这个取舍在编程场景里是合理的项目的记忆大多数是事实型信息比如依赖版本、端口号、目录约定、常见报错。这些内容用精确匹配或关键词检索就够了不需要语义相似度。好处也很直接不依赖 embedding 模型不引入向量库内存和磁盘占用低记忆内容人类可以直接阅读和修改。后面我会展开对比两种方案在资源占用、查询方式和适用边界上的差异。小项目刚开始其实不需要记忆系统直接把项目说明写成 PROJECT.md 丢给 AI 就够了。Llmem 的意义在于把这个能力产品化统一写入、统一读取、统一更新。2. 无嵌入持久记忆和向量记忆方案到底差在哪2.1 传统 embedding 向量库方案做了什么为了避免把方案说得太虚先把 embedding 向量库这条路拆开看。假设你要给 AI 配一个项目知识库常规流程是这样把项目里的 Markdown、代码注释、文档切片成几百字的片段。用 embedding 模型把每个片段转成一个向量。把向量写入向量数据库。查询时把用户的问题转成向量。数据库做相似度检索返回最相近的 top-k 片段。把这些片段塞进上下文让模型基于这些材料回答。这套流程成熟优点也明确语义召回能力强“不用 ES 还是 PG”这种问题即便没有完全一样的关键词也能通过语义匹配到。但代价同样明确需要一个 embedding 模型和向量库需要处理切块长度、索引维度、更新删除本地跑还要考虑模型加载开销。对一台只有 16G 内存、没有独立 GPU 的开发机来说这套链路不算轻。更麻烦的是维护成本。向量库引入之后索引更新策略、向量维度变化、旧数据迁移都会变成新的问题。很多个人项目根本没到那个量级却已经背上了全套基础设施。2.2 无嵌入方案的实现路径无嵌入方案直接把记忆保存成结构化文件。最简单的方式是每个项目一个目录里面放几个 Markdown 或 JSON 文件。读取时就是按目录加载、按关键词筛选、按规则匹配。想要更强一点可以用 SQLite 加全文检索这仍然不是 embedding只是文本倒排索引。在实际的 AI coding 场景里大多数记忆根本不需要语义匹配。比如技术栈Vite Vue 3 TypeScript。构建命令pnpm build 后会生成 dist。端口约定开发服务器固定用 5173。目录约定组件放在 src/components 下。常见坑不要改 lock 文件里的版本。这些内容用关键词匹配就能准确命中。用 embedding 反而可能因为语义漂移把无关内容拉进来。我一般会先在本地建一个 JSON 文件把所有这类事实放进去。字段简单一点比如 id、tag、content、updated_at。这样不管 AI 读取还是我手工修改都很直观。2.3 两类方案的对比对比维度无嵌入持久记忆embedding 向量库语义召回弱主要靠关键词/规则强能匹配近义表达存储复杂度低文件或 SQLite 即可高向量库 索引资源占用低不需要模型和向量存储高embedding 模型 向量检索可解释性好记忆内容直接可读差向量召回片段需要二次判断本地离线容易纯本地文件取决于模型和库是否本地部署适合记忆类型事实、配置、偏好、决策长文档、开放语义知识库初始接入成本低几十分钟能跑通高需要选模型和数据库基于这个对比我的观点是如果你做的是博客知识库问答向量方案很合适如果你做的是 AI 编程辅助和项目记忆无嵌入方案经常更稳。Llmem 选择 no embeddings踩的正是本地、轻量、可读、可维护这条路线。3. 一个本地持久记忆模块需要具备哪些基础能力3.1 存什么记忆内容不是聊天记录而是项目事实很多人第一次做记忆模块最容易犯的错误是把对话历史直接存下来。这样做很快会把记忆文件撑大而且有效信息密度很低。更好的做法是只存提炼后的项目事实项目名称和简介、技术栈、目录结构、启动命令、测试命令、接口请求方式、环境变量、代码风格要求、常见坑。还要记录用户的偏好。比如这个项目里你希望 AI 在修改接口时同时更新前端类型或者遇到不确定的依赖升级时先问再改。这类偏好在会话里可能只是随口一句但如果能持久化后续所有会话都会遵守。决策记录也很重要。比如“为什么不用 ORM”“为什么保留这个兼容层”这些决策如果不在记忆里AI 很可能下一次就给出反向建议。判断一条信息是否值得写进记忆可以看三点第一它是否会在多个会话中重复使用第二它是不是稳定的事实而不是临时状态第三它是否影响 AI 做决策。三点里满足两点就值得存。3.2 怎么存文本、JSON、SQLite 各自适合的阶段无嵌入方案听起来简单但存储格式还是需要设计。最早可以全部用 Markdown 文件目录结构是记忆的索引文件名就是主题。比如 MEMORY.md、commands.md、decisions.md。这种格式人和 AI 都能读也能直接放进 Git 仓库做版本管理适合刚开始接触的阶段。如果记忆需要被 AI 程序频繁更新建议用 JSON。JSON 的定位是让程序能精确地读取和修改单条记录不会像 Markdown 一样容易把格式改乱。缺点是手工读起来不如 Markdown 舒服。等到记忆量变大比如几千条之后可以考虑 SQLite。SQLite 适合做去重、按标签查询、按时间排序还能用 FTS5 做关键词全文检索。它仍然是本地文件不需要单独的服务。给一个简单的选择表存储方式适合阶段优点缺点Markdown起步、少量记忆可读性强可直接版本管理程序更新容易破坏格式JSON中量、程序频繁更新解析稳定结构清晰人工阅读稍差SQLite大量、需要查询过滤查询、去重、排序方便有一点学习成本3.3 记忆生命周期写入、加载、更新、失效记忆不是写入就不管了。它需要一套生命周期管理写入从用户输入、AI 输出、文件分析中提炼出事实经过简单检查后写入。加载在每个新会话开始时读取相关记忆拼到上下文里。更新当新的信息覆盖旧信息时更新对应条目而不是追加一条矛盾记录。失效当记忆内容与当前项目冲突或者已经确定过时要能删除或标记为过时。从实现上看写入和加载是最容易的两步更新和失效才是最需要设计的。我见过很多记忆系统最后失效就是因为只知道往里面加内容不知道清理。一个比较可取的做法是给每条记忆加 updated_at 字段并保留一个可审计的历史。这样不需要全量回滚也能知道哪条内容是什么时候写的。我建议把记忆文件当成代码来管理用 Git 跟踪变更定期 review合并同类项删除过时条目。当记忆文件从几十行膨胀到几千行AI 的注意力会被稀释回答质量反而下降。4. 自己动手接入一个无嵌入持久记忆模块4.1 先做最小闭环一个 memory 类的读写流程这里给一个最小示例用 Python 写一个简单的 PersistentMemory 类用 JSON 文件保存记忆。它不覆盖 Llmem 的全部设计只是演示无嵌入记忆的基本链路读文件、改记录、写回。import json import time from pathlib import Path class PersistentMemory: def __init__(self, path): self.path Path(path) self.data self._read() def _read(self): if not self.path.exists(): return {entries: {}} with open(self.path, r, encodingutf-8) as f: return json.load(f) def _save(self): self.path.parent.mkdir(parentsTrue, exist_okTrue) with open(self.path, w, encodingutf-8) as f: json.dump(self.data, f, ensure_asciiFalse, indent2) def set(self, key, content, taggeneral): entry { content: content, tag: tag, updated_at: int(time.time()) } self.data[entries][key] entry self._save() def get(self, key): entry self.data[entries].get(key) return entry[content] if entry else None def search(self, keyword): results [] for key, entry in self.data[entries].items(): if keyword in entry[content]: results.append((key, entry[content])) return results memory PersistentMemory(./demo_memory.json) memory.set(tech_stack, Vite Vue 3 TypeScript) memory.set(dev_port, 5173, tagconfig) print(memory.get(tech_stack)) print(memory.search(5173))这段代码核心就几个点set 时用 key 作为唯一标识相同 key 会覆盖而不是追加updated_at 记录修改时间search 用简单的子串匹配。在实际项目里search 可以换成 SQLite FTS或者按 tag 过滤。整个模块不依赖任何外部库普通 Python 环境就能跑。注意一点这里 key 要稳定。不要把整个句子当 key尽量用 tech_stack、dev_port 这类短标识。否则同一个事实很容易在多次写入时变成两条不同记录。注意这里不要一上来就设计复杂 schema先用最简单的 JSON 把记忆读写跑通。能稳定读写之后再考虑增加标签、全文检索、SQLite 迁移。4.2 和 AI 编程 Agent 集成的常见方式有了持久化存储下一步是让 AI 用上这些记忆。常见的接入方式有三种按复杂程度递增。第一种最直接把记忆内容拼进提示词。比如启动会话时读取所有 tagconfig 的条目渲染成一段文本告诉 AI 这是项目约定。这种方式适合记忆量小、更新不频繁的阶段。只要注意不要把无用记忆也塞进去。第二种把记忆暴露成工具调用。AI coding agent 在处理任务时通过函数调用读写记忆get_memory(key) 可以读取set_memory(key, content) 可以写入search_memory(keyword) 可以检索。这种方式更接近 Llmem 这类产品的设计AI 能主动决定什么时候查记忆、什么时候更新记忆。缺点是需要 agent 框架支持工具调用实现时会多一点代码。第三种做成上下文压缩缓存。当一次对话快结束时把关键结论、决策、下一步计划抽取出来写入记忆。下次会话开始AI 先加载新的记忆摘要再开始工作。这种方式适合长任务、多轮会话。我建议从第一种开始。先用最小改动跑通再到工具调用和摘要抽取。不要一开始就追求 AI 自主管理记忆那会引入很多不可控的写入反而更容易出现记忆污染。4.3 多项目场景下的存储目录设计当记忆不只有一个项目时目录设计要提前想好。常用结构是这样~/.llmem/ ├── global/ │ └── preferences.json └── projects/ ├── my-project/ │ ├── memory.json │ ├── commands.md │ └── decisions.md └── another-project/ └── memory.json全局记忆放用户通用偏好比如“代码注释用中文”“遇到破坏性变更先询问”。项目记忆按项目隔离。这样既不会让两个项目的约定互相干扰也方便在切换项目时只加载对应的那部分记忆。路径设计成目录而不是单文件还有一个好处不同记忆类型可以分文件管理。commands.md 适合人扫读decisions.md 可以记录时间和原因memory.json 适合 AI 程序读写。不要把所有内容堆在一个文件里否则更新一条配置也要读写同一个大文件。5. 选无嵌入还是选向量库用判断标准来决定5.1 建议优先选无嵌入方案的情况有些人觉得无嵌入方案不够“智能”先入为主地认为记忆系统就该做向量语义检索。实际上在 AI 编程场景里无嵌入方案经常是更合理的选择。哪些情况可以优先考虑无嵌入第一记忆量不大。几百条以内用文件或 SQLite 足够不需要专门搭向量索引。第二记忆内容偏结构化事实。技术栈、版本、命令、规范这类信息关键词覆盖率高不需要语义扩展。第三资源受限。本地开发机没有 GPU内存只有 16G 或 32G再跑一个 embedding 模型会让其他开发工具明显变卡。第四对隐私和离线有要求。记忆文件留在本地磁盘不经过外部服务也不依赖网络。第五希望记忆可读、可审计、可人工修正。向量库里存的是一堆浮点数出了问题很难人工检查无嵌入方案打开文件就能改。以上这几条只要占了两三条就适合先走无嵌入路线。尤其对个人开发者和小团队维护成本往往比功能上限更关键。5.2 需要认真考虑向量方案的场景当然无嵌入方案不是银弹。有些场景明显更适合向量方案。第一种是开放域语义问答。比如你有一个几百篇文档的项目资料库希望 AI 回答“之前有没有人遇到过类似的定时任务问题”。这种问题很难用固定关键词匹配因为提问和文档之间是语义近似不是字面重复。第二种是长文档跨章节召回。项目文档分散在多个章节提问往往跨越多个主题关键词召回很容易漏掉上下文。第三种是记忆规模很大到了万条以上纯文件加载和关键词扫描会变慢向量库加上索引更合适。还有一个判断点你能接受多少误召回。无嵌入精确匹配的问题不是召回少而是容易因为措辞不同漏掉相关内容。向量方案则相反召回范围广但也会把不相干的内容拉进来。在 AI 编程场景误召回的成本可能更高。因为模型可能基于一条不相关的记忆给出一个自信但错误的修改建议。5.3 一个务实路线先用无嵌入后续再升级技术选型不用一次押注。比较务实的路线是先做无嵌入的最小闭环让记忆真正跑起来再根据实际卡点决定要不要引入向量检索。比如先用 JSON 或 SQLite 存记忆用关键词搜索。跑一周之后你发现 AI 经常因为关键词不一致而漏掉相关记忆这时候再增加 embedding 做语义召回和原来的关键词结果做合并排序。这种升级路径比一开始就搭一套完整向量系统平滑得多。从我的经验看大多数个人项目和中小型项目停在这个阶段就够了。真正需要完整向量库的往往是记忆规模大、查询模式复杂的场景。技术选型不用一次押注。先用无嵌入把记忆跑起来等出现明确的“漏召回”问题再考虑加向量召回。6. 落地避坑记忆污染、过期信息和文件权限6.1 记忆污染是整个方案最容易踩的坑记忆系统的核心问题不是存不下而是存进去的内容不够干净。记忆污染是最常见的一个坑。举个例子AI 在一次任务中临时把某个测试端口改成 8081如果这条信息被当成固定配置写入记忆后面所有会话都会认为项目端口是 8081。你需要花更多时间去排查为什么 AI 一直引导你访问错误端口。所以写入记忆之前一定要有过滤意识。我的经验是两个原则。第一只写稳定事实不写临时状态。第二如果不确定就先问一下用户是否要写入记忆或者默认不写只写入高置信度内容。AI 自动写入记忆时要加校验内容是否为空、是否超长、是否包含不完整路径、是否是重复条目。让 AI 自由地把所有输出都塞进记忆一百条之后整个系统基本没法用。6.2 排查链路先看现象再看记忆内容再看写入路径记忆系统出现问题时的现象很相似AI 回答里出现了不该有的信息或者明明有记忆AI 却完全没用到。排查时我按这个顺序看。第一先看记忆文件本身。打开对应的 memory.json 或 Markdown 文件看内容是否完整、格式是否合法、有没有重复或过期条目。很多时候问题就出在记忆内容已经写坏了。第二看加载逻辑。代码有没有读到正确路径路径拼错、文件名大小写不一致、工作目录不对都会导致文件读不到。最常见的是在项目根目录运行时正常换到子目录运行就找不到记忆文件。第三看注入位置。记忆内容拼进提示词之后有没有因为长度限制被截断还是排在大量无关系统指令后面模型根本没注意到这类问题经常表现为“记忆文件里有结果里没有”。第四看写入链路。AI 通过工具调用写记忆时参数是否正确有没有并发写同一个文件导致内容互相覆盖JSON 如果被并发写坏后续读取会直接报错。第五才是怀疑工具设计。只有当记忆内容、加载、注入、写入都正常但 AI 仍然不用再考虑是不是记忆组织形式的问题。这个排查顺序帮我解决过很多“记忆看起来没用”的假问题。遇到记忆相关报错不要先把锅甩给模型。先打开记忆文件看内容是否正常再往加载和注入方向查。6.3 我的建议把“可读、可删、可改”作为设计前提最后给一个收尾建议无论你用 Llmem还是自己写一个本地记忆模块都要把“可读、可删、可改”当作设计前提。可读意味着记忆文件是文本或结构化 JSON人能直接看懂。可删意味着系统能删除单条记忆而不是只能清空整个文件。可改意味着用户手工修正一条错误记忆后后续会话真的会采用修正后的内容。做到了这三点记忆系统哪怕简单也是可维护的。做不到这三点即使加上 embedding 和向量库也只是把脏数据翻得更好看。真正常用下去的工具不是功能最炫的而是不会在某天突然给你一堆过期、冲突、不可控的“记忆”。我个人更建议先把单任务跑稳再考虑批量和接口化。一个只能管理单项目记忆的小工具只要读取稳定、写入干净、能人工修改价值就比一个宣传很复杂却不好维护的“记忆框架”大得多。 无嵌入本地持久记忆：让AI编程助手告别上下文丢失
Llmem 是一个面向 AI 编程场景的本地持久化记忆工具解决的是 AI 编程助手“记不住”的问题核心做法是把项目记忆写到本地下次继续使用。最值得关注的设计点是它不需要 embeddings整个方案因此变得非常轻。实际用 AI 编程时最烦人的地方是每次开新会话都要重新交代背景技术栈、目录结构、接口约定、构建命令、哪些文件不能动。上下文窗口再大也扛不住这种从零开始的重复劳动。Llmem 走的是另一条路把项目事实、偏好、决策记录持久化到本地文件会话启动时自动读回来。它更适合正在尝试本地 AI 编程工作流、或者觉得向量数据库太重的人。下面按它的设计逻辑和落地方式拆一遍。1. 先搞清楚 Llmem 在解决 AI 编程里的哪个痛点1.1 AI 编程时“记不住”才是最大的上下文浪费最近 AI 编程工具迭代明显加快很多 AI coding agent 已经能同时操作多个文件、执行命令、跑测试但有一个问题始终绕不开它记不住。这里说的记不住不是模型能力差而是没有持久化的工作记忆。你在这个会话里告诉它的技术栈、文件路径、命名规范一旦会话结束或者上下文过长被截断它就忘了。下次再问同样的问题它又开始重新猜。这种浪费非常明显。第一是时间浪费每次都要重复交代项目背景。第二是上下文空间浪费同样的背景说明占据大量 token真正要紧的代码逻辑反而没有位置。第三是协同浪费多 Agent 协同工作时任务 A 已经得出的结论如果没有落到共享记忆任务 B 就要从头探索一遍。这三类浪费每天都在真实发生而且项目越复杂浪费越严重。Llmem 这种工具的价值就在这里把价值比较高的记忆从临时对话里拿出来变成持久化的、可复用的本地文件。它不是增强模型的推理能力而是给模型配一个长期工作记忆。从使用视角看它解决的不是“模型能不能写好代码”而是“模型下一次对话是否还知道这个项目长什么样”。我自己判断一个记忆方案是否适合本地 AI 编程一般先问三个问题记忆内容是什么类型是否需要语义相似度匹配我是否愿意为额外模型和数据库付出维护成本三个问题里有两个偏向简单就优先考虑无嵌入方案。1.2 无嵌入不是缺少功能而是一种更轻的取舍现在很多记忆系统默认要上 embeddings。文本先切块再用 embedding 模型转成向量存进向量数据库查询时做语义相似度匹配。这套链路在知识库场景里很成熟但在个人本地的 AI 编程场景里不一定划算。无嵌入方案就没有这一层。记忆内容直接以结构化文本或 JSON 的形式保存使用时按文件、按关键词、按规则加载。Llmem 选择 no embeddings本质上是把“记忆”从语义检索问题重新放回文件管理问题。这个取舍在编程场景里是合理的项目的记忆大多数是事实型信息比如依赖版本、端口号、目录约定、常见报错。这些内容用精确匹配或关键词检索就够了不需要语义相似度。好处也很直接不依赖 embedding 模型不引入向量库内存和磁盘占用低记忆内容人类可以直接阅读和修改。后面我会展开对比两种方案在资源占用、查询方式和适用边界上的差异。小项目刚开始其实不需要记忆系统直接把项目说明写成 PROJECT.md 丢给 AI 就够了。Llmem 的意义在于把这个能力产品化统一写入、统一读取、统一更新。2. 无嵌入持久记忆和向量记忆方案到底差在哪2.1 传统 embedding 向量库方案做了什么为了避免把方案说得太虚先把 embedding 向量库这条路拆开看。假设你要给 AI 配一个项目知识库常规流程是这样把项目里的 Markdown、代码注释、文档切片成几百字的片段。用 embedding 模型把每个片段转成一个向量。把向量写入向量数据库。查询时把用户的问题转成向量。数据库做相似度检索返回最相近的 top-k 片段。把这些片段塞进上下文让模型基于这些材料回答。这套流程成熟优点也明确语义召回能力强“不用 ES 还是 PG”这种问题即便没有完全一样的关键词也能通过语义匹配到。但代价同样明确需要一个 embedding 模型和向量库需要处理切块长度、索引维度、更新删除本地跑还要考虑模型加载开销。对一台只有 16G 内存、没有独立 GPU 的开发机来说这套链路不算轻。更麻烦的是维护成本。向量库引入之后索引更新策略、向量维度变化、旧数据迁移都会变成新的问题。很多个人项目根本没到那个量级却已经背上了全套基础设施。2.2 无嵌入方案的实现路径无嵌入方案直接把记忆保存成结构化文件。最简单的方式是每个项目一个目录里面放几个 Markdown 或 JSON 文件。读取时就是按目录加载、按关键词筛选、按规则匹配。想要更强一点可以用 SQLite 加全文检索这仍然不是 embedding只是文本倒排索引。在实际的 AI coding 场景里大多数记忆根本不需要语义匹配。比如技术栈Vite Vue 3 TypeScript。构建命令pnpm build 后会生成 dist。端口约定开发服务器固定用 5173。目录约定组件放在 src/components 下。常见坑不要改 lock 文件里的版本。这些内容用关键词匹配就能准确命中。用 embedding 反而可能因为语义漂移把无关内容拉进来。我一般会先在本地建一个 JSON 文件把所有这类事实放进去。字段简单一点比如 id、tag、content、updated_at。这样不管 AI 读取还是我手工修改都很直观。2.3 两类方案的对比对比维度无嵌入持久记忆embedding 向量库语义召回弱主要靠关键词/规则强能匹配近义表达存储复杂度低文件或 SQLite 即可高向量库 索引资源占用低不需要模型和向量存储高embedding 模型 向量检索可解释性好记忆内容直接可读差向量召回片段需要二次判断本地离线容易纯本地文件取决于模型和库是否本地部署适合记忆类型事实、配置、偏好、决策长文档、开放语义知识库初始接入成本低几十分钟能跑通高需要选模型和数据库基于这个对比我的观点是如果你做的是博客知识库问答向量方案很合适如果你做的是 AI 编程辅助和项目记忆无嵌入方案经常更稳。Llmem 选择 no embeddings踩的正是本地、轻量、可读、可维护这条路线。3. 一个本地持久记忆模块需要具备哪些基础能力3.1 存什么记忆内容不是聊天记录而是项目事实很多人第一次做记忆模块最容易犯的错误是把对话历史直接存下来。这样做很快会把记忆文件撑大而且有效信息密度很低。更好的做法是只存提炼后的项目事实项目名称和简介、技术栈、目录结构、启动命令、测试命令、接口请求方式、环境变量、代码风格要求、常见坑。还要记录用户的偏好。比如这个项目里你希望 AI 在修改接口时同时更新前端类型或者遇到不确定的依赖升级时先问再改。这类偏好在会话里可能只是随口一句但如果能持久化后续所有会话都会遵守。决策记录也很重要。比如“为什么不用 ORM”“为什么保留这个兼容层”这些决策如果不在记忆里AI 很可能下一次就给出反向建议。判断一条信息是否值得写进记忆可以看三点第一它是否会在多个会话中重复使用第二它是不是稳定的事实而不是临时状态第三它是否影响 AI 做决策。三点里满足两点就值得存。3.2 怎么存文本、JSON、SQLite 各自适合的阶段无嵌入方案听起来简单但存储格式还是需要设计。最早可以全部用 Markdown 文件目录结构是记忆的索引文件名就是主题。比如 MEMORY.md、commands.md、decisions.md。这种格式人和 AI 都能读也能直接放进 Git 仓库做版本管理适合刚开始接触的阶段。如果记忆需要被 AI 程序频繁更新建议用 JSON。JSON 的定位是让程序能精确地读取和修改单条记录不会像 Markdown 一样容易把格式改乱。缺点是手工读起来不如 Markdown 舒服。等到记忆量变大比如几千条之后可以考虑 SQLite。SQLite 适合做去重、按标签查询、按时间排序还能用 FTS5 做关键词全文检索。它仍然是本地文件不需要单独的服务。给一个简单的选择表存储方式适合阶段优点缺点Markdown起步、少量记忆可读性强可直接版本管理程序更新容易破坏格式JSON中量、程序频繁更新解析稳定结构清晰人工阅读稍差SQLite大量、需要查询过滤查询、去重、排序方便有一点学习成本3.3 记忆生命周期写入、加载、更新、失效记忆不是写入就不管了。它需要一套生命周期管理写入从用户输入、AI 输出、文件分析中提炼出事实经过简单检查后写入。加载在每个新会话开始时读取相关记忆拼到上下文里。更新当新的信息覆盖旧信息时更新对应条目而不是追加一条矛盾记录。失效当记忆内容与当前项目冲突或者已经确定过时要能删除或标记为过时。从实现上看写入和加载是最容易的两步更新和失效才是最需要设计的。我见过很多记忆系统最后失效就是因为只知道往里面加内容不知道清理。一个比较可取的做法是给每条记忆加 updated_at 字段并保留一个可审计的历史。这样不需要全量回滚也能知道哪条内容是什么时候写的。我建议把记忆文件当成代码来管理用 Git 跟踪变更定期 review合并同类项删除过时条目。当记忆文件从几十行膨胀到几千行AI 的注意力会被稀释回答质量反而下降。4. 自己动手接入一个无嵌入持久记忆模块4.1 先做最小闭环一个 memory 类的读写流程这里给一个最小示例用 Python 写一个简单的 PersistentMemory 类用 JSON 文件保存记忆。它不覆盖 Llmem 的全部设计只是演示无嵌入记忆的基本链路读文件、改记录、写回。import json import time from pathlib import Path class PersistentMemory: def __init__(self, path): self.path Path(path) self.data self._read() def _read(self): if not self.path.exists(): return {entries: {}} with open(self.path, r, encodingutf-8) as f: return json.load(f) def _save(self): self.path.parent.mkdir(parentsTrue, exist_okTrue) with open(self.path, w, encodingutf-8) as f: json.dump(self.data, f, ensure_asciiFalse, indent2) def set(self, key, content, taggeneral): entry { content: content, tag: tag, updated_at: int(time.time()) } self.data[entries][key] entry self._save() def get(self, key): entry self.data[entries].get(key) return entry[content] if entry else None def search(self, keyword): results [] for key, entry in self.data[entries].items(): if keyword in entry[content]: results.append((key, entry[content])) return results memory PersistentMemory(./demo_memory.json) memory.set(tech_stack, Vite Vue 3 TypeScript) memory.set(dev_port, 5173, tagconfig) print(memory.get(tech_stack)) print(memory.search(5173))这段代码核心就几个点set 时用 key 作为唯一标识相同 key 会覆盖而不是追加updated_at 记录修改时间search 用简单的子串匹配。在实际项目里search 可以换成 SQLite FTS或者按 tag 过滤。整个模块不依赖任何外部库普通 Python 环境就能跑。注意一点这里 key 要稳定。不要把整个句子当 key尽量用 tech_stack、dev_port 这类短标识。否则同一个事实很容易在多次写入时变成两条不同记录。注意这里不要一上来就设计复杂 schema先用最简单的 JSON 把记忆读写跑通。能稳定读写之后再考虑增加标签、全文检索、SQLite 迁移。4.2 和 AI 编程 Agent 集成的常见方式有了持久化存储下一步是让 AI 用上这些记忆。常见的接入方式有三种按复杂程度递增。第一种最直接把记忆内容拼进提示词。比如启动会话时读取所有 tagconfig 的条目渲染成一段文本告诉 AI 这是项目约定。这种方式适合记忆量小、更新不频繁的阶段。只要注意不要把无用记忆也塞进去。第二种把记忆暴露成工具调用。AI coding agent 在处理任务时通过函数调用读写记忆get_memory(key) 可以读取set_memory(key, content) 可以写入search_memory(keyword) 可以检索。这种方式更接近 Llmem 这类产品的设计AI 能主动决定什么时候查记忆、什么时候更新记忆。缺点是需要 agent 框架支持工具调用实现时会多一点代码。第三种做成上下文压缩缓存。当一次对话快结束时把关键结论、决策、下一步计划抽取出来写入记忆。下次会话开始AI 先加载新的记忆摘要再开始工作。这种方式适合长任务、多轮会话。我建议从第一种开始。先用最小改动跑通再到工具调用和摘要抽取。不要一开始就追求 AI 自主管理记忆那会引入很多不可控的写入反而更容易出现记忆污染。4.3 多项目场景下的存储目录设计当记忆不只有一个项目时目录设计要提前想好。常用结构是这样~/.llmem/ ├── global/ │ └── preferences.json └── projects/ ├── my-project/ │ ├── memory.json │ ├── commands.md │ └── decisions.md └── another-project/ └── memory.json全局记忆放用户通用偏好比如“代码注释用中文”“遇到破坏性变更先询问”。项目记忆按项目隔离。这样既不会让两个项目的约定互相干扰也方便在切换项目时只加载对应的那部分记忆。路径设计成目录而不是单文件还有一个好处不同记忆类型可以分文件管理。commands.md 适合人扫读decisions.md 可以记录时间和原因memory.json 适合 AI 程序读写。不要把所有内容堆在一个文件里否则更新一条配置也要读写同一个大文件。5. 选无嵌入还是选向量库用判断标准来决定5.1 建议优先选无嵌入方案的情况有些人觉得无嵌入方案不够“智能”先入为主地认为记忆系统就该做向量语义检索。实际上在 AI 编程场景里无嵌入方案经常是更合理的选择。哪些情况可以优先考虑无嵌入第一记忆量不大。几百条以内用文件或 SQLite 足够不需要专门搭向量索引。第二记忆内容偏结构化事实。技术栈、版本、命令、规范这类信息关键词覆盖率高不需要语义扩展。第三资源受限。本地开发机没有 GPU内存只有 16G 或 32G再跑一个 embedding 模型会让其他开发工具明显变卡。第四对隐私和离线有要求。记忆文件留在本地磁盘不经过外部服务也不依赖网络。第五希望记忆可读、可审计、可人工修正。向量库里存的是一堆浮点数出了问题很难人工检查无嵌入方案打开文件就能改。以上这几条只要占了两三条就适合先走无嵌入路线。尤其对个人开发者和小团队维护成本往往比功能上限更关键。5.2 需要认真考虑向量方案的场景当然无嵌入方案不是银弹。有些场景明显更适合向量方案。第一种是开放域语义问答。比如你有一个几百篇文档的项目资料库希望 AI 回答“之前有没有人遇到过类似的定时任务问题”。这种问题很难用固定关键词匹配因为提问和文档之间是语义近似不是字面重复。第二种是长文档跨章节召回。项目文档分散在多个章节提问往往跨越多个主题关键词召回很容易漏掉上下文。第三种是记忆规模很大到了万条以上纯文件加载和关键词扫描会变慢向量库加上索引更合适。还有一个判断点你能接受多少误召回。无嵌入精确匹配的问题不是召回少而是容易因为措辞不同漏掉相关内容。向量方案则相反召回范围广但也会把不相干的内容拉进来。在 AI 编程场景误召回的成本可能更高。因为模型可能基于一条不相关的记忆给出一个自信但错误的修改建议。5.3 一个务实路线先用无嵌入后续再升级技术选型不用一次押注。比较务实的路线是先做无嵌入的最小闭环让记忆真正跑起来再根据实际卡点决定要不要引入向量检索。比如先用 JSON 或 SQLite 存记忆用关键词搜索。跑一周之后你发现 AI 经常因为关键词不一致而漏掉相关记忆这时候再增加 embedding 做语义召回和原来的关键词结果做合并排序。这种升级路径比一开始就搭一套完整向量系统平滑得多。从我的经验看大多数个人项目和中小型项目停在这个阶段就够了。真正需要完整向量库的往往是记忆规模大、查询模式复杂的场景。技术选型不用一次押注。先用无嵌入把记忆跑起来等出现明确的“漏召回”问题再考虑加向量召回。6. 落地避坑记忆污染、过期信息和文件权限6.1 记忆污染是整个方案最容易踩的坑记忆系统的核心问题不是存不下而是存进去的内容不够干净。记忆污染是最常见的一个坑。举个例子AI 在一次任务中临时把某个测试端口改成 8081如果这条信息被当成固定配置写入记忆后面所有会话都会认为项目端口是 8081。你需要花更多时间去排查为什么 AI 一直引导你访问错误端口。所以写入记忆之前一定要有过滤意识。我的经验是两个原则。第一只写稳定事实不写临时状态。第二如果不确定就先问一下用户是否要写入记忆或者默认不写只写入高置信度内容。AI 自动写入记忆时要加校验内容是否为空、是否超长、是否包含不完整路径、是否是重复条目。让 AI 自由地把所有输出都塞进记忆一百条之后整个系统基本没法用。6.2 排查链路先看现象再看记忆内容再看写入路径记忆系统出现问题时的现象很相似AI 回答里出现了不该有的信息或者明明有记忆AI 却完全没用到。排查时我按这个顺序看。第一先看记忆文件本身。打开对应的 memory.json 或 Markdown 文件看内容是否完整、格式是否合法、有没有重复或过期条目。很多时候问题就出在记忆内容已经写坏了。第二看加载逻辑。代码有没有读到正确路径路径拼错、文件名大小写不一致、工作目录不对都会导致文件读不到。最常见的是在项目根目录运行时正常换到子目录运行就找不到记忆文件。第三看注入位置。记忆内容拼进提示词之后有没有因为长度限制被截断还是排在大量无关系统指令后面模型根本没注意到这类问题经常表现为“记忆文件里有结果里没有”。第四看写入链路。AI 通过工具调用写记忆时参数是否正确有没有并发写同一个文件导致内容互相覆盖JSON 如果被并发写坏后续读取会直接报错。第五才是怀疑工具设计。只有当记忆内容、加载、注入、写入都正常但 AI 仍然不用再考虑是不是记忆组织形式的问题。这个排查顺序帮我解决过很多“记忆看起来没用”的假问题。遇到记忆相关报错不要先把锅甩给模型。先打开记忆文件看内容是否正常再往加载和注入方向查。6.3 我的建议把“可读、可删、可改”作为设计前提最后给一个收尾建议无论你用 Llmem还是自己写一个本地记忆模块都要把“可读、可删、可改”当作设计前提。可读意味着记忆文件是文本或结构化 JSON人能直接看懂。可删意味着系统能删除单条记忆而不是只能清空整个文件。可改意味着用户手工修正一条错误记忆后后续会话真的会采用修正后的内容。做到了这三点记忆系统哪怕简单也是可维护的。做不到这三点即使加上 embedding 和向量库也只是把脏数据翻得更好看。真正常用下去的工具不是功能最炫的而是不会在某天突然给你一堆过期、冲突、不可控的“记忆”。我个人更建议先把单任务跑稳再考虑批量和接口化。一个只能管理单项目记忆的小工具只要读取稳定、写入干净、能人工修改价值就比一个宣传很复杂却不好维护的“记忆框架”大得多。