龙虾机器人记忆系统 v4.15 · 全面解析

OpenClaw · v4.15 · April 2026 正式发布。本次迭代的核心是记忆系统 —— 把过去分散的 prompt buffer、上下文窗口、单次会话日志,统一重构为四层记忆架构,让龙虾机器人第一次真正拥有"昨天的记忆"。这是我们花了三个季度迭代的结果,也是 Agent 从"聪明的临时工"走向"长期搭档"的分水岭。

一 · 为什么要重做记忆 The Memory Problem

在 v4.14 及之前,我们延续了开源社区常见的做法:短期记忆 = 上下文窗口,长期记忆 = 简单 RAG。看似够用,实测却频繁出现三类问题:

• 健忘:用户昨天说过"不要用 XX 方案",今天又被推荐;
• 混乱:多个项目的工程片段被塞进同一个向量库,检索起来张冠李戴;
• 僵硬:明明在同一个会话里已经学会了某个操作,重启后又要从零解释。

归根到底,过去的"记忆"只是一个被动的上下文窗口,而不是一个会主动整理、分层归档、按需召回的系统。v4.15 要解决的就是这个根问题。

二 · 四层架构 The Four-Layer Memory

参考认知科学 Tulving 的记忆分类,我们把龙虾的记忆拆成四层,每层各司其职:

每一层有自己的读写策略、衰减曲线和上层 API。一次对话进来,调度器会决定哪些信息只进工作记忆(无需持久化),哪些该写入情景记忆(昨天聊了什么),哪些应该提炼到语义记忆(用户的公司名、业务流程),哪些是可以沉淀为程序记忆的操作步骤(他每周五都要导出这张表)。

三 · 检索:稠密 + 稀疏双通道 Hybrid Retrieval

v4.14 我们只做了 dense 向量检索。这一版改成 稠密 + 稀疏 + 元数据过滤 的混合检索:

• 稠密:BGE-M3 生成 1024 维向量,用于语义相似("客户抱怨很久" ≈ "客诉处理")
• 稀疏:BM25 + 同义词扩展,保证命名实体、产品型号这种"字面精确"不会丢
• 元数据过滤:先按 tenant_id / project_id / time_window 收窄再检,避免跨租户污染

在内部 benchmark 上,混合检索相比纯 dense 提升 top-3 召回 +18.3%,对带型号的问题提升尤其明显。

// 伪代码 · 混合检索
docs = union(
  dense(query, k=20, filter=tenant),
  sparse(query, k=20, filter=tenant),
)
docs = rerank(query, docs, model="bge-reranker-v2")
top = docs[:8]

四 · 记忆压缩:解决"越聊越慢" Memory Compaction

长会话里,直接把所有历史塞进 context 会变得既贵又慢。v4.15 引入四级压缩流水线:

1. raw(< 24h)· 原始消息完整保留,便于回溯
2. summary(≤ 7d)· 每 N 轮滚动摘要,保留因果和决定
3. facts(≤ 90d)· 抽取出"用户 A 的偏好是 X"这类结构化条目
4. skills(永久)· 把重复操作固化为可调用的技能脚本

旧层会在夜间批量压缩到新层,冗余的原始数据被归档到冷存储,热路径只读 summary + facts,平均一次会话上下文从 28K tokens 降到 6.2K tokens,首字延迟降低 47%。

五 · 跨会话连续性 Session Continuity

最直观的体验变化:重新打开对话时,龙虾会以一句简短的"昨日速报"开场 ——

这句话不是预生成模板,而是情景摘要 + 偏好事实 + 当前意图 三者的实时拼装。用户不再需要"每次从头说起",这是我们收到反馈最多的改进。

六 · 隐私与可控 Privacy & Control

记忆强大就意味着"记得太多"成了风险。v4.15 默认:

• 所有情景记忆 24h 后自动从原始降级到摘要,不保留敏感字段的明文
• 用户可以一键 「忘了这件事」,系统同时清掉情景+语义+程序三层的相关条目
• 管理员可以导出本企业全部记忆,做合规审查
• 每层的写入在 UI 上是可见的 —— 你永远知道"它记住了什么"

辉火云 · OpenClaw v4.15 · 2026-04-22
记忆架构 · 四层分治 · 双通道检索 · 压缩流水线