很多剛開(kāi)始玩大模型 Agent 的朋友第一次做出來(lái)的機(jī)器人像個(gè)金魚聊完上一句就忘。這不是模型笨而是我一開(kāi)始也沒(méi)搞懂 Agent 記憶技術(shù)到底在解決什么問(wèn)題。這篇指南按照我自己從零到能跑通的路線整理面向小白程序員邏輯講透代碼可以直接抄。我會(huì)從原理、分層、代碼、參數(shù)、踩坑五個(gè)角度把“大模型 Agent 怎么記住東西”這件事拆開(kāi)講清楚。你不需要一開(kāi)始就懂向量數(shù)據(jù)庫(kù)也不需要背一堆新名詞跟著順序看下來(lái)基本就能在自己的項(xiàng)目里給 Agent 裝上“記憶”。適合誰(shuí)讀剛接觸大模型應(yīng)用開(kāi)發(fā)、想讓自己的聊天機(jī)器人具備跨會(huì)話記憶、做私人知識(shí)助手、或者想在團(tuán)隊(duì)里搭一個(gè)帶記憶的客服問(wèn)答系統(tǒng)的人。就算你只寫過(guò)一點(diǎn) Python也一樣能跟上。1. 先搞清楚 Agent 為什么需要記憶1.1 大模型生來(lái)就是“無(wú)狀態(tài)”的大模型本質(zhì)上是一個(gè)函數(shù)給它一段文字它返回一段文字。它不會(huì)在上一次調(diào)用結(jié)束后保存任何東西。你發(fā)兩條消息它不會(huì)自動(dòng)記得第一條聊了什么除非你把第一條的內(nèi)容重新塞進(jìn)第二條的輸入里。這一點(diǎn)和人的對(duì)話體驗(yàn)差別巨大。人聊天時(shí)會(huì)自然記住“剛才聊到了什么”“對(duì)方叫什么名字”“他上次說(shuō)過(guò)喜歡簡(jiǎn)潔”。但模型沒(méi)有這個(gè)概念。所謂“模型有記憶”實(shí)際上是在模型外面加了存儲(chǔ)和檢索再把檢索到的內(nèi)容放回輸入里。我剛開(kāi)始做 Agent 時(shí)犯過(guò)一個(gè)經(jīng)典錯(cuò)誤以為把歷史消息存進(jìn)數(shù)據(jù)庫(kù)Agent 就有記憶了。結(jié)果發(fā)現(xiàn)存了等于沒(méi)存因?yàn)槟Ｐ透静粫?huì)自己去查數(shù)據(jù)庫(kù)。它只認(rèn)當(dāng)前請(qǐng)求里的內(nèi)容。所以你真正要做的事情只有一件在合適的時(shí)機(jī)把合適的記憶內(nèi)容變成當(dāng)前請(qǐng)求的一部分。1.2 記憶的本質(zhì)是上下文管理不是單純存儲(chǔ)很多人把“記憶系統(tǒng)”理解成“聊天記錄存儲(chǔ)系統(tǒng)”這是誤區(qū)。存儲(chǔ)只是最底層記憶系統(tǒng)的核心是上下文管理。上下文窗口就像桌面記憶庫(kù)像檔案柜。檔案柜再滿也沒(méi)關(guān)系但桌面只有那么大面積。你不能把所有檔案都攤在桌面上不然真正有用的東西反而找不到。Agent 記憶要做的工作是判斷哪些檔案現(xiàn)在有用、把哪幾份抽出來(lái)放到桌面上、用完后再收回去。換句話說(shuō)記憶系統(tǒng)不是“存得越多越好”而是“放得越準(zhǔn)越好”。精確地決定“放什么進(jìn) Prompt”比“存了多少條歷史”重要得多。1.3 這篇指南解決三類問(wèn)題一類是“記不住”用戶昨天告訴你他喜歡簡(jiǎn)短回復(fù)今天你又說(shuō)了一大篇。這類問(wèn)題源于跨會(huì)話信息丟失。另一類是“記太亂”歷史記錄、用戶偏好、臨時(shí)狀態(tài)全混在一起塞進(jìn) Prompt 后模型被舊信息帶偏回答前后矛盾。還有一類是“記不起”記憶明明存了但檢索的時(shí)候找不準(zhǔn)。比如用戶問(wèn)“上次那個(gè)報(bào)錯(cuò)解決了嗎”系統(tǒng)搜不到因?yàn)楫?dāng)時(shí)的記錄里根本沒(méi)有“報(bào)錯(cuò)”這個(gè)詞。后面所有內(nèi)容基本都在圍繞“怎么記住、怎么存、怎么取、怎么用、怎么忘”這五件事展開(kāi)。2. 記憶體系的四層拆分2.1 第一層會(huì)話工作記憶第一層是“正在聊的這段對(duì)話”也就是當(dāng)前 prompt 里的消息列表。它由模型自帶的上下文窗口承載需要我們自己管理長(zhǎng)度和裁剪策略。典型問(wèn)題用戶連續(xù)聊二十分鐘后歷史太長(zhǎng)超過(guò)窗口上限。簡(jiǎn)單粗暴的做法是“只保留最近 N 條”但這樣會(huì)導(dǎo)致更早的關(guān)鍵信息丟失。稍好一點(diǎn)的做法是把早期內(nèi)容壓縮成摘要再把摘要放在消息列表最前面。這一層的管理頻率非常高幾乎是每次請(qǐng)求都要做。所以它必須足夠輕不能依賴外部數(shù)據(jù)庫(kù)查詢盡量在內(nèi)存里完成。2.2 第二層情景記憶情景記憶存的是“發(fā)生過(guò)的事件”。比如“用戶上午反饋了支付失敗”“上次對(duì)話里用戶要求換個(gè)方案”“上周已經(jīng)發(fā)送過(guò)一封確認(rèn)郵件”。這類記憶的特點(diǎn)是有時(shí)間、有事件、有結(jié)果通常按發(fā)生順序檢索。情景記憶解決的是連續(xù)性。沒(méi)有它用戶下次打開(kāi)對(duì)話時(shí)Agent 完全不知道你們之前發(fā)生過(guò)什么。有了它Agent 可以說(shuō)出“上次你提到支付失敗我查了一下可能是銀行接口超時(shí)”。實(shí)現(xiàn)時(shí)一般會(huì)給每條記憶打上時(shí)間戳、事件類型、關(guān)聯(lián)對(duì)象這樣既能按時(shí)間排序也能按事件類型過(guò)濾。2.3 第三層語(yǔ)義記憶語(yǔ)義記憶存的是“事實(shí)和偏好”不依賴某個(gè)具體事件。比如“用戶喜歡簡(jiǎn)潔回復(fù)”“項(xiàng)目部署在測(cè)試環(huán)境”“用戶所在行業(yè)是教育”。這些內(nèi)容即使不提時(shí)間也長(zhǎng)期有效。語(yǔ)義記憶通常適合用向量檢索。因?yàn)橛脩魡?wèn)法千變?nèi)f化“我上次說(shuō)過(guò)的偏好你還記得嗎”“回復(fù)別那么啰嗦”和“用戶喜歡簡(jiǎn)短回答”這句話在字面上差別很大但語(yǔ)義距離很近。向量檢索能抓這種近似關(guān)系。語(yǔ)義記憶要特別注意覆蓋和去重。同一條偏好可能被寫進(jìn)去三次如果不去重檢索時(shí)會(huì)同時(shí)冒出三條重復(fù)記憶既占空間又干擾模型。2.4 第四層程序性記憶程序性記憶是“怎么做某件事”的經(jīng)驗(yàn)比如“遇到數(shù)學(xué)計(jì)算先調(diào)用計(jì)算工具別自己心算”“生成周報(bào)時(shí)按數(shù)據(jù)、結(jié)論、行動(dòng)計(jì)劃三段來(lái)寫”。在小項(xiàng)目里這部分通常被寫死在代碼邏輯或系統(tǒng)提示詞里。但做得復(fù)雜的 Agent 會(huì)把它沉淀為可檢索的技能模板。比如一個(gè) Agent 遇到 Excel 處理任務(wù)時(shí)會(huì)自動(dòng)調(diào)出“讀取表格-清洗-分析-出報(bào)告”的流程模板。程序性記憶的本質(zhì)是知識(shí)復(fù)用。它能讓 Agent 不去重復(fù)摸索流程而是直接使用已經(jīng)驗(yàn)證過(guò)的方法。四層記憶可以共存。我的經(jīng)驗(yàn)是先把會(huì)話工作記憶和語(yǔ)義記憶做扎實(shí)再考慮情景和程序性記憶。因?yàn)榍皟蓚€(gè)直接決定用戶體驗(yàn)后兩個(gè)更多是錦上添花。記憶類型典型內(nèi)容存儲(chǔ)方式主要用途會(huì)話工作記憶當(dāng)前對(duì)話上下文內(nèi)存消息列表保證當(dāng)前對(duì)話連貫情景記憶某時(shí)某刻發(fā)生的事件數(shù)據(jù)庫(kù)記錄時(shí)間索引跨會(huì)話回溯語(yǔ)義記憶用戶偏好、事實(shí)知識(shí)向量庫(kù)規(guī)則過(guò)濾回答個(gè)性化問(wèn)題程序性記憶任務(wù)流程、技能模板配置/模板庫(kù)自動(dòng)決定執(zhí)行路徑3. 手把手實(shí)現(xiàn)一套可用的記憶組件3.1 最小版會(huì)話窗口管理先寫一個(gè)最簡(jiǎn)單的會(huì)話窗口。作用是控制消息列表長(zhǎng)度超出的部分?jǐn)D壓成摘要而不是直接扔掉。import json from collections import deque class SessionWindow: def __init__(self, max_messages20): self.max_messages max_messages self.messages deque(maxlenmax_messages) def add(self, role, content): self.messages.append({role: role, content: content}) def to_prompt(self): return list(self.messages) def compress_old(self): # 保留最近一半消息把更早的文本拼成一條摘要占位 keep_count self.max_messages // 2 old list(self.messages)[:-keep_count] recent list(self.messages)[-keep_count:] summary_text 之前對(duì)話摘要 .join(m[content] for m in old if m[content]) self.messages.clear() self.messages.append({role: system, content: summary_text}) for m in recent: self.messages.append(m)這里用deque(maxlen...)可以自動(dòng)丟棄最舊的。但只丟棄不總結(jié)會(huì)丟關(guān)鍵信息。compress_old就是把早期內(nèi)容壓成一條摘要再把摘要放到 system 里。注意摘要不能太頻繁做。每輪都?jí)嚎s等于把每次回答都再調(diào)用一次模型做總結(jié)成本和延遲都會(huì)上去。建議當(dāng)消息條數(shù)達(dá)到上限時(shí)才觸發(fā)。3.2 升級(jí)版向量檢索長(zhǎng)期記憶當(dāng)需要跨會(huì)話記住用戶偏好和事件時(shí)純會(huì)話窗口不夠。我們需要一個(gè)“寫進(jìn)去-查出來(lái)”的機(jī)制。最通用方案是向量檢索把文本變成向量用余弦相似度找最接近的內(nèi)容。下面用一個(gè)純 Python 標(biāo)準(zhǔn)庫(kù)演示核心邏輯。生產(chǎn)環(huán)境一般會(huì)用現(xiàn)成的向量庫(kù)或模型服務(wù)提供的 embedding原理一樣。import hashlib import json def tokenize(text): # 簡(jiǎn)單按空格和標(biāo)點(diǎn)切分真實(shí)場(chǎng)景可以用分詞庫(kù) return [t.lower() for t in text.replace(,, ).replace(。, ).split()] def hashed_embedding(text, dim128): vec [0.0] * dim for token in tokenize(text): digest hashlib.md5(token.encode()).hexdigest()[:8] index int(digest, 16) % dim vec[index] 1.0 return vec def cosine_similarity(a, b): dot sum(x * y for x, y in zip(a, b)) norm_a sum(x * x for x in a) ** 0.5 norm_b sum(x * x for x in b) ** 0.5 if norm_a 0 or norm_b 0: return 0.0 return dot / (norm_a * norm_b) class VectorMemory: def __init__(self, pathmemory.json): self.path path self.items self._load() def _load(self): try: with open(self.path, r, encodingutf-8) as f: return json.load(f) except FileNotFoundError: return [] def _save(self): with open(self.path, w, encodingutf-8) as f: json.dump(self.items, f, ensure_asciiFalse, indent2) def add(self, text, categorygeneral): embedding hashed_embedding(text) self.items.append({ text: text, category: category, embedding: embedding, access_count: 0 }) self._save() def search(self, query, top_k3): query_vec hashed_embedding(query) scored [] for item in self.items: score cosine_similarity(query_vec, item[embedding]) scored.append((score, item)) scored.sort(keylambda x: x[0], reverseTrue) return scored[:top_k]這個(gè)寫法可以跑通但有個(gè)明顯缺陷哈希詞袋向量對(duì)“語(yǔ)義相似”不敏感比如“喜歡簡(jiǎn)短”和“別啰嗦”幾乎匹配不到一起。真實(shí)項(xiàng)目里應(yīng)該把hashed_embedding替換成 embedding 模型生成的向量。替換后其他邏輯不用變。搜索后把返回結(jié)果按指定格式拼進(jìn) Prompt 就行memory VectorMemory() results memory.search(用戶喜歡什么風(fēng)格) memory_section \n.join(f- [{r[1][category]}] {r[1][text]} for r in results) prompt f以下是長(zhǎng)期記憶\n{memory_section}\n\n請(qǐng)基于記憶回答當(dāng)前問(wèn)題。每次命中時(shí)最好更新access_count后面做遺忘策略會(huì)用到。3.3 進(jìn)階版寫入與遺忘策略長(zhǎng)期記憶最怕兩件事什么垃圾都存、存了永遠(yuǎn)不刪。所以要加兩道流程寫入前過(guò)濾定期遺忘。寫入前過(guò)濾舉例def should_store(text, min_length10): # 太短的內(nèi)容沒(méi)有存儲(chǔ)價(jià)值 if len(text) min_length: return False # 一些臨時(shí)寒暄不值得記 useless [你好, 哈哈, 再見(jiàn), 不知道] if any(u in text for u in useless): return False return True遺忘策略可以用“低頻且長(zhǎng)期未訪問(wèn)優(yōu)先清理”的思路import time def clean_memory(memory, max_items200, max_age_days30): now time.time() kept [] for item in memory.items: last_access item.get(last_access_ts, now) age_days (now - last_access) / 86400 # 訪問(wèn)次數(shù)低且超過(guò)30天未用準(zhǔn)備淘汰 if age_days max_age_days and item.get(access_count, 0) 3: continue kept.append(item) memory.items kept memory._save()這只是示例生產(chǎn)里更常用加權(quán)分?jǐn)?shù)綜合“最近訪問(wèn)時(shí)間”“訪問(wèn)次數(shù)”“內(nèi)容重要性”算一個(gè)衰減分低于閾值就刪除。操作心得遺忘一定要做成定時(shí)任務(wù)而不是每輪對(duì)話都掃一遍。原因很簡(jiǎn)單記憶表小的時(shí)候怎么掃都無(wú)所謂但數(shù)據(jù)到幾萬(wàn)條后每次掃描都是性能開(kāi)銷。4. 記憶鏈路的四個(gè)關(guān)鍵步驟與參數(shù)選擇4.1 寫入判斷什么值得記記憶寫入最容易犯的錯(cuò)是“全量寫入”。把每輪對(duì)話都原樣存進(jìn)去短期內(nèi)沒(méi)感覺(jué)時(shí)間一長(zhǎng)向量庫(kù)塞滿了“今天天氣不錯(cuò)”“好的”“嗯嗯”這類無(wú)意義內(nèi)容檢索質(zhì)量直線下降。我自己的篩選標(biāo)準(zhǔn)有三條包含事實(shí)比如用戶所在行業(yè)、項(xiàng)目名稱、聯(lián)系方式、產(chǎn)品版本。包含偏好比如“回復(fù)要簡(jiǎn)短”“不喜歡 emoji”“報(bào)告要帶數(shù)據(jù)表”。包含狀態(tài)變化比如“支付失敗已解決”“計(jì)劃從下周二開(kāi)始實(shí)施”。凡是用戶明確表達(dá)、重復(fù)提到、并且后續(xù)可能再次使用的信息才寫入。相反寒暄、臨時(shí)情緒、一次性的流程確認(rèn)通常不寫。寫入時(shí)還要做歸一化。比如用戶說(shuō)“以后叫我老王就行”和“請(qǐng)稱呼我為老王”本質(zhì)是同一件事至少要把稱呼統(tǒng)一成“用戶希望被稱呼為老王”。不做歸一化檢索時(shí)會(huì)同時(shí)命中兩條類似內(nèi)容白白浪費(fèi)上下文空間。4.2 檢索如何讓“相關(guān)”變成“精準(zhǔn)”檢索是記憶系統(tǒng)里最影響體驗(yàn)的環(huán)節(jié)。相關(guān)不代表有用。用戶問(wèn)“昨天那個(gè)問(wèn)題解決了嗎”檢索出十條“昨天聊過(guò)的東西”模型反而不知道具體是哪件事。通用做法是“先過(guò)濾再排序”。先用元數(shù)據(jù)縮小范圍比如時(shí)間范圍、對(duì)話場(chǎng)景、記憶分類然后做向量檢索按相似度排序最后按分?jǐn)?shù)閾值截?cái)?。相關(guān)參數(shù)我建議這樣設(shè)置top_k從 3 開(kāi)始調(diào)。太少容易漏太多容易雜。min_score低于 0.2 的記憶不要放進(jìn)上下文。這個(gè)值需要配合你用的 embedding 模型來(lái)定不同模型分?jǐn)?shù)分布差很多。recency_bonus給近期內(nèi)容加一點(diǎn)權(quán)重。例如最終得分 相似度 * 0.8 時(shí)間新鮮度 * 0.2。調(diào)參時(shí)建議每次只改一個(gè)變量別同時(shí)動(dòng) top_k 和閾值不然你不知道是哪個(gè)改動(dòng)帶來(lái)的效果。4.3 融合檢索結(jié)果如何安全放進(jìn) Prompt檢索結(jié)果進(jìn)了 Prompt不代表模型會(huì)正確使用。你需要告訴模型“哪些是記憶哪些是當(dāng)前對(duì)話”。我常用的格式【長(zhǎng)期記憶】 - 用戶偏好喜歡簡(jiǎn)短回復(fù) - 事實(shí)當(dāng)前項(xiàng)目使用測(cè)試環(huán)境 【當(dāng)前對(duì)話】 用戶昨天那個(gè)報(bào)錯(cuò)后來(lái)怎么解決的這樣模型可以清楚區(qū)分信息來(lái)源不容易把舊記憶當(dāng)成新輸入。如果記憶內(nèi)容和當(dāng)前對(duì)話沖突比如記憶說(shuō)“用戶喜歡詳細(xì)報(bào)告”但當(dāng)前用戶說(shuō)“別廢話直接給結(jié)論”我會(huì)在 Prompt 里加一句“當(dāng)長(zhǎng)期記憶與當(dāng)前對(duì)話矛盾時(shí)以當(dāng)前對(duì)話為準(zhǔn)”。融合階段還要控制體量。我給自己定過(guò)一個(gè)預(yù)算記憶內(nèi)容不超過(guò)整個(gè) Prompt 的 30%。超過(guò)這個(gè)比例模型會(huì)迷失重點(diǎn)回答又臭又長(zhǎng)。4.4 遺忘記憶系統(tǒng)必須會(huì)做減法遺忘和寫入同樣重要。沒(méi)有遺忘記憶庫(kù)就是垃圾堆。舊信息會(huì)干擾新判斷甚至讓 Agent 用過(guò)時(shí)信息回答當(dāng)前問(wèn)題。我項(xiàng)目里至少維護(hù)三種遺忘機(jī)制過(guò)期刪除比如“臨時(shí)任務(wù)”類記憶 24 小時(shí)后失效。低頻刪除超過(guò) 30 天沒(méi)被檢索到的記憶權(quán)重下調(diào)最終清理。沖突覆蓋當(dāng)新記憶與舊記憶語(yǔ)義高度相似且信息更新時(shí)刪除舊記錄。遺忘是記憶系統(tǒng)和日志系統(tǒng)的分界線。日志是”全都要存永不刪除“記憶是”只保留對(duì)后續(xù)決策有用的信息“。很多人把這兩者混在一起最后系統(tǒng)既不像日志也不像記憶。5. 落地實(shí)踐五個(gè)經(jīng)典問(wèn)題5.1 檢索不到用戶覺(jué)得你“失憶”了現(xiàn)象是用戶明確告訴你“我上次說(shuō)過(guò)”Agent 卻說(shuō)“抱歉我沒(méi)有找到相關(guān)信息”。先檢查三步寫入有沒(méi)有成功、檢索條件是不是太嚴(yán)、文本有沒(méi)有分詞或編碼問(wèn)題。我踩過(guò)一個(gè)坑是 embedding 用的是舊模型新對(duì)話里的詞分布變化太大導(dǎo)致相似度普遍偏低。換新 embedding 模型后問(wèn)題消失。如果檢索確實(shí)沒(méi)問(wèn)題但用戶換了說(shuō)法可以加一層“關(guān)鍵詞向量混合檢索”。關(guān)鍵詞負(fù)責(zé)精確匹配向量負(fù)責(zé)語(yǔ)義近似兩邊各自返回一批候選最后合并排序。這樣能覆蓋“字面不同但意思相近”的情況。5.2 檢索出一堆但全用不上現(xiàn)象是明明返回了記憶模型還是答非所問(wèn)。原因通常是 top_k 太大或者檢索時(shí)沒(méi)有限定記憶類型。比如用戶問(wèn)的是項(xiàng)目狀態(tài)結(jié)果系統(tǒng)把用戶閑聊偏好、歷史情緒、任務(wù)記錄全檢索出來(lái)了。正確做法是按“場(chǎng)景 分類”過(guò)濾。查詢前先識(shí)別意圖這是任務(wù)咨詢那就只檢索“任務(wù)類”記憶這是閑聊那就只檢索“偏好類”記憶。過(guò)濾后再做向量排序準(zhǔn)確率和效率都會(huì)好很多。5.3 上下文越來(lái)越長(zhǎng)費(fèi)用吃不住隨著記憶累積每次請(qǐng)求都會(huì)變得越來(lái)越長(zhǎng)。如果不對(duì)上下文做限制Token 費(fèi)用會(huì)線性上漲。我的做法是三層存儲(chǔ)熱記憶最近 1 小時(shí)內(nèi)的會(huì)話直接放內(nèi)存。溫記憶跨天但頻繁使用的內(nèi)容放向量庫(kù)按需檢索。冷記憶一個(gè)月前的內(nèi)容壓縮成摘要后歸檔。每次請(qǐng)求前先算一次總 Token。如果超過(guò)窗口預(yù)算就降低“溫記憶”的召回條數(shù)。比如正常取 5 條超預(yù)算時(shí)就只取 3 條。優(yōu)先保當(dāng)前對(duì)話長(zhǎng)期記憶永遠(yuǎn)讓路。5.4 記憶被污染越修越錯(cuò)這是最隱蔽的問(wèn)題?！拔廴尽敝稿e(cuò)誤的記憶被寫入后模型每次都會(huì)基于錯(cuò)誤信息回答用戶糾正完后舊的錯(cuò)誤還在又會(huì)被檢索出來(lái)。避免污染的關(guān)鍵是更新機(jī)制。當(dāng)出現(xiàn)一條新記憶與舊記憶明顯矛盾時(shí)不應(yīng)“并列存儲(chǔ)”而應(yīng)該做覆蓋。比如舊記憶是“項(xiàng)目部署在測(cè)試環(huán)境”用戶今天說(shuō)“項(xiàng)目已經(jīng)上線生產(chǎn)了”這時(shí)直接刪除舊條目或標(biāo)記為過(guò)期只保留新條目。另外必須給用戶提供“刪除記憶”的能力。哪怕只是提供一個(gè)簡(jiǎn)單的“清除我的所有歷史記憶”按鈕也能兜底解決大部分污染問(wèn)題。5.5 安全與隱私怎么處理記憶里往往包含很多個(gè)人信息和業(yè)務(wù)敏感信息。至少要遵守這幾條不記錄密碼、密鑰、Token 等敏感字段。寫入前先做脫敏手機(jī)號(hào)、身份證號(hào)、銀行卡號(hào)用掩碼替換。記憶數(shù)據(jù)按用戶隔離不能在多用戶間串?dāng)?shù)據(jù)。明確告知用戶我們存儲(chǔ)了哪些信息并支持一鍵清除。合規(guī)這塊不能等項(xiàng)目上線才補(bǔ)。從第一版設(shè)計(jì)記憶組件開(kāi)始就要把數(shù)據(jù)隔離和刪除機(jī)制考慮進(jìn)去。否則后期改造成本會(huì)很高。癥狀可能原因排查順序快速對(duì)策完全檢索不到寫入失敗或閾值過(guò)高先查寫入日志再查檢索分?jǐn)?shù)放寬 min_score啟用混合檢索檢索結(jié)果不相關(guān)top_k 過(guò)大、未按場(chǎng)景過(guò)濾看返回條目的類型分布先按記憶分類過(guò)濾再向量排序上下文超預(yù)算記憶未分級(jí)、沒(méi)有限制條數(shù)統(tǒng)計(jì)每次請(qǐng)求 Token 消耗三層存儲(chǔ)限制溫記憶召回記憶越用越錯(cuò)沖突信息未覆蓋、污染寫入檢查是否有重復(fù)矛盾記錄增加覆蓋機(jī)制提供用戶刪除入口數(shù)據(jù)安全風(fēng)險(xiǎn)敏感字段明文入庫(kù)檢查入庫(kù)前是否有脫敏邏輯脫敏隔離可刪除6. 進(jìn)階方向與選型建議6.1 從向量檢索邁向知識(shí)圖譜向量檢索擅長(zhǎng)回答“語(yǔ)義相近”但不擅長(zhǎng)回答“多跳關(guān)系”。比如“A 用戶負(fù)責(zé)的 B 項(xiàng)目里有哪些模塊是用 C 技術(shù)實(shí)現(xiàn)的”這種問(wèn)題如果只靠向量匹配很難一次命中。知識(shí)圖譜則可以把實(shí)體和關(guān)系串起來(lái)支持精確的關(guān)系查詢。但知識(shí)圖譜的構(gòu)建成本高需要維護(hù)實(shí)體、關(guān)系、屬性和更新邏輯。我的建議是先跑通向量記憶等確實(shí)遇到“關(guān)系推理”類需求再引入圖結(jié)構(gòu)。小項(xiàng)目上來(lái)就做圖譜大概率會(huì)被建圖工作量拖垮。6.2 記憶壓縮的兩種路線一是摘要壓縮。把長(zhǎng)段對(duì)話交給模型生成一段摘要放入長(zhǎng)期記憶。優(yōu)點(diǎn)是保存的信息密度高缺點(diǎn)是有損細(xì)節(jié)會(huì)丟失。二是結(jié)構(gòu)化壓縮。從對(duì)話中抽出結(jié)構(gòu)化信息如字段、時(shí)間、意圖、結(jié)論保存成 JSON。這種格式適合程序處理也適合做條件查詢。一條可行路線是“先結(jié)構(gòu)化再按需摘要”。重要內(nèi)容抽成結(jié)構(gòu)化字段長(zhǎng)期不用的內(nèi)容再合并成摘要。這樣兼顧了即時(shí)檢索和長(zhǎng)期歸檔。6.3 什么時(shí)候該自研什么時(shí)候用現(xiàn)成組件如果是快速做 Demo、驗(yàn)證想法直接用現(xiàn)成框架自帶的記憶模塊最省事。但默認(rèn)實(shí)現(xiàn)通常比較粗糙比如全量存歷史、簡(jiǎn)單截?cái)?、不做遺忘。一旦你的用戶量上來(lái)或者對(duì)記憶準(zhǔn)確率有要求就值得自己寫一套輕量記憶模塊。我個(gè)人的判斷標(biāo)準(zhǔn)是記憶邏輯不超過(guò)幾百行代碼時(shí)自研更劃算。你能精確控制什么時(shí)候?qū)懭?、檢索多少條、如何融合、如何遺忘。而使用重型框架時(shí)光是理解它的記憶生命周期就要花很久。如果你打算在自己的項(xiàng)目里長(zhǎng)期迭代 Agent我建議至少把“寫入過(guò)濾檢索召回遺忘清理”這三個(gè)核心組件自己寫一遍。這樣獨(dú)立于任何框架后續(xù)遷移也方便。最后再分享一點(diǎn)個(gè)人體會(huì)我最初做的記憶系統(tǒng)很蠢一個(gè) JSON 文件存所有歷史每次對(duì)話都把所有歷史塞進(jìn) Prompt。結(jié)果模型越聊越亂成本越燒越高。后來(lái)慢慢改成“寫入前過(guò)濾、檢索時(shí)排序、融合前控制體量、定期做遺忘”整個(gè) Agent 才穩(wěn)定下來(lái)。如果你也在做類似項(xiàng)目我的建議很直白不要一開(kāi)始就上重型設(shè)施。先在本地跑一個(gè) JSON 存儲(chǔ) 向量檢索的最小閉環(huán)把“寫入-檢索-融合-遺忘”體會(huì)一遍。跑通之后自然知道哪些地方必須換數(shù)據(jù)庫(kù)、哪些地方必須加規(guī)則。記憶系統(tǒng)的價(jià)值從來(lái)不是存得多而是用得準(zhǔn)。希望這份指南能讓你少走一點(diǎn)彎路。