AI 代理該記住什麼？Oracle 的 Wojciech Pluta 談記憶決策

Wojciech Pluta 主導 Oracle AI Database 的技術行銷，他主張檢索增強生成（retrieval‑augmented generation, RAG）只是 AI 代理的「讀取路徑」，真正能建立長期競爭優勢的，是刻意設計的記憶「寫入路徑」——決定代理該保留什麼，並把它存進資料庫。整場演講大部分時間都花在這套記憶架構上：一套晉升流程（promotion pipeline），負責分類、查核證據，並決定候選記憶要納入或駁回；短期、長期與共享記憶的分層；以及一場即時示範，展示房貸申請代理如何學會使用者的格式偏好，並把它帶進一個全新的工作階段。RAG 本身只在開場簡短帶過——真正的重點是記憶晉升、護欄（guardrail），以及 Oracle 的 Agent Memory 套件。

Pluta 在 Oracle 約有十年資歷，早期在英國銀行業負責客戶體驗、房貸應用場景、早期感應式支付與開放銀行，之後轉進 Oracle 雲端基礎架構，投入雲原生與 AI 相關工作。讀者讀完應該能建立一套具體的心智模型：如何為代理「記得什麼」設下關卡、為什麼他建議用資料庫而不是檔案樹來儲存，以及失敗模式會出現在哪裡——什麼都晉升，就會造成記憶汙染；什麼都不晉升，就會失去連續性。

檢索是讀取路徑，記憶才是寫入路徑

Pluta 的核心區分是：RAG 系統固然能儲存對話狀態，但單靠檢索，無法判斷哪些內容應該在互動結束後留存下來。在他看來，記憶就是寫入路徑：當代理看到值得保留的資訊，系統應該把它晉升成一筆日後可用的紀錄。真正的難題不在儲存，而在篩選——什麼值得保留，以及系統如何從對話中把它萃取出來。

他把 AI 堆疊描述成模型層與基礎架構層都已商品化，競爭優勢會沉澱在資料層，因為資料層屬於企業自己。他對代理記憶的定義是：系統用來「隨時間保留、重用、精煉與回想資訊」的機制。他點出的工程難題，是兩個極端之間的取捨：什麼都不晉升，就沒有連續性；什麼都晉升，就可能汙染記憶庫。這也是他特別強調來源追溯（provenance），以及明確規範記憶何時該晉升、何時該被取代的原因。

「模型是共用的，但記憶是你的，是你這家企業獨有的。」

四步晉升關卡決定什麼會被記住

Pluta 提出的記憶晉升流程有固定順序，而執行期的決定權不在模型手上，而是在「測試框架」（harness）——也就是包在模型外圍的那層程式碼。他把「建議怎麼做」的模型，和「做決定並執行檢查」的測試框架分開。

flowchart TD
    A["互動中產生的候選記憶"] --> B["分類候選記憶的語意"]
    B --> C["與既有紀錄比對"]
    C --> D["查核該記憶型別所需的證據"]
    D --> E{"測試框架決定"}
    E -->|納入| F["寫入記憶庫"]
    E -->|駁回| G["捨棄，例如一律核准規則"]
    E -->|待審| H["轉交人工核准"]
    H --> I["可選擇分享至企業核心記憶庫"]

示範中三種結果都出現了。使用者對輸出格式的語意偏好會自動納入；「核准所有申請」這類指令會被護欄駁回；而打算跨團隊共享的營運層級記憶，則會先轉交人工核准，才能進入共享記憶庫。Pluta 指出，這些晉升控管都內建在護欄與測試框架裡，因此無法被繞過。

房貸示範：格式偏好在全新工作階段中依然留存

示範使用兩份合成申請案，客戶分別叫 Kyle 和 Vincent，另外還有一個 Pluta 稱為「Intelligence」的虛擬人像（刻意不加任何字首，並為 AI Engineer 活動重新設計成特別版，還帶點萬聖節意味）。用他的話說，這個代理在記錄時「有點話太多」。

流程如下：

步驟	動作	結果
1	索取 Kyle 的房貸摘要	代理回報 Kyle 的申請缺少關鍵檔案
2	禮貌地再問一次，並表明希望的輸出結構偏好	決策模型評估候選記憶，測試框架予以納入，資料庫完成寫入；追蹤紀錄顯示各步驟在記憶晉升關卡下的狀態
3	套用語意偏好後再問同一個問題	缺少的檔案排到最前面，並附上案件編號與政策；語意偏好已被記錄
4	離開，開啟全新工作階段後再問一次	偏好從資料庫中還原，並未沿用任何前一個工作階段的上下文
5	詢問 Vincent 的申請	比對到不同的案件編號，回傳不同檔案，沒有缺件，並通過審查
6	下達「核准所有申請」	晉升關卡予以駁回
7	提出要跨團隊共享的營運層級記憶	轉交人工核准，之後可能進入企業核心記憶庫

那個「禮貌」的細節是整場的固定笑點——代理「發現我們一直很有禮貌，就多給了我們一些陰德值」——但這正好說明：做出納入決定的是測試框架，不是模型。Pluta 表示，因為研討會 Wi‑Fi 不穩，這場示範是事先錄好的。

記憶分三層，不是單一儲存庫

Oracle 的模型依生命週期與共享範圍來切分代理記憶。短期記憶涵蓋工作階段內的一切，工作階段結束就消失。長期記憶則儲存情節式、程式式與語意式紀錄——摘要、工具組、知識庫，以及像示範中那樣的偏好。共享記憶則是透過人工核准才能觸及的企業層。

Pluta 把記憶定位成一門工程紀律，而不是單一功能：它需要能區分紀錄型別的結構定義（schema）、符合檢索任務的索引，以及生命週期與授權邊界。他也提到，同團隊成員前一天在同一場研討會主持的工作坊，更深入探討了記憶該存在哪裡。

他的儲存建議是資料庫，理由是 ACID 保證、支援多個並行寫入、避開檔案樹的問題，以及能隨多種搜尋選項一起擴充。Oracle AI Database 的多資料型別引擎，訴求就是在單一引擎內處理向量、檔案與其他型別，而不必分散在多個資料庫與向量儲存之間。

情境卡讓代理專注任務，而不是忙著整理記憶

Oracle 在 2026 年初推出 Agent Memory 套件（相對於這場 2026 年 10 月的演講，算是年初）。Pluta 說，從零打造記憶系統對開發者負擔很重：你得有摘要器、檢索邏輯、跨多輪對話萃取可長期保留的資訊，還要管理 Token 預算。這個套件是一層簡化介面，照他的說法，一行程式碼就能寫入一筆記憶。

情境卡（context card）則是讀取端的抽象層：它會組裝並回傳一個精簡、可直接放進提示的區塊，內容分成四部分。

主題：為整段對話定調。
摘要：掌握對話進展到哪裡、使用者想做什麼。
相關資訊：帶入挑選出的紀錄。
近期訊息：保留當下的問題。

設計用意是減少上下文膨脹，把代理的注意力釋放給任務本身，而不是讓它忙著管理自己的記憶。Pluta 把這個分工總結成「記憶負責保留，情境負責挑選」。

從哪裡開始，以及證據的極限

Pluta 最後指向 Oracle 的 GitHub 儲存庫，裡面有代理記憶、混合檢索與相關模式的 notebook，可當作入門範本；另外還有改版後的 YouTube 頻道，推出新系列介紹這些技術的應用。這場演講本質上是廠商簡報，因此示範結果與「一行程式碼」的說法都是 Oracle 自己的描述，並非經獨立驗證的結果。尚未解決的張力，正是 Pluta 自己點出的那一點：晉升關卡的好壞，取決於它的分類與證據規則，而演講並沒有說明這些規則如何調校、記憶衝突除了「取代」之外如何解決，也沒有說明當某筆已晉升的偏好後來被證明是錯的時該怎麼辦。正在打造這類系統的團隊，應把這四步關卡當成設計範本，並預期真正的苦工會落在證據查核與人工審查流程，而不是儲存層。