Agent 為什麼不能只靠聊天紀錄？MongoDB 把「長期記憶」做成基礎設施

假設客戶上週向企業客服 AI 反映設備故障，經過確認，客服承諾之後統一用電子郵件回報進度。今天客戶再來詢問時，AI 能不能知道上次說過什麼？如果它只能看到這次對話，就可能重新詢問聯絡偏好；若系統把上一段長對話整篇塞進模型，又可能把大量無關文字一起傳入，增加成本並讓真正重要的資訊被稀釋。

問題不在模型是不是夠聰明，而在應用程式是否建立了可持續使用的記憶機制。MongoDB 在 9 月底公布 Atlas Agent Engine 公開預覽時，將記憶、檢索和治理列為 Agent 從概念驗證走向正式環境所需的能力；官方文件也把短期對話及跨對話長期記憶分開處理。[1][2] 這項產品不是 11 月 5 日才首次發布，本文以已公開的產品文件為基礎，分析它揭示的架構需求。

為何「保存每一句聊天」仍然不夠？

一段對話通常含有問題、假設、修正、無效答案與臨時情緒。對話紀錄保留的是發生過什麼，不保證哪一句仍適用，也不保證某句話是使用者最後確認的版本。若 Agent 在三個月前收到「希望寄紙本」，之後客戶明確改為電子郵件，系統不應因為找到舊紀錄就繼續照舊執行。

因此，保留原始紀錄與提煉可重用知識，是兩件不同的工作。前者強調完整追溯，後者需要辨識資訊是否持久、目前是否有效、來自哪個來源、應適用於誰。企業不能只因聊天紀錄存在，就認為 Agent 已具備長期記憶。也不能把模型自行生成的摘要，當成無需核對的客戶事實。

另一個原因是上下文視窗有限，而且處理與傳送歷史內容存在成本。即使模型可以閱讀很長的資料，也不代表每次都應載入全部。真正的記憶系統會根據當前任務，取回少量與問題相關、且可信度足夠的資訊。這更像一個有分類與權限的工作知識庫，而不是把所有訊息貼到同一個聊天視窗。

MongoDB 提供的，是兩種壽命不同的記憶

MongoDB 的 Agent Memory 文件將記憶區分為短期與長期。短期記憶保存同一段互動中依序發生的對話回合，讓 Agent 知道最近在談什麼。長期記憶則跨越單次對話，保存經過提取或直接寫入的持久資訊，供之後的任務檢索。[2]

MongoDB 說明了一條背景流程：先記錄對話回合；到達設定訊息數量或閒置門檻後，產生對話快照；再由大型語言模型從快照提取持久資訊，將其歸入長期記憶類型。[2][3] 這個流程的關鍵在於「背景提取」。剛剛說過的一句話，不必然立即成為下次執行就可查到的長期記憶。若後續流程需要馬上使用重要決策，就不應只依賴非同步提取，應明確直接寫入並取得完成回執。

公開文件同時說明，應用程式可直接寫入特定記憶。這對企業很重要。若客戶已透過核身並簽署文件確認某項流程偏好，系統可以把確認後的資料當成具明確來源的狀態寫入；相反地，對話中暫時提出的想法，不宜自動晉升為長期事實。記憶的寫入權限和確認流程，往往比記憶量更重要。

四種記憶不是學術名詞，會決定 Agent 能做什麼

MongoDB 把長期記憶分成 Semantic、Episodic、Procedural 及 Taxonomic 四類。[2] 先用企業常見工作解釋。

Semantic Memory 是持久的事實型資訊，例如某個已確認的客戶偏好、設備型號或工廠機台所屬廠區。它回答的是「目前已知的事實是什麼」。這類資料適合附上來源與有效期限，但不應取代 ERP 或 CRM 的正式主檔。

Episodic Memory 是過去發生過的事件，例如上次售後會議做過哪些決定、哪些方案遭否決、最後用什麼理由改變處置。它回答「之前發生過什麼」。在企業實務上，事件記憶最好能連回案件編號、會議記錄或審批資料，避免一個孤立摘要失去證據。

Procedural Memory 保存可重複執行的步驟。比方說收到退貨申請後，先查訂單、確認可退期間、檢查付款狀態，再交給有權限的人核准。它回答「這類事情應如何做」。重要的是，程序記憶不能凌駕於現行政策、程式驗證與權限檢查之上。若退款規則已改，過去的流程摘要不能自行成為最新規則。

Taxonomic Memory 保存專業領域的名詞與分類定義，例如企業內部對客訴、缺陷、退貨、重大事故的分類。它回答「這個組織的術語是什麼意思」。在不同部門使用同一個詞但定義不同時，這一層能協助 Agent 正確解釋任務，也能讓檢索結果具備一致的詞彙基礎。

四類的差異不只是資料欄位，還涉及不同的更新方式。事實需要驗證，事件需要來源，流程需要版本，術語需要定義與適用範圍。若企業把它們全部塞成一段「使用者偏好摘要」，無法確保更新衝突被妥善處理。

記憶與 RAG 不同，但經常需要一起使用

RAG（Retrieval-Augmented Generation）是檢索增強生成。它讓 AI 在回答前從外部資料庫、文件或搜尋系統找出相關內容，再將結果提供給模型。記憶與 RAG 都可能使用搜尋或向量索引，但資料來源與目的並不完全相同。

如果員工問「今年最新的請假規定」，理想答案來自現行人事制度文件，而不是 Agent 記得三個月前有人提過的版本。若員工問「我們上次討論這份假單時，主管決定用哪個方案」，才可能需要上一段互動形成的事件記憶。前者是查詢權威知識，後者是重建歷史上下文。

因此，好的 Agent 應知道什麼時候查正式系統，什麼時候讀長期記憶，什麼時候需要兩者交叉驗證。只靠向量相似度排序，並不能決定哪份文件比較新、哪一份決策具有法律或組織效力。企業至少應在資料中保留建立時間、來源、適用部門、版本與必要的審批狀態。

同一筆資訊，需要不同層次的儲存與檢索

以「本公司付款條件」為例，資料可能存在正式合約、採購知識庫、ERP 客戶設定與歷史對話中。使用者只問「A 客戶現在的付款條件」，系統應優先取得授權範圍內的現行合約與 ERP 主檔；若問「為何去年決定調整條件」，才需要過去會議與溝通紀錄。

這說明記憶設計不能只規劃一個萬用搜尋框。資料檢索需要能依使用者、專案、案件與有效期間過濾，還要分辨結構化查詢與語意相似搜尋。結構化條件適合查精確的客戶 ID、合約版本及日期；語意搜尋適合找「上次談過類似問題的經驗」。兩種方法可以互補，但不應讓模糊匹配凌駕於正式識別碼之上。

在企業環境中，還要避免跨租戶檢索。若同一套 Agent 為多家公司服務，語意上相似的案件可能來自不同客戶。即使搜尋演算法認為另一個客戶的資料非常相關，沒有權限就不能提供。必要的過濾條件應由後端根據已驗證身分套用，而不是讓模型自己判斷是否要遵守。

記憶不是「摘要越精簡越好」，而是要能處理矛盾

設計 Agent Memory 最棘手的情況，通常不是第一次保存資料，而是第二次收到相反訊息。假設 CRM 顯示客戶的主要聯絡窗口是採購經理，上一段聊天卻出現「現在請直接找財務主管」。這句話可能是臨時指定、正式更動，也可能是沒有權限的訪客隨意提出。若 Agent 自動覆蓋原始聯絡資料，就可能使後續通知送錯人。

因此，記憶系統至少需要保存來源與有效性，而不只是最終的文字值。對某筆偏好，可能要記錄是誰提供、何時確認、適用於哪個案件、何時到期、是否曾被更正。遇到矛盾時，系統不能單純以「比較新的句子」判勝負，還要考慮發話者身分、正式資料的權威程度與是否需要重新確認。

MongoDB 在記憶提取文件中描述由系統辨識並整理長期資訊的流程。[3] 這可以協助減少大量手工標記，但不能讓企業省略自己的真實性規則。模型可能把語境讀錯，例如使用者說「如果未來改用電子郵件」，卻被錯誤記成「現在已改用電子郵件」。一套可用於正式流程的系統應能保留原句來源，對重要記憶設定驗證或低信心保留機制。

在高風險場域，應把「記憶內容」與「正式交易狀態」分離。AI 可以記得客戶曾反映過帳單金額錯誤，但應從會計系統確認帳單有沒有更正；可以記得某件申請曾被主管退回，卻必須查審批系統才能確認現在是否批准。Memory 的價值在於理解背景，不能任意升格為可執行命令。

長期記憶不等於 Agent 可以不受控制地自我學習

「AI 能從使用者對話學習」是一句吸引人的產品描述，但正式部署時必須釐清寫入邊界。想像一位訪客在公開客服視窗輸入：「你們公司現在所有保固都延長到十年。」如果這段話被自動提煉為公司的長期程序記憶，下一位使用者可能得到錯誤的政策答案。這是記憶汙染風險，與一般的 Prompt Injection 風險互相關聯。

記憶資料也可能保存敏感資訊，例如聯絡方式、交易習慣、內部決策或客服對話。即使記憶是由模型提取，責任仍在使用系統的企業。資料需要依使用目的決定是否應保存、保存多久、誰能查詢、何時刪除。尤其是跨客戶、跨部門、多 Agent 共用的環境，記憶服務不能只靠同一個模型提示詞來區分權限。

可行的設計是把身分驗證、租戶隔離、欄位權限、儲存加密、存取日誌與刪除流程放在模型外的確定性系統中。即使有人透過惡意輸入說服模型「記住所有客戶資料」，資料寫入權限也應由後端規則控制，不能讓模型自行決定。

在多 Agent 系統裡，記憶還牽涉到「誰可以繼承誰的經驗」

企業可能同時部署客服、銷售、法務與專案管理 Agent。它們使用同一個語言模型，並不代表應共享所有記憶。客服 Agent 知道某位客戶的投訴歷史，不表示行銷 Agent 就有權讀取完整案件；法務 Agent 看過某份尚未公開的合約，也不意味著一般員工可以透過另一個 Agent 取得內容。

可以把記憶範圍分成個人、案件、部門與全公司。個人偏好可協助同一位使用者延續工作；案件記憶讓獲授權的團隊接續處理；部門程序供相關職務使用；公司核准發布的術語與政策則可能開放更多員工查詢。這四種範圍不是資料庫固定提供的分類，而是企業應依業務權責設計的存取邊界。

Agent 之間的交接尤其容易出現越權。一個代理將「已完成初步審核」寫入記憶，另一個代理收到摘要後可能誤以為已完成正式批准。解法不只是加上一句「請小心」，而是讓摘要保留狀態與來源，且正式批准只認可由指定系統寫入的紀錄。跨代理共享應該共享有權限的事實和可追溯任務狀態，而不是共享無法確認來源的結論。

記憶應該附帶「忘記」的能力

持久化聽起來像把資訊永久留在系統中，但長期保存不一定是優點。客戶離開、專案結束、政策改版或使用者要求更正時，過去的記憶可能已經不適合繼續使用。若一套系統只能新增記憶，無法處理撤回、更正、刪除和重建索引，導入規模越大，後續管理負擔越重。

尤其使用向量檢索時，刪除不只是把畫面上某段摘要拿掉。企業還要確認底層原始內容、索引、快取、衍生記憶以及後續檢索管線如何處理。不同產品的資料生命週期和保留條款會有差異，需要對照實際文件與合約，不能把「有刪除按鈕」直接當作所有備份和衍生資訊都已清除。

另一項經常被忽略的要求是版本升級。當企業的報價程序從三步驟變成五步驟，若 Agent 仍檢索到舊版程序記憶，便可能在不知情的情況下執行錯誤流程。至少應有版本號、有效期與正式發布狀態，並能在檢索時排除已失效的程序；必要時，由負責業務的單位重新批准。

知識管理與 AI 記憶的責任仍要分開

企業知識庫通常有維護者、版本、審批與適用範圍；Agent Memory 則可能從大量互動中自動提取線索。這兩種資料管理邏輯不同。前者是制度性發布，後者可能是帶有不確定性的工作經驗。如果把每一次交談自動變成正式知識，反而會破壞原本好不容易建立的文件治理。

較穩健的設計，是讓重要記憶能連結到權威文件或案件紀錄，對尚未確認的內容標明來源與信心，並且提供升級為正式知識的審核流程。當組織建立這條界線，AI 才可能在不犧牲資料可靠性的情況下，跨次保存和重用有價值的經驗。

記憶的成本不能只用儲存空間估算

一筆長期記憶的成本，除了資料庫儲存，還可能包含對話摘要、提取模型、嵌入模型、搜尋索引、檢索請求及應用端的管理工作。當使用者與 Agent 的數量成長，記憶提取與索引更新的頻率也可能增加。若每次回應都大量搜尋歷史內容，延遲和推論輸入成本也可能升高。

因此，測試時應同時衡量每件合格任務所需的模型呼叫次數、記憶查詢量與人工更正時間。若導入記憶後，每次都能少問兩個問題，但需要非常昂貴的背景處理才能維持，也未必對所有業務有正向經濟性。相反地，若它能顯著減少跨日交接遺漏、降低客訴重新開案，收益可能來自錯誤減少，而非省下幾個 Token。

公開預覽階段也應建立退出策略。企業可要求供應商或技術團隊展示記憶資料如何匯出、如何刪除、如何處理不同版本，以及在服務中斷時是否仍能查回正式資料。真正有價值的不是某個模型今天可以記住多少句，而是組織在三年後能否理解、維護並取回這批知識。

產品化的價值，也意味著要理解依賴條件

Atlas Agent Engine 在 2026 年 9 月宣布公開預覽，MongoDB 將執行、記憶、檢索和治理能力整合到平台，並稱使用者可以只採用部分模組。官方聲稱可減少各種 Agent 框架與儲存服務的拼接工作，也強調模型與框架相容性；但「減少整合成本」仍需要在各企業既有環境中驗證，不能直接視為通用的成本結論。[1]

官方安裝文件指出，啟用 Agent Memory 需要設定相關專案與儲存資源，並涉及 Voyage AI 的嵌入模型 API 金鑰；有些部署需要一定等級的 Atlas 叢集才能支援搜尋索引。[4] 這提醒採購者：產品簡報所稱的一體化，不代表零維運工作或沒有額外授權、儲存、檢索與模型費用。

記憶的效果也不會只由資料庫決定。它同時依賴提取規則、資料品質、檢索方法、權限模型、過期處理與回應策略。企業應把它視為一套可配置的基礎設施，而不是購買之後 Agent 就自動具備可靠常識。

與自行架構的差別在哪？

沒有採用 MongoDB 的企業，依然能建立長期記憶。例如使用關聯式資料庫保存結構化偏好與任務事件，利用文件庫保存摘要，再配合向量索引找出相關知識。LangGraph 等 Agent 框架也提供持久狀態與跨執行緒儲存元件，但具體實作仍要由團隊設計。[5]

平台化方案的優點，是以共同的介面管理資料生命週期，可能降低重複開發與工具維護成本；代價是依賴某家供應商的記憶結構、運作方式與費率。自建方式具有可控性，卻要自行維護分類、去重、更新、刪除及監控。兩者沒有適用所有公司的單一答案。

一個實用的比較方法，是把「資料完整性」放在「模型回答好不好」之前。抽出二十個有正式答案的例子，包含同義問題、過時政策、跨租戶資料、撤回同意以及已刪除的客戶資訊。實測 Agent 能否把最新來源和歷史記憶分清楚，能否在沒有權限時拒絕讀取，以及是否會因一段新的錯誤訊息覆寫已確認的制度。這些比單次展示記住客戶名字更能揭示產品成熟度。

如何測試「記憶有用」，而不只測試「AI 有沒有記住」？

最簡單的展示，是告訴 Agent 一個偏好，關掉視窗再問一次。如果它答得出來，確實能證明某種儲存與讀取正在運作，但距離企業驗收仍有一大段距離。正式測試應包含正確記憶、不該記憶、過時記憶與衝突記憶四種情境。

可以挑選二十至五十個真實工作形式、但已去識別或合成的測試案例。每個案例都先定義標準答案與可接受的來源。例如，對已確認的客服偏好，要求 Agent 正確引用；對沒有權限的其他客戶資料，要求完全不能取回；對已被新版政策取代的程序，要求優先採用權威文件；對存在矛盾的歷史說法，要求列出不確定性而不是自行猜測。

指標至少可區分四個面向。檢索命中率觀察應該找到的記憶有沒有找到；精確性觀察拿到的內容是否適合當前問題；時效正確率觀察有沒有引用過時資料；權限與刪除測試觀察系統是否正確拒絕存取。除此之外，記憶是否減少對話回合或人工查找時間，也應作為業務成果而非技術表演。

三個企業情境，檢驗記憶究竟有沒有幫助

第一個是客服。可持久保存的是已取得適當授權的聯絡偏好、案件追蹤與經確認的處置結果；即時訂單、退款狀態與餘額仍應查正式系統。第二個是企業採購。Agent 可以記得前次供應商評估的準則與排除理由，但最新報價與合約條款應回到原始文件。第三個是內部專案。Agent 可以保存上一輪討論的決策及任務交接，卻不可把尚未批准的提案當成正式規格。

這三個情境有一個共同點：記憶要能幫助工作延續，但不應自行取代組織的權威資料。若使用者詢問「上次決定什麼」，Agent 應回報有來源的歷史決議；若問「現在允許什麼」，應回到最新、具有權限且適用的規則。兩者混淆，才是企業上線後最容易付出代價的錯誤之一。

從客服、銷售到專案管理，不是所有情境都需要同一種記憶

客服適合保存具有適當使用權的案件事件與偏好，但最重要的是與正式客服及交易系統連接。銷售管理需要追蹤潛在客戶偏好、會談進展與已確認的提案，但折扣及合約條件必須由現行授權規則控制。專案管理適合保存會議決策與交接脈絡，但真正的工作狀態還應由任務看板或工作流資料庫維護。

對企業主來說，這樣分類能避免把所有問題都交給「更大記憶容量」。如果失誤來自客服人員查不到訂單，根本原因可能是缺少受控 API；如果失誤來自跨日交接遺漏決策，事件記憶才可能提高效果；如果失誤來自同一份制度多個版本並存，應先建立文件治理與最新版識別方式。技術選型應取決於上游問題。

MongoDB 的新產品有助於把這些問題拉到基礎設施層級討論，也帶來更清楚的採購問題：其分類與提取方式是否符合公司的資料治理？能否和既有系統協作？成本如何隨記憶量與檢索量成長？資料需要移轉時能否完整取出？實際決策時應以自己的測試結果驗證供應商承諾，而不是把產品文件的架構描述視為成效證明。

採購前值得要求的一份輸出：記憶生命週期表

一份有價值的評估文件，不是列出產品支援幾種 Memory 類型，而是用實際業務欄位說明每筆資訊從哪裡來、經誰確認、保存多久、何時更新，以及如何刪除。對於客服偏好、專案決策、內部程序與領域詞彙，可以分別設定寫入權限與審查方法。若某一類資料無法確認權威來源，應限制它只用於提供線索，不能作為自動執行的依據。

另外，記憶功能一旦影響企業正式工作，就需要安排定期抽樣和錯誤回報。每次發現 AI 引用錯誤記憶，應能追到原始對話或系統紀錄，判斷錯在提取、更新、搜尋還是使用階段，再針對原因修正。這比單純重新下提示詞，更接近一套可以持續改善的正式系統。

導入前先回答「什麼不該被記住」

如果公司準備開始測試 Agent Memory，第一步不宜是把所有工作對話匯入資料庫。更好的起點是挑選一種真正需要跨次延續的工作：例如客服案件追蹤或採購評估。先列出可保存與不得保存的資訊，再明確決定每一筆記憶的來源、用途、有效期、讀取權限及更正方式。接著建立有標準答案的測試集，比較有無記憶時的工作完成率、人工更正、錯誤引用與資料外洩風險。

若成效確實來自減少重複問答或交接遺失，企業才有理由擴大。相反地，若工作本來就需要每次讀取即時資料，例如庫存、帳款或訂單狀態，投資應先落在 API、正式資料庫與權限，記憶只是一個輔助層。

MongoDB 把長期記憶做成產品，反映出 Agent 市場正在跨過「能不能回答問題」的展示階段，轉向「能不能持續處理工作」的工程階段。可持續的前提不是讓 AI 記得越多越好，而是讓每一份記憶都有來源、範圍、權限、更新和退出機制。做不到這件事，記憶越強，也可能只是讓舊錯誤留得更久。

延伸閱讀與來源

[1] MongoDB，〈MongoDB Launches Atlas Agent Engine to Put AI Agents in Production Without a New Stack〉，2026 年 9 月 29 日：https://www.mongodb.com/company/newsroom/press-releases/mongodb-launches-atlas-agent-engine-to-put-ai-agents-in-production-without-a-new-stack

[2] MongoDB Atlas Agent Engine Docs，〈Agent Memory〉，2026 年 11 月 5 日查閱：https://www.mongodb.com/docs/agentengine/add-features/memory-types/

[3] MongoDB Atlas Agent Engine Docs，〈Memory Extraction〉，2026 年 11 月 5 日查閱：https://www.mongodb.com/docs/agentengine/add-features/memory-extraction/

[4] MongoDB Atlas Agent Engine Docs，〈Add Memory to Your Agent〉，2026 年 11 月 5 日查閱：https://www.mongodb.com/docs/agentengine/add-features/memory/

[5] LangGraph Reference，〈Checkpointing〉，2026 年 11 月 5 日查閱：https://reference.langchain.com/python/langgraph/checkpoints

圖片資訊

封面為原創 AI 概念插畫，資料櫃象徵記憶分類，不代表 MongoDB 的實際產品介面。