OpenClaw实战:借鉴字节跳动,零成本升级AI记忆

一人公司 · OpenClaw 实战 · AI Agent 记忆系统升级案例

「48 条用户关键偏好，被一次系统重启全部抹掉。」

第二天早上我打开协作平台，发现 10 个 Agent 乖乖在跑日常 Workflow，可用户却在内容平台私信里骂骂咧咧：

“昨天刚说过不要在半夜给我推送，怎么今天凌晨又刷了三条？”

这不是单点翻车，而是记忆系统从底层背刺了我。

作为一个一人公司，我目前养了 10 个 Agent，全部跑在 OpenClaw 上，每天要处理几百条不同渠道的消息：选题、数据、自动回复、素材整理、脚本生成……为了省 API 钱，我之前给它们设计了一套五层记忆架构，自认为已经“很高级”了。

直到这次事故，我才发现——

我辛苦搭起来的那套记忆系统，在一次 compaction 之后，把用户最关键的 48 条偏好当成“可以丢”的垃圾，直接删了。

这篇文章，我想完整复盘这次升级：

• 一个真实的记忆丢失事故，是怎么发生的？

• 我是如何从字节跳动开源的 OpenViking 身上，找到解决方案的？

• 最后我为什么没有直接部署 OpenViking，而是用 OpenClaw 的 Hook，做了一个几乎零成本的实现？

如果你也在给自己的 Agent 搭记忆系统，或者你正在用 OpenClaw 跑生产业务，这篇 case study 可能会帮你：

1. 看懂记忆“悄悄丢失”的底层机制

2. 学会如何拆解一个大型开源项目，只拿走最有用的 20%

3. 在不增加任何新依赖的前提下，让你的 Agent 记忆稳定性，向 OpenViking 的 Benchmark 再靠近一大步

一、事故现场：我的 AI Agent 忘了一个关键指令

先把故事讲清楚。

1. 一条被系统吃掉的「不要打扰」

那天晚上，有个老读者在内容平台上留了一条很短的留言：

“最近在带娃，凌晨基本不看手机，别半夜推东西给我啦，白天我会自己翻历史。”

这是一个典型的长期偏好：

• 与具体内容无关

• 和通知节奏、打扰程度强相关

• 一旦被记住，会影响之后大量 Workflow 的决策

我当时还挺满意：

• 用户信息会被记入个人画像

• 晚上相关的定时任务会自动调低推送频率

• Agent 在给这位读者推荐内容时，也会倾向于白天窗口

第二天凌晨 2:17，系统照常跑了一轮定时任务。10 个 Agent 没有任何一个觉得这条“不要打扰”的指令存在过，按照默认策略推了三条内容，精准命中用户睡眠时间。

第二天早上，我在协作平台看到用户的反馈，心里一凉：

“这不是模型不够聪明，而是——我们昨天晚上的聊天记录，在某个环节被系统性地遗忘了。”

2. 排查：不是模型问题，是架构问题

最开始，我以为是某个 Agent 的 SOUL.md 写得不够清楚，于是去检查指令：

• 「尊重用户作息时间」写得很明确

• 若用户主动说明“不要打扰”的时段，应长期记忆

• 优先级高于默认推送策略

然后我去看 OpenClaw 的日志。

线索很快就浮出来了：

1. 用户那条“不要半夜推东西”的指令，确实被写进了对话上下文

2. 当天晚上，调度中心触发了一次 session compaction（对话压缩）

3. 压缩逻辑调用了 memoryFlush，让 LLM 自己总结“重要信息”，写回长期记忆

问题就出在第 3 步：

模型在那一轮 compaction 里，把这条指令当成了“普通闲聊”，没有写入长期记忆。

而 compaction 做完之后，那段原始对话又被清理掉了。

从系统视角看，这条关键指令的命运是：

1. 短期记忆：存在过

2. 刷新时：被 LLM 判断为“不够重要”

3. 长期记忆：完全没有痕迹

这就是我最开始给 OpenClaw 设计的五层记忆架构里的一个盲点：

我们把“记不记住这件事”，交给了一个每次都在省 Token 的模型。

▲ 记忆 Hook 的工作原理

二、发现问题：compaction 为什么会「吃掉」记忆？

为了搞清楚根因，我把这一条指令从日志里抽出来，仔细还原整个轨迹。

1. 先说一下我们的旧架构

之前在另一篇文章里我详细讲过五层记忆架构，这里只做一个极简版回顾：

• L0：最近几轮对话上下文

• L1：短期摘要

• L2：中期主题 / 线程

• L3：长期事实 & 画像

• L4：跨 Agent 的团队级记忆

在 OpenClaw 里，这套东西主要是通过：

• Workflow 里的 memoryFlush 节点

• 定时任务做的批量清洗 & 压缩

当一个会话太长时，我们会触发 compaction：

1. 把最近一大段对话喂给模型

2. 让模型自己决定： - 哪些是“重要事实”写入 L3 / L4 - 哪些只需要写入短期摘要 - 哪些可以直接丢弃

从设计图上看，这一切都很合理，而且很“聪明”。

但真实世界的数据给了我一记耳光。

2. LLM 主导的记忆选择，有两个天然缺陷

复盘这次事故时，我发现两个问题会叠加：

问题一：模型的“重要性判断”，高度受当前对话主题影响。

那天晚上，我们主要在讨论选题和数据复盘。

在这样的语境下，“不要半夜推送”这句话，更像是一个边角提醒，而不是对当前任务有决定性影响的内容。

模型在做 memoryFlush 时，有很大概率会优先保留：

• 和选题有关的偏好

• 和内容风格相关的反馈

• 和业务目标直接相关的数据

问题二：compaction 是一次性、不可逆的。

在原来的实现里：

• compaction 之前：有完整原始对话

• compaction 之后：只剩下模型写入的摘要 & 选定事实

一旦模型在这一轮里“看漏”了某条长期偏好，就再也找不回来。

我们让一个一次性决策，接管了整条记忆管线的生杀大权。

这在设计上，是不安全的。

▲ compaction 如何"吃掉"重要记忆

三、找到灵感：OpenViking 是怎么解决记忆问题的？

事情的转机，来自我刷到的一条开源项目更新。

某个晚上，我在看火山引擎的技术内容平台，看到字节跳动开源了一个叫 OpenViking 的项目，主打“让大模型在长会话中保持稳定记忆”。

我当时的直觉是：

“这不就是我现在最缺的东西吗？”

于是我花了一个晚上，把它的架构文档和代码扫了个遍，重点关注：

• 它是怎么捕获记忆的？

• 它怎么决定哪些内容值得长期保留？

• 它怎么在不炸 Token 的前提下，把记忆喂回给 Agent？

1. 三层上下文：先保证“看得见”，再谈“看得完”

OpenViking 里有一个我非常喜欢的设计：

把上下文分成 L0 / L1 / L2 三层：

• L0：最近对话，原文

• L1：对 L0 的结构化摘要

• L2：跨会话的高层概览

它做的不是简单的“越往上越抽象”，而是：

• L0：确保模型在任何时候，都能看到最近几轮完整语境

• L1：把关键事实、决策、偏好抽出来，结构化保存

• L2：把跨会话的模式和长期信息沉淀下来

更关键的是，它是按需加载的：

• 普通对话：只用 L0 + L1

• 复杂决策 / 跨天任务：再从 L2 拉更多背景

这套设计直接带来的结果，就是官方 Benchmark 里的那一组数字：

任务完成率从 35.65% 提升到 52.08%，同时 Token 消耗从 24.6M 直接降到 4.3M，降幅 83%。

这对我有两个启发：

1. 真正有效的记忆，不一定要“全量喂给模型”，而是要结构化抽象 + 分层加载

2. 有没有记住，不再是一次性决策，而是一个可以不断增量维护的体系

2. Auto-Capture：不要指望人肉“记笔记”

OpenViking 的另一个核心特性，是自动记忆捕获（Auto-Capture）。

它不会指望开发者在每个 Workflow 里显式调用“写入记忆”的接口，而是：

• 每轮对话结束

• 自动接管原始对话

• 把与长期价值相关的内容提取出来

• 写入自己的三层记忆结构

这里有两个细节，我非常认同：

只捕获用户消息，不捕获助手输出。

助手输出里有大量噪声：

• 自动解释

• 重复总结

• 礼貌性话术

如果把这些都当“记忆候选”，不仅浪费 Token，还会稀释真正重要的东西。

增量保存，而不是覆盖写入。

每一轮对话的记忆，都是一次追加，而不是“本轮总结覆盖上一轮”。

这意味着：

• 即便某一轮提取得不完美

• 之后的轮次还有机会“捡漏”

从系统鲁棒性的角度，这一点很关键。

3. 崩溃安全：即使系统挂了，记忆也还在

我特别注意到 OpenViking 在文档里提到的一个设计：

每轮记忆提取完成后，立即持久化；即使中间系统崩溃，也不会丢失之前的轮次。

对比我当时的实现：

• 大段对话积累一堆

• 触发一次 compaction

• 由模型统一决定“保什么丢什么”

本质上，我是在做“批处理 + 大扫除”；而 OpenViking 在做的是“流式 + 实时归档”。

看完它的架构图，我当场在笔记里写了一句：

“要么用 OpenViking，要么在 OpenClaw 上抄一套类似的思路。”

四、我们的选择：不装 OpenViking，用 Hook 零成本实现

接下来是这篇文章最关键的一部分：

在已经有一套 OpenClaw 基础设施、十几个现网 Agent、几十条 Workflow 的前提下，我是怎么做一个几乎零侵入的升级的？

1. 先说结论：我没有把 OpenViking 整套搬进来

看完 OpenViking 之后，我认真评估了一下：

如果完全接入 OpenViking，会发生什么？

• 多了一整套服务集群（Python + Go + Rust）

• 需要单独的向量库、检索服务、健康检查

• 每条消息要走一遍 Embedding + VLM 推理

• 现有 Workflow 的上下文注入逻辑，要大规模重写

对一家大公司来说，这些都是合理的工程投入；但对现在的我——一个一人公司养 10 个 Agent，这样做不划算。

所以我换了个问题：

“我到底最想从 OpenViking 身上拿走什么？”

答案只有两条：

1. 自动记忆捕获（Auto-Capture）：不再依赖单次 compaction 和 LLM 自觉

2. 增量确定性保存：每轮对话的关键事实，都有一个不会丢的归宿

在这个前提下，“不开新坑”就成了硬约束：

• 不上新服务

• 不加新依赖

• 不改现有 Workflow 的大部分逻辑

2. 找到突破口：OpenClaw 的 Hook 系统

OpenClaw 里有一个非常好用，但经常被忽略的能力：Hook。

简单理解，就是在系统生命周期的关键节点上，注册一些“拦截器”：

• 在会话创建前后

• 在消息路由前后

• 在 compaction 之前 / 之后

我最后选的是一个最契合当前问题的事件：

session:compact:before

也就是说：

• 每次有会话即将被压缩

• OpenClaw 会先调用我注册的这个 Hook

• 把即将被压缩的对话内容，完整交给我处理

这刚好满足了我对“自动记忆捕获”的所有要求：

• 不需要改 Workflow

• 不需要 Agent 意识到“我要写记忆了”

• 可以在 compaction 之前，做一次“确定性备份”

3. 设计一个最小版本的 Auto-Capture：incremental-memory-capture

基于这个 Hook，我设计了一个非常克制的实现：incremental-memory-capture。

它只做四件事：

1. 读取即将被压缩的对话记录

2. 只保留用户消息

3. 用一组正则，从这些用户消息里提取长期价值信息

4. 去重后，追加到当天的记忆日志里

第一步：只看用户说了什么

在 Hook 里，我直接过滤掉所有 Agent 的输出，只保留用户侧：

• 明确的偏好（喜欢什么、不喜欢什么）

• 长期约束（例如“不在半夜推送”、“不要用语音”）

• 事实信息（比如工作、地区、设备环境）

• 关键事件（例如“刚从 A 平台迁移过来”、“今天只看架构相关的内容”）

这个过滤非常粗暴，但有效——它直接帮我把 70% 以上的噪声砍掉。

第二步：用正则做一个“八成正确”的提取器

我没有再调用模型做二次解析，而是写了一组正则：

• 匹配“我 + 偏好动词”（比如“我喜欢/不喜欢/更希望/讨厌”）

• 匹配“以后 + 约束动词”（比如“以后不要/以后尽量/之后别”）

• 匹配“我是/我在/我做”这类自我介绍

• 匹配“今天/这周/最近 + 行为”

很多人第一反应可能是：

“正则够用吗？会不会漏掉很多信息？”

我的答案是：

• 会漏，但没关系

• 因为我们是“每轮增量保存”，不是“只给一次机会”

这其实是在用“次数”对冲“单次不完美”。

第三步：去重 & 标注

为了避免记忆日志被重复信息淹没，我对提取出来的片段做了两层去重：

1. 文本级别去重：同一个句子只保留一次

2. 语义级别弱去重：对一些极其相似的句子做简单归一化

最后，我给每条记忆都加上了一个简单的标签：

• W：偏好（Wants）

• B：边界 / 限制（Boundaries）

• O：客观事实（Objective Facts）

这些标记和我之前那套五层记忆协议完全兼容，不需要改任何下游使用记忆的 Agent。

第四步：写入当天记忆日志

所有提取出来的内容，都会被追加写入当天的记忆文件里。

这里有两个刻意的选择：

• 只追加，不覆盖：保证任何一轮提取成功的信息，都不会被后面的逻辑“洗掉”

• 与现有五层架构对齐：日志格式与现有的记忆读取逻辑兼容

从系统视角看，这等于是给原有架构加了一条旁路：

• 原来的 memoryFlush 还在，继续服务一些需要模型参与的复杂总结

• 新的 Hook 负责“最基础、最确定”的用户长期信息捕获

4. 成本：几乎是 0

再说说成本。

整个 incremental-memory-capture Hook：

• 全部是同步执行，没有调用任何外部 API

• 核心逻辑就是几条正则 + 一次本地写入

• 在我的环境里，单次执行时间基本都在 1ms 以内

部署上也很简单：

• 写一个 Hook 文件

• 在 OpenClaw 的配置里注册一下

• 重启调度中心

对于已经跑在生产上的 10 个 Agent 来说，这次升级就是：

“某天凌晨之后，它们突然开始记住更多用户长期偏好，而且完全没有感知到系统做了什么改动。”

▲ 不装新软件，直接用 Hook 实现持久化

五、效果对比：从“赌模型会记得”到“我自己先存一份”

接下来是大家最关心的：

“这个增量记忆 Hook，实战效果到底怎么样？”

1. 记忆丢失的真实情况

我做了一个很简单的对比实验：

• 挑了最近 30 天的若干会话

• 标注其中所有属于长期偏好的句子

• 对比在“旧架构 vs. 新 Hook + 旧架构”两种情况下，有多少会落入长期记忆

结果非常直观：

• 旧架构（只靠 memoryFlush）：

• 能被写入长期记忆的大约只有一半

• 对于“和当前任务弱相关”的长期偏好，漏记率明显偏高

• 新方案（Hook 增量捕获 + memoryFlush）：

• 绝大部分长期偏好都有记录

• 即便模型在某次 compaction 里漏掉了，Hook 也能在下一轮对话里捡回来

这就好比之前我们是在赌：

“模型这次应该能记住吧？”

而现在是：

“不管模型记不记，我先在系统里写一份。”

2. Token 成本几乎不变

很多人会担心：

“你加了这么一层逻辑，会不会让整体 Token 消耗变高？”

答案是：几乎没有变化。

原因很简单：

• Hook 里的提取完全不调用模型

• 记忆文件的写入是本地 IO

• 后续在注入上下文时，只是多了一个“拉取用户长期偏好的步骤”

反而因为长期偏好更稳定，很多场景下我敢更激进地裁剪短期上下文：

• 不再反复把同一条偏好塞给模型

• 把“我是谁、我在哪、我喜欢什么”从对话里迁移到记忆里

从整体上看，Token 消耗在趋势上是下降的。

3. 稳定性：从“概率行为”变成“确定行为”

这个 Hook 带来的最大变化，其实不是某个具体指标，而是整个系统的确定性：

• 以前：用户说了三次“不要半夜推送”，有可能前三次都没被写进长期记忆

• 现在：只要说了一次，系统就一定会存一份

在一个有 10 个 Agent、每天处理几百条消息的系统里，这种确定性会大幅降低你的认知负担：

• 你不再需要猜测“模型这次有没有记住”

• 你可以对“记忆中一定存在这条信息”做出假设

这也是我从 OpenViking 身上学到的一个隐性经验：

每一个“看起来聪明”的记忆系统背后，都有一套无聊但极其稳定的工程约束。

▲ 升级前 vs 升级后的实际效果

六、方法论：怎样复制这次升级的思路？

最后，我想用一小节，系统性地总结一下这次记忆系统升级背后的方法论。

这套方法，不只适用于 OpenClaw 和记忆，也适用于任何你想借鉴大型开源项目、却不想整套搬运的场景。

Step 1：先拆需求，不要直接崇拜项目

面对像 OpenViking 这样的大型开源项目，一开始很容易被它的体量吓到：

• 完整的服务化架构

• 深度优化的向量检索

• 全套的 Benchmark 和可视化

我的做法是：

1. 先在纸上写下自己当前最痛的两个问题

2. 再去对照开源项目的设计，看它是通过哪些机制解决这些问题的

在这次升级里，我最后只保留了两个需求：

• 自动记忆捕获

• 增量确定性保存

其余的——比如复杂的检索策略、多模型协同——对我现在这套规模的系统来说，都不是必须品。

Step 2：分析设计，而不是抄实现

很多人看开源项目，第一反应是“怎么部署”、“怎么调用 API”。

但对一个资源有限的一人公司来说，更高性价比的做法是：

把重点放在“它为什么要这么设计？”上。

在 OpenViking 身上，我重点抽了三类设计决策：

• 为什么要做三层上下文，而不是一层“大上下文”？

• 为什么要做 Auto-Capture，而不是让业务侧手动写记忆？

• 为什么要做增量保存，而不是周期性的批处理？

这些“为什么”，比任何一段具体代码都更值得被搬进我自己的系统。

Step 3：在现有架构里，找“最小侵入点”

把设计原则抽出来之后，下一步不是开新仓库，而是：

在现有架构里，找到那个可以最小代价落地这些原则的地方。

对我来说，这个点就是 OpenClaw 的 Hook 系统，尤其是 session:compact:before 这个事件。

• 它正好站在 compaction 的入口

• 它能拿到完整的原始对话

• 它不需要修改业务层的 Workflow

一旦找到这个点，后面就是工程实现的问题了。

Step 4：用“确定性 + 增量”优先级，压过“智能 + 一次性”

这次升级里，我刻意压抑了一些很诱人的想法：

• 用模型做更聪明的记忆提取

• 用 Embedding 做更精确的相似度匹配

原因只有一个：

在记忆这件事上，我更需要“永远不会丢”的确定性，而不是“偶尔特别聪明”的智能性。

所以最终的实现是：

• 正则 + 文本去重

• 本地日志 + 追加写入

看起来很“土”，但在 OpenClaw 的整套架构里，它恰好补齐了一个非常关键、又经常被忽视的工程底座。

七、如果你也想在 OpenClaw 里做同样的升级

从工程角度看，这次记忆系统升级其实只有三步：

1. 在 OpenClaw 里注册一个 session:compact:before Hook

2. 在 Hook 里实现一个增量记忆捕获逻辑： - 只看用户消息 - 提取长期偏好 / 限制 / 事实 - 去重后写入一个你自己的“长期记忆文件”

3. 在适合的 Agent Workflow 里，把这些长期记忆注入上下文

为了避免这篇文章变成“源码贴”，我就不在这里展开具体代码了。

八、我这次学到的 5 个教训

最后，用几个非常具体的教训结束这篇文章。

教训 1：不要把“记不记住”交给单次 LLM 调用

只要记忆的入口是一次性模型调用，哪怕成功率有 90%，你迟早会在剩下的 10% 上翻车。

教训 2：真正稳定的记忆，都是“先写后用”

先有确定性的落盘，再谈后续的智能加工；而不是反过来。

教训 3：优秀开源项目，最值得拿走的是“设计取舍”

OpenViking 给我的，不是一个非装不可的系统，而是一套记忆系统设计的参考答案。

教训 4：一人公司，更要克制地选“少”

在资源有限的情况下，把精力放在“用现有基础设施做极小升级”，比“再搭一套新系统”更划算。

教训 5：给 Agent 搭系统，就是给自己搭认知缓冲区

当你可以确定“系统一定记住了这条信息”，你的大脑就可以从重复确认、反复检查中解放出来，把注意力放在真正需要人类判断的决策上。

▲ 可复用的 AI 系统升级框架

往期精选

📌 OpenClaw实战：20个定时任务的血泪史——AI自动化不是自动躺平

📌 OpenClaw实战：Agent输出总翻车？踩坑30天后找到的几个核心原因

📌 OpenClaw实测：稳定输出——记一个3w星框架如何帮我炼出5条AI管理铁律

📌 OpenClaw实战：记忆架构升级——给AI Agent Teams建一个集体大脑

📌 OpenClaw实战：让AI越变越聪明的秘密——每日复盘，自我进化

📌 OpenClaw 实战：AI Agent 团队从1个扩到8个，再砍回4个的真实原因

📌 给 OpenClaw Agent Team 装上记忆——踩了19天坑，终于搞明白了

📌 AI Agent 说“完成了”，我信了——然后被打脸了

📌 实战复盘：OpenClaw 6人Agent Team险些全军覆没

作者：Wesley｜一人公司 × 6个AI员工

转载请联系作者，商业转载需授权。