1. 從“健忘”說起Agent 記憶架構(gòu)到底在解決什么問題做 Agent 開發(fā)的人幾乎都經(jīng)歷過這樣一個尷尬時刻你花了一下午調(diào)好的對話助手第一輪聊得好好的第二輪它就把你剛才說的名字、偏好、任務(wù)目標(biāo)全忘了。用戶罵它“人工智障”你心里清楚——不是模型不行是記憶架構(gòu)沒搭對。我最早做 Agent 項目時也踩過這個坑。當(dāng)時用最樸素的方式把整段對話歷史拼進 prompt 里。頭幾輪還行聊到第十輪token 直接爆了成本飆升不說模型還開始“胡言亂語”把早期不相關(guān)的信息當(dāng)成當(dāng)前上下文。后來我才明白Agent 的記憶不是“把歷史全塞進去”這么簡單它是一套分層、有生命周期、需要主動管理的系統(tǒng)。這套系統(tǒng)大致分四層會話記憶Session Memory、短期記憶Short-term Memory、長期記憶Long-term Memory以及最容易被忽略但極其關(guān)鍵的遺忘機制Forgetting。會話記憶管的是“這一次對話的上下文”短期記憶管的是“最近幾輪的任務(wù)狀態(tài)和臨時事實”長期記憶管的是“跨會話沉淀下來的用戶畫像、知識、偏好”而遺忘機制決定了“哪些該丟、哪些該留、什么時候丟”。為什么必須分層因為不同記憶的訪問頻率、存儲成本、時效性完全不同。會話記憶要求毫秒級讀取、隨對話結(jié)束即銷毀長期記憶要求持久化、可檢索、能跨會話復(fù)用但讀取慢一點沒關(guān)系。如果你用一套存儲硬扛所有需求要么貴得離譜要么慢得沒法用。這就像你家里的東西鑰匙放門口掛鉤會話今天要用的文件放書桌短期房產(chǎn)證放保險柜長期過期的傳單直接扔遺忘。全堆在桌上桌子遲早塌。這篇文章適合誰看如果你正在做 Agent 開發(fā)不管是基于 LangChain、AutoGPT 還是自研框架只要涉及到多輪對話、任務(wù)連續(xù)性、個性化服務(wù)這套記憶架構(gòu)你遲早要面對。我會把四層記憶的設(shè)計思路、代碼實現(xiàn)、參數(shù)計算、踩坑經(jīng)驗全部拆開講代碼用 Python 寫但思路是語言無關(guān)的?？赐昴阒辽倌艽畛鲆粋€“不健忘”的 Agent 骨架。2. 四層記憶架構(gòu)的整體設(shè)計與選型邏輯2.1 為什么是這四層而不是三層或五層先說我為什么把記憶分成這四層。市面上有些方案分三層會話、短期、長期有些分五層加了“工作記憶”“情景記憶”。我實測下來四層是最平衡的再少一層職責(zé)會混再多一層維護成本陡增。具體來說會話記憶和短期記憶經(jīng)常被合并但我堅持分開。原因是它們的生命周期觸發(fā)條件不同會話記憶隨“連接建立/斷開”而生滅短期記憶隨“任務(wù)完成/超時”而生滅。一個用戶可能在一個會話里發(fā)起三個任務(wù)每個任務(wù)的短期記憶應(yīng)該獨立但共享同一個會話上下文。如果合并任務(wù) A 的臨時狀態(tài)會污染任務(wù) B。長期記憶和短期記憶的區(qū)別更明顯短期記憶是“這次任務(wù)里記住的”長期記憶是“下次還需要的”。比如用戶說“幫我訂明天去上海的機票”短期記憶存“目的地上海、時間明天”任務(wù)結(jié)束就可以清但如果用戶說“我以后都坐靠窗座位”這就該進長期記憶。至于遺忘機制它不是一層“存儲”而是一套作用于所有層的策略。很多人把它當(dāng)成長期記憶的附屬功能這是錯的。會話記憶也需要遺忘——比如滑動窗口截斷短期記憶也需要遺忘——比如任務(wù)完成后清理。遺忘是橫切的關(guān)注點。2.2 存儲選型為什么不全用向量數(shù)據(jù)庫新手最容易犯的錯是一上來所有記憶都往向量數(shù)據(jù)庫里塞。我試過結(jié)果是會話記憶的讀取延遲從 5ms 漲到 80ms因為向量檢索再快也比不上內(nèi)存字典。而且會話記憶根本不需要“語義檢索”它就是按 session_id 精確取。我的選型是這樣的記憶層存儲介質(zhì)讀取方式典型延遲生命周期會話記憶內(nèi)存Redis/進程內(nèi)字典精確 key 查詢5ms會話期間短期記憶內(nèi)存 輕量持久化精確 key 時間序20ms任務(wù)期間長期記憶向量庫 關(guān)系庫語義檢索 結(jié)構(gòu)化查詢50-200ms永久可歸檔遺忘策略定時任務(wù) 觸發(fā)器批量掃描離線持續(xù)運行這個表是我踩了無數(shù)坑總結(jié)的。核心原則是越靠近當(dāng)前對話的記憶讀取越要快存儲越要輕越遠離的越要能檢索存儲越要穩(wěn)。向量庫我一般選輕量級的方案關(guān)系庫用 SQLite 或 Postgres 都行。這里不展開具體產(chǎn)品因為選型要看你的部署環(huán)境思路比工具重要。2.3 數(shù)據(jù)流轉(zhuǎn)一次對話里記憶是怎么流動的理解架構(gòu)最好的方式是跟一遍數(shù)據(jù)流。假設(shè)用戶說“我叫老王幫我查下北京明天的天氣我一般喜歡看攝氏度?！睍捰洃涍@句話連同 session_id 一起寫入會話緩存同時把最近 N 輪歷史拼進 prompt。短期記憶Agent 解析出“查天氣”這個任務(wù)把{任務(wù): 天氣查詢, 城市: 北京, 日期: 明天}寫入短期記憶。長期記憶Agent 識別到“我叫老王”“喜歡攝氏度”是持久偏好寫入長期記憶打上user_profile標(biāo)簽。遺忘會話結(jié)束后會話記憶按 TTL 過期任務(wù)完成后短期記憶被清理長期記憶里的偏好保留但會定期做去重和置信度衰減。這個流轉(zhuǎn)里寫入時機的判斷是最難的。不是所有信息都值得記。我的經(jīng)驗是顯式聲明“我叫X”“我喜歡Y”優(yōu)先記長期任務(wù)參數(shù)記短期閑聊內(nèi)容只留會話。3. 會話記憶上下文窗口的精細化管理3.1 會話記憶的本質(zhì)是“有損壓縮”很多人以為會話記憶就是把歷史消息存下來。錯。會話記憶的本質(zhì)是在有限 token 預(yù)算下最大化保留對當(dāng)前對話有用的信息。這是一個有損壓縮問題。為什么必須有損因為模型的上下文窗口是有限的。就算你用 128K 窗口的模型聊上幾十輪也會滿而且 token 越多推理越慢、越貴。我算過一筆賬假設(shè)每輪對話平均 200 token128K 窗口理論上能裝 640 輪但實際到 100 輪左右模型對早期信息的注意力就明顯衰減了。所以不是窗口夠大就不用管理。我的會話記憶結(jié)構(gòu)長這樣class SessionMemory: def __init__(self, session_id, max_tokens4000, max_turns20): self.session_id session_id self.messages [] # 完整消息列表 self.summary # 早期對話的摘要 self.max_tokens max_tokens self.max_turns max_turns def add_message(self, role, content): self.messages.append({role: role, content: content}) self._compress_if_needed() def _compress_if_needed(self): # 超過輪數(shù)上限把最老的幾輪壓縮成摘要 if len(self.messages) self.max_turns: old self.messages[:5] self.summary self._summarize(old, self.summary) self.messages self.messages[5:] def get_context(self): # 摘要 最近消息拼成最終上下文 ctx [] if self.summary: ctx.append({role: system, content: f早期對話摘要{self.summary}}) ctx.extend(self.messages) return ctx這段代碼的關(guān)鍵在_compress_if_needed。我沒有用簡單的“截斷最老的”而是把最老的幾輪壓縮成摘要。為什么因為直接截斷會丟失信息比如用戶第一輪說的名字截斷后模型就忘了。摘要雖然也有損但保留了關(guān)鍵實體。3.2 摘要壓縮的觸發(fā)閾值怎么定max_turns20這個值不是拍腦袋定的。我的計算邏輯是先確定 token 預(yù)算再反推輪數(shù)。假設(shè)你的模型上下文窗口是 8K你要留 2K 給系統(tǒng) prompt 和輸出那可用上下文是 6K。每輪對話平均 150 token用戶助手那理論上能裝 40 輪。但為了給摘要和檢索結(jié)果留空間我一般取理論值的 50%也就是 20 輪。這個“50% 安全系數(shù)”是我多次實測的經(jīng)驗值——留太少會頻繁觸發(fā)壓縮留太多會浪費窗口。注意摘要本身也消耗 token。如果你的摘要寫得太長壓縮就失去意義了。我一般把摘要控制在 200 token 以內(nèi)只保留人名、偏好、未完成任務(wù)這些關(guān)鍵信息。3.3 會話記憶的持久化與恢復(fù)會話記憶默認(rèn)在內(nèi)存里但有個問題服務(wù)重啟或用戶換設(shè)備會話就斷了。所以生產(chǎn)環(huán)境我會做輕量持久化——把會話記憶定期快照到 RedisTTL 設(shè)為 30 分鐘。為什么是 30 分鐘因為大部分對話的間隔不會超過這個時間。超過 30 分鐘用戶大概率是開始新話題了舊會話恢復(fù)反而會帶來干擾。這個值可以根據(jù)你的業(yè)務(wù)調(diào)整客服場景可以短一點10 分鐘教育場景可以長一點2 小時?；謴?fù)邏輯很簡單用戶帶著 session_id 回來先從 Redis 取快照取不到就新建。這里有個坑快照要存摘要和最近消息不要存全量。全量快照又大又慢恢復(fù)后還是要壓縮不如直接存壓縮后的狀態(tài)。4. 短期記憶任務(wù)狀態(tài)的臨時賬本4.1 短期記憶和會話記憶的邊界在哪這是最容易被混淆的地方。我用一個例子說清楚用戶在一個會話里說“幫我規(guī)劃一個三天的北京行程第一天去故宮第二天去長城第三天待定”。會話記憶記的是用戶說了這句話助手回了什么。短期記憶記的是{任務(wù): 行程規(guī)劃, 城市: 北京, 天數(shù): 3, 已定: [故宮, 長城], 待定: [第三天]}。區(qū)別在于會話記憶是原始對話流短期記憶是結(jié)構(gòu)化任務(wù)狀態(tài)。會話記憶給模型看短期記憶給程序邏輯用。當(dāng)用戶后來說“第三天改成頤和園”程序從短期記憶里取出任務(wù)狀態(tài)更新待定字段而不是去翻對話歷史。為什么必須分開因為程序邏輯不該依賴自然語言解析。如果每次更新任務(wù)狀態(tài)都要重新解析對話既慢又容易出錯。短期記憶就是把這個解析結(jié)果緩存下來。4.2 短期記憶的數(shù)據(jù)結(jié)構(gòu)設(shè)計短期記憶我一般用“任務(wù)槽Task Slot”模型class TaskSlot: def __init__(self, task_id, task_type): self.task_id task_id self.task_type task_type # 任務(wù)類型如 travel_plan self.slots {} # 槽位如 {city: 北京, days: 3} self.status in_progress # in_progress / completed / abandoned self.created_at time.time() self.updated_at time.time() def update_slot(self, key, value): self.slots[key] value self.updated_at time.time() def is_expired(self, ttl1800): return time.time() - self.updated_at ttlslots字典是核心。它的 key 是預(yù)定義的槽位名value 是當(dāng)前值。預(yù)定義的好處是可控——你知道這個任務(wù)有哪些槽位不會無限膨脹。如果槽位是動態(tài)的短期記憶會變成另一個“什么都往里塞”的垃圾堆。ttl180030 分鐘是任務(wù)超時時間。超過 30 分鐘沒更新任務(wù)大概率被用戶放棄了該清理。這個值也要按業(yè)務(wù)調(diào)訂票類任務(wù)可以短10 分鐘寫作類任務(wù)可以長2 小時。4.3 短期記憶的讀寫時機短期記憶的寫入時機有三個任務(wù)創(chuàng)建時Agent 識別到新任務(wù)創(chuàng)建 TaskSlot。槽位更新時用戶補充信息更新對應(yīng)槽位。任務(wù)完成時標(biāo)記 status 為 completed觸發(fā)清理。讀取時機主要是兩個生成回復(fù)前把當(dāng)前任務(wù)狀態(tài)注入 prompt讓模型知道“現(xiàn)在進行到哪了”。執(zhí)行動作前程序邏輯檢查槽位是否齊全不齊就追問用戶。這里有個實操心得注入 prompt 的任務(wù)狀態(tài)要精簡。我見過有人把整個 slots 字典序列化后塞進去結(jié)果模型被一堆 JSON 搞暈了。正確做法是轉(zhuǎn)成自然語言比如“當(dāng)前任務(wù)規(guī)劃北京三日游已確定故宮和長城第三天待定”。提示短期記憶的清理一定要主動。我早期偷懶靠 TTL 自動過期結(jié)果內(nèi)存里堆了一堆僵尸任務(wù)。后來改成任務(wù)完成時立即清理 定時掃描兜底內(nèi)存占用降了 60%。5. 長期記憶跨會話的知識沉淀5.1 長期記憶存什么不存什么長期記憶是最容易“貪多嚼不爛”的地方。新手恨不得把所有對話都存進去結(jié)果檢索時全是噪聲。我的原則是只存三類東西。第一類是用戶畫像姓名、偏好、習(xí)慣、禁忌。比如“老王”“喜歡攝氏度”“不吃辣”。這類信息復(fù)用率最高幾乎每次對話都用得上。第二類是領(lǐng)域知識用戶在對話中提供的、可復(fù)用的知識。比如用戶說“我們公司的報銷流程是 A→B→C”這個流程下次還可能用到。第三類是歷史決策用戶做過的選擇用于保持一致性。比如“上次選了經(jīng)濟艙”這次推薦時可以默認(rèn)經(jīng)濟艙。不存什么閑聊、一次性查詢、臨時情緒。用戶問“今天天氣怎么樣”這個不需要長期記憶。用戶說“我今天心情不好”除非他明確說“以后都這樣”否則也不存。5.2 長期記憶的存儲結(jié)構(gòu)向量 結(jié)構(gòu)化雙寫長期記憶我用雙寫策略向量庫存語義關(guān)系庫存結(jié)構(gòu)。class LongTermMemory: def __init__(self, vector_store, relational_store): self.vector_store vector_store # 語義檢索 self.relational_store relational_store # 結(jié)構(gòu)化查詢 def write(self, user_id, content, memory_type, metadataNone): # 雙寫向量庫用于語義檢索關(guān)系庫用于精確查詢 doc_id self.vector_store.add( textcontent, metadata{user_id: user_id, type: memory_type, **(metadata or {})} ) self.relational_store.insert( doc_iddoc_id, user_iduser_id, contentcontent, memory_typememory_type, metadatametadata or {}, created_attime.time() ) return doc_id def recall(self, user_id, query, top_k5): # 語義檢索 semantic_results self.vector_store.search( queryquery, filter{user_id: user_id}, top_ktop_k ) # 結(jié)構(gòu)化補充比如取用戶畫像 profile self.relational_store.query( user_iduser_id, memory_typeuser_profile ) return {semantic: semantic_results, profile: profile}為什么要雙寫因為語義檢索和精確查詢解決不同問題。用戶問“我上次說的那個偏好是什么”語義檢索能找到程序要取“用戶的所有畫像字段”結(jié)構(gòu)化查詢更快更準(zhǔn)。只用向量庫取畫像要遍歷只用關(guān)系庫語義匹配做不了。雙寫的代價是一致性維護。兩個庫可能不同步比如向量庫寫成功、關(guān)系庫失敗。我的做法是以關(guān)系庫為準(zhǔn)向量庫異步補償。寫入時先寫關(guān)系庫再異步寫向量庫如果向量庫失敗進重試隊列。讀取時如果向量庫缺失回退到關(guān)系庫做關(guān)鍵詞匹配。5.3 長期記憶的檢索策略怎么讓召回更準(zhǔn)長期記憶的檢索質(zhì)量直接決定 Agent 聰不聰明。我踩過的坑是檢索回來的東西太多太雜模型反而被干擾。我的優(yōu)化策略有三層第一層是過濾。檢索前先按 user_id 和 memory_type 過濾只取相關(guān)的。比如當(dāng)前是訂票任務(wù)就只取user_profile和travel_preference不取work_knowledge。第二層是重排。向量檢索返回 top_k 后用一個輕量模型或規(guī)則做重排。我的規(guī)則是時間越近的權(quán)重越高被引用次數(shù)越多的權(quán)重越高。一個偏好如果被用過 10 次說明它很重要。第三層是截斷。最終注入 prompt 的長期記憶不超過 3 條每條不超過 100 token。為什么這么少因為長期記憶是“錦上添花”不是“雪中送炭”。當(dāng)前對話的上下文才是主角長期記憶太多會喧賓奪主。檢索階段操作目的過濾按 user_id type 篩選縮小范圍降噪召回向量檢索 top 20保證召回率重排時間 引用次數(shù)加權(quán)提升相關(guān)性截斷取 top 3每條限長控制 token 預(yù)算這個表是我調(diào)了很多次才穩(wěn)定的。早期我不做重排直接取 top 5結(jié)果經(jīng)常召回一些“語義相似但實際無關(guān)”的內(nèi)容。加了時間衰減后準(zhǔn)確率明顯提升。6. 遺忘機制被低估的“記憶衛(wèi)生”6.1 為什么遺忘比記憶更重要我見過太多 Agent 項目記憶只進不出最后變成一個“什么都記得但什么都記不清”的糊涂蛋。遺忘不是缺陷是功能。人腦每天遺忘大量信息正是這種遺忘讓重要的信息更突出。Agent 的遺忘要解決三個問題過期清理不再需要的信息、去重合并重復(fù)的信息、置信度衰減可能過時的信息。過期清理最簡單按 TTL 刪。會話記憶 30 分鐘短期記憶任務(wù)完成后立即刪長期記憶里的臨時信息 7 天刪。去重合并稍復(fù)雜。用戶可能在不同會話里說了三次“我喜歡攝氏度”長期記憶里就有三條。我的做法是寫入時先做相似度檢查相似度超過 0.9 就合并更新引用次數(shù)和時間戳。置信度衰減是最容易被忽略的。用戶三年前說“我喜歡攝氏度”現(xiàn)在可能變了。我的策略是長期記憶的置信度隨時間衰減每次被引用時重置。衰減公式用指數(shù)衰減confidence base_confidence * exp(-λ * days_since_last_reference)λ我取 0.01意味著大約 70 天衰減一半。這個值可以調(diào)快消品場景可以大一點醫(yī)療場景可以小一點。6.2 遺忘策略的代碼實現(xiàn)class ForgettingEngine: def __init__(self, ltm, decay_lambda0.01, min_confidence0.3): self.ltm ltm self.decay_lambda decay_lambda self.min_confidence min_confidence def run(self): # 1. 過期清理 self._clean_expired() # 2. 去重合并 self._deduplicate() # 3. 置信度衰減 self._decay_confidence() def _clean_expired(self): now time.time() self.ltm.relational_store.delete_where( created_at ? AND memory_type temporary, (now - 7 * 86400,) ) def _deduplicate(self): # 按 user_id 分組組內(nèi)做相似度合并 for user_id in self.ltm.get_all_users(): memories self.ltm.relational_store.query(user_iduser_id) merged self._merge_similar(memories) if merged: self.ltm.batch_update(merged) def _decay_confidence(self): now time.time() for mem in self.ltm.relational_store.query_all(): days (now - mem[last_referenced_at]) / 86400 new_conf mem[confidence] * math.exp(-self.decay_lambda * days) if new_conf self.min_confidence: self.ltm.relational_store.delete(mem[doc_id]) else: self.ltm.relational_store.update( mem[doc_id], confidencenew_conf )這段代碼里min_confidence0.3是刪除閾值。低于這個值說明這條記憶已經(jīng)“不可信”了刪掉。decay_lambda0.01控制衰減速度。這兩個參數(shù)需要根據(jù)業(yè)務(wù)調(diào)我一般先跑一周看刪除量再微調(diào)。注意遺忘引擎一定要離線跑不要放在請求鏈路里。我早期圖省事在每次對話結(jié)束時同步跑遺忘結(jié)果響應(yīng)時間從 200ms 漲到 800ms。后來改成定時任務(wù)每小時跑一次響應(yīng)時間恢復(fù)正常。6.3 遺忘的“軟刪除”與可恢復(fù)直接刪數(shù)據(jù)有風(fēng)險——萬一刪錯了呢所以我用軟刪除標(biāo)記deleted_at不物理刪除。保留 30 天后再由另一個任務(wù)物理清理。軟刪除的好處是可恢復(fù)。如果用戶投訴“你怎么忘了我說過的話”你可以從軟刪除里撈回來。這個機制在客服場景特別有用我靠它救過好幾次場。7. 全鏈路代碼實戰(zhàn)串起四層記憶7.1 整體調(diào)用流程把四層記憶串起來一次對話的完整流程是這樣的class AgentMemorySystem: def __init__(self, session_store, task_store, ltm, forgetting): self.session_store session_store self.task_store task_store self.ltm ltm self.forgetting forgetting def process(self, user_id, session_id, user_input): # 1. 取會話記憶 session self.session_store.get_or_create(session_id) session.add_message(user, user_input) # 2. 取短期記憶當(dāng)前任務(wù)狀態(tài) task self.task_store.get_active_task(session_id) # 3. 檢索長期記憶 ltm_context self.ltm.recall(user_id, user_input, top_k3) # 4. 組裝 prompt prompt self._build_prompt(session, task, ltm_context) # 5. 調(diào)用模型 response self._call_llm(prompt) # 6. 更新記憶 session.add_message(assistant, response) self._update_task(task, user_input, response) self._maybe_write_ltm(user_id, user_input, response) return response def _build_prompt(self, session, task, ltm_context): parts [] if ltm_context[profile]: parts.append(f用戶畫像{ltm_context[profile]}) if ltm_context[semantic]: parts.append(f相關(guān)記憶{ltm_context[semantic]}) if task: parts.append(f當(dāng)前任務(wù){(diào)task.to_natural_language()}) parts.append(對話歷史) parts.extend(session.get_context()) return \n.join(str(p) for p in parts)這個流程里第 6 步的更新邏輯是重點。_update_task負責(zé)解析用戶輸入更新任務(wù)槽位_maybe_write_ltm負責(zé)判斷是否值得寫長期記憶。7.2 判斷“是否寫長期記憶”的規(guī)則def _maybe_write_ltm(self, user_id, user_input, response): # 規(guī)則1顯式聲明 if any(kw in user_input for kw in [我叫, 我是, 我喜歡, 我偏好, 記住]): self.ltm.write(user_id, user_input, user_profile) return # 規(guī)則2任務(wù)完成后的結(jié)論 if self._is_task_conclusion(response): self.ltm.write(user_id, response, task_conclusion) return # 規(guī)則3用戶糾正 if any(kw in user_input for kw in [不對, 錯了, 應(yīng)該是]): self.ltm.write(user_id, user_input, correction)這三條規(guī)則覆蓋了大部分需要長期記憶的場景。規(guī)則 1 抓顯式聲明規(guī)則 2 抓任務(wù)結(jié)論規(guī)則 3 抓糾正。其他情況默認(rèn)不寫避免噪聲。7.3 參數(shù)計算token 預(yù)算怎么分配最后說一個實操中必須算清楚的賬token 預(yù)算分配。假設(shè)模型窗口 8K輸出預(yù)留 1K系統(tǒng) prompt 占 500那可用 6.5K。我的分配是部分預(yù)算說明長期記憶3003 條每條 100任務(wù)狀態(tài)200自然語言描述會話摘要200早期對話壓縮最近對話5000約 25 輪緩沖800防止超限這個分配不是固定的要根據(jù)任務(wù)類型調(diào)。任務(wù)型對話訂票、查詢可以壓縮最近對話多留任務(wù)狀態(tài)閑聊型對話可以壓縮任務(wù)狀態(tài)多留對話。我踩過的坑是沒留緩沖。有一次用戶輸入特別長加上檢索結(jié)果直接超了窗口模型報錯。后來我強制留 800 token 緩沖再沒出過問題。8. 常見問題與排查技巧實錄8.1 記憶串味不同用戶/會話的記憶混了這是最嚴(yán)重的問題。我遇到過一次用戶 A 的偏好被注入到用戶 B 的對話里差點造成隱私事故。排查下來是過濾條件寫漏了——向量檢索時忘了加 user_id 過濾。排查思路先查檢索代碼的 filter 參數(shù)再看存儲時 user_id 是否正確寫入。我的經(jīng)驗是所有記憶操作強制帶 user_id 和 session_id在數(shù)據(jù)層做校驗不依賴調(diào)用方傳參。8.2 記憶膨脹存儲越來越大檢索越來越慢長期記憶只進不出三個月后檢索延遲從 50ms 漲到 500ms。解決靠遺忘引擎但更根本的是寫入時就要克制。我的規(guī)則是寫入前先查重相似度超 0.9 不寫寫入時打 TTL 標(biāo)簽臨時信息 7 天自動清。8.3 摘要失真壓縮后關(guān)鍵信息丟了摘要模型如果太弱會把“用戶要訂去上海的機票”壓縮成“用戶要訂票”丟了目的地。我的做法是摘要用規(guī)則 模型結(jié)合。規(guī)則提取實體人名、地名、時間模型負責(zé)組織語言。這樣關(guān)鍵實體不會丟。8.4 常見問題速查表問題可能原因排查方向解決記憶串味過濾條件缺失檢查 filter 參數(shù)強制帶 user_id檢索慢數(shù)據(jù)膨脹看存儲量啟用遺忘引擎摘要失真模型太弱對比摘要和原文規(guī)則模型結(jié)合任務(wù)狀態(tài)丟失TTL 太短看任務(wù)間隔調(diào)大 TTL長期記憶不召回向量庫不同步查雙寫日志異步補償這張表是我從多次故障里總結(jié)的基本覆蓋了 80% 的記憶相關(guān)問題。遇到問題先查表能省不少時間。8.5 獨家避坑技巧最后分享幾個文檔里不會寫的技巧。第一記憶寫入要冪等。同一個信息重復(fù)寫入要能去重否則重試機制會導(dǎo)致重復(fù)。第二檢索結(jié)果要打時間戳。模型看到“用戶三個月前說喜歡攝氏度”會自己判斷是否過時。第三遺忘引擎要有 dry-run 模式。上線前先跑一遍看會刪什么確認(rèn)無誤再真刪。我靠 dry-run 避免過一次誤刪用戶畫像的事故。這套架構(gòu)我用了大半年從最初的“聊三輪就失憶”到現(xiàn)在能穩(wěn)定支撐多輪復(fù)雜任務(wù)核心就是把記憶當(dāng)成一個有生命周期的系統(tǒng)來設(shè)計而不是一個簡單的存儲桶。會話、短期、長期、遺忘四層各司其職缺一層都會出問題。代碼不用照抄但分層的思路和那些參數(shù)背后的計算邏輯應(yīng)該能幫你少走不少彎路。