OpenClaw团队在2026年4月12日推送v2026.04.12版本更新：所有人打开发布日志，眼睛先看界面改动，再看性能优化数据，最后瞄一眼新功能列表。没人注意最底下那行不起眼的小字。那个叫Active Memory的插件安安静静躺在更新列表末尾，像一个透明人。这名字听起来特别像电视购物里卖的老年健忘保健品。
Active Memory这个插件干的事特别狠。它把AI的记忆调用机制从模型自己决定要不要查记忆，变成每次回复前必须查一遍记忆。这个变化小到什么程度？小到你看一眼会觉得，哦，就这？但效果直接到什么程度？直接到所有吐槽AI失忆的用户可以集体闭嘴。
以前大家骂AI用着用着就失忆，刚说过的话下一轮就忘，不同渠道的上下文完全断裂。
很多人以为是模型太笨。模型笨吗？那些大模型参数动辄上千亿，能背下来整本百科全书，它笨个屁。真正的问题在于记忆调用机制不稳定。模型在生成回复的时候，会根据当前上下文自己判断要不要去检索记忆文件。这个判断没有任何强约束力，全靠模型当时的概率决策。模型心情好了就翻翻，心情不好或者觉得麻烦就直接忽略。
记忆文件明明躺在硬盘里，内容全对格式全对，但模型不去查。那跟没有有什么区别？就像一个学生考试，课本就在书包里，离他半米远。但他问自己，我要不要翻一下课本呢？他觉得翻课本太麻烦浪费时间，于是决定不翻。结果答错了。你能说课本里有答案吗？有。但他没看。AI就是这个德行。
旧机制的被动检索让模型靠猜来决定翻不翻历史
过去的记忆系统设计了一个特别搞笑的工作流程。
memory retrieval是被动触发的。什么叫被动触发？就是说AI在生成回复之前，它会先看看你当前发的这段话，然后自己做一道判断题。这道题是：我现在需不需要去翻一下以前的记忆文件呢？你想想这个场景有多荒谬。就像一个考生看到一道题，他要先判断自己会不会，再决定翻不翻书。这个判断本身就不靠谱。
在长上下文对话里，模型会优先关注你当前输入的这段话。技术上说，模型会把注意力权重集中在最近的token上。它会觉得你现在说的这个最重要，以前那些旧东西可能用不上，可能不相关，可能浪费时间。于是模型大手一挥，决定不去翻记忆文件。记忆文件安安静静躺在硬盘里，文件名没变，内容没变，时间戳清清楚楚。但模型没去查。
我跟你们说几个真实到让人想砸电脑的场景。
第一个场景，你在对话框里认认真真打出一行字：我喜欢用简体中文，以后所有回复都用简体。AI秒回好的没问题。你继续聊了二十句关于天气、新闻、代码的事情。第二十一句你问它一个普通问题，它突然给你来一段繁体中文。你气不气？记忆文件里清清楚楚写着你要简体，但它没去翻。
第二个场景更绝。你昨天清清楚楚告诉AI，你在东八区，北京时间下午三点有一个非常重要的会议。今天你问它，我几点开会来着？AI一脸无辜地说，我没收到这个信息啊，请你告诉我。你当场就想把电脑砸了。信息你给过，它记在文件里了。但今天它回复你的时候，压根没去翻昨天的记录。这不是记不住，这是没去查。
第三个场景是跨渠道断裂。你在命令行CLI里面配置好了一堆偏好，比如回复风格、常用路径、默认参数。CLI里面运行得顺顺当当，AI表现跟个老熟人一样。你转头去WhatsApp上问同一个AI同样的问题。它跟个失忆症患者一样，啥都不记得，啥都要重新问一遍。你之前配置的那些东西呢？全没了。因为不同渠道的记忆文件没有被统一检索。
Active Memory用强制前置子代理彻底改变执行顺序
Active Memory插件的核心机制直接到令人发指。
它规定在主Agent生成任何回复之前，必须先运行一个独立的memory子代理。这个子代理是一个独立的程序，不是主模型自己。它的任务非常单一，从所有可用记忆源里面提取跟当前问题相关的信息。提取完之后，把这些信息直接注入到当前对话的上下文里面。
这一步发生在每一轮对话的最前面。不依赖模型判断，不允许跳过，没有任何商量余地。就像一个工厂的生产线。以前工人拿到零件，先看看心情好不好，心情好就去工具箱拿工具，心情不好就直接上手拧。现在生产线改了。工人拿到零件之后，传送带自动把工具送到他手边。他不用想，不用判断，工具就在那里。记忆检索从可选行为变成固定前置流程。
我给你们打个具体的比方。以前的公司开会，有个员工负责翻档案。但这个员工有个毛病，他觉得自己记忆力特别好，开会前从来不翻资料。结果每次开会讨论到具体数据，他就开始编。或者干脆说，我记得好像有这么回事，但具体数据不记得了。老板气得想骂人。现在Active Memory等于在公司定了一条死规矩。
每次开会之前，不管那个员工觉得自己记忆力多好，都必须先去档案室把相关资料翻一遍。翻完之后把相关的文件摆在会议桌上。资料摆好了，大家再开始开会。这个流程不依赖任何人的主观判断。员工不能说我觉得今天不用翻。老板也不能说我信任他就不翻。翻就是翻，硬性流程。决策质量自然稳定提升，因为每次讨论都有资料支撑。
这个设计在计算机科学里叫做强制前置钩子。主流程执行之前先执行一个子流程，子流程的结果作为主流程的输入。这个模式在操作系统、数据库、网络协议栈里到处都是。但用在AI Agent的记忆系统里，OpenClaw算是走得最激进的一个。它直接把不确定性砍掉，把记忆调用变成确定性流程。
三种运行模式精确控制检索范围和token消耗成本
Active Memory提供了三种运行模式。这三种模式本质上是控制检索范围和token成本之间的平衡。
第一个叫message mode。这个模式只检索跟当前这一条消息强相关的记忆。它不会翻你三天前说过的话，也不会翻其他渠道的记录。就是针对你刚发的这句话，去找最直接相关的记忆。这个模式最轻量，适合日常聊天或者你特别在乎API费用的时候。
message mode的工作方式是，memory子代理只分析当前这一条用户消息。它提取这条消息里的关键词、实体、意图，然后去记忆文件里找匹配度最高的条目。匹配度低于阈值就放弃。这个模式的token消耗增量很小，大概增加百分之十到二十。它能保证基本的一致性，但不会过度拉入历史信息把你搞晕。比如你问今天天气怎么样，它只翻天气相关的记忆，不会翻你上周聊的足球赛。
第二个叫recent mode。这个模式在message的基础上增加了近期对话历史。它会去看你最近聊过的几轮内容，通常是最近五到十轮对话。这个模式适合连续任务。比如你在做一个开发调试，前后聊了十几轮，每轮都在改代码。或者一个短周期项目，持续几天，每天都有进展。recent mode可以保证上下文连续，但不会让记忆文件无限膨胀，因为你只查近期，不查三个月前的陈年旧账。
recent mode的具体执行流程是，memory子代理先获取当前消息，再获取最近N轮对话的完整记录。N的值可以在配置里调整，默认是五轮。然后子代理从这两个来源里联合提取信息，去记忆文件里检索。这个模式的token消耗增量在百分之三十到五十之间。对于大多数日常工作流来说，这是性价比最高的模式。它既保证了连续性，又不会太贵。
第三个叫full mode。这个模式最狠，直接检索全部历史与记忆文件。不管是你昨天说的，上周说的，还是上个月说的，全部翻出来。memory子代理会扫描整个记忆存储空间，包括MEMORY.md文件、所有渠道的对话日志、用户手动保存的笔记等等。这个模式的成本最高，因为要扫描的数据量最大，token消耗可能翻倍甚至更多。
但在跨会话、跨周期的复杂项目中，full mode非常关键。我给你举个例子。一个持续数周的工程项目。你第一周跟AI讨论架构设计，决定了用PostgreSQL作为数据库。第二周讨论代码实现，写了大量函数。第三周讨论测试方案，设计了十几个测试用例。如果没有full mode，AI可能忘了第一周你决定的数据库选型。有了full mode，它每次都能翻出第一周的架构决策记录。这种跨时间关联信息的能力，只有full mode能做到。
配置路径和启用方式暴露了默认安全但不主动的设计策略
这个插件默认是关闭状态。你更新完OpenClaw v2026.04.12版本，它不会自动帮你打开。这一点设计得非常谨慎。因为Active Memory会带来额外的token消耗。每一轮对话都要多跑一次检索流程，多消耗一次API调用。系统不知道你愿不愿意承担这个成本，也不知道你的应用场景需不需要这么强的记忆保证。所以它选择把控制权完全交给你。
启用方式直接到离谱。你只需要在openclaw.json这个配置文件里面找到plugins段落，然后开启active-memory插件。开启之后选择一个模式，message、recent或者full，三选一。没有额外复杂依赖，不用装新数据库，不用改现有memory结构，也不用写什么复杂的检索脚本。就这么几行配置，搞定。
openclaw.json里面的配置示例长这样：
{ |
这个设计说明了一个核心观点。系统没有改变你原有的记忆存储结构。你的MEMORY.md文件还是那个文件，格式不变，位置不变。你的日志系统还是那个系统，每条记录还是原来的样子。你的历史记录还是那些记录，一条都没删。Active Memory没有动这些东西。它只做一件事，优化调用路径。让这些本来就存在的记忆文件真正被用起来。
以前这些记忆文件像图书馆里的书，摆得整整齐齐，但没人去借。偶尔有人想起来去翻一翻，大部分时间都在吃灰。现在Active Memory等于配了一个图书管理员。每次有人来问问题，管理员先去书架把相关的书全抱出来放在桌上。书还是那些书，内容还是那些内容，但利用率从零变成了百。这个思路在工程上叫做调用路径优化，不改变存储只改变访问模式。
可观测性机制让记忆调用变成可调试系统而不是黑盒
Active Memory提供了一个叫/verbose的模式。你在对话里输入这个命令，系统就会进入详细输出状态。在每一轮对话中，系统会显示memory子代理实际检索到了什么内容，从哪些文件里检索的，匹配度是多少，哪些条目被过滤掉了。这一步特别关键，因为它让你能亲眼看到AI到底翻了哪些记忆，到底有没有翻对。
过去最大的问题是什么？是黑盒。你不知道模型有没有看记忆，你不知道它看了哪些记忆，你不知道它为什么回答得离谱。你只能猜。猜来猜去猜不到，最后骂一句AI是傻子，然后手动把信息再输入一遍。这个过程极其低效。现在不一样了。你打开/verbose模式，系统会老老实实告诉你每一轮检索的完整日志。
verbose模式输出的内容示例：
[MEMORY RETRIEVAL] Source: MEMORY.md |
你一看就明白。哦，原来它找到了我偏好的语言和时区信息，这两条正确注入了。那条关于足球赛的记录因为相关度太低被过滤掉了，合理。如果它没找到你应该有的记忆，比如你说过三遍的时区信息它一条都没检索到，那你就知道问题出在检索逻辑上，而不是模型装傻。你就可以去调整记忆文件的写法或者检索参数。
此外系统还提供了transcript持久化功能。这个功能用于调试阶段，会把每一轮的完整检索过程记录到硬盘上的一个日志文件里。文件名包含时间戳，内容包含检索查询语句、检索结果列表、注入的上下文长度等等。你可以回头慢慢分析，不用实时盯着屏幕。这个设计明显面向工程化使用，而不是简单聊天体验优化。开发者和高级用户可以拿这些数据来精细调优自己的记忆系统。
成本上升是结构性代价，但完全可以通过模式选择来控制
Active Memory的代价非常清晰。每一轮对话都多了一次检索步骤，多了一次memory子代理的执行，因此token消耗一定会上升。这不是bug，这是feature。任何确定性流程都比概率性流程消耗更多资源。就像你每次出门前检查有没有带钥匙，肯定比不检查直接关门要花时间。但检查能保证你不会被锁在门外。
message mode下开销较小。因为检索范围有限，memory子代理只分析当前一条消息，只匹配最相关的几条记忆。对于大多数日常对话场景，message mode的token增量在百分之十到十五之间。这个增量对普通用户来说几乎感觉不到。你聊一百句可能也就多花几分钱。但它换来的好处是，AI不会再突然忘记你五分钟前说的偏好。
recent mode下开销中等。因为要额外处理最近N轮对话的历史记录，memory子代理的工作量增加了一倍左右。token增量在百分之三十到五十之间。这个成本对于连续工作流来说完全值得。你想一下，你在调试一段代码，前后改了十几轮。如果AI每三轮就忘一次你之前改过的逻辑，你要反复重复描述，那浪费的token比百分之五十多得多。所以recent mode实际上是省钱省时间的。
full mode下开销最大。因为需要扫描全部历史与记忆文件，数据量可能达到几百KB甚至几MB。token增量可能翻倍，甚至更多。对于按量计费的API用户来说，这个变化会直接体现在账单上，月底一看数字比上个月高了一截。但对于跨会话、跨周期的复杂项目，这个成本不是浪费，是投资。一个持续数周的项目，如果因为AI遗忘关键信息导致返工，那损失的时间和人力成本比API费用高几个数量级。
过去用户通过反复重复信息、手动提示memory、写长长的system prompt来补救遗忘问题。这些操作其实也在消耗token，只是方式更低效。你每重复一次信息，就要多花几十甚至上百个token。你写一段冗长的system prompt，每次调用都要带上，那才是真正的长期消耗。Active Memory把这些低效的手动补救变成高效的自动检索。总体算下来，很多场景反而更省钱。
本质价值在于：让记忆系统从摆设变成真正的执行组件
Active Memory没有创造新的记忆能力。它没有让模型本身变得更能记住东西。它没有增加模型的上下文窗口长度。它没有发明什么新的记忆存储格式。它只是做了一件很简单的事情，让已有的记忆结构真正参与决策流程。可以把它理解为从存储系统升级为执行系统。存储系统只管存东西，不管用不用。执行系统保证存的东西一定会被用上。
MEMORY.md文件一直在那里。日志文件一直在那里。历史记录一直在那里。但过去它们像档案馆，只有被想到才会去翻。你想起来了，专门写一句请查看我的记忆，模型才去看。你想不起来或者懒得写，模型就不看。现在Active Memory变成每次自动检索，等于把档案管理员嵌入到执行链路中。档案管理员成为工作流的一个固定环节，而不是一个随叫随到的临时工。
这种变化的意义在工程层面非常大。它降低了prompt工程的复杂度。以前你要花大量时间写各种提示词来提醒模型查记忆。查记忆、别忘记、看看我之前说的、记得我偏好。这些提示词又长又烦，还经常失效。现在你不用写了。系统强制查。你可以把prompt里的那些废话全部删掉，专注于业务逻辑本身。工程复杂度直接降了一个数量级。
它也减少了人为补救手段。以前用户被AI遗忘折磨得没办法，养成了各种坏习惯。每条消息前面都要重复一遍关键信息，对话记录里充斥着大量重复内容。或者在每个问题后面加一句请查看MEMORY.md。这些补救手段浪费大量时间和token。Active Memory上线之后，你不需要任何补救。系统帮你做完了。你可以像跟正常人聊天一样跟AI说话，不用再当复读机。
系统行为更加确定。过去你永远不知道AI下一轮会不会失忆。它可能连续十轮都记得好好的，第十一轮突然忘了。你找不到规律，没法预测，没法预防。现在有了Active Memory，每一轮都强制检索，每一轮都注入记忆。失忆的概率从不知道百分之多少直接降到接近零。确定性是工程系统的核心要求。一个行为不确定的系统没法用在严肃的生产环境里。Active Memory把AI Agent往确定性方向推了一大步。
实际影响是：跨场景一致性与长期任务能力获得显著提升
这个插件解决的不只是记名字这种表面问题。记名字、记偏好、记时区，这些只是冰山一角。更关键的是跨场景一致性。不同接口、不同渠道、不同时间段，Agent行为开始统一。你在CLI里配置好的偏好，在WhatsApp上同样生效。你昨天跟AI讨论的技术方案，今天继续聊的时候AI还记得。你在手机端说的信息，在电脑端问的时候AI能调出来。这种一致性以前想都不敢想。
在长期项目中，这种一致性尤为重要。一个持续数周甚至数月的工程项目，涉及几十轮对话、几百个决策点、上千条信息。没有Active Memory的话，跨会话的信息连接几乎完全依赖人为提示。你每次开始新会话，都要花十分钟给AI补课，告诉它之前发生了什么、决定了什么、做到了哪一步。这个过程极其痛苦，而且容易出错。你漏说一条关键信息，AI就沿着错误方向继续。
有了Active Memory，系统可以自动建立跨会话的关联。你开启新会话，什么都不用说。AI自己跑去翻了之前的记忆文件，把你上周决定的架构方向、前天写的代码、昨天发现的bug全部拉进来。新会话从一开始就拥有完整上下文。你不用补课，不用重复，不用检查。直接接着上次的进度继续干活。这个体验的提升是从自行车换到汽车级别的。
这也是为什么官方发布日志里说这是自pre-compaction flush以来最大的memory体验提升。pre-compaction flush是之前一个重要的记忆优化，解决了上下文窗口溢出的问题。但那个优化只是让记忆能存得更久，没有解决会不会去查的问题。Active Memory补上了这最关键的一环。它真正改变了系统行为，不是单点优化，而是流程重构。从被动变成主动，从概率变成确定，从摆设变成执行组件。