可治理的 Agent Memory：分層、審批與 catalog 注入

方法論答卷 B：知識不是越自動越好，而是越可見、可審、可關閉越好。操作步驟見 使用者指南 §15。

系列位置

完整導讀見 系列導讀與產品定位。

一、問題定義：自動 Memory 與無審批 RAG 為何不足

許多 AI 產品把「記住使用者說過的話」當成預設能力：對話結束就寫入向量庫，下次檢索相似片段塞回 prompt。對數據分析場景，這會帶來三類風險——不是模型不夠聰明，而是記憶缺乏治理：

1. 不可見：使用者不知道模型「以為」哪些規則成立。
2. 不可控：錯誤推論或幻覺可能被當成長期事實。
3. 不可關閉：合規或敏感專案需要明確切斷記憶注入。

Lantide Data 的立場是：只有經使用者核准、寫入正式知識檔的內容，才進入 Agent 上下文；其餘建議停留在佇列，直到 Apply 或 Dismiss。

部分產品透過「越問越懂 schema／業務規則」做會話內自適應記憶——方便，但跨專案口徑一旦寫錯，代價高於「少記一點」。Lantide 選擇 Queued Knowledge + 人工 Apply：口徑須 evidence_quote 可驗、核准後才注入，與 工作流 §三 SQL-first 互補——知識檔沉澱的是已審閱的口徑，不是 Insights 終端的副產品。

二、分層 · 分型 · 審批

2.1 兩層知識

專案知識僅在該專案被 focus 且 Agent Memory Enabled 時注入。

2.2 Rules 與 Info

每份知識檔固定兩區（舊版四區會在讀取時遷移）：

## Rules    ← 約束、流程、分析／呈現偏好（要怎麼做）
## Info     ← 定義、背景、欄位語意（是什麼）

萃取入佇列時標記 Type：rule 或 info，核准後寫入對應區塊。

2.3 總開關 Enabled 與 Automatic suggestions

• **Enabled（總開關）關閉後：**不背景萃取、不注入、不顯示佇列紅點；Agent 提案與受控寫入一併暫停。Agent 行為等同無記憶庫。
• **Automatic suggestions 關閉（Enabled 仍開）：**不跑對話結束後的背景萃取 LLM／入隊；已核准知識仍注入，手動編輯與佇列審批仍可用；Agent propose_knowledge 仍可入隊。

詳見 §15.3。

三、兩段式知識流

flowchart LR
  chat[對話結束]
  extract[LLM 萃取建議]
  queue[Queued Knowledge]
  apply[Apply User / Project]
  file[Rules + Info 知識檔]
  inject[下一輪注入 prompt]
  chat --> extract --> queue
  queue -->|Apply| apply --> file --> inject
  queue -->|Dismiss| dismissed[記錄 hash 不再建議]

原則： 佇列項目永遠不直接進模型；只有寫入磁碟知識檔後才注入。

四、Queued Knowledge：審核入口

4.1 萃取規則

在 Enabled 與 Automatic suggestions 皆開啟、且 LLM 可用時，對話正常結束後背景執行：

• 僅掃描最近一輪中的 user 訊息（預設最近 8 條）。
• System instruction（Execute Plan、Resolve Comments、HTML Report 指令等）不參與萃取。
• 每條建議須含 evidence_quote（使用者原話引述），後端校驗引述必須出現在上述 user 訊息中，否則丟棄。
• 每輪最多入隊 3 條。
• 有聚焦專案時，建議偏 project 層並預填專案 ID。

僅關閉 Automatic suggestions 時跳過上述背景流程；不影響已核准知識注入。

4.2 去重與取代

與已核准知識、pending 佇列、同專案知識檔做語意比對；重複則略過。若為更新表述，可 supersedes 取代語意相同的舊 pending 項。Dismiss 後會記錄 hash，避免反覆建議同一條。

4.3 Agent 主動提案（propose_knowledge）

分析中 Agent 可呼叫 propose_knowledge 將可重用口徑／欄位規則送入同一 Queued Knowledge 佇列。與被動萃取相同：核准前不注入。

與 Query Step Ledger 的分工：

提案可附 evidence_quote 作審閱依據，但不要求逐字驗證；禁止把 SQL、快取表名等執行態內容寫進知識檔；頻控與契約細節見 AI Agent 架構 §八。

4.4 核准操作

Agent proposed 與 Chat extraction 共用同一佇列。入隊後可在兩處審批：

• 對話串流知識提案卡片 — User / Project / Dismiss（不暫停 ReAct，與 ask_user 不同）；卡片依佇列狀態持久化，重載對話後仍同步；有聚焦專案時 Project 預設寫入該專案。
• Queued Knowledge 分頁 — Apply to User、Apply to Project（Pick project 項須手動選專案）或 Dismiss；批次 Process all 會跳過仍須手動選專案的項目。

列表僅顯示 pending 項，並區分來源；套用後自列表移除屬預期。聊天卡片與 Agent Memory 透過佇列變更事件雙向刷新；成功套用時 toast 標明 User 或 Project 落點。

操作介面見 §15.5。

五、知識檔契約

5.1 條目結構

• 以 Markdown 頂格 bullet 為主；可有一層縮排子條（目錄模式）。
• 葉條目：實際規則／事實正文；僅作分組標題的父行不計入 Library status 的 Rules/Info 計數。
• Save 上限 8,000 字元（與注入預算 6,000 / 20,000 不同）。

5.2 Library status

編輯器右側顯示 Rules/Info 葉條目數、字元數／注入上限、Last updated、Mode（flat / catalog）。統計以磁碟已儲存內容為準；未 Save 時提示 Counts update after Save。

六、Apply 與 Reorganize

6.1 Apply

核准後合併至對應 ## Rules 或 ## Info，新條目常以單行頂格 bullet 寫入，待下次 Reorganize 整理。User 與 Project 落點不同，勿在錯誤分頁查找。已 Dismiss 或已 processed 的佇列項再次 Apply 時不會重複寫檔（重複操作安全）；前端以 Already dismissed / Already saved 提示，而非假成功。

6.2 手動 Reorganize

對目前左側選定的 User 或 Project 檔觸發 LLM：去重、濃縮贅字、依字數決定是否收成「短目錄標題 + 縮排子條」。

• 重組前備份 .bak；結構不合法不覆寫。
• 未 Save 時 Reorganize 按鈕禁用。
• 進行中：編輯區蒙版 + 狀態文字，最長約 300 秒；可切換其他知識檔並行重組；關閉對話框不取消背景請求。

詳見 §15.6。

6.3 Pre-inject Reorganize

已達 catalog 字數但檔內仍全頂格（無父+子結構）時，新對話首次向 Agent 發送訊息前，系統可能自動 Reorganize 一次（介面提示「Reorganizing Agent Memory before injection…」）。同一 conversation 每檔最多試一次；失敗不阻斷聊天，新開對話可再試。編輯器有未儲存變更時請先 Save，避免自動重組覆寫磁碟。

七、flat → catalog → expand

知識檔較短時，模型一次看見全部 Rules/Info；超過字數門檻後，注入變成「目錄標籤列表」，模型需用 expand_knowledge_catalog 按需展開——類似「先給索引，再查詳情」，避免長期知識撐爆 context。

7.1 注入模式

超過注入預算（User 6,000、Project 20,000 字元）時附加截斷提示。

7.2 expand_knowledge_catalog

catalog 模式下，system prompt 會提示 Agent 以精確父標籤呼叫 expand_knowledge_catalog 批次載入完整條目（含縮排子條）。工具實作與狀態限制見 AI Agent 架構 §八。

7.3 project_id 語意

• 注入時使用的 project_id 以 session 聚焦專案為準。
• 萃取入佇列時優先使用對話 context 的聚焦專案，再 fallback session，以減少 Pick project。

八、與答卷 A（Agent 時代的數據分析工作流）的關係

兩者正交：好的交付流程不等於自動記憶；記憶也不應取代 Plan 上的明確假設。

九、反模式

十、結語

Agent Memory 在 Lantide Data 裡是治理系統，不是聊天記錄的副產品：可見、可審、可關閉，口徑須經 evidence 與 Apply 才進模型。

這與工作流的 SQL-first 互補——Plan 承載單次分析的假設，知識檔承載跨專案口徑。下一篇 Prompt 與 Context 工程 說明核准後的知識如何與 Context Summary、State Prompt 一起組裝進模型。