Hi带娃的我热爱AI 大模型应用落地、意识解码与 AI 开发工具链。 创业路上用技术换时间一起把 AI 变成生产力 WeClaw_59_AI的失忆症处方跨会话经验知识图谱让AI越用越聪明系列文章第 59 篇- 从每次修 Bug 都从零开始到越用越聪明的个人助手 专栏信息《从零到一构建跨平台 AI 助手WeClaw 实战指南》专栏本文是模块十第 2 篇探讨如何用 SQLite 向量检索为 AI 构建经验记忆让每一次自我修正都能复用上一次的智慧。‍ 作者与项目作者简介翁勇刚 WENG YONGGANG新概念龙虾-WeClaw 开发团队负责人一群专注于跨平台 AI 应用的实践者理念“再复杂的技术也能用代码讲清楚” 摘要本文结构概览本文从两个表面不同、根因相同的真实 Bug 修复场景切入揭示 AI 助手的核心体验缺陷——跨会话失忆症。然后设计 ExperienceStore经验知识图谱的 SQLite 向量双存储架构展示记录经验 → 语义检索 → 上下文注入的完整数据流探讨经验泛化这一核心难点最后给出经验积累系统的 Do’s/Don’ts 清单。背景WeClaw 已经具备自我反思闭环感知 → 诊断 → 修复 → 重启但每次对话是无状态的。第 1 周花了 30 分钟修复 stock_query 的浮点解析 Bug第 3 周 log_viewer 出现类似的编码问题时AI 完全不记得上次的防御性数据解析经验又从零分析了一遍。核心问题如何让 AI 在跨会话场景下积累经验实现越用越聪明而非每次从零开始解决方案构建 ExperienceStore在每次自我修正闭环完成后自动记录结构化经验trigger / diagnosis / fix / outcome下次遇到类似问题时通过向量检索召回历史经验注入 System Prompt 供 LLM 参考。关键成果设计了 experience 数据模型7 字段 向量 embedding复用现有 embedding 模型和 SQLite 基础设施零额外依赖提出经验泛化问题的 LLM 辅助抽象方案明确经验积累 vs 自主目标设定的投入产出比判断适合读者对 AI Agent 记忆系统、向量检索、知识图谱感兴趣的开发者阅读时长约 14 分钟关键词经验积累、向量检索、跨会话记忆、知识图谱、Embedding、语义搜索、System Prompt一、AI 的失忆症——一个被忽视的核心体验缺陷1.1 两个场景同一个根因想象这两个真实场景第 1 周用户“stock_query 查询港股价格时报错了。”AI 花 30 分钟排查发现问题根因外部 API 返回的价格字段有时是字符串N/A直接float()转换导致 ValueError。修复方案引入float_or_none()安全转换函数对无法解析的值返回 None 而非抛异常。第 3 周用户“log_viewer 读取日志时出现编码异常。”AI 从零开始分析花了 20 分钟排查。发现根因日志文件中的某些行包含非 UTF-8 字符直接读取导致 UnicodeDecodeError。修复方案open()时添加errorsreplace参数。发现问题了吗┌──────────────────────────────────────────────────────┐ │ │ │ stock_query Bug log_viewer Bug │ │ ────────────── ────────────── │ │ 外部 API 返回 N/A 日志文件含非 UTF-8 字符 │ │ ↓ ↓ │ │ 直接 float() 转换 直接 open() 读取 │ │ ↓ ↓ │ │ ValueError UnicodeDecodeError │ │ ↓ ↓ │ │ 修复防御性转换 修复防御性读取 │ │ │ │ 共同根因外部数据未做防御性解析 │ │ │ │ 但 AI 在第 3 周完全不知道第 1 周的经验 │ └──────────────────────────────────────────────────────┘1.2 失忆症的本质无状态对话架构WeClaw 当前每次对话是无状态的。虽然chat_history可以检索历史对话文本但它只存储原始聊天消息不存储结构化的诊断经验。维度chat_history已有ExperienceStore需要存储内容原始对话文本结构化经验记录检索方式关键词匹配向量语义检索信息密度低大量闲聊夹杂少量技术信息高每条记录都是提炼后的诊断结论跨会话可用部分需手动翻阅自动注入适合场景“我们上周聊了什么”“上次类似的 Bug 是怎么修的”chat_history 不是不能用而是用不好。让 AI 从几百条对话记录中找到上次类似的 Bug 修复经验就像让你在微信聊天记录里找上次那个修水管师傅的电话——技术上可行体验上痛苦。1.3 产品差异化“越用越聪明”这其实是 WeClaw 与普通 AI 助手的核心差异点。用户会感受到“它记得上次帮我修了什么这次直接告诉我可能是类似的问题——这个 AI 在成长。”这种体验粘性远强于每次对话都从零开始的竞品。二、ExperienceStore 架构设计——SQLite 向量的双存储方案2.1 核心数据模型每条经验记录包含 7 个结构化字段 1 个向量 embedding┌─────────────────────────────────────────────────────┐ │ Experience 数据模型 │ │ │ │ ┌─────────────┐ ┌─────────────────────────────┐ │ │ │ 结构化字段 │ │ trigger: tool_audit错误率上升 │ │ │ │ (SQLite) │ │ diagnosis: 浮点解析bug │ │ │ │ │ │ fix: 添加float_or_none() │ │ │ │ │ │ outcome: success │ │ │ │ │ │ related_files: [stock.py] │ │ │ │ │ │ pattern: 防御性数据解析 │ │ ← 抽象化标签 │ │ │ │ created: 2026-05-29 │ │ │ └─────────────┘ └─────────────────────────────┘ │ │ │ │ ┌─────────────┐ ┌─────────────────────────────┐ │ │ │ 向量字段 │ │ embedding: [0.12, -0.34, │ │ │ │ (向量索引) │ │ 0.56, ...] (384维) │ │ │ │ │ │ │ │ │ │ │ │ 编码内容: trigger diagnosis │ │ │ │ │ │ fix pattern │ │ │ └─────────────┘ └─────────────────────────────┘ │ └─────────────────────────────────────────────────────┘2.2 完整数据流自我修正闭环完成 │ ▼ ┌─────────────────────┐ │ ExperienceStore │ │ .record() │ │ │ │ 1. 提取结构化字段 │ │ 2. LLM 抽象化 │ │ → pattern 标签 │ │ 3. Embedding 编码 │ │ 4. 写入 SQLite │ └────────┬────────────┘ │ │ 下次遇到类似问题 ▼ ┌─────────────────────┐ │ ExperienceStore │ │ .recall() │ │ │ │ 1. 编码当前问题 │ │ 2. 向量相似度检索 │ │ 3. 返回 Top-K 经验 │ └────────┬────────────┘ │ ▼ ┌─────────────────────┐ │ System Prompt │ │ 注入相关经验 │ │ │ │ 历史经验参考 │ │ 3周前修复过类似 │ │ 的防御性解析问题... │ └─────────────────────┘2.3 为什么选择 SQLite 向量而非纯向量数据库方案优势劣势适合场景纯向量数据库如 Milvus高性能检索额外依赖、运维成本高大规模 SaaS纯 SQLite 全文搜索零依赖、简单只能关键词匹配无法语义检索简单日志SQLite 内嵌向量零额外依赖、语义检索、事务安全向量维度受限个人桌面应用WeClaw 选择第三种方案。已有的基础设施几乎可以直接复用resources/embedding_models/本地 embedding 模型已部署SQLite项目核心数据库引擎已使用System Prompt 注入已有的上下文管理机制三、实战代码详解——ExperienceStore 的概念实现3.1 经验记录与检索以下是 ExperienceStore 的核心逻辑概念版展示设计思路classExperienceStore:跨会话经验知识图谱。 在每次自我修正闭环完成后自动记录经验 下次遇到类似问题时通过向量检索召回历史经验。 defrecord(self,trigger,diagnosis,fix,outcome,files):记录一次自我修正经验。# Step 1: 用 LLM 做抽象化提取通用 patternpatternself._extract_pattern(trigger,diagnosis,fix)# 例triggerstock_query浮点错误, fixfloat_or_none()# → pattern防御性数据解析# Step 2: 生成语义向量textf{trigger}{diagnosis}{fix}{pattern}embeddingself.embedder.encode(text)# Step 3: 写入 SQLiteself.db.execute( INSERT INTO experiences (trigger, diagnosis, fix, outcome, pattern, related_files, embedding, created) VALUES (?, ?, ?, ?, ?, ?, ?, ?) ,(trigger,diagnosis,fix,outcome,pattern,json.dumps(files),embedding,datetime.now()))defrecall(self,current_problem:str,top_k:int5):检索与当前问题最相似的历史经验。query_embself.embedder.encode(current_problem)# 向量余弦相似度检索returnself.db.vector_search(tableexperiences,query_vectorquery_emb,top_ktop_k)3.2 经验抽象化从具体 Fix 到通用 Pattern_extract_pattern()是整个系统最关键的一步。如果只记录stock_query 的 float() 改成了 float_or_none()那这条经验只对 stock_query 有用。我们需要 LLM 做抽象def_extract_pattern(self,trigger,diagnosis,fix)-str:用 LLM 从具体修复中提炼通用模式。promptf 以下是 AI 系统的一次自我修复记录 - 触发{trigger}- 诊断{diagnosis}- 修复{fix}请用 3-5 个字概括这类问题的通用模式如防御性数据解析、 并发竞态保护、编码兼容处理只输出模式名称。 returnself.llm.generate(prompt,max_tokens20)这个抽象化步骤的价值具体记录低泛化 stock_query 的 float() 改为 float_or_none() → 只对 stock_query 有用 抽象记录高泛化 pattern 防御性数据解析 → 对 log_viewer 编码问题、API 响应解析问题都有参考价值3.3 与 System Prompt 的集成在每次新对话开始或自我反思触发时自动将相关经验注入上下文asyncdefinject_experience_context(self,current_problem:str):将相关历史经验注入 LLM 上下文。experiencesself.recall(current_problem,top_k3)ifnotexperiences:returncontext_lines[\n## 历史经验参考自动检索]fori,expinenumerate(experiences,1):context_lines.append(f\n{i}. [{exp.created[:10]}]{exp.pattern}\nf 触发{exp.trigger}\nf 诊断{exp.diagnosis}\nf 修复{exp.fix}\nf 结果{exp.outcome})return\n.join(context_lines)AI 看到的上下文注入效果## 历史经验参考自动检索 1. [2026-05-01] 防御性数据解析 触发stock_query 查询港股价格报错 诊断外部 API 返回 N/A直接 float() 转换失败 修复引入 float_or_none() 安全转换函数 结果success 2. [2026-05-15] 编码兼容处理 触发文件读取出现 UnicodeDecodeError 诊断日志文件含非 UTF-8 字符 修复open() 添加 errorsreplace 结果success有了这段上下文当 log_viewer 再次出现类似问题时AI 会直接联想到防御性数据解析这个通用模式而不是从零开始分析。四、问题诊断与修复——经验系统的三个核心挑战4.1 挑战一经验噪声——假经验干扰决策问题并非所有修复都值得记录。如果 AI 修了一个 typo变量名拼写错误这条经验几乎没有复用价值反而会在后续检索中成为噪声。解决思路引入经验质量评分机制。# 记录时由 LLM 评估经验的复用价值quality_prompt 评估以下修复经验的复用价值1-5分 - 1分一次性问题typo、配置错误 - 3分同类模块可能遇到特定数据格式问题 - 5分通用模式防御性解析、并发保护、编码兼容 # 只保存 quality 3 的经验4.2 挑战二经验膨胀——数据库越来越大检索越来越慢问题随着使用时间增长经验记录越来越多向量检索的性能会下降注入 System Prompt 的内容也会膨胀。解决思路┌──────────────────────────────────────────────┐ │ 经验生命周期管理 │ │ │ │ 新增经验 → 活跃期30天→ 沉淀期 → 归档/淘汰 │ │ │ │ 活跃期全量参与检索 │ │ 沉淀期仅 pattern 参与检索摘要级别 │ │ 归档outcomefailed 的经验 90 天后自动归档 │ │ 淘汰相似度 0.95 的经验合并去重 │ └──────────────────────────────────────────────┘关键设计相似经验合并。如果 3 条经验的 pattern 都是防御性数据解析且相似度 0.95合并为一条超级经验记录多次修复的共同模式。4.3 挑战三经验误导——历史经验可能是错误的问题如果一次修复的 outcome 后来被证明是失败的重启后问题依然存在但经验已经被记录后续可能会被错误地召回参考。解决思路# 闭环验证重启后检查修复是否真正生效asyncdefverify_experience(self,experience_id:str):重启后验证修复是否生效。expself.get(experience_id)# 检查相关错误是否不再出现recent_errorsawaittool_audit.get_recent_errors(keywordexp.trigger,hours1)ifrecent_errors:# 修复失败标记经验为无效self.update(experience_id,outcomefailed)else:# 修复成功确认经验有效self.update(experience_id,outcomeverified)教训经验不是记录了就完事必须有闭环验证机制。一条被标记为failed的经验不会参与后续检索。五、最佳实践——经验积累系统的设计原则5.1 Do’s / Don’tsDo’s推荐做法✅修复成功后才记录只在自我修正闭环完成且验证成功后才调用record()✅抽象化 pattern 标签不只记具体 fix更记通用 pattern✅限制注入数量System Prompt 中最多注入 3-5 条经验避免上下文膨胀✅经验去重合并相似度 0.95 的经验自动合并防止数据库膨胀✅闭环验证 outcome重启后检查修复是否真正生效失败经验标记为failed✅复用现有基础设施embedding 模型、SQLite 引擎、System Prompt 机制都是现成的Don’ts避免做法❌ 不要记录 typo 类一次性修复quality 3❌ 不要把完整代码 diff 存入经验——只存诊断思路和修复方案❌ 不要让经验注入占用过多 System Prompt 预算建议 500 tokens❌ 不要跳过闭环验证——未验证的经验可能是毒药❌ 不要在经验中存储用户敏感信息遵循与 tool_audit 相同的脱敏原则5.2 投入产出比分析在自我反思能力体系的后三项中经验积累的投入产出比是最优的能力实现周期核心价值适用场景推荐优先级跨会话经验积累1-2 周解决失忆症核心痛点所有对话场景P3推荐自主设定改进目标2-4 周信号量不足单用户高并发 SaaS暂缓为什么经验积累是刚需自主目标是奢侈品WeClaw 是单用户桌面应用日均交互量在几十到几百次级别错误信号量不足以支撑空闲自省的统计显著性。每小时跑一次 LLM 分析可能得到的结论是今天一切正常——白白消耗 API 费用。而经验积累是被动触发的——只在自我修正闭环完成时才记录零额外 API 消耗零噪声产生。5.3 黄金法则让 AI 记住过去比让 AI 主动思考未来更实际。对个人助手而言经验积累是刚需自主目标是奢侈品。先把记忆力做好再考虑想象力。六、总结与展望6.1 核心要点回顾本文从失忆症切入设计了跨会话经验知识图谱3 个关键设计SQLite 向量双存储结构化字段用 SQLite 管理语义检索用向量编码零额外依赖LLM 辅助抽象化不只记具体 fix更记通用 pattern如防御性数据解析闭环验证机制修复成功才记录失败经验自动标记未验证经验不参与检索1 个核心公式经验积累 结构化记录 语义检索 上下文注入 闭环验证6.2 下一步学习方向前置知识✅ 上一篇《当 AI 学会照镜子自我反思闭环架构》✅ Embedding 模型原理与余弦相似度计算✅ System Prompt 上下文管理机制后续主题 下一篇《能力越强护栏越硬AI 自主进化的安全边界工程与核能类比》6.3 互动环节思考题如果两条经验的 pattern 相同但 fix 不同一个成功一个失败系统应该如何处理经验注入 System Prompt 时应该按时间排序还是按相似度排序各有什么利弊讨论话题你认为 AI 助手应该记住多少历史经验如果记忆太多导致信息过载该如何取舍欢迎在评论区讨论。下期预告《能力越强护栏越硬AI 自主进化的安全边界工程与核能类比》AI 突破沙箱需要的六项能力WeClaw 具备了几项为什么说权限提升和隐蔽行动是真正的安全红线能力-安全共演化每扩展一项能力需要多少安全护栏敬请期待附录 A技术栈对比组件已有基础设施ExperienceStore 复用方式数据库引擎SQLitetool_audit.db新建 experience.db同模式向量编码resources/embedding_models/直接调用本地 embedding 模型上下文注入System Prompt 构建机制在 prompt 组装阶段注入经验触发时机自我反思闭环闭环最后一步自动record()检索时机自我反思第一步自动recall()并注入附录 B参考资料Sentence-BERT: Sentence Embeddings using Siamese BERT-NetworksSQLite Vector Search Extensions: sqlite-vec上一篇《当 AI 学会照镜子自我反思闭环架构从哲学之问到工程实践》下一篇《能力越强护栏越硬AI 自主进化的安全边界工程与核能类比》版权声明本文为 CSDN 博主「yweng18」的原创文章遵循 CC 4.0 BY-SA 版权协议转载请附上原文出处链接及本声明。