對話記憶（多輪對話記憶）
功能簡介
對話記憶讓 AI 機器人記住目前會話中聊過的內容。
沒有記憶時，機器人每次都「失憶」式地單獨回答——您先問「這個多少錢」，再問「那運費呢」，它根本不知道「這個」指的是什麼。開啟對話記憶後，機器人回答前會先回顧之前的對話，追問、指代都難不 倒它：
訪客：我叫張三，想查一下我的訂單。 機器人：您好張三！請告訴我您的訂單號。 訪客：我忘了，我是誰來著？ 機器人：您是張三。您也可以在「我的訂單」頁面找到訂單號……
對話記憶對開啟了大模型對話的機器人預設開啟，凡是透過微語 AI 閘道接入的模型都支援，包括 DeepSeek、智譜 GLM、阿里雲百鍊（通義千問）。記憶還能跨會話延續：同一訪客再次諮詢同一工作組或機器人時，會接著使用同一本「記憶本」。
工作原理（大白話）
可以把機器人想像成一位隨身帶小本子的客服：
- 隨手記——會話中的每一輪問答（訪客問了什麼、機器人答了什麼）都會自動記到「記憶本」上，儲存在您自己的資料庫裡。
- 答前翻——新問題來臨時，機器人先翻一翻最近的記錄，把它們連同新問題一起交給大模型，回答就能接得上前文。
- 只翻最近幾頁——機器人只重讀最近 N 條訊息（即「上下文訊息數」，預設 10 條），既記得住，又不會因為塞太多內容導致變慢、變貴。
- 一位訪客、一個服務入口，一個本子——記憶按「服務入口 + 訪客身份」（即會話主題）記錄。不同訪客之間互不干擾，絕不會把 A 客戶聊的內容串到 B 客戶那裡；而同一訪客再次諮詢同一工作組或機器人時，仍會寫進同一個本子——機器人因此記得之前的諮詢。
記憶可以跨會話延續：同一訪客開啟新會話，只要還是同一工作組或機器人，會話主題就不變，機器人依然記得之前聊過的內容（最近 N 條以內）。訪客身份儲存在瀏覽器中，清除瀏覽器資料或換裝置後會被識別為新訪客，記憶重新開始。
你能做什麼
- 按機器人開關記憶——在管理後台的機器人設定中，「進階功能」裡有「多輪記憶」開關（預設開啟）。
- 控制記多少——「上下文訊息數」滑桿決定每次重讀多少條最近訊息（預設 10 條，最大 50 條）。
- 查看機器人記住了什麼——超級管理員可以瀏覽全部記憶記錄，按會話 ID、訊息類型、內容關鍵字篩選查詢，並點開查看詳情。
- 讓機器人忘掉——一鍵刪除某個會話主題下的全部記憶，立即 生效：該訪客後續的提問將不再攜帶任何上文。
快速上手
-
前提：機器人已開啟大模型對話，並設定了文字模型（DeepSeek、智譜、百鍊均可）。
-
開啟記憶：管理後台 → AI → 機器人 → 編輯機器人 → 展開進階功能 → 確認多輪記憶已開啟。
-
調節視窗：設定上下文訊息數（建議從 10 開始；長對話中機器人「忘得太快」時再調大）。
-
驗證效果：打開訪客聊天視窗，依序傳送：
- 「我叫張三」
- 「我是誰？」
- 「我剛才問了你什麼？」
機器人都能答對，說明記憶已生效。
查看與管理記憶
記憶記錄在管理後台統一管理：超級管理員 → 訊息 → 對話記憶記錄（企業版/平台版可見，且需要相應的角色權限）。
每條記錄包含：
| 欄位 | 含義 |
|---|---|
| 會話 ID | 這條記憶屬於哪組對話——ID 即會話主題，同一訪客在同一工作組/機器人下的會話共用同一個 ID（一個 ID 對應多條記錄） |
| 序列號 | 該訊息在會話中的順序 |
| 類型 | 這句話是誰說的——見下方說明 |
| 訊息內容 | 訊息原文 |
| 時間戳 | 記錄時間 |
類型共四種：
- USER——訪客說的話
- ASSISTANT——機器人的回覆
- SYSTEM——系統設定（如機器人的人設提示詞）
- TOOL——機器人呼叫工具（如查詢訂單）的中間過程
使用刪除操作可以清空某個會話的全部記憶——例如客戶提出資料刪除請求，或需要清理測試會話時。
常見問題
哪些模型支援多輪記憶？
凡是透過微語 AI 閘道接入的機器人都支援，包括 DeepSeek、智譜 GLM、阿里雲百鍊（通義千問）。記憶是平台能力，無需在模型廠商側做任何設定。
記憶儲存在哪裡？會不會上傳到第三方？
記憶儲存在您自己伺服器的資料庫中（SPRING_AI_CHAT_MEMORY 表，部署時自動建立）。除正常呼叫大模型介面外，不會向任何第三方傳送資料。
下次再來諮詢，機器人還記得我嗎？
記得——只要訪客身份不變（儲存在瀏覽器中）且諮詢的是同一工作組或機器人，會話主題就不變，機器人會接著同一本「記憶本」，記得最近的交流內容（最多「上下文訊息數」條）。清除瀏覽器資料或更換裝置後會被當作新訪客，記憶重新開始。客服端中單獨建立的 AI 助理對話，每次建立都是新會話，記憶互不共享。
關閉多輪記憶 後會怎樣？
機器人回退到舊模式：直接從聊天訊息記錄中讀取最近訊息來補充上下文。會話仍可正常進行，但不再維護統一的「記憶本」，記憶管理頁面也不會再產生新記錄。
上下文訊息數是不是越大越好？
不是。條數越多連續性越好，但 token 成本更高、回覆更慢。客服場景建議 10–20 條，只有複雜的長諮詢才需要調大。
怎麼讓機器人忘掉某段對話？
超級管理員 → 訊息 → 對話記憶記錄 → 找到對應會話 → 刪除。下一條回覆立即失去該上下文。
最佳實踐
- 視窗保持 10–20 條——客服對話足夠用，避免為不必要的 token 買單。
- 及時清理測試會話——測試機器人會產生記憶記錄，刪除後統計和列表更乾淨。
- 重視隱私合規——若訪客可能輸入敏感個人資訊，請將記憶管理權限只授予可信角色，並支援按需刪除。
- 機器人「失憶」了怎麼辦——先確認「多輪記憶」開關是否開啟，再檢查該會話記憶是否被刪除；這兩者都會導致機器人回答不帶上文。
技術背景（選讀）
- 記憶基於 Spring AI
ChatMemory實作：每次模型呼叫都會經過MessageChatMemoryAdvisor，由 JDBC 儲存庫持久化到SPRING_AI_CHAT_MEMORY表。會話 ID 即 threadTopic（ 如org/workgroup/{wgUid}/{visitorUid}），同一訪客 + 同一工作組/機器人的 topic 保持不變，因此記憶天然跨會話延續；AI 助理會話 topic（org/robot/llm/{robotUid}/{userUid}/{randomUid}）帶隨機後綴，每通會話獨立。 - 機器人級開關：
RobotLlm.memoryEnabled；視窗大小：contextMsgCount。Advisor 鏈在AdvisorChainFactory中組裝；各廠商服務（SpringAIDeepseekService、ZhipuaiService、DashscopeService）共享同一套基底類別實作。 - 查詢/刪除介面：
/api/v1/chat/memory/query/org與/api/v1/chat/memory/delete，受CHAT_MEMORY_*權限保護。