AI Agent Memory 的目標不是保存所有對話，而是讓「仍然正確、可追溯、適用範圍清楚」的知識在需要時被取用。企業若把每次交談自動寫進長期記憶，錯誤口徑、過期規則與敏感資訊就可能跨對話持續影響結果；因此寫入、套用與淘汰都應有人審批。
先分清楚：四種記憶不是同一件事
討論 Agent Memory 時，最常見的誤會是把所有「模型能看到的過去」都叫做長期記憶。實務上至少要分成四層：
| 類型 | 用途 | 典型生命週期 | 適合內容 |
|---|---|---|---|
| Working memory | 維持當前任務狀態 | 一個回合或一段任務 | 本輪目標、剛查到的表結構 |
| Episodic memory | 找回過去經驗 | 跨回合，可過期 | 上次分析採用的步驟與結果 |
| Semantic memory | 保存穩定知識 | 跨任務，需維護 | 指標定義、欄位語意、業務規則 |
| Project knowledge | 限定在專案的背景 | 專案期間 | 活動範圍、專案專屬假設 |
這些層級的風險不同。當前查詢用的暫存表名稱屬於 working memory；「GMV 不含退款」可能是 semantic memory；「本次活動只算 6 月 1 日至 20 日」通常只屬於這次 Plan。若把三者都永久保存，下一次分析很容易拿錯範圍。
一項 2026 年的多輪 Text-to-SQL 研究，以 300 個 session、1,400 個 turns 比較 working window、episodic retrieval 與 semantic augmentation。結果顯示，增加記憶元件並沒有單調提升準確率，效果會隨模型與資料集而異。這是特定 benchmark 的結果，不代表所有 Agent；但它足以提醒團隊：**Memory 架構必須被驗證，不能把「記得更多」當成品質保證。**研究細節見 EnterpriseMem-Bench 論文。
為什麼自動記住會把小錯變成長期問題
1. 錯誤口徑會複利
假設某次對話中有人暫時說「active customer 是 30 天內下過單」，Agent 卻把它當成全公司定義。下次分析、下下次報表，模型都可能在沒有提醒的情況下沿用。單次回答錯誤變成跨任務的系統性偏差。
2. 知識會過期，卻不一定自己失效
產品狀態碼、組織名稱、退款政策都會變。沒有 owner、適用範圍與 review date 的記憶，即使當初正確，也會逐漸變成「可信外觀的舊資料」。
3. 記憶本身是攻擊面
OWASP 的 AI Agent Security Cheat Sheet 將 memory poisoning 列為 Agent 風險：惡意或受污染的內容若被持久保存，可能影響未來 session。這不表示每段外部內容都惡意，而是寫入長期記憶前必須知道「誰說的、證據在哪、它能影響哪些任務」。
4. 敏感內容可能被帶入不該出現的上下文
記憶若跨專案、跨資料範圍注入，原本只屬於單一客戶或機密專案的資訊，可能出現在其他任務的模型上下文。關閉 Memory、分層 scope 與限制寫入內容，都是必要選項；但仍要依模型供應商與外部連線政策評估資料是否離開裝置。
一個可落地的「E-S-A-R」審批框架
對每一條準備進入長期知識的內容，依序檢查四件事：
- Evidence（證據）：原句、文件或負責人是什麼？Agent 的推論不能自己證明自己。
- Scope（範圍）：只適用本次分析、某個專案，還是所有工作？
- Approval（核准）：誰有權把它變成預設背景？業務口徑通常需要業務 owner，而不只是工具管理者。
- Review（複查）：何時過期、由誰更新、錯了如何停用？
可以把待審項目寫成以下格式：
知識：GMV 排除已全額退款訂單
Evidence：財務口徑文件 3.2 節；owner：Finance Ops
Scope：Project「Commerce Metrics」
類型：Rule
Review：每季或退款狀態碼變更時
決定：Apply / Dismiss / 請補證據
如果 evidence 只證明「這次活動」的條件，就不要把 scope 擴大到全域。若規則仍有爭議，先留在當次 Plan，比永久記錯更安全。
Lantide Data 如何把 Memory 變成可治理的知識流
Lantide Data 將 Agent Memory 視為治理系統，而不是聊天紀錄的自動副本。對話萃取或 Agent 主動提出的知識先進入 Queued Knowledge；建議必須帶有可驗證的 evidence_quote，而且核准前不會注入 Agent。使用者可以 Apply 到 User 或指定 Project，也可以 Dismiss；有聚焦專案時會預設該專案。
核准後的知識分為 Rules 與 Info。短知識可直接注入；內容較大時轉為 catalog，由 Agent 按需展開，減少不相關背景佔滿 context。你也能關閉 Enabled，停止萃取與注入；或只關閉 Automatic suggestions，保留已核准知識。完整行為與門檻見 Agent Memory 使用指南 與 可治理的 Agent Memory 設計。
這套機制的邊界也很明確：審批不能證明一條規則永遠正確，catalog 也不等於自動解決衝突。團隊仍需指定 owner、定期複查，並把單次分析假設留在 Plan。Lantide 是 local-first 工作環境，但若使用外部模型或連線，核准知識可能進入該模型的上下文；不能把 local-first 解讀為「所有資料永不離開本機」。
結語：先決定什麼值得留下，再談記憶容量
企業導入 Agent Memory 的第一個問題，不該是向量庫能放多少，而是哪些內容有資格跨任務影響決策。先用 E-S-A-R 檢查現有規則：拿不出 evidence、scope 或 owner 的項目先不要注入；值得保留的知識，再建立明確的 Apply 與複查流程。