AI 記憶調用的工程學：四路存取路徑 × 十大場景全矩陣實測報告

核心問題： 一個每 24 小時重啟一次的 AI 助理，如何可靠地「記得一切」？
測試環境： Mac Studio M3 Ultra · 96GB RAM · 1,193 行長期記憶 · 18 隻港股深度調研 · 7 條存取路徑
方法論： 場景矩陣法 — 10 種真實使用場景 × 7 條存取路徑 = 70 格實測數據

前言：記憶不是一個問題，是十個

建立 AI 記憶系統的人，一開始都犯同一個錯：假設「記憶問題」是一個問題。

它不是。它至少是十個。

「老闆上次說什麼時候要跟進？」是任務追蹤問題。「為什麼我們不用 Lovable 建網站了？」是歷史決策問題。「Ray Leung 是誰？他跟我們什麼關係？」是人物關聯問題。「部署流程中的紅線是什麼？」是規則檢索問題。這些查詢的語義結構、時間跨度、資訊密度完全不同。

「沒有一條路徑能同時做好所有場景。記憶系統的工程挑戰不是選最好的那條，而是讓每種場景走對的路。」

本文將君澤智庫 AI 助理（UltraClaw）的完整記憶調用架構拆解為七條存取路徑，在十種真實日常工作場景中進行全矩陣對比測試，揭露每條路徑的適用邊界、致命盲點和最優組合方案。

一、七條記憶存取路徑

在我們的架構中，AI 助理可以通過以下七種方式讀取記憶：

P1 · 文件直讀

最原始但最可靠的方式。AI 通過 read tool 直接打開檔案系統中的 .md / .json / .txt 文件。

P2 · Qdrant 向量搜索

通過 vector-memory__mem_search 調用本地 Qdrant 實例（openclaw_mem collection），使用 BGE-m3 模型（1024 維）進行語義相似度檢索。

P3 · MemoryHub 捕獲管線

capture_daemon 每分鐘掃描 Session JSONL + daily log 文件，將對話片段和非結構化文本捕獲到 Qdrant（通過其自身的去重和嵌入管線）。可通過 memhub.best-thinktank.com/api/search API 進行關鍵詞搜索。

P4/P5 · agentmemory 搜尋

agentmemory 是基於 REST API 的外部記憶服務（localhost:3111），提供 memory_recall（BM25）和 memory_smart_search（混合搜索）兩種查詢路徑。

P6 · Session 歷史

通過 sessions_history 直接讀取原始 JSONL 對話記錄，精確還原歷史對話內容。

P7 · Bootstrap 注入

AI 啟動時自動預載 SOUL.md、USER.md、MEMORY.md、RULES.md、PERMANENT-RULES.md 等文件內容到上下文窗口。零延遲，零 API 調用。

二、十大記憶調用場景

這些場景提取自 UltraClaw 過去 34 天的實戰工作日誌，覆蓋了 AI 助理日常運作中的所有記憶需求類型：

場景分類邏輯： S1-S2 是每次對話的「必選動作」；S3-S9 是任務驅動的「按需查詢」；S10 是時間維度的「連續性需求」。三類場景對記憶系統的要求完全不同。

三、全矩陣實測結果

以下是七條路徑在十種場景下的命中率、精準度和完整性的實測對比。測試查詢均取自已發生的真實對話場景。

3.1 S1 · 啟動載入

查詢：「我是誰、老闆是誰、最近發生什麼」

🔬 洞察： Bootstrap 注入是 S1 的命脈。MEMORY.md 目前 1,193 行且持續增長中。即使門檻已從 12KB 提高到 80KB，仍有觸頂風險。Qdrant 向量搜索是最佳備援方案 — 當 Bootstrap 內容被截斷時，語義搜索可以補回被截部分。

3.2 S2 · 待辦跟進

查詢：「有什麼要提醒老闆的？」（測試文件中包含 12 項科技類 + 6 項業務類 + 2 項郵件待辦）

🔬 洞察： 這是結構化 vs 非結構化的經典對決。follow_up_tracker.json 是一個精心設計的 JSON schema，包含 T1-T14 的精確任務描述、優先級和狀態。向量搜索可以從語義空間中「感受」到任務的存在（命中率 20%），但永遠無法重建這個 schema。這不是技術限制 — 是資訊結構的根本差異。數字 schema 不活在語義空間中。

3.3 S3 · 專案狀態

查詢：「AIApps 項目進度如何？」

🔬 洞察： 專案狀態的最佳來源是 memory/projects/PROJECT.md（獨立維護） + MEMORY.md（Key Decisions 中的摘要）。Qdrant 能找到相關段落，但可能不是最新的。當專案進度以結構化方式維護時，文件是最佳路徑；當專案討論散布在對話中時，Qdrant + MemHub 才有增量價值。

3.4 S4 · 歷史決策

查詢：「為什麼我們放棄了 Lovable？」

🔬 洞察： 這是 Qdrant 的甜蜜點場景。歷史決策通常分散在長文件中（MEMORY.md 1,193 行），你不知道精確位置，甚至不知道是否存在。但「Lovable」這個關鍵詞 + 決策的語義特徵讓向量搜索一擊命中。文件直讀在此場景反而需要人工定位 — 你必須先知道答案在哪個文件，然後在 1,193 行中搜尋。

3.5 S5 · 踩坑查詢

查詢：「之前做 AK-SDD DI 披露易數據踩過什麼坑？」

🔬 洞察： 踩坑查詢有兩種子類型：「發現型」和「確認型」。發現型（「做 DI 之前有什麼坑？」）適合 Qdrant — 你不知道有哪些坑，語義搜索幫你發現。確認型（「9982 誤判停牌那個坑的具體原因？」）適合文件直讀 — 你知道要找什麼，需要精確內容。

3.6 S6 · 規則/流程

查詢：「部署流程是什麼？有什麼紅線？」

🔬 洞察： Bootstrap + 技能文件是規則查詢的完美方案。向量搜索在此場景的表現顯著低於其他場景 — 因為規則需要精確完整，不能靠「大概相似」。一條規則少一個步驟就可能是部署災難。

3.7 S7 · 人物/聯絡

查詢：「Ray Leung 是誰？他跟我們什麼關係？」

🔬 洞察： 人物資訊是最適合向量搜索的場景 — 你不知道這個名字出現在哪個文件（MEMORY.md？5/9 daily log？HKOW 專案文件？），但語義搜索能跨文件自動關聯。這是 Qdrant 的第二個甜蜜點。

3.8 S8 · 技術配置

查詢：「cloudflared tunnel 怎麼配置的？」

🔬 洞察： 技術配置場景，文件直讀和 Qdrant 表現相當。Qdrant 的獨特價值在於跨文件關聯 — 同一個查詢可以同時命中 tunnel 配置 + DNS 教訓 + LaunchAgent 配置，形成比單一文件更豐富的上下文。

3.9 S9 · 領域知識

查詢：「之前調研過哪些數據中心股票？」

🔬 洞察： 領域知識是 Qdrant 的第三個甜蜜點。查詢「數據中心」和記憶中的「1686.HK 新意網」在語義上高度相關，即使查詢詞和原文不完全一致。文件直讀的障礙在於需要知道答案在 Key Decision #50 且理解分類邏輯。

3.10 S10 · 跨 Session 連續性

查詢：「上次聊到一半的是什麼？」

🔬 洞察： Session 歷史是最權威的跨 Session 來源。MemHub daemon 的設計初衷就是補這個缺口 — 但目前的捕獲粒度太粗，只記「片段」不記「脈絡」，無法回答「聊到哪裡了」這種需要對話流的問題。

四、綜合評分矩陣

評分：10 = 完美，8-9 = 優秀，5-7 = 可用，3-4 = 勉強，1-2 = 不足，0 = 無效

五、五大核心洞察

洞察 1：文件直讀 + Qdrant 是黃金組合

文件直讀在「我知道要查什麼」（結構化場景 S2/S6）中無敵；Qdrant 在「我不知道答案在哪個文件」（發現型場景 S4/S7/S9）中無敵。兩者覆蓋了 9/10 場景的高品質需求。 它們不是競爭關係，是互補關係 — 就像參考書和搜索引擎，一個給你精確答案，一個告訴你去哪找。

洞察 2：結構化 vs 非結構化的鴻溝無法用向量跨越

這是本次測試最深刻的發現。follow_up_tracker.json 中的 T1-T14 任務清單是一個人工設計的 JSON schema。向量搜索可以從語義空間中「感受」到「有待辦事項」，但永遠無法還原 T1（ES 容器 OOM 修復）、T2（PG 向量字串化 Bug）、T3（Daemon 啟動阻塞）之間的獨立性和優先級關係。

「數字屬性是 schema 的產物，不是語義的產物。」

一個記憶系統如果只依賴向量搜索，它在結構化查詢場景（S2 待辦跟進、S6 規則檢索）中必然失能。向量記憶是必要的，但不是充分的。

洞察 3：MemoryHub 捕獲管線的設計偏離了核心需求

MemoryHub capture daemon 的核心設計是「被動記錄對話片段」→「事後全文搜索」。但在實戰中，AI 助理真正需要的記憶能力是：

• 結構化任務狀態 — daemon 不掃描 follow_up_tracker.json
• 跨文件關係關聯 — daemon 不建立實體圖譜
• 即時上下文查詢 — API 延遲 500ms+，對於啟動載入太高

它目前更像一個「記憶黑盒」而非「記憶工具」。這不是說它沒價值 — 它在 S10（跨 Session 連續性）中提供了一定程度的跨對話可見性 — 但它的設計假設（「被動捕獲就夠了」）與實際需求（「主動索引 + 結構化理解」）之間存在顯著鴻溝。

洞察 4：agentmemory 應從啟動流程中降級

兩輪獨立的對比測試（共 20 次查詢）中，agentmemory 對中文查詢的命中率為 0%。

根因在於它的設計假設：agentmemory 是為 Claude Code 等英文 coding agent 設計的，通過 hooks 自動捕獲 session → 自然累積記憶。但我們的記憶語料是繁體中文、結構化混雜、領域特定（港股、併購、香港法律）。agentmemory 的嵌入模型和搜索算法從未被調優來處理這類數據。

建議：保留 agentmemory 但從 HEARTBEAT.md 和啟動流程中移除強制檢查項。它不是壞工具，只是不適合我們的場景。

洞察 5：Bootstrap 注入是隱形 MVP

SOUL.md + USER.md + MEMORY.md + RULES.md + PERMANENT-RULES.md 的自動注入，在 S1（啟動載入）、S6（規則流程）和部分 S3（專案摘要）中提供了完全零延遲的記憶可用性。

這是整個架構中 ROI 最高的機制：零查詢成本、零維護成本、每次對話自動可用。但它有天花板 — 文件增長會觸發截斷。解決方案不是無限制提高門檻（context window 不是免費的），而是讓 Qdrant 向量備援補上被截斷的部分。

六、場景路由：讓每種查詢走對的路

基於以上洞察，提出一個三層路由的記憶調用策略：

查詢進來
    │
    ├─ 結構化查詢（S2 待辦、S6 規則）
    │     → P1 文件直讀（follow_up_tracker.json / RULES.md）
    │
    ├─ 發現型查詢（S4 決策、S7 人物、S9 領域知識）
    │     → P2 Qdrant 向量搜索 + P1 文件確認
    │
    └─ 對話連續性（S10）
          → P6 Session 歷史（短）+ P3 MemHub（中）+ P1 Daily Log（長）

路由邏輯： 結構化用文件，發現型用向量，連續性用時間線。不讓向量搜任務清單，也不讓文件搜跨文件關聯。

七、優化路徑圖

🥇 P0 — 立即見效（代碼量最小，效果最大）

🥈 P1 — 中期改造（架構級改進）

🥉 P2 — 長期願景（範式升級）

📈 預期提升量化

S2 待辦跟進（現狀 → P0 → P1）：
  文件 100% → 100% → 100%
  Qdrant 20%  → 70%   → 90%
  MemHub 5%    → 60%   → 90%

S4 歷史決策（現狀 → P0 → P1）：
  文件 70% → 70%  → 80%
  Qdrant 90% → 95%  → 95%
  MemHub 30% → 60%  → 70%

S10 連續性（現狀 → P1 → P2）：
  Session 100% → 100% → 100%
  自動推送    0%  → 30% → 80%  ← 從 0 到 1

結論：記憶不是一個數據庫，是一個路由系統

這次全矩陣測試得出的核心結論，可以歸納為一句話：

「好的記憶系統不是選一個最好的數據庫來存所有東西。它是讓每種類型的記憶需求走最適合它的路。」

文件直讀適合精確結構化查詢。Qdrant 向量搜索適合跨文件語義發現。Bootstrap 注入適合零延遲身份和規則。Session 歷史適合對話連續性。MemoryHub 適合自動捕獲。

五條路徑，五個角色。當它們被當作獨立方案比較時，每條都有盲點。當它們被當作路由系統的節點時，每條都在補另一條的不足。

這不是技術選擇問題。這是架構設計問題。

方法論披露： 本文所有測試數據來自君澤智庫 AI 助理（UltraClaw）在 2026 年 5 月 23 日的實戰測試。測試查詢均基於過去 34 天工作日誌中的真實場景。評分為主觀+客觀混合 — 命中率和延遲為實測數據，精準度和完整性為人工評估。

測試限制： agentmemory 的路徑測試受限於其僅索引約 50 條手工導入的記憶（vs Qdrant 的 1,156 條）。如果對 agentmemory 進行同等規模的全量導入，結果可能有所不同 — 但考慮到其設計初衷（英文 coding agent 語境），我們認為即使擴大數據量，中文語義搜索的結構性問題不會根本改變。