兩套系統，兩種用途
| Plan / Report | Agent Memory | |
|---|---|---|
| 回答 | 這次分析 要做什麼、結論是什麼 | 以後每次 Agent 預設知道什麼 |
| 修改方式 | 批註、Execute、新 Plan | Queued → 你 Apply 才寫入 |
| 審核節點 | Execute 前審 Plan | Apply 前審每一條提案 |
| 錯用後果 | 單次分析錯 | 所有後續分析 帶錯口徑 |
Plan 是單次契約；Memory 是長期背景。 不要把活動專屬假設寫進 Memory，也不要把公司級口徑只留在某次 Plan 裡卻從不沉澱（若確實要全團隊統一）。
Queued Knowledge：治理核心
所有進長期記憶的內容，預設走 Queued Knowledge（待核准佇列）：
- 對話背景萃取 — 從 user 訊息提建議，附 evidence
- Agent
propose_knowledge— 分析中主動提案可重用規則
核准前不注入 Agent——不會默默改變行為。
PM 該做的：
- 決定 誰有權 Apply（通常分析負責人 + PM 對 Project 層規則）
- 區分 User（個人偏好）vs Project（專案口徑）
- 對不確定條目 Dismiss，寧可寫進下次 Plan
合規與開關
- Agent Memory 可整體關閉（Enabled 關）——關閉後不背景萃取、不注入，適合敏感專案或試用期
- Automatic suggestions 可單獨關閉——只停對話後背景萃取；已核准知識仍注入，手動維護與 Agent 提案仍可用
- 不會 預設把整段對話灌進向量庫；入隊有頻控與 evidence 校驗
- 敏感資料場景：先 關 Memory + 限制資料夾內容，再評估是否開啟
詳細操作見 USER_GUIDE §15。
常見治理決策
| 內容 | 建議落點 |
|---|---|
| 「GMV 不含退款」全公司統一 | Project 或 User Knowledge（Apply 後） |
| 「本次 618 只算 6/1–6/20」 | 僅 Plan / Report |
| 「分析師 A 偏好繁中回覆」 | User Knowledge |
| 某次 SQL 的 join 陷阱 | 不進 Memory；留在當次分析步驟紀錄 |
與 PM 試點的關係
試點初期建議 先關 Memory 或嚴格 Apply，等團隊習慣 Plan / Execute 後再開——否則容易「Plan 還沒審，背景規則已經歪了」。
分析師操作細節見 Plan vs Memory。