OpenClaw如何做好记忆持久化的 · 三、一条记忆的完整生命旅程
三、一条记忆的完整生命旅程⏱ 30 秒速览| 记忆有 3 条路径路径 A自动提取 噪声过滤 → Smart Extraction 六类分类 → 两阶段去重 → 向量存储 →8 步混合检索ANN BM25 Cross-Encoder Weibull 衰减→ 智能遗忘。其中检索管线全在本地完成0 LLM API token提取和去重阶段消耗少量 LLM token端到端 ~200ms。路径 B自修改 Agent 把关键偏好写入配置文件确定性生效永不遗忘——这是从记忆到学习的跨越。路径 C主动记忆 24/7 后台监控 Cron/Heartbeat/Webhook 事件驱动不等你问就主动想起。三者协同 广度 深度 主动性。核心叙事章节。用一个具体例子串联记忆从诞生到消亡的全过程。路径 A 是主线6 步详解路径 B 和 C 是差异化补充——三条路径篇幅不同但重要性互补。架构告诉我们有什么这一章要回答怎么运作。我们将用一个具体的用户场景追踪一条记忆从诞生到召回再到衰减的完整生命周期。3.1 路径 A自动提取路径Auto-Capture → Recall → Decay以下以memory-lancedb-pro为例。这是社区最成熟的生产级记忆插件3.6k Star也是大多数用户的实际选择。内置的memory-lancedb实现了基础版的相似管线但缺少 Cross-Encoder、Weibull 衰减等进阶能力。STEP 1 · 触发——一句话的开始周一下午你在 某工具上对 OpenClaw 说“以后数据库都用 PostgreSQL别再给我推荐 MySQL 了。”这句话看似简单但背后立即触发了一连串处理agent_end钩子→ 每次 LLM 调用结束后自动执行的回调函数触发 Auto-Capture 管线噪声过滤器先行判定这不是问候“你好”、不是拒绝“不用了”、不是元问题“你是谁”——这些都不需要记住CJK 感知长度阈值通过中文 6 字英文 15 字符——太短的内容通常不含值得记忆的信息So What不是所有对话都值得记住。噪声过滤是记忆质量的第一道防线。如果什么都记记忆库很快会被谢谢、“好的”、帮我看看淹没真正重要的偏好被噪声稀释。[准确性]信息论这一步是最粗粒度的有损压缩——从所有对话中筛选出值得处理的约一半~50%。其余直接丢弃信息损失大但噪声损失更大净效果为正。STEP 2 · 提取——Smart Extraction 把自然语言变成结构化记忆通过噪声过滤的对话进入 Smart Extraction 管线。LLM 分析这句话后执行两个操作操作 1分类。将记忆归入 6 个类别之一profile基本信息名字、职业、时区preferences偏好技术栈、风格、习惯entities实体项目名、公司名、联系人events事件会议、截止日期、里程碑cases案例问题-解决方案对、debug 经历patterns模式反复出现的工作流、决策逻辑以后数据库都用 PostgreSQL被分类为preferences用户偏好。这个分类不仅是标签——它直接影响后续的去重逻辑STEP 3和衰减策略STEP 6。操作 2生成三层摘要L0 / L1 / L2 层级存储L0 一句话索引“用户偏好 PostgreSQL明确拒绝 MySQL”~10 tokensL1 结构化摘要{ category: preferences, key: database, value: PostgreSQL, negative: MySQL, confidence: 0.95 }~30 tokens。注意confidence由 LLM 自评生成校准性有限——高分不等于高准确率这与 §5 F1幻觉持久化直接相关高置信度的错误记忆比低置信度的更难被后续过滤发现L2 完整上下文叙述保留原始对话上下文、时间戳、渠道信息~200 tokensSo WhatL0/L1/L2 三层设计的精妙之处——检索时用 L0轻量快速展示时用 L1结构化需要追溯时用 L2完整原文。不同场景读不同层平衡了速度与深度。[延迟] [召回率]信息论从原始对话~500 tokens到 L0~10 tokens压缩比 ~50:1。关键是这次压缩由 LLM 执行所以是语义有损而非随机有损——丢掉的是冗余表述保留的是核心事实。STEP 3 · 去重——两阶段管线防止记忆膨胀如果用户上周已经说过我喜欢 PostgreSQL这条新记忆会与旧记忆冲突吗去重管线负责回答这个问题阶段 1 · 向量相似度搜索——用 ANN→ Approximate Nearest Neighbor近似最近邻搜索做快速粗筛。注意这里的 ANN 用于存储时去重与 STEP 5 中用于召回时检索的 ANN 是同一算法的不同应用场景。系统检查是否存在相似度 ≥ 0.7 的已有记忆。阶段 2 · LLM 语义决策——向量相似度只能判断像不像不能判断是不是同一回事。“喜欢 PostgreSQL” 和 “正在学 PostgreSQL” 向量很近但含义完全不同。所以对阶段 1 的候选结果LLM 做最终判断CREATE全新信息新建记忆MERGE与现有记忆本质相同但信息更丰富合并更新SKIP纯重复跳过类别感知规则让逻辑更智能profile类始终合并用户名字只有一个events/cases类始终追加每次会议都是不同事件。So What去重是抑制记忆膨胀的核心机制。没有去重用户每提一次 PostgreSQL向量库就多一条几乎相同的记忆检索时被这些重复项占据 Top-K 名额真正需要的其他记忆反而被挤出去。[准确性] [成本]STEP 4 · 存储——向量化并写入 LanceDB通过去重筛选的记忆被向量化并持久存储Embedding 模型选择memory-lancedb-pro 默认使用 OpenAItext-embedding-3-small1536 维也可配置为本地模型如nomic-embed-text。Embedding 模型直接决定向量检索质量——维度越高语义区分度越好但存储和计算成本也越高。存储后端是LanceDB→ 嵌入式向量数据库零服务器部署使用 Lance 列式格式支持 ANN 和全文索引每条记忆附带丰富的元数据scope谁的记忆/category6 类之一/tierPeripheral/Working/Core 三级/importance重要度分数/timestampSo WhatLanceDB 的嵌入式特性意味着不需要单独部署数据库服务——这对本地优先架构至关重要。没有服务端口暴露、没有认证配置、没有网络延迟。cp一下目录就是完整备份rm -rf就是彻底删除。[隐私] [可控性]STEP 5 · 召回——三天后的跨会话记忆恢复三天过去了。你在一个全新的对话中说了一句看似不相关的话周四上午你在新会话里说“帮我设计一个数据存储方案。”你没有提到 PostgreSQL没有提到数据库偏好。但before_prompt_build钩子→ 在构建 LLM 提示词之前执行的回调触发了 Auto-Recall混合检索管线启动。这条管线共 8 步每一步都解决一个具体问题步骤操作术语解释解决什么1Vector ANN用向量空间中的语义距离找到含义相近的记忆语义相关性2BM25 FTS→ Best Matching 25经典全文检索算法按关键词精确匹配精确关键词匹配PostgreSQL这个词3Hybrid Fusion将向量分数与关键词分数加权融合综合语义关键词4Cross-Encoder 重排→ 将查询和候选记忆拼接后送入小型 transformer 模型非完整 LLM打分比双塔模型更准但更慢精排提升准确度5Weibull 衰减加权→ Weibull 分布衰减函数综合考虑 recency多久前 frequency被想起几次 intrinsic value记忆本身的重要性时间感知新的/常用的/重要的记忆优先6Length Normalization锚定 500 字符防止长条目因字数多而获得不公平的高分防长条目垄断7MMR 多样性过滤→ Maximal Marginal Relevance余弦相似度 0.85 的近似重复结果降权防信息茧房8Hard Min Score 过滤0.35 以下直接丢弃淘汰低质量候选最终 Top-K 结果通常 5~15 条注入relevant-memories标签插入系统提示词。你三天前在 某工具上说的 PostgreSQL 偏好此刻被精准送到了 LLM 面前。延迟分解back-of-envelope查询 Embedding API ~50ms Vector ANN ~10ms BM25 ~10ms Hybrid Fusion ~1ms Cross-Encoder 推理 ~50ms Weibull/Norm/MMR/Threshold ~5ms ≈~130ms 纯管线延迟。加上 Gateway 钩子调度、结果序列化等开销端到端约~200ms。瓶颈是两个推理步骤——Embedding API 调用和 Cross-Encoder 本地推理各占约 40%。使用本地 Embedding 模型需 GPU可将纯管线延迟降至 ~80ms。记忆注入 vs 上下文预算以 200K 上下文窗口为例Top-10 记忆注入约 600 tokens~0.3%加上 Workspace 文件注入4 个核心文件约 ~2K tokens如 Agent 创建了大量 Skills该值会随之增长记忆层总共占用上下文预算的 ~1.3%。这就是无限积累 vs 有限窗口矛盾的量化答案——通过 8 步管线精选海量记忆被压缩到 2%的窗口占用。So What8 步管线看似复杂但每一步都有明确的必要性。去掉 BM25“PostgreSQL” 这个精确词可能被语义近似的 “MySQL” 干扰。去掉 Cross-Encoder排序质量下降。去掉 Weibull三个月前的过时偏好和昨天的新偏好权重一样。这是工程上的每一步都不能少。[召回率] [准确性]信息论从向量库中的数万条记忆到最终注入的 5~15 条选择性压缩比 ~1000:1。8 步管线的本质是一个信息论意义上的最优选择器——用最少的 Token 预算传递最多的相关信息。STEP 6 · 演化——记忆的生长与遗忘记忆不是静态的快照。存入后它会随着时间和交互持续演化——有些变得更重要有些逐渐被遗忘。Weibull 衰减引擎是整套机制的数学基础S(t)e−(t/λ)kS(t) e^{-(t/\lambda)^k}S(t)e−(t/λ)k其中S(t)S(t)S(t)是记忆在时间ttt的存活分数1.0 刚存入→0 即将被遗忘λ\lambdaλ是尺度参数由记忆重要度调制越重要λ\lambdaλ越大衰减越慢kkk是形状参数控制衰减曲线的陡峭程度。kkk的取值至关重要揭示了一个可以称为持久性悖论 (Persistence Paradox)“的认知原理当k1k 1k1时存活越久的记忆衰减速率反而越低——存活时间本身就成为重要性的证据越老的记忆越难被遗忘。这与人类记忆的幂律遗忘一致老记忆越来越坚固”。当k1k 1k1时恰好相反存活越久越容易被清除。因此 memory-lancedb-pro 对重要记忆倾向使用k≤1k \leq 1k≤1利用持久性悖论让经过时间考验的记忆自动晋升为不可遗忘。这与艾宾浩斯遗忘曲线同属时间指数族函数——并非巧合而是因为两者都在描述同一个认知现实遗忘不是匀速的它是前快后慢的。围绕 Weibull 衰减还有一套完整的演化机制三级记忆晋升Peripheral外围 → 很少被用到↔Working活跃 → 近期常用↔Core核心 → 被反复证实的重要记忆访问强化类似间隔重复学习每次被召回都延缓衰减曲线——对应认知心理学中的提取练习效应重要性调制半衰期Core级记忆的λ\lambdaλ可达Peripheral的 10 倍以上智能遗忘噪声记忆不被调用 → 衰减分数持续下降 → 最终被清理无需手动删除So What这套机制解决了无限积累 vs 有限窗口的核心矛盾——不是记住一切而是记住对的东西、忘掉该忘的东西。这正是人类记忆的工作方式你不记得上周三午餐吃了什么低重要性 无后续强化但你记得十年前学会骑自行车高重要性 反复练习。[准确性] [成本]3.2 路径 BAgent 自主写入路径Self-Modification这条路径代表 OpenClaw 最独特的记忆机制——Agent 能改写自己的指令。场景你第三次对 Agent 说“用 tabs 不要 spaces我说过多少遍了”用户的沮丧说明了一个问题向量记忆路径 A是概率性召回的——有时被检索到注入提示词有时不会。对于这种高频、关键、确定性的偏好有一种更好的记忆方式。执行流程Agent 读取当前AGENTS.md行为指令/USER.md用户画像判断应写入哪个文件——代码风格偏好属于行为指令写入AGENTS.md在文件中添加一行- Code style: always use tabs for indentation, never spaces保存文件 → Gateway 检测变更 →触发热重载从此所有会话包括 Slack、CLI 等不同渠道自动生效从第 4 步开始Agent 的行为就永久性地改变了。它不需要检索数据库来想起这条偏好——偏好已经成为系统提示词的一部分每次调用都会被看到。为什么这比向量记忆更强维度向量记忆路径 A自修改路径 B生效方式被检索到才注入概率性永远注入系统提示词确定性编辑主体自动化管线Agent 自主判断适用场景大量零散事实高频、关键、确定性的偏好认知科学类比程序性记忆隐式习惯陈述性记忆显式知识¹¹ 注路径 B 内部包含两种认知模式——编辑 AGENTS.md/USER.md 属陈述性记忆显式可读的偏好知识创建 Skills 则属程序性记忆参见 §2.2 认知科学对照表。此处取主要机制。并发安全Gateway 作为单一控制平面协调写入防止多 Agent 同时改同一文件产生冲突写后读一致性保证热重载完成后才确认写入成功Skills 创建——记忆的最高形态Agent 不仅能记住偏好还能从对话中提炼可复用工作流发现用户反复执行拉分支 → 改代码 → 跑测试 → 提 PR流程自动创建 Skill 写入~/.openclaw/workspace/skills/skill/SKILL.md热加载后成为永久能力——对应认知心理学中的程序性记忆从知道怎么做到不用想就能做Skills 生命周期阶段行为类比创建Agent 在对话中识别可复用模式 → 写入 SKILL.md你第一次学会骑自行车发现热重载后自动注入同 Workspace 命名空间可被所有 Agent 发现肌肉记忆随时可调用演化Agent 可修改已有 Skill 文件以改进流程越骑越熟练弃用用户或 Agent 删除 SKILL.md目前无自动弃用机制技能遗忘目前需手动版本控制同 Workspace 文件可git init后跟踪变更历史记录每次改进So What路径 A 让 Agent “记住你说过什么”路径 B 让 Agent “变成你想要的样子”。前者是记忆后者是学习。路径 A 积累的是数据路径 B 积累的是能力——这是两种截然不同的记忆形态相互补充而非替代。[可控性] [准确性]3.3 路径 C主动记忆路径Proactive Pipeline以社区项目 memU13k Star为代表。在 Locomo 长对话记忆基准测试中报告准确率 92.09%来源memU README同一基准上基线 RAG 方案约 72%纯 LLM 无记忆约 58%——具体数字需以 memU 团队发布的对比表为准。路径 A 和 B 都有一个共同特点被动。用户说了什么Agent 才处理什么。路径 C 颠覆了这个模式。路径 A vs 路径 C 的本质区别路径 A被动路径 C主动触发时机对话结束后全时段后台监控提取范围当前对话内容跨对话、跨渠道、跨时间段目标存储事实预判需求、主动行动认知科学类比海马体记忆巩固睡眠后整理前额叶执行功能主动规划双 Agent 协作模型memU 引入了一个精巧的架构——两个 Agent 分工协作Main Agent处理用户请求、执行任务MemU Bot后台运行的记忆管家——持续监控、提取、预判这种分离确保了记忆处理不干扰主交互的延迟同时让记忆管理可以更深入——MemU Bot 有足够的计算预算来做跨对话的模式识别和预测。主动记忆循环四步闭环监控(Monitor)观察所有 Agent 的输入输出流记忆化(Memorize)实时提取洞察 → 分层存储Resource → Item → Category 三级结构预测(Predict)基于历史记忆模式预判用户下一步需求行动(Act)预取上下文 / 推送建议 / 自主更新待办事件驱动——记忆的外部触发路径 C 的另一个关键能力是事件驱动的记忆更新触发机制场景记忆影响Cron Jobs每日 9:00记忆整理、日报生成、主动推送今天有 3 个待办Heartbeat每 4 小时Agent 主动 check-in检查用户日历/邮件/代码变更WebhookGitHub Push 事件自动更新项目记忆“main 分支新增了 auth 模块”Gmail Pub/Sub新邮件到达学习沟通模式、检测日程冲突、草拟常规回复想象这个场景你没有和 Agent 说任何话但你的 GitHub 收到了一个新的 Pull Request。Webhook 触发后Agent 自动阅读 PR 内容更新自己对项目状态的记忆甚至在你下次问项目最近有什么变化时不需要再去查——它已经知道了。So What主动记忆将 AI 助手从工具变成了伙伴。工具是你用的时候才有用伙伴是一直在帮你想事情。这区分了记忆能力capability存得准、取得快和记忆体验experience感觉它真的认识你。前者是技术问题后者是产品问题——路径 C 同时解决了两者。[召回率]3.4 小结三条路径的协同——记忆三原力 (Memory Triad)三条路径不是三选一的关系它们在不同维度上互相补强路径 AAuto-Capture→ 广度积累海量零散记忆 路径 BSelf-Modification→ 深度固化关键决策为永久指令 路径 CProactive→ 主动性将记忆转化为主动行动 ↓ 三原力协同 ↓ 一个不断学习、持续进化、永远在线的个人 AI路径 A 提供了广度——任何值得记住的对话内容都会被捕获。路径 B 提供了深度——最重要的偏好和能力被固化为确定性指令。路径 C 提供了主动性——记忆不再是被动的数据库而是驱动行为的引擎。缺少任何一条系统都不完整只有 A 是无脑存储只有 B 是手动配置只有 C 是空转监控。三原力的价值在于闭环。一个真实的场景你在 某工具上随口提到下周一有个重要的项目演示路径 A 捕获为events类记忆。Agent 把你的演示偏好写入AGENTS.md——“准备 PPT 时使用深色主题”路径 B。周一早上 9 点Agent 通过 Heartbeat 检测到日历事件主动推送今天有项目演示需要我帮你准备什么吗路径 C。三条路径一个最终效果AI 真正记住了你。▲ Part 1 结束 ·至此你已了解 OpenClaw 三层记忆模型及其运作方式。以下 Part 2 从设计哲学、故障分析、经济学、竞品对比等角度深入评估。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2480141.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!