两套系統，两種用途
| Plan / Report | Agent Memory | |
|---|---|---|
| 回答 | 这次分析 要做什麼、结論是什麼 | 以后每次 Agent 预设知道什麼 |
| 修改方式 | 批註、Execute、新 Plan | Queued → 你 Apply 才写入 |
| 審核節点 | Execute 前審 Plan | Apply 前審每一條提案 |
| 錯用后果 | 单次分析錯 | 所有后續分析 帶錯口徑 |
Plan 是单次契約；Memory 是长期背景。 不要把活動專属假设写进 Memory，也不要把公司級口徑只留在某次 Plan 里卻从不沉澱（若確实要全團隊統一）。
Queued Knowledge：治理核心
所有进长期記憶的内容，预设走 Queued Knowledge（待核准佇列）：
- 对話背景萃取 — 从 user 讯息提建議，附 evidence
- Agent @@PROTECT0@@ — 分析中主動提案可重用规则
核准前不注入 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。