1. 项目概述：从“失忆”的AI到构建持久记忆

最近在折腾OpenClaw这个本地AI智能体框架时，我遇到了一个挺典型的问题：昨天和它聊得好好的，今天再打开，它就像得了健忘症一样，完全不记得我们之前的对话内容了。这让我意识到，对于OpenClaw这类旨在模拟人类长期交互的智能体来说，一个健壮、可靠的“记忆力系统”不是锦上添花，而是核心基础设施。没有记忆，每一次对话都是孤岛，智能体无法学习、无法成长，更谈不上形成连贯的“人格”或完成复杂的多轮任务。

OpenClaw本身是一个功能强大的开源AI智能体框架，它允许你将大语言模型（LLM）与各种工具、技能（Skill）连接起来，构建能自动化处理任务的“数字员工”。从网络上的讨论热度来看，大家关注点已经从“如何安装部署”深入到“如何用好用活”，比如接入飞书/微信、配置多模型、结合Hermes Agent等。而“第二天就不知道昨天会话的内容了”这个具体痛点，恰恰指向了其默认架构中的一个关键缺口：缺乏一个系统化的、可持久化的记忆管理机制。

因此，我们今天不聊怎么装Docker、怎么配Ollama，那些基础教程已经很多了。我们来深入探讨一下，如果要为OpenClaw设计一个真正可用的记忆力系统，我们应该从哪些维度去思考它的架构。这不仅仅是加一个数据库那么简单，它涉及到记忆的采集、存储、索引、检索、更新乃至遗忘的完整生命周期，是一个典型的系统设计问题。

2. 记忆系统的核心需求与设计目标

在设计任何系统之前，明确我们要解决什么问题至关重要。对于OpenClaw的记忆力系统，其核心需求远不止“记住聊天记录”这么简单。

2.1 从用户痛点推导功能需求

首先，我们梳理一下从实际使用和网络反馈中暴露出的痛点：

1. 会话失忆：最直接的问题，智能体无法跨会话维持上下文。这导致无法进行长期的、渐进式的对话或任务协作。
2. 信息碎片化：即使在一个会话内，如果对话很长，模型有限的上下文窗口也会导致“开头说了什么已经忘了”。我们需要一种机制来提炼和压缩关键信息。
3. 缺乏个性化：一个理想的智能体应该能记住用户的偏好、习惯、历史决策。比如，用户说过“我喜欢用Markdown格式回复”，智能体就应该在后续交互中默认采用。
4. 知识无法积累：智能体在解决一个问题的过程中学到的知识（例如，通过搜索获得的某个API的调用方式），无法沉淀下来供未来直接使用，导致重复劳动。
5. 隐私与安全：记忆必然涉及用户数据。如何安全地存储、访问这些记忆，并让用户拥有控制权（如查看、修改、删除特定记忆）是必须考虑的问题。

基于这些痛点，我们可以归纳出记忆力系统的设计目标：

• 持久化：记忆必须能跨越进程、会话和时间持久保存。
• 结构化：记忆不能只是一堆杂乱的文本，需要有一定的结构以便高效管理和检索。
• 可检索：在需要的时候（如下一轮对话），系统能快速、准确地找到相关的记忆片段。
• 可更新：记忆不是一成不变的。新的信息可能证实、补充或否定旧的记忆，系统需要支持动态更新。
• 可聚合：能够将零散的短期记忆，整合、抽象成长期的、概括性的知识或用户画像。
• 可控性：用户或系统管理员应对记忆的存储、使用和生命周期拥有明确的控制策略。

2.2 记忆的分类与粒度

在设计存储和检索方案前，我们必须对记忆本身进行分类。不同类别的记忆，其生命周期、重要性和检索频率都不同。

• 会话记忆：最细粒度的记忆，保存单次对话中的原始消息序列。它的主要作用是维持短期上下文，通常在会话结束后可以归档或清理。存储上可以直接使用对话日志。
• 实体记忆：关于特定“事物”的事实性信息。例如，用户说“我的项目叫‘星辰大海’，截止日期是下周五”。这里“项目名称”和“截止日期”就是关于“星辰大海项目”这个实体的记忆。这类记忆需要结构化存储，便于精确查询。
• 用户偏好记忆：关于用户行为习惯的总结。例如，“用户通常在工作时间（9-18点）活跃”，“用户倾向于接收简洁的摘要而非详细报告”。这类记忆是长期且相对稳定的，是实现个性化的关键。
• 程序性记忆/技能记忆：智能体通过实践学会的“如何做某事”的知识。例如，“当用户问天气时，应调用‘get_weather’技能，并需要参数‘city’”。这可以看作是技能配置或使用历史的优化总结。
• 摘要记忆：对长对话或复杂任务的总结性描述。例如，“上周协助用户制定了Q3的产品规划，核心是聚焦A市场和B功能”。它是对原始信息的压缩和提炼，用于快速唤起对过往重大事件的整体印象。

明确这些分类，有助于我们后续设计不同的存储表、索引策略和清理机制。

3. 记忆力系统的核心架构设计

一个完整的记忆力系统，可以抽象为一个典型的数据处理管道，包含“写”和“读”两个核心方向。下面我们来拆解每个环节的设计考量。

3.1 记忆的采集与编码：从对话流到记忆单元

记忆不是自动产生的，需要从智能体与用户的交互流中主动提取。这里的关键是“记忆提取器”模块。

它的工作流程是：

1. 监听：挂载在OpenClaw的消息总线上，监听每一轮完整的Agent-User交互。
2. 解析：利用LLM（可以是一个轻量级模型）对交互内容进行解析。这里不是简单存储，而是进行信息抽取。
   • 意图识别：这段对话是关于查询、指令、闲聊还是信息更新？
   • 实体与关系抽取：识别并结构化对话中提到的关键实体（人、事、物、时间）及其属性、关系。
   • 重要性打分：判断当前交互中产生的信息，哪些是值得长期记忆的（如用户设置偏好），哪些是临时性的（如问候语）。
3. 编码与向量化：将提取出的结构化信息（如“用户偏好：报告格式 -> Markdown”）和关键的原始文本片段，转换为向量嵌入。这一步是为后续的语义检索做准备。可以使用OpenAI的text-embedding-3-small、本地部署的BGE或SentenceTransformer等模型。
4. 封装：将原始文本、结构化数据、向量嵌入、元数据（时间戳、会话ID、重要性分数、记忆类型标签）打包成一个“记忆单元”。

实操心得：记忆提取的粒度很重要。不宜过细（每条消息都存），那会成为垃圾数据场；也不宜过粗（只存会话摘要），会丢失细节。一个折中的策略是，在每轮对话结束时，触发一次提取，重点抽取本轮出现的新事实、新决策和新偏好。同时，可以设置一个定时或定长的摘要任务，例如每10轮对话或会话结束时，生成一个“摘要记忆”。

3.2 记忆的存储与索引：数据库选型与结构设计

这是系统的基石。我们需要一个既能处理结构化查询，又能高效进行向量相似度搜索的存储方案。

方案一：关系型数据库 + 独立向量数据库（推荐用于生产环境）这是目前最成熟、性能最有保障的方案。

• 关系型数据库（如PostgreSQL, MySQL）：
  • 作用：存储记忆的元数据、结构化属性、类型标签、关系等。
  • 表结构设计示例：

    -- 记忆主表 CREATE TABLE memories ( id UUID PRIMARY KEY, content_text TEXT, -- 原始文本摘要 memory_type VARCHAR(50), -- 'entity', 'preference', 'summary'等 entity_name VARCHAR(255), -- 关联的实体名 importance_score FLOAT, created_at TIMESTAMP, last_accessed_at TIMESTAMP, session_id VARCHAR(255) ); -- 记忆属性表（用于存储结构化数据） CREATE TABLE memory_attributes ( memory_id UUID REFERENCES memories(id), key VARCHAR(255), value TEXT );

• 向量数据库（如Qdrant, Weaviate, Pinecone, pgvector）：
  • 作用：专门存储记忆单元的向量嵌入，并提供高效的近似最近邻搜索。
  • 选择考量：如果使用PostgreSQL，pgvector扩展能让你在同一个库完成所有操作，简化架构。若对向量搜索性能有极致要求，或数据量极大，独立的向量数据库如Qdrant是更好的选择。

方案二：全功能多模数据库（简化架构）像Weaviate、Milvus这类数据库，原生支持将向量、文本、结构化属性存储在一个对象里，并统一检索。这大大简化了数据模型和查询逻辑，适合快速原型或中小型应用。

设计要点：

• 索引策略：除了向量索引，务必为memory_type,entity_name,created_at等常用过滤字段建立数据库索引。
• 分片与分区：可以根据memory_type或时间范围进行分区，提升查询和管理效率。
• 连接关系：在关系型数据库中，可以通过外键明确记忆单元之间的关系（如，一个“项目”实体记忆，关联多个“任务”实体记忆）。

3.3 记忆的检索与召回：让AI想起该想的事

当用户发起新一轮对话时，记忆力系统的核心任务就是：根据当前对话的上下文，从海量记忆中召回最相关的那一小部分，并将其作为上下文喂给LLM。这是系统智能度的体现。

检索流程通常是多路并行的：

1. 关键词/过滤器检索：根据当前对话解析出的明确实体或类型进行精确查询。
   • 场景：用户说“继续我们昨天关于‘星辰大海’项目的讨论”。
   • 操作：直接在数据库中查询entity_name = ‘星辰大海项目’ AND memory_type = ‘entity’的记忆。
2. 向量语义检索：将当前的用户问题或对话历史摘要转换成向量，在向量数据库中进行相似度搜索。
   • 场景：用户说“我之前好像让你帮我总结过一些市场趋势”。
   • 操作：对这句话做向量化，搜索memory_type = ‘summary’且向量最相似的记忆。
3. 时间衰减与重要性加权：检索结果不是简单的并集。我们需要一个重排序过程。
   • 时间衰减：越近的记忆通常越相关。可以给记忆的相似度分数乘以一个随时间指数衰减的权重。
   • 重要性加权：在采集阶段打的importance_score在这里用上，重要的记忆排名靠前。
   • 访问频率：last_accessed_at也可以作为一个因子，被经常访问的记忆可能更相关。
4. 结果融合与截断：将多路检索的结果基于加权分数进行融合、去重，然后取Top-K（例如，Top 5）最相关的记忆片段。最终，将这些记忆片段以清晰的格式（如“【系统记忆】用户偏好：...；关于XX项目：...”）插入到发给LLM的提示词中。

避坑指南：直接做向量相似度搜索有一个经典问题——“语义相似但不相关”。比如，用户问“怎么养猫”，可能召回一篇关于“猫科动物基因研究”的论文，因为都有“猫”这个核心概念。解决方法就是混合检索：先用关键词/过滤器圈定一个大致范围（如memory_type=’preference’），再在这个范围内做向量搜索，能极大提升准确性。

3.4 记忆的更新、合并与遗忘：系统不是硬盘

记忆不是只增不减的。一个只有写入没有更新的系统，很快就会充满矛盾和过时的信息。

• 更新：当检测到用户明确修正信息时（如“不对，我喜欢的颜色是蓝色，不是绿色”），系统应能定位到旧的“颜色偏好”记忆，将其标记为过时或直接更新值。
• 合并：当关于同一实体的多条记忆在语义上高度相似或互补时，可以触发合并操作。例如，多次提到“喜欢喝咖啡”，可以合并为一条“用户有喝咖啡的习惯”的记忆，并附加“提及频率：高”的元数据。这通常需要LLM来判断。
• 遗忘（清理）：这是高级特性，但对系统健康度至关重要。可以基于多种策略：
  • 基于时间的TTL：为session_memory等设置存活时间，到期自动删除。
  • 基于重要性的淘汰：定期扫描，删除importance_score极低且长时间未被访问的记忆。
  • 主动遗忘：提供用户接口，让用户可以删除特定记忆。
  • 摘要化后删除细节：将详细的对话记录压缩成一条“摘要记忆”后，删除原始冗长的日志，节省空间。

4. 在OpenClaw中的集成与实践路径

理论说完，我们看看怎么把它塞进OpenClaw。OpenClaw的插件化架构为这种能力扩展提供了便利。

4.1 以插件/技能形式集成

最优雅的方式是开发一个MemoryManagerSkill插件。

1. 技能初始化：在技能加载时，连接配置好的记忆数据库（向量库+关系库）。
2. 挂载钩子：
   • on_message_received：在收到用户消息后、发送给LLM前，调用检索逻辑，获取相关记忆，并拼接到上下文。
   • on_message_sent：在LLM回复完成后，调用记忆提取逻辑，分析本轮交互，生成记忆单元并存储。
3. 提供管理指令：通过自定义技能指令，让用户或管理员能与记忆系统交互。
   • /memory_list [entity]：列出与某实体相关的记忆。
   • /memory_forget <id|entity>：删除特定记忆。
   • /memory_summary：生成当前会话或用户的记忆摘要。

4.2 配置与扩展点考虑

• 模型配置：在config.yaml中需要新增记忆相关的配置项，如向量模型路径、数据库连接串、各种阈值（重要性阈值、相似度阈值等）。
• 可扩展的记忆提取器：可以设计成插件化的提取器链。例如，一个提取器专门抽实体，一个专门判断偏好，方便后续增删功能。
• 与现有技能的协同：例如，当WebSearchSkill搜索到一个结果并被用户认可后，可以主动触发记忆系统，将这条信息作为“知识记忆”保存下来。

4.3 针对“会话失忆”问题的渐进式解决方案

如果你觉得上述整套系统太重量级，可以分步实施，优先解决最痛的“跨会话失忆”问题：

第一步：简易会话持久化修改OpenClaw的对话历史管理模块，将原本只在内存中的对话记录，在会话结束时自动追加存储到本地文件（如JSONL）或一个简单的SQLite表中。下次同一用户发起会话时，先加载最近的N条历史记录。这能立刻解决“完全失忆”问题。

第二步：添加基于向量的上下文检索在第一步的基础上，引入一个轻量级向量库（比如用chromadb）。将每轮对话的关键内容向量化存储。当新会话开始或上下文窗口快满时，不是简单截断最老的，而是用当前问题去检索整个历史中最相关的片段，组成“精华上下文”喂给LLM。这解决了长上下文下的“碎片化失忆”。

第三步：引入结构化记忆与摘要在前两步运行稳定后，再引入LLM进行信息提取和摘要生成，开始区分记忆类型，实现真正的记忆系统。

5. 潜在挑战与进阶思考

设计这样一个系统，路上少不了坑。

• LLM的“幻觉”与记忆污染：记忆提取器本身也是LLM，它可能提取错误的信息。一旦错误记忆被存入，会在后续检索中不断强化，造成“幻觉循环”。解决方案：设置高置信度阈值，对于关键记忆（如用户个人信息）可以设计“用户确认”环节（如“我将记住您喜欢蓝色，对吗？”）。
• 隐私、安全与合规：记忆里可能包含敏感信息。必须做到：
  • 加密存储：对存储的文本内容进行加密。
  • 访问控制：记忆严格按用户隔离，绝不允许串号。
  • 数据清理工具：提供完整的数据导出和删除功能，以满足合规要求。
• 性能与成本：每次交互都调用LLM做提取和向量化，成本不低。需要优化：
  • 异步处理：记忆提取和存储可以放在后台异步队列中执行，不阻塞主对话流程。
  • 缓存：频繁访问的“热点记忆”可以缓存在内存中。
  • 轻量化模型：提取和向量化可以使用参数量小、专门优化的模型。
• 记忆的冲突与推理：当两条记忆矛盾时怎么办？系统需要具备一定的推理能力，例如结合时间戳（以最新的为准）或来源可信度来判断。更高级的系统甚至可以主动发起澄清询问。
• 迈向“自主记忆管理”：最终极的形态，是智能体能够像人一样，自主决定记住什么、忘记什么、如何组织记忆。这需要LLM具备更高层次的元认知能力，目前仍处于前沿探索阶段。

为OpenClaw设计记忆力系统，本质上是在为其注入“时间”维度和“经验”积累的能力。它从一款一次性的对话工具，蜕变为一个可以长期陪伴、持续学习的数字伙伴。这个架构思考的过程，涉及数据流水线设计、存储选型、检索算法和AI工程化，是一个微缩版的AI系统设计实战。