OpenClaw 新插件 active-memory 到底值不值得装,我替你试明白了
看到OpenClaw创始人转发了很多用户使用active-memory插件后反馈的好评,好奇心驱使就去试了一试。

其实当我第一次看到 OpenClaw 新插件 active-memory,直觉以为它就是“更方便一点的 memory_search”。但看完文档之后,觉得这东西不是一个小修小补,它其实是在补 Agent 体验里一个很现实的缺口:
记忆系统明明已经有了,可大多数时候,它还是太被动。
以前的记忆系统通常依赖两种方式触发:要么用户自己说“帮我搜一下记忆”,要么主 Agent 自己判断这时候该去查 memory_search。问题就在这儿,很多真正自然的记忆场景,恰恰发生在你还没来得及明确提出“请查记忆”的那一刻。
active-memory 干的就是这件事。它是一个插件拥有的、阻塞式的 memory sub-agent。你可以简单理解成:在主回复真正生成之前,系统先给自己一次受限的、快速的记忆检索机会。
它的价值,不是“让系统能记住东西”,而是把记忆召回从被动动作,变成一次有条件自动触发的前置动作。

Active memory 原理
官方文档也明确强调,它只适合用户可见、持续存在的对话型会话,像 direct chat、持久聊天这类场景很适合;但一次性任务、后台 worker、heartbeat、内部 helper 就不适合开,因为这些路径更强调确定性和速度。
如果你想先跑起来,最稳妥的方式,是在 openclaw.json 里把 active-memory 插件打开,并把目标 agent 限定在 main,聊天类型限定在 direct。推荐配置里把 queryMode 设成 recent,promptStyle 用 balanced,timeoutMs 给到 15000,maxSummaryChars 设成 220。这样既不会太激进,也不会因为召回内容过长把主模型上下文挤爆。配完后重启 openclaw gateway,插件才会真正进运行态。配置方法参考如下:
{plugins: {entries: {"active-memory": {enabled: true,config: {enabled: true,agents: ["main"],allowedChatTypes: ["direct"],modelFallback: "google/gemini-3-flash",queryMode: "recent",promptStyle: "balanced",timeoutMs: 15000,maxSummaryChars: 220,persistTranscripts: false,logging: true}}}}}
配完之后,别忘了重启:
openclaw gateway restart
验证是否生效也别靠感觉。最直接的方法,是在当前会话里执行 /active-memory status,再打开 /verbose on 和 /trace on。
/active-memory status
如果插件真的在跑,正常回复后一般会附带两行诊断信息,一行告诉你这轮 active-memory 有没有执行、耗时多少、召回了多少字符;另一行则会给出一段人类可读的 debug 摘要。这个检查非常关键,因为 active-memory 不是“插件开了就一定跑”,它还要同时满足 agent 命中、聊天类型允许、会话类型合格这些前提。
其中queryMode 该怎么选,我的建议是:第一次装,先用 recent。message 虽然更快,但上下文太短;full 虽然更强,但延迟会明显增加。大多数真实对话里,recent 已经够用了,而且性价比最好。
如果让我一句话概括 active-memory,我会说:它不是在增强记忆库,而是在增强对话时机。很多人讨论记忆功能,习惯盯着“能不能存更多”“能不能搜更准”,但 active-memory 真正聪明的地方,其实是让系统在主回复前,先获得一次“主动想起点什么”的机会。对聊天型 Agent 来说,这一步很小,却很关键。
当然,它也不是无成本的。你会付出一点延迟,也会让回复链路变得更依赖配置边界。所以最好的用法,不是全局乱开,而是在真正需要连续感的主对话场景里,克制地开。
这才是它最合适的位置。
好了,今天的分享就到这里。
关注我,在AI浪潮中保持清醒,在生活节奏中守住健康
夜雨聆风