MongoDB 把代理人記憶放進資料庫：企業導入前先畫六層地圖

客服代理人記住一件事：某個企業客戶偏好月繳方案。

這種記憶很有用。下次客戶詢問升級，代理人可以少問一輪問題，也能把回覆接上過去脈絡。

但如果它記住的是一次敏感抱怨、一個已經更正的錯誤資料、一段不該跨 session 保存的內部備註，問題就變了。AI 代理人記憶（agent memory）聽起來像產品魔法，實作上是資料設計、權限設計和保存期限設計。

MongoDB 5 月 7 日在 MongoDB.local London 宣布一組企業 AI 資料平台能力，包含 Automated Voyage AI Embeddings in MongoDB Vector Search、LangGraph.js 長期記憶、MongoDB 8.3 效能提升，以及跨雲、on-prem、hybrid 部署定位。

這則新聞可以當成一張正式上線 AI 代理人的資料地圖來看：代理人要可靠，不能只靠模型回答。它需要找得到資料、分得清短期對話與長期記憶，也要知道哪些內容永遠不該被寫進記憶層。

記憶是資料設計問題

MongoDB 這次最清楚的主張，是把 AI 代理人品質問題拉回資料層。

新聞稿裡，MongoDB 說正式上線的 AI 代理人需要即時資料庫、全文與向量搜尋、記憶、embeddings、reranker models。它的產品方向是讓企業不用把營運資料、向量資料庫、embedding pipeline 和記憶儲存拆成多套系統再同步。

這個方向很合理。很多代理人錯誤不是模型突然變笨，而是它拿不到最新資料、檢索到錯的文件、記住了不該記的內容，或把同一段對話裡的暫時狀態當成長期事實。

所以導入 AI 代理人記憶前，問題不該只問「能不能記住」。更實際的是：記住什麼、在哪一層記住、誰能改、多久刪、如何查證。

MongoDB 想包住三個資料面

第一個面是營運資料。

MongoDB Vector Search 產品頁說，向量資料可以和營運資料放在 Atlas 裡，同時支援 metadata filters、graph lookups、aggregation pipelines、geospatial search、lexical search 等混合查詢。對正式上線的 AI 代理人來說，這代表它可以在同一個資料環境中找文字、結構化條件和語意相似內容。

第二個面是 embeddings。

MongoDB 表示 Automated Voyage AI Embeddings in MongoDB Vector Search 目前是 public preview，可以在資料寫入或更新時自動產生 embeddings。產品頁也說 Auto Embeddings 會在資料變化時自動產生和同步 embeddings。

這能減少一個常見工程負擔：資料庫更新了，向量索引沒有同步；或資料已經刪改，代理人檢索還抓到舊版本。

第三個面是記憶。

MongoDB 5 月 8 日的產品更新說，LangGraph.js 現在支援 MongoDB 作為長期 AI 代理人記憶的後端。MongoDB Memory Store 可以保存和取回跨 session 資料，並支援語意記憶搜尋，背後可使用 client-side embeddings provider 或 MongoDB Atlas Automated Embeddings。

這裡要特別拆開短期和長期。

MongoDB docs 把 LangGraph memory 分成兩種機制：短期記憶用 checkpointer 保存單一 thread 的狀態；長期記憶用 Store abstraction 保存跨 threads 的資料。前者像這次對話的工作記憶，後者才像跨會話的使用者偏好、政策限制、穩定事實。

六層資料地圖

MongoDB 的公告最適合用這張表讀。

層級	MongoDB 這次主張	團隊還要自己決定
營運資料	即時業務資料與向量資料放在同一平台	代理人可讀哪些表、哪些欄位、哪些客戶資料
Embeddings	資料寫入或更新時自動 vectorize	embedding 錯配、舊資料、敏感內容如何處理
Vector Search	支援 vector、metadata、lexical、geospatial 等混合查詢	檢索結果如何排序、驗證、引用
短期記憶	用 checkpointer 保持單一 thread 狀態	對話結束後哪些狀態必須消失
長期記憶	用 Store 保存跨 session 事實與偏好	consent、retention、delete、correction 規則
效能	MongoDB 8.3 宣稱 read/write/transaction 提升	你的 workload 是否符合 MongoDB 的測試條件

這張表也說明資料庫能解什麼、不能解什麼。

資料庫可以讓 AI 代理人比較容易抓到最新資料。可以幫你減少 embedding pipeline。可以把跨 session 記憶變成可查詢、可管理的資料物件。

但資料庫不會替你判斷某段記憶是否應該存在。它也不會自動知道某個使用者是否撤回同意、某份文件是否過期、某個代理人是否有權看特定客戶資料。

效能數字要當 vendor claim

MongoDB 也把 MongoDB 8.3 放進這次企業 AI 敘事。新聞稿說 MongoDB 8.3 相比 MongoDB 8.0，有 up to 45% more reads、35% more writes、15% more ACID transactions、30% more complex operations。

這些數字可以報，但要當 MongoDB 自己的 claim。沒有獨立 benchmark，就不該寫成普遍保證。

對 AI 代理人工作負載來說，效能也不是單一數字。retrieval latency、embedding generation、vector index update、memory write、權限檢查、LLM round-trip，每一段都可能是瓶頸。資料庫更快，不等於整個代理人回應就可靠。

採用前，先定義什麼不該被記住

MongoDB 這次抓到一個真問題：正式上線的 AI 代理人不能只靠一個 prompt 和一個模型。它需要資料層，尤其需要即時資料、語意檢索、短期狀態和長期記憶分工。

但企業真的導入時，最好先把反面清單寫出來。

哪些內容只能存在當前對話？哪些偏好可以跨 session 保存？哪些法規、醫療、金融、HR、客訴資料不可進入長期記憶？使用者要怎麼查、改、刪自己的記憶？記憶被拿來生成回答時，能不能顯示來源？

如果這些問題還沒回答，AI 代理人記憶只是把模糊風險存得更久。資料層可以讓記憶變得可查、可索引、可同步；要讓記憶變得可負責，還要靠產品邊界和治理規則一起落地。

林子睿（編輯：廖玄同），《MongoDB 把代理人記憶放進資料庫：企業導入前先畫六層地圖》，矽基前沿 [Si]gnals，2026-05-16。https://signals.tw/articles/mongodb-agent-data-layer/