最近我花了不少时间研究 OpenClaw 的源码，想搞清楚一个问题：

为什么它能做到让 AI 记住这么多事，还能保持响应流畅，甚至能主动联系用户？

答案就藏在三个核心模块里：记忆管理、上下文管理和主动性设计。

今天把我的学习笔记整理出来，分享给正在做 AI 产品的朋友们。

一、记忆模块：不只是存数据，而是会思考的存储

OpenClaw 最让我意外的是它的记忆存储方式，就是一个普通的 Markdown 文件。

没有复杂的数据库，没有向量数据库的运维负担。每个 md 文件就是一条记忆，内容就是普通的自然语言文本。

这个设计太聪明了，因为它人类就可以直接读取、检查、编辑，并且 Git 还可以追踪，这就让所有记忆的变更历史变得一目了然，当出问题的时候，直接看文件就行了。

但文件只是皮，真正的核心是怎么找到有用的记忆。

OpenClaw 的记忆检索用了混合搜索 + MMR 重排的组合拳。

混合搜索：向量搜索（语义相似）+ BM25（关键词精确匹配），权重默认 0.7:0.3。这意味着既理解你的意图，又能精准匹配专有名词、代码标识符。

MMR 重排：找到相关记忆后，还会再做一轮去重。用 Jaccard 相似度过滤掉内容太相似的记忆，确保返回的结果多样化，这样就能确保不会十条记忆都在说同一件事。。。

时间衰减：就是让记忆也会生老病死，哈哈。记忆不是越久越好，过时的信息可能反而会干扰到判断。

所以，OpenClaw 引入了时间衰减机制，最近创建的记忆得分更高，老记忆会逐渐淡忘。

但还有个特殊的设计，Evergreen 记忆不受衰减影响。比如，用户的长期偏好、核心项目信息，可以标记为常青，永远保持高权重。

记忆刷新：这是我最喜欢的设计之一。

当对话上下文接近压缩阈值时，系统会静默触发记忆刷新：把当前会话的重要信息提取出来，写入记忆文件，但不打断对话流程。

用户完全感知不到这个过程，只觉得这个 AI 真的记得我说过的话。

那你可能会想，如果嵌入服务全部不可用怎么办？这点 OpenClaw 也想到了，它会自动降级为纯 BM25 关键词搜索。

这不是报错退出，而是尽力而为。这种优雅降级的思维，也是成熟产品的标志。

二、上下文管理：AI 产品的隐形战场

上下文管理不好，用户体验就会直接崩了，要么失忆，要么报上下文太长，响应越来越慢。

OpenClaw 的上下文管理用了多层防护架构，每一层都是一道保险。

第一层，是上下文窗口守护。

实时监控上下文使用情况：

• 接近阈值时发出软警告
• 超过阈值时发出硬警告
• 开发者可以据此调整策略

这是预防层面的设计，在问题发生前就感知到风险。

第二层，是自动 Compaction。当上下文接近压缩阈值（比如 128K 窗口，阈值约 104K tokens），系统就会自动触发上下文压缩：

• 把历史对话分块
• 用 LLM 生成结构化摘要（必须包含 5 个章节）
• 检查摘要质量，不合格就重试
• 用摘要替换历史消息

还有一个关键细节，那就是摘要会精确的保留标识符，像UUID、文件路径、URL 这些关键信息不会被去掉，而是完整的保留下来。

第三层：Overflow Compaction（溢出恢复）。这是兜底层面的设计：万一压缩后还是超了怎么办？

OpenClaw 的处理非常精细：

• 精确计算溢出量：从 API 的错误信息里用正则提取具体超了多少 tokens
• 智能判断处理策略：
• 如果本次请求已经触发过 SDK 自动压缩但仍溢出 → 直接重试
• 如果压缩失败（错误信息含 compaction failed 等）→ 放弃，不无限循环
• 如果是首次溢出 → 执行压缩，传入精确的溢出量帮助决策
• 智能截断 Tool Result：如果工具返回内容太长，自动识别尾部是否有错误/结果/JSON结构，优先保留头+尾
• 重试限制：最多 3 次压缩尝试，避免无限循环

还有一个细节，那就是，每条消息的 token 数不是实时计算的，而是在首次计算后缓存。后续更新时累加或累减。这种方式既保证了精确性，又避免了重复计算的开销。

三、主动性设计：让 AI 不只是被动等待

这是让我最惊喜的部分。

很多 AI 产品只会在用户主动发起时才响应，但 OpenClaw 能主动联系用户。关键在于：它做到了主动但不打扰。

Heartbeat：周期性感知，而非定时打扰

OpenClaw 有一个心跳机制，每隔一段时间（默认 30 分钟）会自动运行一次。但它的设计非常聪明，如果检查完发现没有需要关注的事项，模型会回复一个特殊标记 HEARTBEAT_OK，系统会直接丢弃这条消息，不打扰用户。

同时，用户还可以定义一个 Markdown 文件，列出每次心跳要检查什么。一次心跳可以批量处理多项检查，而不是让用户设置 5 个独立的定时任务。

上下文感知决策：心跳运行在主会话中，拥有完整的对话历史。这意味着模型可以智能判断哪些紧急、哪些可以等待，这才是真正的智能啊。

Cron Jobs：精确定时与隔离执行

有些任务需要精确的时间点，比如，每天早上 7 点发送简报。这时候就需要 Cron Jobs了。

OpenClaw 的 Cron 设计有两个亮点：

两种会话模式：

• main 模式：在主会话中运行，保留完整上下文，适合需要与用户对话相关的提醒。
• isolated 模式：在独立会话中运行，全新上下文，适合独立任务、不同模型、避免历史污染。

自动故障处理：如果一个任务连续 3 次调度失败，会自动禁用，但会通知用户，避免静默禁用让用户困惑。

Followup Queue：用户可能发起一个耗时的后台任务，然后去做别的事。任务完成后怎么通知用户？

OpenClaw 用 Followup Queue 保存了任务的回信地址：

• 跨渠道路由：用户从 WhatsApp 发起任务，结果可以发送到 Telegram
• 线程感知：消息会回到正确的对话线程
• 智能去重：同一条消息不会重复触发

研究完这些机制，我总结出几个设计原则：

研究完这三个模块，我最大的感受是：OpenClaw 的成功不是靠某个单一技术，而是靠一系列刚刚好的决策。

决策一：简单优于强大。记忆存储选文件而非数据库，表面上看是不够强大，实际上换来了零运维成本、极高的可靠性，还有可调试性。

在 AI 产品里，可靠性往往比功能强大更重要。

决策二：多层防护优于单点完美。上下文管理没有追求一次压缩到位，而是设计了多层防护：预警层（守护）、预防层（自动压缩）、兜底层（溢出恢复）。每一层都可能不完美，但组合起来就形成了高可用的系统。

决策三：用户无感知优于显式交互。记忆刷新、上下文压缩、心跳检查都是静默进行的。用户不需要理解这些概念，只需要感受到这个 AI 真的懂我、这个 AI 会主动帮我 就够了。

好的产品设计，是让复杂的技术在背后默默工作，而用户只要享受结果就行了。

决策四：优雅降级优于失败报错。嵌入服务不可用的时候，降级为关键词搜索。压缩失败了，就尝试更大的压缩比。工具返回太长，就直接截断保留关键部分。每一处都有 Plan B，这种工程思维才是 AI 产品走向成熟的必修课。

决策五：智能判断优于机械触发。心跳不是简单的定时发消息，而是让模型自己判断要不要打扰用户。这才是真正的智能。

研究 OpenClaw 的源码让我意识到，AI 产品的竞争力，往往藏在这些看不见的地方。

因为，用户不会说“你的记忆检索用了混合搜索，真棒啊”，他们只会觉得这个 AI 真的懂我，而且不管和它聊多长多久，也从来都不会报错，还会主动跑来帮自己解决问题。

正是这些沉默的体验，才是 AI 产品的护城河。

如果你觉得有帮助，欢迎点赞分享，并关注我的后续AI应用探索，我们一起学习探讨。

感谢阅读！如果这篇文章让你也有所启发，不妨点个 「赞」 和 「在看」 或 「转发」。

如果想第一时间收到推送，也可以给我个关注～谢谢你的支持和鼓励