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