系列说明本系列共计 20 篇全面介绍 OpenClaw 开源 AI 智能体框架从历史背景到核心原理从安装部署到应用生态。本文为系列第 012 篇聚焦于 OpenClaw 独特的文件即真相记忆系统深入解析其上下文压缩、向量搜索等核心机制。摘要OpenClaw 的记忆系统是其区别于传统聊天机器人的核心创新之一。与依赖向量数据库存储对话历史的方案不同OpenClaw 采用文件即真相File is Truth的设计理念将所有记忆以 Markdown 文件的形式存储在本地文件系统。本文深入剖析 OpenClaw 记忆系统的工作原理包括 Memory.md 文件结构、上下文压缩机制Compaction、向量搜索功能以及会话管理策略。通过本文读者将全面理解如何利用 OpenClaw 的记忆系统实现跨会话的持续对话和个性化智能助手体验。一、文件即真相设计理念1.1 传统方案的局限性在探讨 OpenClaw 的记忆系统之前有必要回顾一下传统 AI 助手处理记忆的方式。早期的大多数 AI 聊天机器人采用简单的会话隔离模式每次对话都是独立的关闭聊天窗口后所有的对话历史就会被遗忘。如果想让 AI 记住之前的信息需要使用向量数据库如 Pinecone、Weaviate、Chroma 等将对话历史转换为向量嵌入并存储在云端然后在后续对话中通过相似度搜索检索相关历史。这种方案虽然有效但存在几个显著问题。首先是复杂性向量数据库的部署、维护和扩展都需要专业技术知识对普通用户不够友好。其次是隐私问题将对话历史存储在第三方云服务可能引发数据安全担忧尤其是在处理敏感信息时。第三是成本问题向量存储和搜索需要额外的计算资源增加了整体运营成本。第四是厂商锁定一旦选择某一款向量数据库服务迁移数据和切换供应商的成本很高。1.2 OpenClaw 的革新方案OpenClaw 提出了一个优雅而实用的解决方案将所有记忆存储在本地文件系统中。用户创建的每个会话都会对应生成一个 Memory.md 文件记录该会话的所有关键信息。这种设计有几个核心理念第一所有数据都存储在用户自己的设备上隐私安全完全由用户自己掌控第二使用人类可读的 Markdown 格式存储方便用户直接查看、编辑和导出第三无需额外的基础设施依赖降低了使用门槛第四文件格式的通用性使得数据迁移极为简单。文件即真相这一口号的含义是文件系统是所有信息的唯一真实来源。与其依赖数据库查询或者 API 调用来获取历史信息不如让用户直接读写文件系统中的 Markdown 文件。这种设计不仅简化了系统架构还赋予了用户更大的控制权。用户可以随时打开 Memory.md 文件删除不想要的记忆修改错误的记录或者添加特定的个人偏好设置这些修改会立即生效并影响后续对话。1.3 记忆系统的核心组件OpenClaw 的记忆系统由几个核心组件构成。Memory.md 是存储会话记忆的核心文件记录了用户信息、偏好设置、会话历史等关键数据。Context Manager 负责管理对话上下文的动态组装和压缩确保在有限的模型上下文窗口内传递最相关的信息。Vector Search 模块可选提供基于嵌入向量的语义搜索能力增强记忆检索的准确性。Message Store 负责持久化和管理消息历史支持会话的恢复和继续。这种模块化的设计使得各个组件可以独立演进和优化同时保持整体的协调性。用户可以根据自己的需求选择性地启用或配置各个模块。例如对于隐私要求极高的用户可以只使用基础的 Memory.md 功能而不启用向量搜索对于需要更智能记忆检索的高级用户可以配置本地 embedding 模型来实现语义搜索。二、Memory.md 文件结构详解2.1 文件格式与存储位置Memory.md 文件采用标准 Markdown 格式存储每个 OpenClaw 会话对应一个独立的文件。在默认配置下这些文件存储在用户数据目录的memory子目录中。文件的命名通常采用会话标识符如 UUID 或用户自定义名称方便用户识别和管理。一个典型的 Memory.md 文件结构包含以下几个主要部分文件头部包含会话元数据如创建时间、最后更新时间、会话状态等用户画像部分记录用户的背景信息、偏好设置、技能水平等对话历史部分按时间顺序记录所有对话内容工具调用记录部分保存 Agent 执行过的操作历史总结摘要部分如果启用了压缩功能包含早期对话的浓缩版本。2.2 用户画像与偏好设置Memory.md 中最重要的一部分是用户画像User Profile。这部分信息由 OpenClaw 自动从对话中提取并持续更新涵盖用户的基本信息、偏好设置、已知事实等多个维度。用户画像的典型内容包括基本信息如姓名、工作领域、所在时区等技术背景如编程语言偏好、技术栈熟练程度等沟通偏好如回复详细程度、是否偏好代码示例等个人习惯如常用时间段、常用渠道等。这些信息会在每次对话中自动更新和丰富使得 AI 助手能够越来越精准地理解用户提供更加个性化的服务。偏好设置部分还支持用户手动添加特定指令。例如用户可以直接在 Memory.md 中添加请始终使用中文回复或代码示例优先使用 TypeScript等指令OpenClaw 会将这些指令作为系统提示词的一部分确保用户的明确需求得到满足。2.3 对话历史的组织方式Memory.md 中的对话历史采用分层结构组织。顶层按照时间顺序记录每轮对话的用户输入和 AI 输出每条记录包含时间戳、消息内容、使用的模型、执行的工具等信息。对于包含工具调用的对话系统会详细记录工具名称、输入参数、执行结果等完整信息。这种结构化的历史记录有几个重要用途。首先它使得上下文压缩成为可能——当对话长度超过模型限制时系统可以识别出对话的关键节点生成浓缩摘要。其次它支持精确的历史检索——用户可以查找特定时间或特定主题的对话内容。第三它为调试和问题排查提供了完整的执行轨迹。三、上下文压缩机制详解3.1 问题的起源在上一篇文章介绍 Agent 循环时我们提到每次 LLM 调用都会将完整的消息历史发送给模型。随着对话的持续进行消息数组会不断增长逐渐逼近模型的上下文窗口上限。当达到上限时对话将无法继续。这就是所谓的上下文耗尽问题。传统的解决方案是简单地截断早期对话丢弃超出的部分。这种方式简单但粗糙可能导致重要信息的丢失尤其是对话早期提到的关键背景信息或用户偏好设置。OpenClaw 采用了更智能的解决方案上下文压缩Compaction。3.2 Compaction 工作原理OpenClaw 的上下文压缩机制是一种智能的记忆提炼技术。当对话长度接近上下文窗口阈值时默认设置为上下文上限的 80%系统会触发压缩流程。压缩过程分为几个步骤第一步是消息选择。系统会分析整个对话历史识别出每个消息的重要程度评分。评分算法会考虑多个因素消息是否包含用户提供的关键信息如姓名、偏好、事实等、消息是否包含重要的决策或结论、消息是否包含后续对话依赖的上下文、消息的距离越近的消息通常越重要。基于这些因素系统会选择需要保留的核心消息。第二步是摘要生成。对于被标记为可压缩的早期消息系统会调用 LLM 生成一段简洁的摘要。摘要不是简单的文本压缩而是理解消息核心含义后的重新表达。例如一段详细的代码调试过程可能被摘要为用户解决了某模块的登录问题使用了重新安装依赖的方法。第三步是上下文重组。压缩后的对话历史会重新组装为新的消息数组保留核心的原始消息作为精确参考插入摘要消息作为背景参考最后是近期的完整消息。这种结构确保了最近对话的精确性同时保留了早期对话的关键信息。3.3 压缩效果的量化评估OpenClaw 的压缩机制可以显著延长对话的有效长度。以 GPT-4o 为例其上下文窗口为 128K tokens假设每轮对话平均消耗 500 tokens包含用户输入、模型输出和工具结果不使用压缩的情况下大约可以维持 250 轮对话。启用压缩后通过将早期对话浓缩为摘要单个摘要可以压缩约 10-20 倍的信息量使得有效对话轮数可以提升到 500 轮甚至更多。更重要的是压缩后的摘要仍然保留了对话的连贯性。经过合理压缩的对话历史LLM 仍然能够理解之前讨论的上下文不会出现断片现象。这使得用户可以与 OpenClaw 进行长达数周甚至数月的持续对话而无需频繁开启新会话。3.4 压缩配置的调整OpenClaw 允许用户根据自己的需求调整压缩相关的参数。核心配置项包括触发阈值compressionThreshold控制何时触发压缩流程默认为上下文窗口的 80%压缩比compressionRatio控制每个原始消息被压缩为摘要后的目标长度比例保留策略retentionPolicy决定哪些类型的消息永远不被压缩如用户明确声明的重要信息。在auth-profiles.json中的典型配置json{“memory”: {“compressionThreshold”: 0.8,“compressionRatio”: 10,“retentionPolicy”: {“userFacts”: “never”,“preferences”: “never”,“toolResults”: “keep_last_50”}}}## 四、向量搜索与语义检索 ### 4.1 向量搜索的价值 虽然 Memory.md 文件系统提供了可靠的记忆存储和简单的文本检索能力但在某些场景下用户需要根据语义相似性而非精确关键词来查找历史记录。例如用户可能记得上次讨论过某个项目管理工具但忘记了具体是哪个工具或者想找关于 API 设计的讨论而不是搜索精确的关键词。 向量搜索通过将文本转换为高维向量嵌入然后计算向量之间的相似度来解决这个问题。当用户提出一个查询时系统会将查询也转换为向量然后在向量空间中找出最相似的记忆片段。这种方式不依赖于关键词的精确匹配而是理解语义层面的相似性。 ### 4.2 本地 Embedding 模型 OpenClaw 支持使用本地部署的 embedding 模型来生成向量表示这与依赖 OpenAI API使用 text-embedding-ada-002 等模型的方案形成对比。本地 embedding 的优势包括完全离线可用无需网络连接数据完全不离开用户设备隐私安全性更高长期使用成本为零无需支付 API 调用费用。 根据技术社区的反馈本地 embedding 可以在多种硬件配置上运行。在现代 Mac 电脑上可以使用 Apple Silicon 的 Neural Engine 加速推理在 AMD 锐龙 AI Max 处理器上可以高效运行 7B 参数的 embedding 模型在普通 PC 上可以选择更小的模型如 MiniLM 系列以平衡性能和速度。 ### 4.3 向量搜索的配置与使用 启用 OpenClaw 的向量搜索功能需要在配置中指定 embedding 模型。配置示例json { memory: { vectorSearch: { enabled: true, model: bge-small-zh-v1.5, embeddingDimension: 512, indexPath: ./data/vector-index } } }在实际使用中向量搜索通常与关键词搜索结合使用。系统会同时执行两种搜索策略然后合并结果并根据相关性排序。这种混合搜索方式既能处理精确匹配的查询也能处理语义相似但表达方式不同的查询。五、会话管理与持久化策略5.1 会话的生命周期OpenClaw 中的每个会话Session都有其完整的生命周期。新会话的创建可以由用户主动发起通过命令行或渠道消息也可以由系统根据配置自动创建如定时任务触发的会话。每个会话都有独立的状态包括活动状态Active、暂停状态Paused、已完成状态Completed。当会话处于活动状态时Memory.md 文件会实时更新记录所有新的对话内容和系统观察。每条记录都包含精确的时间戳方便后续检索和回溯。当会话暂停或完成时Memory.md 进入只读状态可以被归档或导出。5.2 跨会话的记忆传递OpenClaw 设计中有一个重要的概念跨会话记忆传递。虽然每个会话有独立的 Memory.md 文件但用户可以选择让新会话继承旧会话的记忆。这种设计支持两种模式连续模式新会话自动加载历史 Memory.md 的内容作为起始上下文独立模式每个会话完全独立不继承任何历史记忆。连续模式对于构建长期助手关系非常有用。例如用户可以让 OpenClaw 记住自己的项目背景、技术偏好、工作习惯等信息然后在后续会话中继续基于这些背景进行深入交流。随着使用时间的增长AI 助手会变得越来越了解用户提供更加精准和个性化的服务。5.3 备份与导出功能由于所有数据都存储在本地文件中OpenClaw 的备份和导出操作变得极为简单。用户只需复制整个数据目录即可完成完整备份。导出的格式可以是 Markdown保持 Memory.md 原格式、JSON便于程序处理或纯文本。这种设计还使得数据迁移变得非常简单。如果需要更换设备或在新机器上部署 OpenClaw只需将旧设备的 memory 目录复制过去即可。OpenClaw 会自动识别并加载这些历史数据无需额外的导入操作。六、隐私与安全考量6.1 数据存储的安全性OpenClaw 的本地优先设计为数据安全提供了坚实基础。所有对话历史、用户偏好、工具调用记录都存储在用户自己的设备上不依赖任何云服务。这意味着即使用户使用 OpenClaw 处理敏感信息如公司内部资料、个人隐私数据等这些数据也不会离开用户的控制范围。对于企业用户这种设计尤其重要。企业通常对数据存储有严格的合规要求如 GDPR、CCPA 等数据保护法规。OpenClaw 的本地存储模式使得企业可以完全掌控数据存储位置满足数据驻留要求而无需担心第三方服务商的数据处理实践。6.2 Memory.md 的访问控制虽然 Memory.md 文件存储在本地文件系统但用户仍然需要注意适当的访问控制。建议的实践包括为 OpenClaw 使用专用用户账户运行避免与其他应用共享文件系统权限定期检查 Memory.md 文件的权限设置确保只有授权账户可以读取在多用户环境下使用文件系统加密如 Linux 的 eCryptfs、Windows 的 BitLocker保护敏感数据。6.3 清理与数据删除用户可以随时手动清理或删除 Memory.md 中的特定内容。最简单的方式是直接编辑 Memory.md 文件删除不需要保留的记录。系统会在下次对话时自动读取更新后的文件。用户也可以启用自动清理功能设置某些类型的记忆在特定时间后自动过期。对于希望完全重置记忆的用户OpenClaw 提供了会话重置功能可以清除单个会话的所有记忆恢复到初始状态。这一操作不可撤销因此在执行前系统会要求用户确认。七、记忆系统的高级应用7.1 构建个人知识库利用 OpenClaw 的记忆系统用户可以构建一个个人化的 AI 知识库。具体做法是在 Memory.md 中预先录入需要 AI 了解的知识内容如个人项目文档、技术笔记、产品需求等利用向量搜索功能让 AI 能够根据语义检索这些知识当用户提问涉及这些知识时AI 会自动结合记忆中的相关内容给出更准确的回答。这种应用场景特别适合需要 AI 辅助工作的专业人士。例如软件开发者可以将项目的架构设计、编码规范、API 文档等信息录入 Memory.md后续在讨论项目相关问题时AI 就能基于这些背景知识提供更精准的建议。7.2 多角色记忆隔离对于需要在同一 OpenClaw 实例中服务多个用户的场景如家庭共享或小型团队使用可以使用多角色记忆隔离功能。每个用户可以拥有独立的 Memory.md 文件系统会根据当前交互的用户自动切换到对应的记忆上下文。这种设计的配置需要在 auth-profiles.json 中为每个用户定义独立的 profile每个 profile 指向不同的 Memory.md 文件路径。系统会根据消息来源的渠道标识如 Telegram 用户 ID、飞书用户 OpenID 等自动选择对应的 profile 和记忆文件。7.3 与外部知识库的集成虽然 OpenClaw 默认使用本地文件系统存储记忆但它也支持与外部知识库的集成。对于需要引用大量外部文档的场景如企业知识库、学术论文库等可以通过 Skills 机制接入外部知识检索系统然后在对话中动态引用检索结果。这种混合架构结合了本地记忆和外部知识的优势本地记忆存储用户的个人偏好和会话特定信息确保对话的连续性和个性化外部知识库提供大规模的信息检索能力满足复杂的信息查询需求。八、总结OpenClaw 的记忆系统是其区别于传统 AI 助手的核心创新之一。通过文件即真相的设计理念OpenClaw 将所有记忆以人类可读的 Markdown 格式存储在本地文件系统既保证了数据隐私和安全又提供了极大的灵活性和可控制性。本文详细介绍了 Memory.md 的文件结构、上下文压缩机制的工作原理、向量搜索功能的配置方法、会话管理的策略以及隐私安全方面的考量。掌握这些知识后用户可以充分利用 OpenClaw 的记忆系统构建具有持久记忆的个性化 AI 助手。记忆系统是实现真正智能助手的关键技术。随着对话的持续积累OpenClaw 会越来越了解用户提供越来越精准的服务。这种越用越聪明的特性正是 OpenClaw 作为下一代 AI 智能体平台的魅力所在。在后续的文章中我们将继续探讨 OpenClaw 的更多高级特性包括安全机制、云端部署、实战案例等内容。上一篇[第 011 篇] OpenClaw 多模型支持与接入配置——OpenAI、Claude、国产大模型全指南下一篇[第 013 篇] OpenClaw 安全机制深度解析——沙盒隔离、权限控制与安全最佳实践参考资料OpenClaw 官方文档 - 记忆系统OpenClaw 官方文档 - 上下文压缩CompactionOpenClaw GitHub - Memory 模块源码How OpenClaw Works: Skills, Heartbeat, Memory, and ChannelsOpenClaw 架构深度解析从 Gateway 到 Skills 的完整数据流OpenClaw Memory.md 文件格式详解 - 知乎一文彻底搞懂 OpenClaw 的架构设计与运行原理OpenClaw Context Window Management 最佳实践BGE Embedding 模型中文文档OpenClaw 本地向量搜索配置指南 - CSDNAI Agent 上下文管理综述 - 机器之心