最近看企業 AI Agent 的發展，我越來越覺得：記憶不是讓 Agent 變聰明的裝飾，而是讓它能不能進正式流程的分水嶺。聊天助理記錯一句偏好，頂多讓人皺眉；工作型 Agent 記錯一個規則、引用到不該看的資料、或沿用已經失效的上下文，後果就完全不是同一個等級。
很多團隊一開始做 Agent 記憶，直覺會往「怎麼讓它記更多」走。把對話摘要存起來、把使用者偏好寫進 profile、把常用文件丟進向量資料庫，然後期待下一次回答更貼近情境。這些都可以做，也確實有用。但如果目標是企業內部的正式工作流，我會先問另一組問題：這段記憶從哪裡來？誰有權讓它被召回？多久之後應該失效？如果內容錯了，要怎麼更正？如果不該再被使用，要怎麼確定真的刪乾淨？
這些問題聽起來不像 AI，反而比較像資料治理。但也正因為如此，它才重要。
記憶不是一大包上下文
在原型階段，把「相關資料」全部塞進 prompt 是最快的做法。反正先讓 demo 跑起來，讓 Agent 看得到文件、看得到歷史對話、看得到任務紀錄，效果通常會立刻變好。可是這種做法有一個隱性代價：所有東西都被壓成同一種上下文，失去了原本的生命週期。
企業資料其實很少是同質的。作業規範可能半年才改一次；客戶狀態可能每天變；使用者偏好可能只是某次任務的暫時選擇；錯誤修正則可能應該被保留成規則。這些資料如果都被叫做「記憶」，Agent 很容易在不該用的時候使用它，或在應該忘記的時候繼續相信它。
我比較偏好的設計，是先把記憶拆成不同類型：事實、偏好、規則、任務狀態、人工更正、稽核紀錄。每一種類型都應該有自己的來源、權限、保存期限和召回條件。Agent 不是「想起所有相關的東西」，而是在某個明確 scope 裡，依照任務需要拿到被允許的上下文。
Scope 比記得多更重要
企業 Agent 最怕的不是不知道，而是不知道自己不該知道。
例如一個協助整理採購資料的 Agent，可能需要看供應商基本資料、歷史交期、異常紀錄和當前詢價狀態。但它不一定應該看所有部門的成本結構，也不一定能讀到其他流程裡的敏感備註。若記憶系統只靠語意相似度召回，「看起來相關」就可能變成越權的入口。
所以我現在看 Agent memory，會特別在意 scoped retrieval。不是只有「找得到」，而是要先通過身份、角色、任務、資料分類、流程狀態的過濾。召回不是搜尋功能而已，它本身就是權限執行的一部分。
這也是為什麼我不太相信只用 prompt 約束的記憶治理。你可以在 system prompt 裡寫「不要使用未授權資料」，但如果底層 retrieval 已經把資料塞進上下文，模型就被迫在看過之後假裝沒看過。真正可靠的做法，是不該看的資料一開始就不要進入模型視野。
刪除能力是成熟度指標
很多 AI 產品喜歡強調「長期記憶」，但我反而會先看它怎麼刪除。
能記住很容易，能正確忘記才難。企業裡的資料可能因為合約、政策、個資、流程變更或人工修正而需要停止使用。這時候如果記憶散落在摘要、向量索引、cache、任務紀錄和使用者 profile 裡，只提供一個「刪除按鈕」其實不夠。你需要知道它刪了哪裡、還有哪些衍生物、下一次召回是否真的排除了它。
這件事在 Agent 場景更麻煩，因為 Agent 會把資料轉成行動。它可能根據舊記憶做建議、建立草稿、更新任務，甚至觸發下一個流程。如果記憶被修正，相關的任務狀態也可能需要標記「曾使用過已撤回資訊」。這不是一般聊天紀錄刪除可以解決的。
我會把刪除、失效、保留期限視為 memory schema 的一部分，而不是事後補上的管理功能。每一筆可召回記憶至少要有來源、擁有者、scope、有效狀態、版本與撤回紀錄。沒有這些欄位，短期看起來開發很快，長期會變成查不清楚的黑箱。
記憶要接進資料層，不只是模型層
這幾年大家談 Agent，常常把焦點放在模型、工具和 prompt。但如果 Agent 真的要做工作，它的記憶最後一定會碰到資料庫、權限系統、文件管理、流程引擎和稽核紀錄。這些東西本來就是企業系統的老問題，只是 Agent 讓它變得更明顯。
我不覺得每家公司都需要一開始就做很重的記憶平台。小型 MVP 可以很簡單：先限定任務範圍、只保存必要資訊、把記憶分型、保留來源與版本、確保人工可以檢視和撤回。但即使是 MVP，也不要把所有上下文混成一包「給 AI 參考」。這種債以後很難還。
對 CTO 來說，Agent 記憶的關鍵問題不是「它能不能更像人一樣記得我」，而是「這套記憶能不能被組織管理」。能管理，才有辦法擴大；能追溯，才有辦法修正；能刪除，才有辦法承擔風險。
我對企業 Agent 的判斷也越來越簡單：如果一個 Agent 只能靠記得更多來變好，它還停在助理階段；如果它能把記憶變成有 scope、有期限、有版本、有稽核的資料層，它才開始像一個可以被放進正式流程的工作系統。