[Feature Request] Dreaming 功能支援 - 三種實作策略分析與可行性評估

[jlin53882]

問題描述

在 OpenClaw UI 中啟用 Dreaming 設定時，出現錯誤：

Selected memory plugin 'memory-lancedb-pro' does not support dreaming settings.

經分析，問題根因是 memory-lancedb-pro 的 configSchema 缺少 dreaming 設定區塊，導致 OpenClaw UI 驗證失敗。

相關 Issue： #565

---

功能需求

作為 memory-lancedb-pro 的使用者，我希望能夠在 OpenClaw 中啟用 Dreaming 功能，以便：

• 自動執行記憶整合與 consolidation
• 將重要記憶從短期晉升到長期記憶
• 獲得類似 memory-core 的 Dreaming 體驗

---

實作策略分析

針對這個需求，我設計了三種不同深度的實作策略：

Strategy A：完整實作（工作量最大）

核心理念： 完全移植 memory-core 的 Light/Deep/REM 三階段架構到 LanceDB

架構：

src/dreaming/
├── index.ts              # 主入口
├── phases/
│   ├── light-phase.ts    # Light Phase - 收集候選記憶
│   ├── deep-phase.ts     # Deep Phase - 評分晉升
│   └── rem-phase.ts      # REM Phase - 主題反思
├── signals.ts            # Phase Signal 管理
├── scheduler.ts          # Cron 調度器
├── state.ts              # 狀態管理
└── types.ts              # 類型定義
src/dream-store.ts        # LanceDB Dream 集合

預估工作量： ~1700 行新程式碼

優點：

• 功能完整，符合 Dreaming 的完整定義
• 獨立的 Dream Store 和 Phase Signals
• 與 memory-core 的 Dreaming 完全相容

缺點：

• 工作量極大
• 需要維護新的程式碼模組
• 複雜度高

---

Strategy B：橋接模式（工作量中等）

核心理念： 將 Dreaming 操作對應到現有的 memory-lancedb-pro 功能

對應關係：

Dreaming Phase	現有功能對應
Light Phase	autoCapture + smartExtraction
Deep Phase	tierManager.evaluateAll() + decayEngine
REM Phase	memoryReflection (sessionStrategy)

架構：

src/dreaming/
├── index.ts              # 橋接服務主入口
├── types.ts              # 最小類型定義
├── compatibility.ts      # UI 相容性層
└── bridge-tools.ts       # 橋接工具

預估工作量： ~490 行

優點：

• 工作量適中
• 複用現有功能，不需要新資料庫
• 可以提供部分的 Dreaming 功能

缺點：

• Dream Diary 和 Phase Signals 是模擬的
• 與真正的 Dreaming 有差異

---

Strategy C：提示模式（工作量最小）

核心理念： 只需要新增設定區塊，讓 UI 不再報錯

預估工作量： ~50 行

優點：

• 最少工作，快速解決 UI 報錯問題
• 容易實作和維護

缺點：

• 沒有實際功能
• UI 狀態是假的

---

三種策略比較

面向	Strategy A	Strategy B	Strategy C
程式碼量	~1700 行	~490 行	~50 行
新檔案	8 個	4 個	0 個
LanceDB 集合	新建 dreams/signals	無	無
功能完整度	100%	60%	0%
工作時間	數天	6-8 小時	30 分鐘

---

問題與討論

1. 官方是否有計畫支援 Dreaming 功能？

2. 這三個策略中，哪個方向較符合專案的發展方向？

   • 如果注重功能完整性 → Strategy A
   • 如果注重開發效率 → Strategy B
   • 如果只是快速修復 → Strategy C

3. 是否有任何技術限制或設計考量會阻礙這些實作？

4. 關於 Bridge Mode 的設計：

   • 如果採用 Strategy B，是否可以接受「Dream Diary 是模擬生成」？
   • 還是必須要有真實的 Dream Store？

5. 長期規劃：

   • 官方是否希望 memory-lancedb-pro 與 memory-core 保持功能對等？
   • 還是兩個插件可以有各自的特色功能？

---

參考資料

• OpenClaw Dreaming 文件：https://docs.openclaw.ai/concepts/dreaming
• Issue "memory-lancedb-pro" does not support dreaming settings #565："memory-lancedb-pro" does not support dreaming settings #565
• Issue openclaw最新版的 dreams 不兼容 #571：openclaw最新版的 dreams 不兼容 #571

---

願望清單

• 官方回覆可行性評估
• 確認採用的實作策略
• 規劃實作時間表

[jlin53882]

memory-lancedb-pro_Dreaming相容性分析報告_2026-04-09.md
memory-lancedb-pro_Dreaming_實作方案_A_完整實作.md
memory-lancedb-pro_Dreaming_實作方案_B_橋接模式.md
memory-lancedb-pro_Dreaming_實作方案_C_提示模式.md
memory-lancedb-pro_Dreaming_實作方案_總覽.md
這裡面是一些 對memory lancedb pro 完整分析一些可以實現的方案 ，請你們評估一下方案，有沒有機會可以實現，或是建議，我自己 覺得 C 單純只是解決表面問題，所以C 方案可以先不用看 ，簡易內容都在上述PR 中。