为什么源代码重要
营销文案告诉你产品想成为什么。源代码告诉你它实际是什么。随着 OpenClaw 在 2026 年 2 月超过 100,000 个 GitHub 星标，我们决定做任何负责任的技术分析师应该做的事：阅读代码。
以下是对 OpenClaw 记忆子系统的逐行分析。我们检查了记忆如何存储、如何提取、如何检索，以及代码揭示了系统设计哲学和局限性的什么。
这不是批评。OpenClaw 的记忆系统在其预期目的上是精心设计的。但理解代码做什么和不做什么，对于决定其内置记忆是否足够的团队至关重要。
仓库概览
OpenClaw 的记忆系统位于主仓库的专用模块中。记忆相关代码约 3,200 行 TypeScript，分为四个主文件：memory-store.ts、memory-extractor.ts、memory-retriever.ts 和 memory-index.ts。
代码库非常干净。函数命名良好，副作用隔离，数据流易于跟踪。这不是匆忙开源的原型。
记忆模块依赖最小：better-sqlite3、分词器和 LLM 客户端。没有外部记忆服务、向量数据库或云 API。
记忆目录结构
OpenClaw 在每个项目根目录创建 .openclaw/memory 目录。记忆组织为三个子目录：facts/、daily/ 和 meta/。
facts/ 中的每个记忆文件遵循一致的命名模式：{timestamp}-{slugified-summary}.md。这种命名约定使记忆按时间可浏览、按主题可搜索。
daily/ 目录包含每个活跃会话一个文件，按日期命名。这些文件捕获会话级上下文。
MEMORY.md 格式
每个记忆文件使用 YAML 前端元数据后跟 markdown 内容。前端元数据包括：时间戳、类别、置信度、源对话回合和标签。
正文是自由格式的 markdown，通常 1-5 句话。提取管道生成内容，以简洁、独立的陈述为目标。
格式中值得注意的缺失：记忆类型（所有记忆共享相同格式）、时间关系、冲突标记和溯源链。
每日笔记系统
每日笔记系统是 OpenClaw 最优雅的功能之一。在每个会话开始时，系统创建（或追加到）一个每日笔记文件。
每日笔记与事实记忆的目的不同。事实记忆捕获持久的、可重用的知识。每日笔记捕获临时的、上下文相关的信息。
实现很直接：每个对话回合结束时，提取管道向当前每日笔记追加一行摘要。会话结束时，生成摘要段落。
记忆提取管道
提取管道是 OpenClaw 记忆系统的核心。它在每个对话回合后运行，分析交流以找到值得持久化的信息。管道由三个阶段组成：分类、提取和去重。
分类阶段使用轻量级提示让 LLM 确定对话回合是否包含持久信息。这种二元分类防止记忆存储被噪音淹没。
提取阶段获取分类为正的回合并生成结构化记忆条目。LLM 提取具体事实、分配置信度分数、生成标签并写入 markdown 内容。
实体识别
OpenClaw 的提取管道包含基本的实体识别——识别对话中提到的人物、技术、项目和组织。
实体识别是基于提示的，而非使用专用 NER 模型。这种方法比基于模型的 NER 更简单灵活，但一致性较差。
基于提示方法的一个局限是缺乏实体消解。"React"、"ReactJS"和"React.js"被视为不同实体。
SQLite 索引层
SQLite 数据库作为 markdown 文件存储之上的性能层。它索引记忆元数据并使用 FTS5 扩展提供全文搜索。数据库还存储预计算的嵌入向量用于语义搜索。
模式很直接：memories 表、tags 表和 FTS5 虚拟表。
SQLite 方法非常适合本地优先架构。如果索引损坏，可以从 markdown 源文件重建——文件是真实来源，不是数据库。
检索架构
当新对话开始时，检索系统从记忆存储中组装相关上下文。检索分三遍：近期性、相关性和频率。
三遍方法产生候选记忆的排序列表。系统选择前 N 条记忆并格式化为 LLM 提示的上下文。
一个值得注意的设计选择：检索系统不区分记忆类型。偏好、事实、决策和背景细节在同一尺度上排名。
混合搜索策略
相关性遍使用混合搜索策略，结合关键词搜索（FTS5）和语义搜索（嵌入余弦相似度）。两种方法的分数归一化后以可配置的权重组合。
语义搜索的嵌入模型可配置，默认使用无需网络访问的轻量级本地模型。
搜索实现优雅地处理了冷启动问题。当记忆存储为空或很小时，系统回退到注入项目的简单摘要。
记忆生命周期
OpenClaw 实现基本的记忆生命周期：创建、检索和删除。没有自动更新、过期或整合。
缺乏自动更新是显著的。如果用户的偏好改变，提取管道创建新记忆而不修改或取代旧记忆。两条记忆在存储中共存。
没有记忆整合——定期审查记忆、合并相关记忆、解决冲突和综合更高级模式的过程。
优势：代码做对了什么
代码揭示了几个真正的优势。源和索引的分离使系统具有弹性。提取管道的分类阶段有效防止了记忆膨胀。混合搜索策略提供了出人意料好的检索质量。
每日笔记系统值得特别提及。它优雅地解决了"会话连续性"问题而不会过载永久记忆存储。
代码还展示了出色的工程纪律。错误处理彻底，SQLite 操作使用适当的事务，提取管道包含 LLM 失败的重试逻辑。
局限：代码揭示了什么
代码也揭示了特定局限性。缺乏记忆类型意味着检索系统无法优化查询。时间索引的缺失意味着基于时间的查询退化为扫描和过滤操作。
提取管道中的去重逻辑是基于相似度的：如果新记忆与现有记忆相似度超过 85%，就会被丢弃。这对完全重复有效，但会遗漏语义更新。
缺乏溯源追踪意味着无法以编程方式将记忆追溯到其源对话。
缺失的支柱
阅读代码明确了生产记忆用例缺失的内容。三个架构支柱缺失：计算、外部数据补充和多智能体协调。
这些不是可以增量添加的功能。它们需要对记忆格式、存储层和检索层进行架构变更。它们代表了不同类别的记忆系统。
这不是对 OpenClaw 的批评——这是对开发者工具和记忆基础设施之间边界的描述。
MemoryLake 如何互补
OpenClaw 和 MemoryLake 之间最自然的集成是通过 MCP。OpenClaw 的记忆系统处理面向开发者的体验。MemoryLake 处理基础设施。
在这种架构中，OpenClaw 继续存储本地 markdown 文件以保持透明性和可编辑性。但在幕后，每条记忆也存储在 MemoryLake 中，具有完整的类型化、溯源和时间元数据。
这种互补架构是我们推荐给喜欢 OpenClaw 开发者体验但需要生产级记忆的团队的方案。你不需要在二者之间选择。
结论
阅读 OpenClaw 的源代码证实了其流行度所暗示的：这是一个精心设计的系统，真正解决了面向开发者的 AI 记忆问题。
代码也证实了 OpenClaw 的设计边界。类型化记忆、时间索引、冲突检测和溯源追踪在架构上是缺失的——不是作为 bug 而是作为设计范围决策。
OpenClaw 代表了当今最好的面向开发者的 AI 记忆。MemoryLake 代表了最深层的记忆基础设施。两者共同提供了完整的解决方案。