拆解 OpenClaw 架构（四）：70% 向量 + 30% 关键词，一套生产级记忆检索引擎¶

Ch01.1064 拆解 OpenClaw 架构（四）：70% 向量 + 30% 关键词，一套生产级记忆检索引擎¶

📊 Level ⭐⭐ | 5.9KB | entities/拆解-openclaw-架构四70-向量-30-关键词一套生产级记忆检索引擎.md

来源: 科技充电站

发布日期: 2026-03-01

原文链接: https://mp.weixin.qq.com/s/t4OzcK0zHh3Toxs5V6EQQg

AI 时代，有两种行为：

一种，活在别人的评测里，把模型的强当自己的强，痴人说梦；

另一种，活在真实的实战里，用最顶级的 AI，武装自己。

前者在噪音里坐享"技术平权"，后者在疼痛中完成"自我进化"。

朋友们好，我是行小招。

这是 OpenClaw 深度技术解析系列的第四篇。前三篇我们拆了消息流水线、人格系统和 Agent Runner，今天聊 Memory，也就是 OpenClaw 的记忆系统。

上篇结尾我提到，OpenClaw 的记忆不是传统 RAG，而是一套完整的 IR 工程。写这篇之前我其实有点犹豫，因为"记忆"这个词太容易让人想到向量数据库、Embedding、语义检索这套标准叙事。

但读完 OpenClaw 的记忆模块源码后，我发现这套系统最有意思的地方根本不在检索算法，而在一个更底层的设计哲学。

先说结论， OpenClaw 的记忆系统不用数据库做主存储。

所有记忆都是 Markdown 文件，明文存放在 Agent 的工作区目录里。

SQLite？只是一个派生的加速层。你把 SQLite 文件删了，系统会从 Markdown 文件自动重建索引。数据不会丢一个字。

这个设计选择在数据库出身的工程师看来简直是"开历史倒车"，但在 AI Agent 的场景下，它有自己的道理。

传统 RAG 把数据藏在不透明的向量数据库里。你知道数据"在里面"，但想看看具体存了什么？要写查询；想修改一条记录？要写代码；想追踪某条记忆是什么时候、因为什么事件被存进来的？祝你好运。

OpenClaw 的 Markdown 文件呢？人类可读， cat 一下就能看；Git 可版本化，谁改了什么一目了然； grep 可搜索，不用等索引构建；任何编辑器可编辑，vim、VS Code、甚至 iPhone 备忘录都行。

官方把这叫 "Memory as Documentation" ，跟传统的 "Memory as Database" 形成鲜明对比。

我觉得这个选择背后的逻辑是：对于 AI Agent 的记忆，可审计性比查询性能重要得多。

你想想，一个 Agent 替你管日程、写文档、回消息，时间长了它积累的"记忆"里会有你的偏好、你的决策模式、你跟谁聊了什么。这些信息如果藏在一个二进制的向量数据库里，你连看都看不到，更别说审计和修改。但如果它就是一堆 Markdown 文件，放在你能直接访问的目录下，安全感就完全不同了。

Milvus/Zilliz 团队后来把这套记忆架构提取成了一个独立库叫 memsearch ，让任何 Agent 都能用 OpenClaw 风格的记忆系统。一个向量数据库公司主动把"不以向量数据库为中心"的架构做成通用库推广，这本身就说明这个设计思路得到了业内认可。

OpenClaw 的记忆不是一个单一的"记忆库"，而是一套层级分明的文件体系。每个文件有明确的职责和加载规则：

文件用途加载时机

SOUL.md Agent 人格、语气、价值观、边界每次会话

AGENTS.md 操作指令、启动序列每次会话

USER.md 用户档案：名字、时区、