讀時間： 約 6 分鐘 · 系列： 分析師進階 · 上一步： Reference docs：大型參照怎麼放
先分清楚：這次分析 vs 長期口徑
| 放哪裡 | 適合什麼 | 例子 |
|---|---|---|
| Plan | 這一次分析的假設、時間窗、checkpoint | 「本次 618 大促 6/1–6/20，分母為建單用戶」 |
| Project Knowledge | 這個專案長期有效的短規則與 [Ref: …] 索引 |
「本專案 GMV 均不含退款」 |
| Reference 檔 | 大型映射表、字典全文（按需讀取） | 50 行 status code 對照表 → 見 Reference docs |
| User Knowledge | 跨專案你的偏好與術語 | 「回覆用繁中」「活躍用 90 天窗口」 |
| Queued Knowledge | 尚未核准的提案 | Agent 或背景萃取建議，你 Apply 前不生效 |
常見錯誤： 把「只做一次的 618 時間窗」寫進 User Knowledge，導致三個月後每個專案 Agent 仍預設 618 窗口。
Queued Knowledge 怎麼運作
Agent Memory 預設 可關閉；開啟後有兩路提案進 Queued Knowledge（待核准佇列）：
- 對話結束後的背景萃取（需另開 Automatic suggestions）— 從近期 user 訊息提建議（需附 evidence）
- Agent 主動
propose_knowledge— 分析中覺得某條口徑可重用時提案（只跟 Enabled，不跟 Automatic suggestions）
關閉 Automatic suggestions 不會停用已核准知識的注入。
核准前：
- 不寫入正式知識檔
- 不注入 Agent 下一輪 prompt
核准方式：
- 對話裡的 User / Project / Dismiss 卡片
- Agent Memory 面板的 Apply / Dismiss
Agent Memory 左側頂部為 User Knowledge（Global），其下為各專案 Project Knowledge；目前聚焦的專案列旁有綠色 Eye 圖示，方便確認套用目標。
分析師日常：看到卡片就決定——這條是永久口徑還是本次 Plan 就好；不確定先 Dismiss，寫進 Plan 更明確。
什麼該進 Memory、什麼不該
適合進 Memory（核准後）：
- 穩定的欄位定義（「
paid_at為支付成功時間」） - 團隊共識的業務規則（「trial 用戶不計入 ARPU」）
- 你的輸出偏好（語言、詳略）
不適合進 Memory：
- 單次 SQL 的坑（應在 Query Step Ledger / 對話步驟，不污染長期庫）
- 整段 SQL 或快取表名
- 尚未與 PM / 財務對齊、可能變的口徑
與 Plan 批註的協作
- Plan 批註 = 這版分析契約的修訂
- Memory Apply = 以後每次分析都帶上的背景
若 PM 在 Plan 批註「GMV 不含退款」，且這是全公司長期規則，分析師可在核准後寫入 Project 或 User Knowledge；若只是本次活動規則，留在 Plan / Report 即可。
PM 視角的治理見 Memory 治理。