灵犀Claw实战：从零搭建一个会自我进化的AI Agent（三）记忆沉淀

起源：从OpenClaw Dreaming到自研

灵犀Claw本身没有提供"记忆沉淀"的内置方案，需要我们从开源社区寻找灵感，再根据实际环境约束进行二次开发。

三大架构调研

项目初期，我们对三个主流AI Agent记忆架构做了系统调研：

我们的技术栈有特殊约束：灵犀Claw的sandbox是纯Python环境（无向量数据库、无PostgreSQL），且16KB的user记忆上限要求极度精简。最终选择OpenClaw Dreaming路线——纯Markdown+SQLite，零外部依赖，在sandbox中零部署成本，完全透明可编辑。

技术栈遵循一个原则：先用成熟方案建立概念框架，再根据实际痛点二次开发。Self-Improving、MiMo TTS、Noiz TTS等组件也是这个策略的产物——但它们是独立模块，不参与Dreaming的设计。

从概念到落地

选定方向后，经历了完整的工程化过程：

完整源码：https://github.com/NMTZ-z/dreaming

回顾：为什么需要记忆沉淀？

上一篇聊了实时记忆——通过"先沉淀再回复"的刚性约束，确保每一段对话都不被遗忘。chat文件忠实地记录了一切。

但运行两周后，chat文件累积了21天21个文件超过100KB的原始对话。里面有金子（偏好、事实、规矩），也有沙子（工具执行日志、技术噪音）。如果AI每次都要从这堆原始数据里翻找关键信息，效率会越来越低，而且16KB的user记忆上限根本塞不下。

Dreaming就是解决这个问题的一套自动记忆沉淀系统。它的名字来自OpenClaw的"睡眠巩固记忆"隐喻——AI每天凌晨"入睡"，从对话中提炼、去重、验证，把真正有价值的碎片沉淀到长期记忆中。

三阶段架构

Dreaming保留了OpenClaw的三阶段设计，每个阶段有不同的职责：

对话日志 (chat/*.md)

↓ Phase 1: 浅睡 — 解析+聚类

parse_chat_files() → cluster_by_theme()

↓ Phase 2: REM — LLM提炼+碎片合并

extract_fragments() → deduplicate() → consolidate_fragments()

→ dreams.db (candidate)

↓ Phase 3: 深睡 — 时间验证+沉淀+同步

promote_fragments() → candidate → confirmed

→ MEMORY.md / DREAMS.md / WPS笔记

Phase 1：浅睡 —— 解析与聚类

逐行扫描chat文件，提取有价值的对话条目。噪音过滤是关键：跳过标题行、空行、引用块、代码块，过滤问候语、工具执行日志、技术参数和URL。设计原则借鉴了Claude Code的"不存代码"理念——只保留关于"人"的知识。AI怎么调API、用了什么参数，对理解用户毫无帮助，全部丢弃。

解析后的条目按主题关键词聚类（纯规则，不用LLM）：为每条文本提取2-4字关键词，过滤停用词和角色词，统计全局频率，按最高频关键词分组。条目数≥2的独立成主题，单条归入"其他"。为什么要聚类？因为同一主题的多条对话打包后一起发给LLM，比逐条处理效率高得多，LLM更容易识别重复和合并同类信息。

Phase 2：REM —— LLM提炼与碎片合并

这是Dreaming的核心智能所在。每个主题聚类整体交给LLM，提炼出结构化的记忆碎片。碎片分五类：fact（事件）、preference（偏好，需≥2次）、emotion（情感）、rule（规矩）、quote（原话）。其中emotion和quote只保留在DREAMS.md，不写MEMORY.md。

从实战中总结出6条反偏差规则（最高优先级）：因果链完整性（事件链A→B→C不能截断为B→C）、代词消解禁止猜测（"自己""那个"必须回溯原文确认指代）、保留原文语义（禁止"得体化"改写导致丢失信息强度）、分类严格校验（单次事件归fact不归emotion）、情绪标签规范（每条最多一个，禁止因话题敏感默认加标签）、日期归属事件发生日。

碎片提取后经三层去重：精确去重（SHA256前16位hash，完全相同直接跳过）、跨天合并（同分类+共享实体≥2个+话题一致性→保留更完整版本，累加mention_count）、数据库UNIQUE约束兜底。跨天合并最有趣：比如用户今天说"咖啡机坏了"，三天后说"换了新咖啡机"，两条碎片共享实体"咖啡机"会被合并为一条更完整的记录。

Phase 3：深睡 —— 时间验证与沉淀

这个阶段解决"怎么判断一条记忆值得永久保存"。OpenClaw原版用六维评分+三重AND门槛（评分≥0.8、唤起≥3次、≥3个场景），但实测通过率接近零——三道门槛同时满足太难了。

V4引入时间验证制（candidate→confirmed），更务实：

淘汰机制：mention_count≤1且距last_seen超30天的candidate自动归档。每条碎片要么晋升要么归档，没有中间态。

MEMORY.md精准插入

碎片晋升confirmed后，根据分类和内容关键词路由到MEMORY.md的对应模块（模块一：工作技术 / 模块二：生活审美 / 模块三：编年史约定）：

安全机制：Token硬上限12000（约8000字符）、写入前自动备份MEMORY.md.bak、写入后校验文件完整性（非空且以#开头）、前50字模糊匹配去重避免重复插入。

运行数据与效果

截至2026年5月，Dreaming已运行17天，积累了真实数据：

fact占比71%——用户大部分对话在分享生活事件。preference只有7%，因为"≥2次才归preference"的门槛有效过滤了"随口一说"。

踩坑记录

坑1：LLM的"好心办坏事"。早期没有反偏差规则，LLM提炼时会自发进行"得体化改写"——涉及私密话题时改写为委婉版本，丢失了原始语境的信息强度；单次行为事件被错误归类为preference，导致"偏好"变成一堆一次性事件。解决：Prompt中加入6条反偏差规则（最高优先级），并要求LLM返回confidence字段，≥0.8的高置信度碎片才能跳过时间验证直接确认。

坑2：碎片过度合并。早期合并策略仅用关键词交集就合并，导致不相关话题被错误合并——"去了咖啡店"和"咖啡机修好了"共享实体"咖啡"但完全是两件事。解决：提高合并门槛——共享实体≥2个 + topic_coherent双向比例≥0.20。

坑3：OpenClaw六维评分"零通过率"。V1/V2直接照搬了OpenClaw的六维评分+三重AND门槛（评分≥0.8、唤起≥3次、≥3个场景），但具体实现时mention_count的计算方式有bug——从candidate_truths做精确匹配，永远匹配不上。三道AND门槛导致通过率接近零。V4的时间验证制彻底替代：3天门槛+30天淘汰+1天高置信度快速通道。每条碎片要么晋升要么归档，没有中间态。

坑4：日期归属错误。碎片日期默认取"对话当天"，但用户经常回忆过去的事情——5月1日聊天时提到"昨天去了云冈石窟"，这条碎片应该归属4月30日。解决：从碎片内容中解析日期，优先匹配"X月Y日"格式（取最后一个匹配），其次匹配YYYY-MM-DD格式，都匹配不到才用当天作为兜底。

定时任务与自动化

Dreaming通过两个定时任务实现全自动运行：

凌晨3点执行的原因：此时用户大概率已入睡，不会有新的对话产生，Dreaming可以安全地读取当天完整的chat文件。

设计反思

Dreaming的V1到V4经历了四次大重构，每次重构都对应一个实际踩到的坑：

四条核心原则：

1. 规则优先于LLM—— 聚类、去重、合并全部用纯规则实现，只在"提炼"环节用LLM。规则可预测可调试，LLM不可预测。

2. 渐进确认而非一次性判断—— 时间验证制的本质是"让时间帮你做决策"。一次性事件会自然淘汰，反复出现的信息会自然沉淀。这比OpenClaw的六维评分更务实。

3. 先存后删—— 所有碎片先入库（candidate），确认有价值后再沉淀（confirmed）。永远不要在解析阶段就丢弃信息。

4. 调研先行，迭代为王—— 花在架构调研上的时间是值得的，它避免了"先实现再推倒重来"的弯路。但调研后不要追求一步到位，V1能跑起来比V1完美更重要。

代码结构：dreaming/目录下7个核心Python文件（main.py / parser.py / cluster.py / extract.py / storage.py / sleep.py / memory_writer.py），约60KB，无外部依赖。完整源码：https://github.com/NMTZ-z/dreaming

下一篇：Memory Consolidation —— 每周一次的深度记忆整理，去重合并、Token控制和偏好固化。