Plugin Version
1.1.0-beta10
OpenClaw Version
2026.3.23
Bug Description
发现最近lancedb-pro数据库增长速度过快，猜测有错误的loop不断错误得写入lancedb-pro的数据库。
这是GPT5.4帮我总结的：
我基本查清了，罪魁祸首是 memory-lancedb-pro 现在启用的“新会话摘要入库”链路。
• 你当前配置里，/root/.openclaw/openclaw.json:300 是 sessionStrategy: "systemSessionMemory"；这会注册 /new 的 hook，把会话摘要直接写进 LanceDB。
• 真正写垃圾的代码在 /root/.openclaw/workspace/plugins/memory-lancedb-pro/index.ts:3256，它在 command:new 时触发；构造的文本就是：
• /root/.openclaw/workspace/plugins/memory-lancedb-pro/index.ts:3320
• Session: ...
• Session Key: ...
• Session ID: ...
• Conversation Summary: ...
• 这条记录被当成普通 fact 存进去，metadata 里还明确标了 type: "session-summary"，见 /root/.openclaw/workspace/plugins/memory-lancedb-pro/index.ts:3351。
• 所以你在 memory_list 里看到的一串 Session: 2026-04-02 ... 脏记忆，不是幻觉，也不是 cron 误报；它们就是这条 hook 批量写进去的实物。
• memoryReflection.storeToLanceDB = false 在这里挡不住，因为那是另一条链路；换句话说，昨晚你怀疑“明明关了 reflection 入库怎么还在进垃圾”，答案是：进垃圾的主要不是 reflection，而是 systemSessionMemory。
• 次级污染源也有：reflection 产物里确实仍带 Session Key/Session ID 头，见 /root/.openclaw/workspace/plugins/memory-lancedb-pro/src/reflection-store.ts:135。不过那部分理论上落在 reflection 语义层，危害没有 systemSessionMemory 这条大。
还有两个细节也印证了这个判断：
• 插件自己已经知道要排除 session-summary，比如 tier 维护时专门过滤了它，见 /root/.openclaw/workspace/plugins/memory-lancedb-pro/index.ts:1869。
• recall 注入时也会跳过 archive/reflection 层，见 /root/.openclaw/workspace/plugins/memory-lancedb-pro/index.ts:2266；说明作者本来也知道这类东西不该参与正常召回，但问题在于它们还是被持续写入主库、污染 recent memories 和整体信噪比。
我对“到底是什么东西导致的”现在的判断是：
• 主因：sessionStrategy = systemSessionMemory
• 触发时机：每次 /new / /reset
• 写入内容：带 Session Key / Session ID / Conversation Summary 的整段会话摘要
• 表现结果：大量 fact:agent:main 垃圾记忆，最近列表里连续出现
• cron 的角色：只是把这个问题复盘出来，不是写入源
Expected Behavior
应该避免这些无用信息入库
Steps to Reproduce
见上
Error Logs / Screenshots
Embedding Provider
Jina
OS / Platform
ubuntu
Plugin Version
1.1.0-beta10
OpenClaw Version
2026.3.23
Bug Description
发现最近lancedb-pro数据库增长速度过快，猜测有错误的loop不断错误得写入lancedb-pro的数据库。
这是GPT5.4帮我总结的：
我基本查清了，罪魁祸首是 memory-lancedb-pro 现在启用的“新会话摘要入库”链路。
• 你当前配置里，/root/.openclaw/openclaw.json:300 是 sessionStrategy: "systemSessionMemory"；这会注册 /new 的 hook，把会话摘要直接写进 LanceDB。
• 真正写垃圾的代码在 /root/.openclaw/workspace/plugins/memory-lancedb-pro/index.ts:3256，它在 command:new 时触发；构造的文本就是：
• /root/.openclaw/workspace/plugins/memory-lancedb-pro/index.ts:3320
• Session: ...
• Session Key: ...
• Session ID: ...
• Conversation Summary: ...
• 这条记录被当成普通 fact 存进去，metadata 里还明确标了 type: "session-summary"，见 /root/.openclaw/workspace/plugins/memory-lancedb-pro/index.ts:3351。
• 所以你在 memory_list 里看到的一串 Session: 2026-04-02 ... 脏记忆，不是幻觉，也不是 cron 误报；它们就是这条 hook 批量写进去的实物。
• memoryReflection.storeToLanceDB = false 在这里挡不住，因为那是另一条链路；换句话说，昨晚你怀疑“明明关了 reflection 入库怎么还在进垃圾”，答案是：进垃圾的主要不是 reflection，而是 systemSessionMemory。
• 次级污染源也有：reflection 产物里确实仍带 Session Key/Session ID 头，见 /root/.openclaw/workspace/plugins/memory-lancedb-pro/src/reflection-store.ts:135。不过那部分理论上落在 reflection 语义层，危害没有 systemSessionMemory 这条大。
还有两个细节也印证了这个判断：
• 插件自己已经知道要排除 session-summary，比如 tier 维护时专门过滤了它，见 /root/.openclaw/workspace/plugins/memory-lancedb-pro/index.ts:1869。
• recall 注入时也会跳过 archive/reflection 层，见 /root/.openclaw/workspace/plugins/memory-lancedb-pro/index.ts:2266；说明作者本来也知道这类东西不该参与正常召回，但问题在于它们还是被持续写入主库、污染 recent memories 和整体信噪比。
我对“到底是什么东西导致的”现在的判断是：
• 主因：sessionStrategy = systemSessionMemory
• 触发时机：每次 /new / /reset
• 写入内容：带 Session Key / Session ID / Conversation Summary 的整段会话摘要
• 表现结果：大量 fact:agent:main 垃圾记忆，最近列表里连续出现
• cron 的角色：只是把这个问题复盘出来，不是写入源
Expected Behavior
应该避免这些无用信息入库
Steps to Reproduce
见上
Error Logs / Screenshots
Embedding Provider
Jina
OS / Platform
ubuntu