1. 项目概述为AI智能体装上“长期记忆”在AI智能体Agent的开发与使用中一个长期存在的痛点就是“健忘症”。无论是基于OpenAI API还是本地部署的大模型标准的对话模式都是无状态的——每次交互对于模型来说都是一次全新的开始。这意味着你无法与一个智能体建立持续的关系它无法记住你的偏好、你的历史对话更无法基于过去的互动进行更深入、更个性化的交流。这正是unforget-ai/openclaw插件要解决的核心问题。它为OpenClaw框架下的智能体提供了一个开箱即用的长期记忆系统。想象一下你正在训练一个专属的个人助理或者构建一个需要理解用户长期意图的客服机器人。这个插件能让你的智能体像人一样拥有记忆和遗忘的能力从而实现真正连贯、有上下文的对话。它的设计哲学非常明确零配置、零LLM调用开销、完全本地化。你不需要申请任何外部API密钥不需要启动复杂的Docker容器甚至不需要手动搭建数据库。安装即用记忆的存储、检索、更新和删除全部在后台自动完成。对于开发者而言这意味着你可以将精力完全集中在智能体的核心逻辑和业务功能上而无需为状态管理、向量数据库集成等基础设施问题分心。2. 核心设计思路与架构拆解2.1 为什么选择“零LLM写入”在传统的记忆系统中存储一段记忆通常需要两个步骤1. 使用嵌入模型Embedding Model将文本转换为向量2. 将这个向量存入向量数据库。许多方案在第一步会直接调用像OpenAI的text-embedding-ada-002这样的API或者使用一个本地的大语言模型来生成“记忆摘要”。unforget-ai/openclaw插件摒弃了在写入时使用LLM的做法这背后有几个关键的考量成本与延迟每次对话回合Turn都可能产生需要存储的记忆。如果每次存储都调用一次LLM API或运行一次本地大模型推理累积下来的成本和响应延迟将是不可忽视的。尤其是在高频交互场景下这会成为性能瓶颈。确定性记忆的存储应该是一个确定性的、可靠的操作。依赖外部API或复杂的模型推理可能会引入不稳定性如网络波动、模型输出随机性。插件选择使用一个轻量级、专门优化的嵌入模型unforget-embed它只负责将文本转换为向量这个操作是快速且确定的。专注检索质量系统的核心智能体现在“回忆”阶段而非“存储”阶段。存储时我们只需要一个高质量的、通用的文本表示向量。而在回忆时系统会动用多通道混合检索策略从多个维度去理解当前查询与历史记忆的相关性。这种设计将计算资源用在了刀刃上。因此插件的写入路径极其轻量原始对话文本 - 轻量嵌入模型 - 向量存储。这保证了记忆操作的实时性和高吞吐量。2.2 四通道混合检索超越简单的语义搜索单一的语义搜索即基于向量余弦相似度在记忆检索中存在明显局限。比如用户问“我上周三提到了什么关于项目预算的事情”。纯语义搜索可能找到所有关于“项目”和“预算”的对话但无法精准定位到“上周三”这个时间点。为此该插件实现了四通道混合检索4-Channel Retrieval并将结果通过倒数排序融合Reciprocal Rank Fusion, RRF算法进行合并。这是一种在信息检索领域被验证有效的策略能显著提升召回结果的相关性和多样性。语义搜索Semantic基于unforget-embed生成的向量计算与查询向量的相似度。这是理解“意思相似”的基础通道。关键词搜索BM25这是一个经典的文本检索算法擅长处理精确的词项匹配、短语匹配。当用户使用非常具体的术语或名称时BM25的效果往往比语义搜索更好。例如记住了一个产品代号“Project Aurora”BM25能确保这个精确名称被准确召回。实体搜索Entity系统会从文本中提取命名实体如人名、地名、组织名、时间、日期等。这个通道专门用于记忆与特定实体相关的对话。当用户提到“Alex”时系统能快速找到所有与“Alex”这个实体相关的记忆即使上下文中没有出现“名字”、“用户”等语义相关的词。时间搜索Temporal每条记忆都带有时间戳。这个通道允许进行基于时间的过滤和排序例如“找到最近一周的记忆”或“找到在某个日期之后的对话”。这模拟了人类的记忆特性——越近发生的事情印象越深。RRF算法的作用是将这四个通道各自的检索结果列表每个结果都有排名通过一个公式进行加权合并产生一个最终的综合排名列表。这样既保证了语义上的相关性又兼顾了关键词精确度、实体关联性和时间新鲜度。2.3 插件与OpenClaw的无缝集成架构插件的架构设计体现了“非侵入式”和“松耦合”的思想。它通过OpenClaw的插件钩子Hooks机制介入智能体的生命周期而不是修改智能体本身的核心代码。OpenClaw Agent (你的智能体应用) │ │ 生命周期钩子: before_agent_start, agent_end ▼ unforget-ai/openclaw Plugin (TypeScript/JavaScript) │ │ HTTP请求 (默认 localhost:9077) ▼ unforget-embed Daemon (Python 后台进程) ├── unforget Core Library (实现4通道检索逻辑) └── pgserver (内嵌的 PostgreSQL pgvector 数据库)工作流程解析before_agent_start钩子自动回忆在智能体处理用户输入之前插件被触发。它会将当前的用户查询可能结合一些上下文发送给unforget-embed后台进程。后台进程执行四通道混合检索从数据库中找出最相关的K条历史记忆autoRecallTopK可配置默认10条。记忆注入检索到的记忆文本会被格式化例如加上“根据我们之前的对话我记得...”的前缀然后作为系统提示System Prompt的一部分或放在用户查询的上下文窗口中传递给大语言模型LLM。这样LLM在生成回复时就已经“知道”了相关的历史信息。agent_end钩子自动保留在智能体完成一次完整的对话回合用户输入助手回复后插件再次被触发。它将这一轮对话的完整内容或经过简单清洗的内容发送给unforget-embed进程由其生成向量并存储到内嵌的PostgreSQL中形成一条新的记忆。记忆管理当用户说出“忘记我喜欢披萨”或“记住我的名字是Kobi”这样的指令时这些指令会先经过LLM处理LLM能理解这是记忆操作指令。然后LLM的结构化输出或插件解析的指令会触发插件对记忆数据库进行相应的删除或更新操作。关键在于记忆的增删改查逻辑是由插件和unforget-embed完成的LLM只负责理解用户的自然语言意图这解耦了逻辑提高了可靠性。这种架构的好处是作为智能体开发者你几乎感知不到记忆系统的存在。你只需要像往常一样定义智能体的角色和基础能力记忆功能会自动附着上去大大降低了开发复杂度。3. 从零开始完整安装与配置指南3.1 环境准备与依赖安装虽然项目宣称“零配置”但一个正确的基础环境是必需的。以下是详细的步骤和注意事项。首要条件Python 3.12unforget-embed后台进程对Python版本有明确要求。我推荐使用pyenv来管理多个Python版本这对于同时进行多个项目的开发者来说是最佳实践。# 1. 安装pyenv以macOS为例其他系统请参考pyenv官网 brew update brew install pyenv # 2. 将pyenv初始化添加到shell配置文件如 ~/.zshrc echo export PYENV_ROOT$HOME/.pyenv ~/.zshrc echo command -v pyenv /dev/null || export PATH$PYENV_ROOT/bin:$PATH ~/.zshrc echo eval $(pyenv init -) ~/.zshrc source ~/.zshrc # 3. 安装Python 3.12.0 (建议安装具体的小版本号避免兼容性问题) pyenv install 3.12.0 pyenv global 3.12.0 # 将其设为全局默认版本或仅在项目目录下使用 pyenv local 3.12.0 # 4. 验证安装 python --version # 应输出 Python 3.12.0注意有些Linux发行版的包管理器可能也提供了Python 3.12但通过pyenv安装可以确保环境的纯净和版本的精确控制避免与系统自带的Python发生冲突。安装unforget-embed官方推荐使用pipx来安装unforget-embed。pipx专门用于安装和运行Python命令行应用它会为每个应用创建独立的虚拟环境避免依赖冲突。# 1. 安装pipx (如果尚未安装) python -m pip install --user pipx python -m pipx ensurepath # 安装后需要重新打开终端或 source 你的shell配置文件 # 2. 使用pipx安装unforget-embed pipx install unforget-embed # 3. 验证安装可以尝试运行其帮助命令 unforget-embed --help实操心得使用pipx安装后unforget-embed命令会全局可用。当你第一次启动OpenClaw并触发记忆插件时插件会自动尝试在后台启动unforget-embed进程。你也可以手动启动它进行调试unforget-embed serve。默认会在localhost:9077启动服务。3.2 安装OpenClaw记忆插件确保你已经在你的OpenClaw项目目录中。OpenClaw的插件管理系统使得安装过程非常简单。# 在OpenClaw项目根目录下执行 openclaw plugins install unforget-ai/openclaw这个命令会从npm仓库下载unforget-ai/openclaw插件包。将其安装到当前OpenClaw项目的插件目录中。更新项目的配置文件通常是openclaw.json或openclaw.config.js将插件添加到插件列表。安装完成后你通常不需要做任何其他操作。插件默认是启用的enabled: true并且autoRetain和autoRecall也默认开启。下次你运行你的OpenClaw智能体时记忆功能就已经生效了。3.3 配置文件详解与高级设置尽管零配置即可运行但openclaw.json中的配置项让你能精细控制记忆系统的行为。配置文件通常位于项目根目录。{ plugins: { entries: { unforget-ai/openclaw: { enabled: true, // 总开关设为false则完全禁用记忆功能 config: { orgId: openclaw, // 组织标识符用于在多租户环境下隔离记忆数据 autoRetain: true, // 是否在每次对话后自动保留记忆 autoRecall: true, // 是否在每次对话前自动回忆相关记忆 autoRecallTopK: 10, // 每次回忆时检索并注入上下文的记忆条数上限 debug: false // 开启调试模式会在控制台打印详细的检索和存储日志 } } } } }关键配置项解析orgId: 这是一个非常重要的命名空间概念。所有记忆都会存储在以orgId命名的“桶”里。如果你开发的是多用户应用例如每个用户有自己的智能体实例你需要为每个用户或会话设置不同的orgId以确保他们的记忆完全隔离。对于单用户桌面应用使用默认值即可。autoRecallTopK: 这个值需要权衡。设置太小如3可能无法召回足够相关的记忆影响智能体的连续性设置太大如50会占用大量的LLM上下文窗口Token增加成本并可能稀释核心指令的注意力。建议从默认值10开始根据智能体的对话长度和你的上下文窗口大小进行调整。例如如果你的LLM上下文窗口是8K Token每条记忆平均100 Token那么10条记忆就是1K Token这是比较安全的占比。debug: true: 在开发阶段强烈建议开启。它会输出类似以下的日志帮助你理解记忆系统的工作过程[Unforget] Recalling memories for query: Whats my name? [Unforget] Retrieved 2 memories via semantic search. [Unforget] Retrieved 1 memory via BM25 search. [Unforget] RRF fused results: 3 memories selected. [Unforget] Injected memory context: “用户曾说过我的名字是Alex...”这能让你确认记忆是否被正确检索和注入。3.4 连接外部Unforget服务器可选如果你已经在另一台机器上运行了Unforget服务或者希望使用自己管理的、具有更高可用性的PostgreSQL数据库例如云上的RDS你可以配置插件连接外部服务器。{ plugins: { entries: { unforget-ai/openclaw: { enabled: true, config: { apiUrl: http://your-unforget-server-host:9077, // 指向外部服务地址 orgId: your-org-id, // ... 其他配置 } } } } }使用场景团队共享开发团队可以共用一个中央Unforget服务器所有成员的智能体实例都将记忆存储在同一位置便于管理和备份。生产环境在内嵌的SQLite/PostgreSQL之外你可能需要企业级的数据库支持连接池、监控、主从复制等功能。性能分离将记忆检索服务部署在性能更强的机器上与你运行LLM推理的机器分离。注意事项当配置了apiUrl后插件将不会自动启动本地的unforget-embed进程而是直接向指定的URL发送HTTP请求。请确保该服务端已正确安装并运行unforget-embed serve且网络可达。4. 实战演练记忆系统的核心操作与交互4.1 基础对话流程与记忆的自动流转让我们通过一个完整的终端会话示例来直观感受记忆系统如何工作。假设我们有一个名为MyAssistant的OpenClaw智能体。# 启动你的OpenClaw智能体 openclaw run MyAssistant # 终端进入交互模式 You: 你好我的名字是王伟我是一名软件工程师住在北京。 Agent: 你好王伟很高兴认识你软件工程师。北京是个很棒的城市。今天有什么可以帮你的吗 # [幕后] agent_end钩子触发本轮对话“名字-王伟职业-软件工程师城市-北京”被向量化并存储。 You: 我最近对机器学习特别感兴趣。 Agent: 机器学习是当前非常热门的领域有很多有趣的方向比如深度学习、强化学习。你具体想了解哪方面呢 # [幕后] 新的记忆“对机器学习感兴趣”被存储。 You: 对了我的职业是什么我住在哪里 # [幕后] before_agent_start钩子触发。查询“职业是什么住在哪里”被发送。 # 四通道检索开始工作 # - 语义搜索匹配“职业”、“住”、“哪里”。 # - 实体搜索识别出“我”可能关联的已存实体“王伟”。 # - BM25精确匹配“职业”、“住”。 # - 时间所有记忆时间都很近权重相似。 # RRF融合后前两条关于“职业”和“城市”的记忆被选出注入本次对话的上下文。 Agent: 你之前提到过你是一名软件工程师并且住在北京。这个过程完全自动化。用户和开发者都无需关心记忆是如何被保存和查找的对话自然地进行智能体却表现出了“记忆力”。4.2 主动记忆管理记住与遗忘记忆系统不仅能被动记录还能响应主动的指令。这是通过让LLM理解用户的自然语言指令然后输出结构化命令给插件来实现的。“记住”指令You: 请记住我每天早上9点需要喝一杯咖啡并且对花生严重过敏。 Agent: 明白了我已经记下你每天上午9点需要咖啡并且对花生严重过敏。这些信息很重要我会在相关场景下留意。底层操作LLM识别出这是一个“记忆存储”的意图。插件可能会将整句指令或由LLM提取出的结构化信息{“action”: “remember”, “content”: “用户每天早上9点需要喝咖啡且对花生过敏”}作为一条新记忆存储。更高级的实现中LLM可能会将信息分解为多条原子记忆如“偏好-咖啡-时间-9am”、“过敏源-花生”便于未来更精确的检索。“忘记”指令You: 忘记我住在北京这件事。 Agent: 好的关于你居住在北京的信息已经被移除了。底层操作这是更复杂的操作。插件需要定位到包含“住在北京”这条信息的记忆条目并将其删除。通常这通过以下步骤完成LLM理解指令输出如{“action”: “forget”, “query”: “住在北京”}的指令。插件使用这个query作为检索词在记忆库中执行一次搜索。找到最匹配的一条或几条记忆可能通过相似度阈值控制。从数据库中物理删除或逻辑标记这些记忆条目为“已遗忘”。重要提示“忘记”操作是基于检索的并非精确匹配。如果记忆库中有多条语义相近的记忆例如“我住在北京朝阳区”和“我的家在北京”可能都需要被定位和处理。目前这更像是一个“模糊删除”对于要求精确记忆管理的场景未来的版本可能会引入记忆的唯一ID或更细粒度的管理接口。4.3 处理会话与记忆的隔离在实际应用中你可能会开启新的对话会话/new或者为不同的任务创建不同的智能体实例。记忆如何在这些场景下工作场景一同一智能体新会话正如项目描述所示使用/new开始一个新会话并不会清空记忆。因为记忆是绑定在orgId下的而不是会话ID。只要orgId不变新的会话依然能访问到之前的所有记忆。You: /new New session started. You: 我喜欢的颜色是什么假设之前从未提及 Agent: 你还没有告诉过我你喜欢的颜色。这符合预期因为记忆库中没有相关信息。场景二多智能体应用如果你开发的是一个支持多用户的平台每个用户有自己的智能体。关键在于为每个用户设置不同的orgId。// 在你的OpenClaw应用代码中动态配置插件 const userId getCurrentUserId(); // 例如 “user_123” const agent new OpenClaw({ // ... 其他配置 plugins: { entries: { unforget-ai/openclaw: { enabled: true, config: { orgId: userId, // 用用户ID作为命名空间 // ... 其他配置 } } } } });这样用户A的记忆完全不会泄露给用户B实现了数据的天然隔离。5. 深入原理四通道检索与RRF算法实战解析5.1 各检索通道的实现原理与适用场景为了真正用好这个记忆系统理解其四个检索通道的底层原理至关重要。这能帮助你在调试和优化时知道该从哪个角度入手。语义搜索通道原理利用unforget-embed模型将文本记忆和查询转换为高维向量例如768维。检索时计算查询向量与所有记忆向量的余弦相似度取相似度最高的Top K条。优势理解同义词和语义关联。例如查询“编程”能召回包含“写代码”、“软件开发”的记忆。劣势对专有名词、精确术语不敏感无法处理时间、数字等精确过滤。适用场景通用对话、概念性查询、总结性提问。BM25关键词搜索通道原理基于经典的Okapi BM25算法。它将文档记忆和查询视为词袋Bag of Words计算每个词项的权重考虑词频TF和逆文档频率IDF。BM25分数反映了查询词项在文档中的匹配程度。优势擅长精确匹配。对于产品型号“iPhone 15 Pro”、错误代码“Error 404”、特定人名/地名等BM25的召回准确率通常高于语义搜索。劣势无法理解语义。查询“ canine companion”无法匹配到包含“dog”的记忆。适用场景精确信息查找、代码片段、技术术语、包含数字和符号的查询。实体搜索通道原理在记忆存储时使用一个命名实体识别NER模型或规则从文本中提取实体如[PERSON: Alex],[DATE: last Wednesday],[ORG: OpenAI]。检索时同样从查询中提取实体然后匹配记忆中的实体标签。优势建立实体间的强关联网络。当用户提到一个实体如“Alex”系统能快速找到所有与“Alex”相关的记忆无论上下文如何变化。劣势依赖NER的准确性。如果实体识别错误如把“Apple”公司识别为水果检索就会出错。适用场景基于人物、地点、组织、时间等实体的关系性查询。时间搜索通道原理每条记忆都有时间戳。检索时可以按时间倒序最近优先排序或者支持基于时间范围的过滤如“timestamp ‘2023-10-01’”。优势模拟记忆的时效性和新鲜度。人类更易记住最近的事智能体也应如此。劣势单独使用价值有限必须与其他通道结合。适用场景查询近期事务“我上周说了什么”、或需要时间线上下文的任务。5.2 RRF融合算法从多维度结果到统一排名假设一次查询四个通道分别返回了以下结果记忆ID列表语义通道:[记忆A, 记忆B, 记忆C]BM25通道:[记忆C, 记忆D, 记忆A]实体通道:[记忆B, 记忆E]时间通道:[记忆A, 记忆F, 记忆C](按时间倒序)RRF算法的核心公式是score(d) Σ (1 / (k rank_i(d)))其中d是某个记忆文档。rank_i(d)是该文档在第i个检索通道结果列表中的排名从1开始如果未出现则忽略此项或赋予一个很大的排名值。k是一个常数通常取60用于平滑排名靠后文档的分数差异。计算示例假设常数k60。记忆A在语义通道排名1BM25排名3时间通道排名1。分数 1/(601) 1/(603) 1/(601) ≈ 0.0164 0.0159 0.0164 0.0487记忆C在语义通道排名3BM25排名1时间通道排名3。分数 1/(603) 1/(601) 1/(603) ≈ 0.0159 0.0164 0.0159 0.0482虽然记忆C在两个通道中排名第一但记忆A在三个通道中都出现了且排名靠前其RRF总分略高于记忆C。最终系统会按RRF分数对所有出现过的记忆进行降序排序取前autoRecallTopK条如10条注入上下文。这种融合策略的优势在于它不需要预先知道哪个通道更“好”而是通过民主投票的方式让在多个通道中都表现良好的记忆脱颖而出从而得到更稳健、更全面的检索结果。6. 开发与生产实践问题排查与性能优化6.1 常见问题与解决方案速查表在实际集成和使用过程中你可能会遇到以下问题。这里提供一个快速排查指南。问题现象可能原因排查步骤与解决方案插件安装后对话无记忆效果。1. 插件未启用。2.unforget-embed进程未启动。3. Python版本不是3.12。1. 检查openclaw.json中enabled是否为true。2. 查看终端日志是否有[Unforget]开头的日志没有则进程未启动。尝试手动运行unforget-embed serve看是否有报错。3. 运行python --version确认版本。使用pyenv切换至3.12。控制台报错Connection refused或Failed to connect。unforget-embed服务未在localhost:9077上运行。1. 检查unforget-embed进程是否存活ps aux记忆似乎不准确或召回无关内容。1.autoRecallTopK设置过大注入了噪声。2. 查询本身模糊。3. 嵌入模型对特定领域文本效果不佳。1. 将debug设为true查看具体召回了哪些记忆。尝试调小autoRecallTopK(如改为5)。2. 优化你的智能体提示词引导用户提出更明确的问题。3. 目前unforget-embed使用的是通用嵌入模型。对于极专业领域如法律、医学可关注未来是否支持自定义模型。“忘记”指令没有生效。1. LLM未能正确解析指令为“遗忘”操作。2. 检索到的记忆与目标不完全匹配未达到删除阈值。1. 开启debug模式查看插件收到的指令是什么。可能需要优化你的系统提示词教导LLM如何格式化记忆操作指令。2. “忘记”是模糊操作。对于关键信息考虑在应用层实现更精确的记忆管理界面如列出记忆并让用户选择删除。随着记忆增多响应速度变慢。向量检索在全量数据中进行数据量越大线性扫描越慢。这是向量数据库的普遍问题。内嵌的PgVector支持使用IVFFlat或HNSW索引加速。你需要关注unforget-embed的未来版本看是否会提供自动索引功能或者考虑迁移到支持索引的外部PG数据库。在多轮复杂对话后LLM上下文窗口不足。注入的记忆条数 (autoRecallTopK) 或单条记忆过长挤占了对话上下文。1. 减少autoRecallTopK。2. 在存储记忆前让LLM对长对话进行摘要只存储摘要而非全文。这需要自定义插件的autoRetain逻辑是进阶用法。6.2 性能优化与进阶调优建议对于生产环境或高频使用的场景可以考虑以下优化方向记忆摘要与压缩问题原始的对话回合可能很长直接存储会占用大量数据库空间且检索时注入的Token数会很高。方案在autoRetain环节介入。可以配置在存储前调用一次LLM使用低成本模型如gpt-3.5-turbo对当前对话回合进行总结生成一条简洁的“记忆点”再存储。例如将一段关于编程问题的讨论总结为“用户正在学习Python装饰器遇到了理解递归调用的问题”。实现思路这需要修改插件代码或通过OpenClaw的中间件Middleware在调用插件前对数据进行预处理。记忆分片与元数据问题所有记忆混在一起当数据量很大时即使有索引检索效率也会下降且可能召回无关领域的记忆。方案为记忆打上标签或分类。例如在存储时让LLM或规则引擎为记忆生成标签如#工作、#个人偏好、#项目A。在检索时可以先根据当前对话的上下文预测一个或几个相关标签然后只在带有这些标签的记忆中进行检索大幅缩小搜索范围。实现思路这需要对unforget-embed的存储结构和检索接口进行扩展目前可能需等待官方功能或自行fork修改。使用外部高性能向量数据库问题内嵌的PgVector适合轻量级应用但对于千万级甚至亿级的记忆向量专业向量数据库如Qdrant, Milvus, Weaviate在分布式、索引优化、过滤查询上更有优势。方案配置插件连接外部Unforget服务器而该服务器后端连接的是你部署的、带有高性能向量扩展的PostgreSQL如TimescaleDB with pgvector或者直接使用上述专业向量数据库。这需要你自行部署和维护unforget-embed服务并修改其数据库连接配置。控制记忆的生命周期问题记忆永远保存可能导致存储膨胀和检索到过时信息。方案实现记忆的自动清理策略。例如基于时间自动删除30天前的记忆。基于访问频率长期未被检索到的记忆可以归档或删除。基于重要性在存储时让LLM对记忆的重要性打分低分记忆定期清理。实现思路需要定期运行一个后台任务查询数据库并执行清理逻辑。这同样需要扩展unforget-embed的功能或直接操作数据库。6.3 调试技巧利用日志洞察内部运作将debug设置为true是最强大的调试手段。以下是一段典型的调试日志分析[Unforget] Query: “推荐一家附近的意大利餐厅。” [Unforget] Semantic search top3: [记忆ID: 103 (score:0.87), 记忆ID: 205 (score:0.76), 记忆ID: 178 (score:0.71)] [Unforget] BM25 search top3: [记忆ID: 205 (score:12.4), 记忆ID: 301 (score:9.8), 记忆ID: 103 (score:5.2)] [Unforget] Entity search: [记忆ID: 103 (entity: ‘意大利’)] [Unforget] Temporal search (last week): [记忆ID: 301, 178] [Unforget] RRF fused scores: {103: 0.142, 205: 0.138, 301: 0.095, 178: 0.088} [Unforget] Injected memories (ID: 103, 205): “用户曾说他喜欢意大利菜尤其是披萨。”, “用户上周在市中心吃了一家不错的餐厅。”从日志中我们可以读出语义搜索找到了关于“意大利菜”和“餐厅”的通用记忆103 205 178。BM25搜索因为精确匹配“意大利”这个词给了记忆205和103很高的分数。实体搜索识别出记忆103中包含“意大利”这个实体。时间搜索找出了最近一周的记忆301 178。RRF融合后记忆103和205胜出因为它们在多个通道中都排名靠前综合相关性最强。最终这两条记忆被注入上下文智能体就能基于“喜欢意大利菜”和“上周在市中心有不错体验”这两个信息做出更个性化的推荐。通过分析这样的日志你可以清晰地看到是哪个通道主导了检索结果从而判断记忆系统的行为是否符合你的预期并为调优提供依据。记忆系统是构建高级AI智能体的基石之一。unforget-ai/openclaw插件以其零配置、高性能和巧妙的多通道检索设计大大降低了为OpenClaw智能体添加长期记忆能力的门槛。从简单的个人助手到复杂的多轮对话系统它都能提供坚实的状态管理支持。理解其背后的架构、检索原理和配置细节能帮助你在实际项目中更好地驾驭它打造出真正“善解人意”且“过目不忘”的AI伙伴。