)
1. 為什么你的 Agent 總是“轉頭就忘”做過 Agent 項目的人大概率都遇到過這種場景用戶上一句剛說了“我住在杭州平時喜歡喝美式”下一句問“幫我推薦個附近的咖啡店”Agent 卻像失憶一樣反問“請問您在哪個城市”。這不是模型不夠聰明而是記憶架構沒搭好。大模型本身是無狀態(tài)的每一次調用對它來說都是“第一次見面”所謂“記住”本質上是我們外部給它喂了歷史信息。喂多少、喂哪些、喂多久、什么時候丟這一整套設計就是 Agent 記憶架構。我前后在客服機器人、個人助理、代碼助手這幾類項目里都踩過記憶相關的坑最深的體會是記憶不是把聊天記錄一股腦塞進上下文就完事那樣既燒 token 又容易讓模型抓不住重點。真正商用的 Agent 記憶通常要拆成四層來設計——會話記憶、短期記憶、長期記憶、遺忘機制。這四層各司其職配合起來才能讓 Agent 既“記得住當下”又“想得起過去”還不會“被垃圾信息淹沒”。這篇文章我會把這四層從原理到代碼完整拆一遍給出可直接復現的實現思路。適合正在做 Agent 開發(fā)、被上下文長度和記憶混亂折磨過的同學也適合剛入門想搞清楚“記憶到底怎么存”的朋友。全程用大白話加代碼盡量讓你看完就能動手改自己的項目。2. 記憶架構的整體設計與分層思路2.1 四層記憶到底各管什么先把概念理清楚不然后面代碼會亂。我習慣把 Agent 記憶按“時間尺度”和“存儲位置”兩個維度切成四塊會話記憶Session Memory當前這一輪對話的完整上下文生命周期就是這次會話。用戶關掉窗口、超時、主動結束它就沒了。它保證的是“對話連貫性”。短期記憶Short-term Memory跨幾輪甚至跨會話但有時效性的信息比如“用戶今天在查機票”。它通常放在內存或 Redis 里帶 TTL。長期記憶Long-term Memory用戶偏好、身份信息、歷史結論這類需要長期保留的落到數據庫或向量庫靠檢索召回。遺忘機制Forgetting不是單獨一層而是貫穿前三層的清理策略——過期刪除、重要性衰減、容量淘汰。為什么非要分這么細因為它們的讀寫頻率、存儲成本、召回方式完全不同。會話記憶每輪都全量讀必須快長期記憶偶爾查一次可以慢但必須準。混在一起做要么慢要么貴要么亂。2.2 為什么不能只靠“把歷史全塞進 Prompt”很多人第一版 Agent 就是這么干的維護一個 messages 數組每輪把整個數組拼進 prompt。小規(guī)模能用一旦上量就崩。我實測過一個客服場景單會話平均 40 輪每輪平均 120 token到后面光歷史就 4800 token加上系統(tǒng)提示和工具定義一次調用輕松破 8000。按商用 API 的價格算成本直接翻幾倍而且模型在長上下文里對中間部分的注意力會衰減早期關鍵信息反而被忽略。所以分層設計的核心目的就兩個控制進入 prompt 的信息量以及讓該被記住的信息以更高優(yōu)先級出現。會話記憶負責最近幾輪短期記憶負責“最近發(fā)生的事”長期記憶負責“這個人的底色”遺忘機制負責把沒用的清出去。2.3 一個可落地的數據流我常用的數據流是這樣的用戶輸入進來先寫進會話記憶原始消息同時抽取關鍵信息寫入短期記憶每輪組裝 prompt 時按“系統(tǒng)提示 → 長期記憶召回 → 短期記憶摘要 → 會話最近 N 輪”的順序拼接會話結束時把值得長期保留的內容沉淀到長期記憶其余交給遺忘機制處理。這個順序有講究長期記憶放前面是因為它相對穩(wěn)定能作為“背景設定”短期記憶摘要放中間作為“近期狀態(tài)”最近幾輪對話放最后因為模型對末尾內容注意力最強正好用來承接當前話題。下面幾章我會逐層展開。3. 會話記憶讓對話不“斷片”的基礎層3.1 會話記憶的本質是一個滑動窗口會話記憶說白了就是“最近幾輪對話”。但“最近幾輪”怎么定義直接決定體驗。我見過兩種極端做法一種是只保留最后一輪Agent 完全沒有上下文另一種是全保留token 爆炸。合理的做法是滑動窗口 摘要壓縮?；瑒哟翱诘囊馑际侵槐Ａ糇罱?K 輪原文比如 K6。超出的部分不是直接丟而是壓縮成一句摘要塞進短期記憶。這樣既保證了近期對話的完整細節(jié)又不會讓歷史無限膨脹。K 的取值要看場景閑聊類可以小一點4~6任務類比如訂票、寫代碼可以大一點8~10因為任務往往需要更多上下文。3.2 會話 ID 與狀態(tài)管理會話記憶必須綁定一個會話 ID否則多用戶并發(fā)時會串臺。我一般用user_id session_id作為 keysession_id 在用戶開啟新會話時生成。這里有個容易忽略的點會話的“開啟”和“連接”是兩回事。連接是網絡層的會話是業(yè)務層的。用戶可能斷線重連但會話應該延續(xù)也可能一直連著但主動點了“新對話”那會話就該重置。把這兩個概念分開能避免很多詭異 bug。存儲上單機可以用內存字典多實例部署必須用 Redis 之類的共享存儲否則用戶請求打到不同實例上就會“記憶分裂”。這是我早期踩過的大坑本地測試一切正常一上負載均衡就各種失憶。3.3 會話記憶的代碼實現下面是一個精簡但可用的會話記憶實現用 Python 寫存儲抽象成接口方便替換from collections import deque from typing import List, Dict class SessionMemory: def __init__(self, max_turns: int 6): # 每個 turn 是一條 user 或 assistant 消息 self.max_turns max_turns self.buffer deque(maxlenmax_turns * 2) def add(self, role: str, content: str): self.buffer.append({role: role, content: content}) def get_recent(self) - List[Dict]: return list(self.buffer) def overflow(self) - List[Dict]: # 返回被擠出窗口的消息交給摘要器處理 return list(self.buffer)[: -self.max_turns * 2] if len(self.buffer) self.max_turns * 2 else []deque設了maxlen超出自動從左邊彈出天然就是滑動窗口。overflow方法用來拿到被擠出的內容交給下一層的摘要邏輯。實際項目里我會把 buffer 換成 Redis 的 list用LPUSHLTRIM實現同樣的效果這樣多實例共享。注意滑動窗口的“輪”要按對話輪次算不是按消息條數。一輪 用戶一句 助手一句別把工具調用的中間消息也算進去否則窗口會被工具消息占滿。3.4 會話記憶的實操心得我踩過的一個坑是把工具調用的返回結果也塞進會話記憶結果一次搜索返回幾千字直接把窗口撐爆。后來改成工具結果只保留摘要原文放短期記憶按需召回。另一個心得是會話記憶里最好保留原始措辭不要過早改寫因為用戶可能引用自己之前的話改寫后對不上。還有一點會話記憶的讀取要“按需”不是每輪都全量拼。比如用戶只是說了句“謝謝”完全沒必要把六輪歷史都帶上。我一般會根據當前輸入的意圖判斷如果是延續(xù)性話題就帶全窗口如果是全新話題就只帶最近一兩輪。4. 短期記憶跨輪次的“工作臺”4.1 短期記憶和會話記憶的邊界很多人分不清短期記憶和會話記憶我用一個類比會話記憶是“你正在說的這段話”短期記憶是“你今天腦子里裝的事”。會話記憶隨會話結束而消失短期記憶可以跨會話但有時間限制比如幾小時到幾天。典型場景用戶上午問“幫我看看明天杭州的天氣”下午又問“那我要不要帶傘”。這兩次可能是不同會話但短期記憶里存著“用戶關注杭州明天天氣”Agent 就能接上。如果只靠會話記憶下午這次就是全新對話Agent 根本不知道“那”指什么。4.2 短期記憶存什么、怎么存短期記憶我一般存三類東西實體信息用戶提到的地點、時間、人名、任務狀態(tài)正在進行的任務、已完成步驟、臨時結論Agent 自己算出來或查到的結果。存儲結構用 key-value 加 TTL 最省事Redis 的SETEX一行搞定。TTL 的設置要看信息類型任務狀態(tài)可以短一點30 分鐘實體信息可以長一點24 小時。我習慣給每條短期記憶打一個“重要性”分數重要性高的 TTL 長低的短。重要性怎么算簡單點可以用規(guī)則比如包含時間、金額、人名的加分復雜點可以用一個小模型打分但大多數場景規(guī)則就夠了。4.3 短期記憶的讀寫代碼import json import time import redis class ShortTermMemory: def __init__(self, r: redis.Redis, prefix: str stm:): self.r r self.prefix prefix def _key(self, user_id: str) - str: return f{self.prefix}{user_id} def write(self, user_id: str, slot: str, value, ttl: int 3600, importance: float 0.5): # importance 越高ttl 越長 real_ttl int(ttl * (0.5 importance)) data {value: value, ts: time.time(), importance: importance} self.r.hset(self._key(user_id), slot, json.dumps(data)) self.r.expire(self._key(user_id), real_ttl) def read(self, user_id: str, slot: str): raw self.r.hget(self._key(user_id), slot) return json.loads(raw)[value] if raw else None def all_slots(self, user_id: str): return {k.decode(): json.loads(v) for k, v in self.r.hgetall(self._key(user_id)).items()}這里用 hash 存一個用戶的所有短期記憶槽位整體設過期時間。importance影響 TTL 是個實用技巧重要信息活得更久。讀取時all_slots可以一次性拿到所有短期記憶組裝 prompt 時按重要性排序取前幾個。4.4 短期記憶的壓縮與摘要短期記憶不能無限堆我一般設一個上限比如每個用戶最多 20 個槽位超了就按重要性和時間淘汰。另外短期記憶在進入 prompt 前最好做一次摘要把多個槽位合并成一段自然語言比直接塞 JSON 更省 token 也更好理解。摘要的 prompt 我常用這個模板“以下是用戶近期的關鍵信息請用一段話概括保留時間、地點、任務狀態(tài){slots}”。實測下來20 個槽位摘要后通常能壓到 100 token 以內效果比原始 JSON 好很多。提示短期記憶的寫入時機很關鍵。不要等會話結束才寫那樣中途斷線就丟了。我一般在每輪對話后異步寫用消息隊列解耦避免阻塞主流程。5. 長期記憶讓 Agent 真正“認識”用戶5.1 長期記憶的兩種形態(tài)長期記憶我分成兩類結構化記憶和非結構化記憶。結構化的是用戶畫像比如“用戶叫張三常住杭州偏好美式咖啡是后端工程師”存數據庫字段清晰查詢快。非結構化的是歷史對話片段、文檔、結論存向量庫靠語義檢索召回。為什么要分兩種因為它們的召回方式不同。結構化信息適合精確匹配和過濾比如“查所有偏好美式的用戶”非結構化信息適合模糊語義檢索比如“用戶之前提過的那個項目叫什么來著”。兩者配合才能既準又全。5.2 向量檢索的核心參數非結構化長期記憶的核心是向量檢索。這里有幾個參數必須調好否則召回質量很差chunk 大小切分粒度。太小語義不完整太大檢索不準。我一般按 200~500 token 切帶一點重疊。top_k召回條數。太少漏信息太多噪聲大。常用 3~5。相似度閾值低于閾值的不召回避免答非所問。經驗值 0.7 左右具體看 embedding 模型。重排序召回后用一個 cross-encoder 重排能顯著提升精度但會增加延遲按需開啟。這些參數沒有萬能值必須拿真實數據調。我的做法是先固定 top_k5然后調閾值觀察召回結果的相關性再反過來調 chunk 大小。5.3 長期記憶的寫入策略長期記憶不能什么都寫否則很快變成垃圾場。我的寫入策略是“事件驅動 重要性過濾”會話結束時觸發(fā)一次沉淀用一個小模型或規(guī)則判斷哪些內容值得長期保留。值得保留的通常是用戶明確表達的偏好、身份信息、重要結論、反復出現的話題。def should_persist(text: str, importance: float) - bool: # 規(guī)則 分數雙重判斷 keywords [我喜歡, 我習慣, 我是, 記住, 以后都] if any(k in text for k in keywords): return True return importance 0.75這個函數很粗糙但實用。實際項目里我會再加一層去重用向量相似度判斷新記憶和已有記憶是否重復避免同一偏好存十遍。5.4 長期記憶的召回與注入召回時機有兩個每輪都召回和按需召回。每輪都召回簡單但費錢按需召回省錢但可能漏。我折中一下先用一個輕量分類器判斷當前輸入是否需要長期記憶比如問“我是誰”“我之前說過什么”就需要需要才召回。召回后的注入也有講究。不要把召回原文直接塞進 prompt最好整理成“背景信息”的形式比如“關于該用戶的歷史信息1. 常住杭州2. 偏好美式咖啡”。這樣模型更容易理解這是背景而非當前對話。注意長期記憶召回的內容要標注來源和時間比如“2024-05 記錄”避免模型把過期信息當現狀。用戶搬家了但舊記憶還寫著老地址這種錯誤很常見。6. 遺忘機制會“忘”才是好記憶6.1 為什么必須主動遺忘人的記憶靠遺忘來保持高效Agent 也一樣。不遺忘的后果有三個存儲成本無限增長、檢索噪聲越來越大、過期信息誤導模型。我見過一個項目長期記憶庫跑了一年沒清理用戶問“我上次說的那個方案”召回出來五個不同時期的方案模型直接懵了。遺忘不是刪除那么簡單要分清楚“該忘什么”。我的原則是時效性強的信息到期就刪重要性低的信息優(yōu)先淘汰矛盾的信息保留最新的。6.2 三種遺忘策略基于時間的遺忘TTL短期記憶天然帶 TTL到期自動清。長期記憶里的臨時信息也設 TTL比如“用戶本周在出差”這種一周后自動失效?；谥匾缘倪z忘LRU/LFU 變體給每條記憶打重要性分容量滿時淘汰最低分的。重要性可以隨訪問次數動態(tài)調整被召回過的加分?；诿艿倪z忘新記憶和舊記憶沖突時保留新的、標記舊的為失效。比如用戶說“我搬到上海了”舊的“常住杭州”就該失效。6.3 遺忘機制的實現class ForgettingPolicy: def __init__(self, max_items: int 1000, decay: float 0.95): self.max_items max_items self.decay decay def score(self, item: dict, now: float) - float: age_hours (now - item[ts]) / 3600 # 時間衰減 重要性 訪問加成 return item[importance] * (self.decay ** age_hours) 0.1 * item.get(hits, 0) def evict(self, items: list, now: float) - list: if len(items) self.max_items: return items items.sort(keylambda x: self.score(x, now), reverseTrue) return items[: self.max_items]這個score函數把時間衰減、重要性和訪問次數揉在一起decay0.95表示每小時衰減 5%。實測下來這個簡單公式比純 LRU 更符合直覺因為重要的老記憶不會被輕易淘汰。6.4 遺忘的實操心得遺忘最怕“誤刪”。我踩過的坑是 TTL 設太短用戶第二天回來發(fā)現 Agent 完全不認識自己了。后來改成核心畫像姓名、長期偏好永不過期只對臨時信息設 TTL。另外刪除前最好留個“墓碑”記錄方便排查問題比如記錄“某條記憶在何時因何被刪”。還有一個技巧是“軟刪除”不真刪只標記失效檢索時過濾掉。這樣萬一誤刪還能恢復代價是存儲多一點。對大多數項目來說這點存儲成本完全值得。7. 全鏈路串聯與常見問題排查7.1 一次完整請求的記憶流轉把四層串起來看一次請求用戶輸入 → 寫入會話記憶 → 抽取實體寫短期記憶 → 判斷是否召回長期記憶 → 組裝 prompt長期 短期摘要 會話窗口→ 調用模型 → 返回結果寫會話記憶 → 會話結束觸發(fā)長期沉淀和遺忘清理。這個流程里每一步都可能出問題下面整理成速查表?，F象可能原因排查方向Agent 完全失憶會話 ID 丟失或存儲不通檢查 session_id 生成和 Redis 連接記得舊的不記新的短期記憶 TTL 太長或未更新檢查寫入時機和 TTL 配置召回答非所問向量閾值太低或 chunk 太大調高閾值、縮小 chunktoken 超限會話窗口太大或長期記憶召回太多縮小 K、限制 top_k多實例記憶不一致用了本地內存存儲換成共享存儲過期信息誤導遺忘機制沒生效檢查 TTL 和矛盾檢測7.2 并發(fā)場景下的記憶安全Agent 扛并發(fā)時記憶的讀寫要加鎖或用原子操作。比如兩個請求同時更新同一個用戶的短期記憶可能互相覆蓋。我的做法是用 Redis 的HSET原子性保證單字段更新安全跨字段的更新用 Lua 腳本或分布式鎖。會話記憶的追加用LPUSH天然原子不用擔心。另一個并發(fā)坑是“會話串臺”用戶 A 的請求因為異步處理結果寫到了用戶 B 的會話里。這通常是上下文傳遞時丟了 user_id排查時重點看異步任務的參數傳遞。7.3 記憶架構的演進建議剛開始做不用一上來就四層全上可以按需演進第一版只做會話記憶能跑通對話第二版加短期記憶解決跨會話第三版加長期記憶和向量檢索解決個性化最后加遺忘機制解決長期運行。每加一層都要有明確的痛點驅動別為了架構而架構。我個人的體會是記憶架構的復雜度要和業(yè)務價值匹配。一個內部工具類 Agent會話記憶加簡單短期記憶就夠了一個面向 C 端的個人助理長期記憶和遺忘機制才是核心競爭力。想清楚你的 Agent 到底要“記住什么”比堆技術更重要。最后分享一個小技巧給記憶系統(tǒng)加一個“調試面板”能實時看到當前用戶的所有記憶內容。排查問題時一眼就能看出是沒存進去、存錯了還是沒召回。這個面板我每個項目都會做省下的排查時間遠超開發(fā)成本。 Agent記憶架構四層設計：會話、短期、長期與遺忘機制實戰(zhàn)
1. 為什么你的 Agent 總是“轉頭就忘”做過 Agent 項目的人大概率都遇到過這種場景用戶上一句剛說了“我住在杭州平時喜歡喝美式”下一句問“幫我推薦個附近的咖啡店”Agent 卻像失憶一樣反問“請問您在哪個城市”。這不是模型不夠聰明而是記憶架構沒搭好。大模型本身是無狀態(tài)的每一次調用對它來說都是“第一次見面”所謂“記住”本質上是我們外部給它喂了歷史信息。喂多少、喂哪些、喂多久、什么時候丟這一整套設計就是 Agent 記憶架構。我前后在客服機器人、個人助理、代碼助手這幾類項目里都踩過記憶相關的坑最深的體會是記憶不是把聊天記錄一股腦塞進上下文就完事那樣既燒 token 又容易讓模型抓不住重點。真正商用的 Agent 記憶通常要拆成四層來設計——會話記憶、短期記憶、長期記憶、遺忘機制。這四層各司其職配合起來才能讓 Agent 既“記得住當下”又“想得起過去”還不會“被垃圾信息淹沒”。這篇文章我會把這四層從原理到代碼完整拆一遍給出可直接復現的實現思路。適合正在做 Agent 開發(fā)、被上下文長度和記憶混亂折磨過的同學也適合剛入門想搞清楚“記憶到底怎么存”的朋友。全程用大白話加代碼盡量讓你看完就能動手改自己的項目。2. 記憶架構的整體設計與分層思路2.1 四層記憶到底各管什么先把概念理清楚不然后面代碼會亂。我習慣把 Agent 記憶按“時間尺度”和“存儲位置”兩個維度切成四塊會話記憶Session Memory當前這一輪對話的完整上下文生命周期就是這次會話。用戶關掉窗口、超時、主動結束它就沒了。它保證的是“對話連貫性”。短期記憶Short-term Memory跨幾輪甚至跨會話但有時效性的信息比如“用戶今天在查機票”。它通常放在內存或 Redis 里帶 TTL。長期記憶Long-term Memory用戶偏好、身份信息、歷史結論這類需要長期保留的落到數據庫或向量庫靠檢索召回。遺忘機制Forgetting不是單獨一層而是貫穿前三層的清理策略——過期刪除、重要性衰減、容量淘汰。為什么非要分這么細因為它們的讀寫頻率、存儲成本、召回方式完全不同。會話記憶每輪都全量讀必須快長期記憶偶爾查一次可以慢但必須準。混在一起做要么慢要么貴要么亂。2.2 為什么不能只靠“把歷史全塞進 Prompt”很多人第一版 Agent 就是這么干的維護一個 messages 數組每輪把整個數組拼進 prompt。小規(guī)模能用一旦上量就崩。我實測過一個客服場景單會話平均 40 輪每輪平均 120 token到后面光歷史就 4800 token加上系統(tǒng)提示和工具定義一次調用輕松破 8000。按商用 API 的價格算成本直接翻幾倍而且模型在長上下文里對中間部分的注意力會衰減早期關鍵信息反而被忽略。所以分層設計的核心目的就兩個控制進入 prompt 的信息量以及讓該被記住的信息以更高優(yōu)先級出現。會話記憶負責最近幾輪短期記憶負責“最近發(fā)生的事”長期記憶負責“這個人的底色”遺忘機制負責把沒用的清出去。2.3 一個可落地的數據流我常用的數據流是這樣的用戶輸入進來先寫進會話記憶原始消息同時抽取關鍵信息寫入短期記憶每輪組裝 prompt 時按“系統(tǒng)提示 → 長期記憶召回 → 短期記憶摘要 → 會話最近 N 輪”的順序拼接會話結束時把值得長期保留的內容沉淀到長期記憶其余交給遺忘機制處理。這個順序有講究長期記憶放前面是因為它相對穩(wěn)定能作為“背景設定”短期記憶摘要放中間作為“近期狀態(tài)”最近幾輪對話放最后因為模型對末尾內容注意力最強正好用來承接當前話題。下面幾章我會逐層展開。3. 會話記憶讓對話不“斷片”的基礎層3.1 會話記憶的本質是一個滑動窗口會話記憶說白了就是“最近幾輪對話”。但“最近幾輪”怎么定義直接決定體驗。我見過兩種極端做法一種是只保留最后一輪Agent 完全沒有上下文另一種是全保留token 爆炸。合理的做法是滑動窗口 摘要壓縮?；瑒哟翱诘囊馑际侵槐Ａ糇罱?K 輪原文比如 K6。超出的部分不是直接丟而是壓縮成一句摘要塞進短期記憶。這樣既保證了近期對話的完整細節(jié)又不會讓歷史無限膨脹。K 的取值要看場景閑聊類可以小一點4~6任務類比如訂票、寫代碼可以大一點8~10因為任務往往需要更多上下文。3.2 會話 ID 與狀態(tài)管理會話記憶必須綁定一個會話 ID否則多用戶并發(fā)時會串臺。我一般用user_id session_id作為 keysession_id 在用戶開啟新會話時生成。這里有個容易忽略的點會話的“開啟”和“連接”是兩回事。連接是網絡層的會話是業(yè)務層的。用戶可能斷線重連但會話應該延續(xù)也可能一直連著但主動點了“新對話”那會話就該重置。把這兩個概念分開能避免很多詭異 bug。存儲上單機可以用內存字典多實例部署必須用 Redis 之類的共享存儲否則用戶請求打到不同實例上就會“記憶分裂”。這是我早期踩過的大坑本地測試一切正常一上負載均衡就各種失憶。3.3 會話記憶的代碼實現下面是一個精簡但可用的會話記憶實現用 Python 寫存儲抽象成接口方便替換from collections import deque from typing import List, Dict class SessionMemory: def __init__(self, max_turns: int 6): # 每個 turn 是一條 user 或 assistant 消息 self.max_turns max_turns self.buffer deque(maxlenmax_turns * 2) def add(self, role: str, content: str): self.buffer.append({role: role, content: content}) def get_recent(self) - List[Dict]: return list(self.buffer) def overflow(self) - List[Dict]: # 返回被擠出窗口的消息交給摘要器處理 return list(self.buffer)[: -self.max_turns * 2] if len(self.buffer) self.max_turns * 2 else []deque設了maxlen超出自動從左邊彈出天然就是滑動窗口。overflow方法用來拿到被擠出的內容交給下一層的摘要邏輯。實際項目里我會把 buffer 換成 Redis 的 list用LPUSHLTRIM實現同樣的效果這樣多實例共享。注意滑動窗口的“輪”要按對話輪次算不是按消息條數。一輪 用戶一句 助手一句別把工具調用的中間消息也算進去否則窗口會被工具消息占滿。3.4 會話記憶的實操心得我踩過的一個坑是把工具調用的返回結果也塞進會話記憶結果一次搜索返回幾千字直接把窗口撐爆。后來改成工具結果只保留摘要原文放短期記憶按需召回。另一個心得是會話記憶里最好保留原始措辭不要過早改寫因為用戶可能引用自己之前的話改寫后對不上。還有一點會話記憶的讀取要“按需”不是每輪都全量拼。比如用戶只是說了句“謝謝”完全沒必要把六輪歷史都帶上。我一般會根據當前輸入的意圖判斷如果是延續(xù)性話題就帶全窗口如果是全新話題就只帶最近一兩輪。4. 短期記憶跨輪次的“工作臺”4.1 短期記憶和會話記憶的邊界很多人分不清短期記憶和會話記憶我用一個類比會話記憶是“你正在說的這段話”短期記憶是“你今天腦子里裝的事”。會話記憶隨會話結束而消失短期記憶可以跨會話但有時間限制比如幾小時到幾天。典型場景用戶上午問“幫我看看明天杭州的天氣”下午又問“那我要不要帶傘”。這兩次可能是不同會話但短期記憶里存著“用戶關注杭州明天天氣”Agent 就能接上。如果只靠會話記憶下午這次就是全新對話Agent 根本不知道“那”指什么。4.2 短期記憶存什么、怎么存短期記憶我一般存三類東西實體信息用戶提到的地點、時間、人名、任務狀態(tài)正在進行的任務、已完成步驟、臨時結論Agent 自己算出來或查到的結果。存儲結構用 key-value 加 TTL 最省事Redis 的SETEX一行搞定。TTL 的設置要看信息類型任務狀態(tài)可以短一點30 分鐘實體信息可以長一點24 小時。我習慣給每條短期記憶打一個“重要性”分數重要性高的 TTL 長低的短。重要性怎么算簡單點可以用規(guī)則比如包含時間、金額、人名的加分復雜點可以用一個小模型打分但大多數場景規(guī)則就夠了。4.3 短期記憶的讀寫代碼import json import time import redis class ShortTermMemory: def __init__(self, r: redis.Redis, prefix: str stm:): self.r r self.prefix prefix def _key(self, user_id: str) - str: return f{self.prefix}{user_id} def write(self, user_id: str, slot: str, value, ttl: int 3600, importance: float 0.5): # importance 越高ttl 越長 real_ttl int(ttl * (0.5 importance)) data {value: value, ts: time.time(), importance: importance} self.r.hset(self._key(user_id), slot, json.dumps(data)) self.r.expire(self._key(user_id), real_ttl) def read(self, user_id: str, slot: str): raw self.r.hget(self._key(user_id), slot) return json.loads(raw)[value] if raw else None def all_slots(self, user_id: str): return {k.decode(): json.loads(v) for k, v in self.r.hgetall(self._key(user_id)).items()}這里用 hash 存一個用戶的所有短期記憶槽位整體設過期時間。importance影響 TTL 是個實用技巧重要信息活得更久。讀取時all_slots可以一次性拿到所有短期記憶組裝 prompt 時按重要性排序取前幾個。4.4 短期記憶的壓縮與摘要短期記憶不能無限堆我一般設一個上限比如每個用戶最多 20 個槽位超了就按重要性和時間淘汰。另外短期記憶在進入 prompt 前最好做一次摘要把多個槽位合并成一段自然語言比直接塞 JSON 更省 token 也更好理解。摘要的 prompt 我常用這個模板“以下是用戶近期的關鍵信息請用一段話概括保留時間、地點、任務狀態(tài){slots}”。實測下來20 個槽位摘要后通常能壓到 100 token 以內效果比原始 JSON 好很多。提示短期記憶的寫入時機很關鍵。不要等會話結束才寫那樣中途斷線就丟了。我一般在每輪對話后異步寫用消息隊列解耦避免阻塞主流程。5. 長期記憶讓 Agent 真正“認識”用戶5.1 長期記憶的兩種形態(tài)長期記憶我分成兩類結構化記憶和非結構化記憶。結構化的是用戶畫像比如“用戶叫張三常住杭州偏好美式咖啡是后端工程師”存數據庫字段清晰查詢快。非結構化的是歷史對話片段、文檔、結論存向量庫靠語義檢索召回。為什么要分兩種因為它們的召回方式不同。結構化信息適合精確匹配和過濾比如“查所有偏好美式的用戶”非結構化信息適合模糊語義檢索比如“用戶之前提過的那個項目叫什么來著”。兩者配合才能既準又全。5.2 向量檢索的核心參數非結構化長期記憶的核心是向量檢索。這里有幾個參數必須調好否則召回質量很差chunk 大小切分粒度。太小語義不完整太大檢索不準。我一般按 200~500 token 切帶一點重疊。top_k召回條數。太少漏信息太多噪聲大。常用 3~5。相似度閾值低于閾值的不召回避免答非所問。經驗值 0.7 左右具體看 embedding 模型。重排序召回后用一個 cross-encoder 重排能顯著提升精度但會增加延遲按需開啟。這些參數沒有萬能值必須拿真實數據調。我的做法是先固定 top_k5然后調閾值觀察召回結果的相關性再反過來調 chunk 大小。5.3 長期記憶的寫入策略長期記憶不能什么都寫否則很快變成垃圾場。我的寫入策略是“事件驅動 重要性過濾”會話結束時觸發(fā)一次沉淀用一個小模型或規(guī)則判斷哪些內容值得長期保留。值得保留的通常是用戶明確表達的偏好、身份信息、重要結論、反復出現的話題。def should_persist(text: str, importance: float) - bool: # 規(guī)則 分數雙重判斷 keywords [我喜歡, 我習慣, 我是, 記住, 以后都] if any(k in text for k in keywords): return True return importance 0.75這個函數很粗糙但實用。實際項目里我會再加一層去重用向量相似度判斷新記憶和已有記憶是否重復避免同一偏好存十遍。5.4 長期記憶的召回與注入召回時機有兩個每輪都召回和按需召回。每輪都召回簡單但費錢按需召回省錢但可能漏。我折中一下先用一個輕量分類器判斷當前輸入是否需要長期記憶比如問“我是誰”“我之前說過什么”就需要需要才召回。召回后的注入也有講究。不要把召回原文直接塞進 prompt最好整理成“背景信息”的形式比如“關于該用戶的歷史信息1. 常住杭州2. 偏好美式咖啡”。這樣模型更容易理解這是背景而非當前對話。注意長期記憶召回的內容要標注來源和時間比如“2024-05 記錄”避免模型把過期信息當現狀。用戶搬家了但舊記憶還寫著老地址這種錯誤很常見。6. 遺忘機制會“忘”才是好記憶6.1 為什么必須主動遺忘人的記憶靠遺忘來保持高效Agent 也一樣。不遺忘的后果有三個存儲成本無限增長、檢索噪聲越來越大、過期信息誤導模型。我見過一個項目長期記憶庫跑了一年沒清理用戶問“我上次說的那個方案”召回出來五個不同時期的方案模型直接懵了。遺忘不是刪除那么簡單要分清楚“該忘什么”。我的原則是時效性強的信息到期就刪重要性低的信息優(yōu)先淘汰矛盾的信息保留最新的。6.2 三種遺忘策略基于時間的遺忘TTL短期記憶天然帶 TTL到期自動清。長期記憶里的臨時信息也設 TTL比如“用戶本周在出差”這種一周后自動失效?；谥匾缘倪z忘LRU/LFU 變體給每條記憶打重要性分容量滿時淘汰最低分的。重要性可以隨訪問次數動態(tài)調整被召回過的加分?；诿艿倪z忘新記憶和舊記憶沖突時保留新的、標記舊的為失效。比如用戶說“我搬到上海了”舊的“常住杭州”就該失效。6.3 遺忘機制的實現class ForgettingPolicy: def __init__(self, max_items: int 1000, decay: float 0.95): self.max_items max_items self.decay decay def score(self, item: dict, now: float) - float: age_hours (now - item[ts]) / 3600 # 時間衰減 重要性 訪問加成 return item[importance] * (self.decay ** age_hours) 0.1 * item.get(hits, 0) def evict(self, items: list, now: float) - list: if len(items) self.max_items: return items items.sort(keylambda x: self.score(x, now), reverseTrue) return items[: self.max_items]這個score函數把時間衰減、重要性和訪問次數揉在一起decay0.95表示每小時衰減 5%。實測下來這個簡單公式比純 LRU 更符合直覺因為重要的老記憶不會被輕易淘汰。6.4 遺忘的實操心得遺忘最怕“誤刪”。我踩過的坑是 TTL 設太短用戶第二天回來發(fā)現 Agent 完全不認識自己了。后來改成核心畫像姓名、長期偏好永不過期只對臨時信息設 TTL。另外刪除前最好留個“墓碑”記錄方便排查問題比如記錄“某條記憶在何時因何被刪”。還有一個技巧是“軟刪除”不真刪只標記失效檢索時過濾掉。這樣萬一誤刪還能恢復代價是存儲多一點。對大多數項目來說這點存儲成本完全值得。7. 全鏈路串聯與常見問題排查7.1 一次完整請求的記憶流轉把四層串起來看一次請求用戶輸入 → 寫入會話記憶 → 抽取實體寫短期記憶 → 判斷是否召回長期記憶 → 組裝 prompt長期 短期摘要 會話窗口→ 調用模型 → 返回結果寫會話記憶 → 會話結束觸發(fā)長期沉淀和遺忘清理。這個流程里每一步都可能出問題下面整理成速查表?，F象可能原因排查方向Agent 完全失憶會話 ID 丟失或存儲不通檢查 session_id 生成和 Redis 連接記得舊的不記新的短期記憶 TTL 太長或未更新檢查寫入時機和 TTL 配置召回答非所問向量閾值太低或 chunk 太大調高閾值、縮小 chunktoken 超限會話窗口太大或長期記憶召回太多縮小 K、限制 top_k多實例記憶不一致用了本地內存存儲換成共享存儲過期信息誤導遺忘機制沒生效檢查 TTL 和矛盾檢測7.2 并發(fā)場景下的記憶安全Agent 扛并發(fā)時記憶的讀寫要加鎖或用原子操作。比如兩個請求同時更新同一個用戶的短期記憶可能互相覆蓋。我的做法是用 Redis 的HSET原子性保證單字段更新安全跨字段的更新用 Lua 腳本或分布式鎖。會話記憶的追加用LPUSH天然原子不用擔心。另一個并發(fā)坑是“會話串臺”用戶 A 的請求因為異步處理結果寫到了用戶 B 的會話里。這通常是上下文傳遞時丟了 user_id排查時重點看異步任務的參數傳遞。7.3 記憶架構的演進建議剛開始做不用一上來就四層全上可以按需演進第一版只做會話記憶能跑通對話第二版加短期記憶解決跨會話第三版加長期記憶和向量檢索解決個性化最后加遺忘機制解決長期運行。每加一層都要有明確的痛點驅動別為了架構而架構。我個人的體會是記憶架構的復雜度要和業(yè)務價值匹配。一個內部工具類 Agent會話記憶加簡單短期記憶就夠了一個面向 C 端的個人助理長期記憶和遺忘機制才是核心競爭力。想清楚你的 Agent 到底要“記住什么”比堆技術更重要。最后分享一個小技巧給記憶系統(tǒng)加一個“調試面板”能實時看到當前用戶的所有記憶內容。排查問題時一眼就能看出是沒存進去、存錯了還是沒召回。這個面板我每個項目都會做省下的排查時間遠超開發(fā)成本。