如果你是從之前那幾篇一路看過來的應(yīng)該還記得我們在Demo Agent上折騰過工具調(diào)用、琢磨過多輪對話。但不管做到哪一版都有一個特別扎眼的毛病——它是個“金魚腦”。用戶昨天剛告訴它“我每周三下午都在某某健身房練背”今天問一句“那我明天下班后該去哪兒”它就徹底懵了。這種體驗(yàn)放在聊天玩具里還能忍真要做成客服、助手、陪練這類產(chǎn)品級Agent根本不行。記憶管理就是來解決這個問題的。說白了Agent的記憶管理要管的不只是“把聊天記錄存下來”而是要讓Agent知道該記什么、存在哪兒、什么時候想起來、什么時候忘掉。這篇教程我盡量不堆概念直接按我實(shí)際做項(xiàng)目的思路來寫先給記憶分類再講存儲選型然后拆寫入、檢索、遺忘這三個環(huán)節(jié)最后附一個能跑的行程助手核心代碼。想給Agent裝上真正能用的記憶照著這套思路落地基本不會跑偏。1. 記憶缺失的代價沒有記憶的Agent只能算高級問答機(jī)先別急著寫代碼。我見過不少人給Agent加記憶的方式就是在 messages 數(shù)組里越堆越長堆到報錯就問“我該怎么處理長上下文”然后跑去調(diào)窗口大小。方向從一開始就錯了。記憶管理不是一個存儲問題它是一套圍繞“信息生命周期”的機(jī)制設(shè)計。你首先要搞明白Agent需要哪幾種記憶它們各自解決什么問題。1.1 三種記憶到底指什么工作記憶、情景記憶、語義記憶我在設(shè)計記憶模塊時會把Agent的記憶分成三層和人的記憶做一個粗粒度對照工作記憶指當(dāng)前這輪任務(wù)里臨時要用的信息對應(yīng)到工程上就是上下文窗口里的消息列表。它該被快速讀取、快速丟棄不需要落地持久化。情景記憶指用戶和歷史交互中發(fā)生的具體事件比如“昨天下午3點(diǎn)用戶問過機(jī)票退改規(guī)則”“上周二訂了去某地的酒店”。這類記憶帶時間線特征適合按時間存儲和回放。語義記憶指從歷史交互中提煉出來的事實(shí)和偏好比如“用戶偏好靠窗座位”“用戶出差多、常駐某城市”。這類記憶沒有強(qiáng)時間屬性是用戶畫像的構(gòu)建基礎(chǔ)。這個劃分不是學(xué)院派名詞它直接決定存儲和檢索方案。情景記憶要求你能回答“什么時候發(fā)生了什么”所以要有時間戳和事件結(jié)構(gòu)語義記憶要求你能回答“用戶是個什么樣的人”所以要能合并、去重、更新。把這兩類混在一張表里存后面檢索一定亂。1.2 Agent失憶的三個典型現(xiàn)場我實(shí)際調(diào)試過幾個Agent項(xiàng)目“失憶”的表現(xiàn)基本可以歸成三類第一類是跨會話失憶。用戶昨天在客服Agent上報了工單號今天再來問處理進(jìn)度Agent問“請問您的工單號是多少”。這不是技術(shù)問題是產(chǎn)品體驗(yàn)問題——用戶會覺得你在裝傻。第二類是事實(shí)沖突。用戶在閑聊里說過“我平時不吃辣”結(jié)果第二天Agent推薦了一堆川菜館。它不是找不到信息而是相關(guān)記憶沒有被檢索出來或者檢索出來了但權(quán)重不夠被無關(guān)上下文淹沒了。第三類是上下文窗口的“虛假記憶”。很多人的記憶就是無腦往messages里塞對話結(jié)果上下文越來越長模型開始“記住”一些被裁剪掉的中間內(nèi)容或者因?yàn)樘L的關(guān)系把早期關(guān)鍵指令給稀釋了。這本質(zhì)上還是沒有做記憶管理造成的。這三類問題的共同根源是你把“存儲”當(dāng)成了“記憶”。存下來的只是字節(jié)能被合適時機(jī)調(diào)取、能被更新和覆蓋的才是記憶。后面幾節(jié)我會逐個說清楚怎么設(shè)計。2. 存儲設(shè)計別一上來就上向量數(shù)據(jù)庫很多人一說給Agent加記憶腦子里第一個蹦出來的就是向量數(shù)據(jù)庫。我的建議是先忍住。存儲選型應(yīng)該跟著記憶類型走不同類型的記憶有完全不同的讀寫模式一股腦全做向量化純屬給自己挖坑。2.1 短期記憶一段受token預(yù)算控制的對話窗口短期記憶的實(shí)現(xiàn)聽上去簡單就是維護(hù)最近幾輪對話。但有個細(xì)節(jié)很容易被忽視這個窗口的大小不是“我記N輪”而是“我的token預(yù)算允許我裝多少輪”。輪數(shù)是不可控的某用戶一句廢話可能頂別人五句token才是真正約束模型能力的單位。我在項(xiàng)目里一般這樣做維護(hù)一個消息列表每進(jìn)來一輪就追加。每次追加后統(tǒng)計當(dāng)前總token數(shù)超出預(yù)算就從最舊的消息開始淘汰。預(yù)算分配上給短期記憶留一個上限比如總窗口的40%剩下的留給系統(tǒng)指令、檢索到的長期記憶和當(dāng)前用戶輸入。這樣做的核心思路是短期記憶是“最貴”的記憶因?yàn)槊看握埱笏家S上下文發(fā)送給模型是成本最敏感的部分。所以它只在當(dāng)前會話內(nèi)存活一旦會話結(jié)束就該被壓縮、沉淀或者直接丟棄。2.2 長期記憶從KV到向量庫的分級方案長期記憶才有資格談持久化。但“持久化”三個字底下至少有兩種完全不同的存儲需求一種是結(jié)構(gòu)化事實(shí)型記憶比如“用戶姓名”“會員等級”“偏好口味”。這類數(shù)據(jù)字段明確、寫一次要讀很多次而且經(jīng)常要精確更新。這種場景用一個簡單的鍵值存儲或者關(guān)系表就能搞定把它向量化反而是負(fù)優(yōu)化。另一種是語義片段型記憶比如一段對話里用戶描述過的某種復(fù)雜需求、一段你希望Agent以后能關(guān)聯(lián)起來回憶的內(nèi)容。這類信息沒有固定字段只能靠語義相似度去檢索這才是向量數(shù)據(jù)庫的用武之地。所以我的經(jīng)驗(yàn)是長期記憶不要只依賴單一存儲按信息形態(tài)分級。你可以先畫一張表做選型參考記憶類型典型內(nèi)容推薦存儲檢索方式更新頻率用戶畫像型姓名、偏好、常駐地KV或關(guān)系表精確匹配低頻事件記錄型做過什么、買過什么時序日志表按時間范圍篩選高頻追加語義片段型對話中的隱含需求向量索引相似度檢索中頻會話摘要型某次長聊的壓縮結(jié)果文檔存儲結(jié)構(gòu)化向量混合會話結(jié)束時寫入如果你剛開始做別急著搭一堆組件。我通常的建議是先用KV存事實(shí)用文件或者一張表存事件用向量庫存語義片段。等量級上來、檢索效果出現(xiàn)瓶頸了再考慮引入專門的向量庫服務(wù)。2.3 我比較推薦的混合存儲結(jié)構(gòu)跑過一個完整的客服Agent之后我沉淀出來的存儲結(jié)構(gòu)大概是這個形態(tài)每個用戶有一個獨(dú)立的記憶空間里面有“用戶資料表”存結(jié)構(gòu)化屬性“事件表”按時間戳記流水“語義記憶索引”存從聊天中抽取出來的說明性內(nèi)容。三張表通過 user_id 關(guān)聯(lián)檢索時先查精確字段再走語義搜索最后把結(jié)果按重要性和時間排序拼進(jìn)提示詞。有些平臺喜歡用向量庫一統(tǒng)天下把用戶資料也編碼成向量。我試過后果是更新某個字段時需要重新生成向量否則就會出現(xiàn)“資料明明改了Agent還按舊字段回答”的詭異現(xiàn)象。結(jié)構(gòu)化數(shù)據(jù)就該被精確更新別硬塞給向量庫。3. 記憶的生命周期寫入、檢索、遺忘三道閘門存儲方案定了記憶管理真正核心的部分才開始。我給記憶設(shè)計了三個處理環(huán)節(jié)寫入、檢索、遺忘。你可以把它們理解成三道閘門每一道都要有明確的策略否則記憶系統(tǒng)就是一鍋粥。3.1 寫入閘門不是所有對話都值得記很多人的第一版長期記憶是這樣的每輪對話結(jié)束后把整段對話文字塞進(jìn)向量庫。結(jié)果很快就會發(fā)現(xiàn)檢索出來的記憶全是垃圾因?yàn)槿粘υ捓?0%的句子不具備長期記憶價值。寫入策略的核心是“篩選”。我在實(shí)際項(xiàng)目中會用兩種方式配合第一種是規(guī)則抽取。針對明確的字段比如用戶報了自己名字、說了某個偏好、提到某個具體日期直接用規(guī)則從對話里抽出來寫進(jìn)結(jié)構(gòu)化表。優(yōu)點(diǎn)是精確缺點(diǎn)是無法覆蓋復(fù)雜表述。第二種是總結(jié)沉淀。會話結(jié)束后讓大模型基于整段對話生成幾條記憶摘要例如“用戶提到在公司午休時間喜歡到樓下咖啡店坐坐”。每次生成摘要時我還會額外要求模型標(biāo)注“可遺忘項(xiàng)”也就是那些只對單次任務(wù)有用、不值得長期保存的臨時信息。這一步能大幅降低噪聲。寫入的觸發(fā)時機(jī)也很講究。我的做法是會話進(jìn)行中只寫確定的、規(guī)則能識別的事實(shí)會話結(jié)束后才做全局總結(jié)沉淀。實(shí)時寫入容易把用戶中途反悔的話也記進(jìn)去之后又要做一遍糾錯非常不劃算。3.2 檢索閘門相似度之外還要有過濾和重排寫完記憶Agent碰到新輸入時要從記憶里挑相關(guān)內(nèi)容也就是檢索。檢索如果只做“向量相似度TopK”那基本等于盲人摸象。我會在檢索鏈路里加三道護(hù)欄第一道是用戶隔離。所有檢索必須帶 user_id 過濾千萬不能做成全局檢索否則用戶A的記憶會串到用戶B那里。這種錯誤在產(chǎn)品環(huán)境是事故級的。第二道是時間衰減。同樣相似度的兩條記憶一條是昨天的、一條是半年前的它們的可信度完全不同。我習(xí)慣在打分公式里疊加一個時間衰減因子讓近期記憶獲得更高的排序權(quán)重。第三道是上下文重排。向量檢索結(jié)果先各給一個相似度分匯集到提示詞時會再做一輪重排把那些“語義相似但實(shí)際是另一個話題”的結(jié)果降權(quán)把和當(dāng)前任務(wù)真正相關(guān)的記憶往前放。這一步效果很明顯尤其當(dāng)你的向量模型質(zhì)量一般的時候。3.3 遺忘閘門讓記憶既能新增也能過期這一條是被很多人忽略的。記憶只增不減的系統(tǒng)最后一定會變質(zhì)。用戶三個月前的偏好可能已經(jīng)變了而遺忘機(jī)制就是防止Agent抱著過期數(shù)據(jù)不放。我做的至少有三層短期遺忘工作記憶隨會話結(jié)束清空不殘留。時間過期給記憶打上 ttl有效期比如“用戶在出差”這類信息兩周后就失效再檢索到就自動丟棄。合并覆蓋用戶說“我現(xiàn)在不吃辣了”之后新的“不吃辣”記憶要覆蓋舊記錄。我一般用時間戳加置信度來判斷誰覆蓋誰新記憶的置信度權(quán)重更高。還有一個容易被忽視的問題大模型在總結(jié)記憶的時候會“腦補(bǔ)”寫出來一些對話里沒有的細(xì)節(jié)。我在長期記憶寫入時會做一個一致性校驗(yàn)讓模型輸出必須附帶上原始對話段落編號如果哪條總結(jié)找不到對應(yīng)出處寧可丟棄也不寫入。這個坑我踩過一次修起來非常痛苦因?yàn)殄e誤記憶會像滾雪球一樣影響后續(xù)所有對話。4. 手把手做一個帶長期記憶的行程助手理論環(huán)節(jié)說完下面進(jìn)入實(shí)操。我用一個“行程助手”來演示它需要記住用戶提到的地點(diǎn)偏好、時間安排等長期信息并在后續(xù)對話里正確調(diào)用。這個Demo刻意不依賴特定云服務(wù)代碼結(jié)構(gòu)讓你可以輕松替換成自己手頭的向量庫和模型接口。4.1 整體鏈路與最小依賴整個鏈路是這樣的用戶輸入一句話。Agent先檢索該用戶的長期記憶。短期記憶窗口加上檢索結(jié)果一起組裝成提示詞。調(diào)用模型生成回復(fù)?；貜?fù)之后對當(dāng)前對話做一次提取把確定的偏好寫入長期記憶。代碼層面只需要 Python 3 和一個能調(diào)用大模型API的環(huán)境。我這里自己實(shí)現(xiàn)了一個極簡向量索引基于余弦相似度只用來演示語義檢索的原理。你在實(shí)際項(xiàng)目里完全可以換成任何一個你想用的開源向量庫接口保持一致就行。import time import math def estimate_tokens(text: str) - int: # 中英文混合場景下的粗略token估算 return max(1, int(len(text) * 1.3)) def cosine_similarity(a, b): dot sum(x * y for x, y in zip(a, b)) norm_a math.sqrt(sum(x * x for x in a)) norm_b math.sqrt(sum(x * x for x in b)) if norm_a 0 or norm_b 0: return 0.0 return dot / (norm_a * norm_b)這里我把 token 估算簡化成等長計費(fèi)真實(shí)項(xiàng)目里建議用對應(yīng)的分詞器接口。4.2 核心代碼拆解短期記憶與長期記憶模塊先看短期記憶模塊。它的職責(zé)就是維護(hù)一個受預(yù)算控制的滾動窗口class ShortTermMemory: def __init__(self, max_tokens1500): self.messages [] self.max_tokens max_tokens def add_message(self, role: str, content: str): self.messages.append({ role: role, content: content, ts: time.time(), }) self._trim() def _trim(self): while len(self.messages) 1: total sum(estimate_tokens(m[content]) for m in self.messages) if total self.max_tokens: break # 從最舊的消息開始淘汰 self.messages.pop(0) def to_text(self) - str: return \n.join(f{m[role]}: {m[content]} for m in self.messages)下面是自己實(shí)現(xiàn)的迷你向量索引只保留核心邏輯方便你理解檢索原理class SimpleVectorIndex: def __init__(self, embed_fn): self.embed_fn embed_fn self.items [] # 每個元素是 (metadata, vector) def add_item(self, metadata, text): vector self.embed_fn(text) self.items.append(({**metadata, text: text}, vector)) def query(self, query_text, top_k3, user_idNone, max_age_secondsNone): query_vec self.embed_fn(query_text) scored [] now time.time() for metadata, vector in self.items: if user_id is not None and metadata.get(user_id) ! user_id: continue if max_age_seconds is not None: score_age 1.0 if metadata.get(ts, 0) - now 0 else max(0.0, 1.0 - (now - metadata.get(ts, now)) / max_age_seconds) else: score_age 1.0 score cosine_similarity(query_vec, vector) * score_age scored.append((score, metadata)) scored.sort(keylambda x: x[0], reverseTrue) return scored[:top_k] def search_all(self, keyword, user_idNone): results [] for metadata, _ in self.items: if user_id is not None and metadata.get(user_id) ! user_id: continue if keyword in metadata.get(text, ): results.append(metadata.copy()) return results注意上面我用了一個關(guān)鍵詞搜索方法 search_all它是給精確更新用的。用戶說“我改主意了”的時候你需要先找到舊記憶再覆蓋而不是直接再插一條否則會出現(xiàn)兩條互相矛盾的記憶同時被檢索出來。長期記憶模塊封裝了“寫事實(shí)”和“讀記憶”兩個能力class LongTermMemory: def __init__(self, embed_fn): self.embed_fn embed_fn self.facts {} # user_id - {屬性: 值} self.index SimpleVectorIndex(embed_fn) def record_fact(self, user_id, attribute, value): # 結(jié)構(gòu)化事實(shí)直接精確覆蓋 if user_id not in self.facts: self.facts[user_id] {} self.facts[user_id][attribute] value def get_fact(self, user_id, attribute): return self.facts.get(user_id, {}).get(attribute) def memorize(self, user_id, text, importance0.5): self.index.add_item({ user_id: user_id, ts: time.time(), type: episodic, importance: importance, }, text) def recall(self, user_id, query_text, top_k3): semantic self.index.query(query_text, top_ktop_k, user_iduser_id, max_age_seconds86400) results [] for score, metadata in semantic: results.append({src: semantic, score: score, content: metadata[text], ts: metadata[ts]}) facts self.facts.get(user_id, {}) for attr, value in facts.items(): if attr and value: # 結(jié)構(gòu)化事實(shí)轉(zhuǎn)成自然語言參與排序維持統(tǒng)一輸出格式 results.append({src: fact, score: 0.8, content: f{attr}{value}, ts: 0}) results.sort(keylambda x: x[score], reverseTrue) return results[:top_k]這一步就有意識地把結(jié)構(gòu)化事實(shí)和語義片段統(tǒng)一成帶 score 的列表在組裝提示詞時一視同仁。實(shí)際項(xiàng)目里很多人把兩條檢索鏈路分開做結(jié)果提示詞里一會兒出現(xiàn)句子、一會兒出現(xiàn)字段模型經(jīng)常搞混。4.3 跑通一次完整對話的驗(yàn)證過程組合起來你就能模擬一次完整交互了。我習(xí)慣把每次交互畫成五步查記憶、更新短期記憶、調(diào)模型、取回復(fù)、沉淀記憶。代碼如下class MemoryAgent: def __init__(self, embed_fn, llm_fn): self.stm ShortTermMemory() self.ltm LongTermMemory(embed_fn) self.llm_fn llm_fn # 大模型調(diào)用函數(shù) self.user_id demo_user def process_input(self, user_text): # 1. 檢索長期記憶 recalled self.ltm.recall(self.user_id, user_text, top_k3) memory_text \n.join(f[記憶] {item[content]} for item in recalled) # 2. 短期記憶寫入用戶輸入 self.stm.add_message(user, user_text) # 3. 組裝提示詞 system_prompt ( 你是一個行程助手。請結(jié)合已知記憶回答 如果記憶中沒有可以明確說不知道。\n ) messages [ {role: system, content: system_prompt memory_text}, ] messages.extend( {role: m[role], content: m[content]} for m in self.stm.messages ) # 4. 調(diào)用模型 reply self.llm_fn(messages) # 5. 簡單提取并沉淀長期記憶 self.stm.add_message(assistant, reply) if 我喜歡 in user_text: self.ltm.record_fact(self.user_id, 偏好, user_text.split(我喜歡)[-1].strip()) else: self.ltm.memorize(self.user_id, user_text, importance0.3) return reply跑一輪驗(yàn)證是這樣的def llm_fn(messages): # 接入你的大模型API服務(wù)商 # response your_llm_client.chat(messages) last messages[-1][content] return f我已收到約束也參考了記憶中的信息。你說的是{last}。 embed_fn lambda text: [float(ord(c) % 100) / 99.0 for c in text[:32]] agent MemoryAgent(embed_fnembed_fn, llm_fnllm_fn) print(agent.process_input(我喜歡靠窗的座位)) print(agent.process_input(幫我訂明天下午去某地的車票)) print(agent.ltm.recall(demo_user, 坐車偏好, top_k5))上面這個簡易 embedding 函數(shù)工業(yè)上沒什么用純粹讓Demo能獨(dú)立跑通。但后綴的 recall 結(jié)果能看到“靠窗”相關(guān)記憶被檢索出來說明鏈路是通的。換成真實(shí)embedding模型后語義召回的效果會直接上一個臺階。5. 工程化路上最常踩的五個坑代碼能跑只是開始。把這套東西放到真實(shí)數(shù)據(jù)上你大概率會遇到下面這些問題。我把它們按殺傷力從大到小排一遍每個都附上我的處理經(jīng)驗(yàn)。5.1 看似能搜到其實(shí)召回全是噪聲最迷惑人的情況是你搜索“靠窗”結(jié)果也能搜出來但搜索“用戶喜歡哪種座位”或者“這次的偏好是啥”搜出來的東西就開始亂套。原因基本出在三個地方一是嵌入模型太弱中文長句、近義詞辨識度不夠。解決辦法是換更強(qiáng)的大模型向量接口或者對長文本做分塊再向量化塊與塊之間保留重疊避免語義跨塊斷掉。二是沒有做查詢改寫。用戶問“附近吃飯推薦”但記憶里存的是“用戶喜歡清淡口味”這句原文和“吃飯”在語義上有關(guān)聯(lián)但向量距離未必近。我現(xiàn)在的做法是檢索前先用模型把用戶問題改寫成若干個候選查詢句分別檢索再合并結(jié)果召回率會明顯提升。三是缺少過濾。比如你存了十條“用戶喜歡靠窗”然后檢索出來十條全是靠窗。不是你記性差是你沒有做去重。寫入前先檢索一次如果已經(jīng)有相同語義的記憶就做合并和更新時間戳不要每次都插新。5.2 記憶漂移用戶改主意之后舊記憶還在這是“甜蜜的負(fù)擔(dān)”——系統(tǒng)記住太多忘記太少。用戶說“我不喜歡靠窗了”結(jié)果你下次還是推薦靠窗座位因?yàn)樗瓉硐矚g靠窗的句子還靜靜躺在向量庫里。要解決記憶漂移我的方案是給記憶加置信度和生命周期兩層屬性。置信度低的記憶不被輸出生命周期過了的記憶即使相關(guān)也要被篩掉。用戶的最新說法寫入時對同一主題的舊記憶做主動降權(quán)和過期而不是等到檢索時才發(fā)現(xiàn)問題。實(shí)際操作上我在“新增記憶”之外總會跑一條“更新記憶”流程拿新文本去檢索自己用戶的舊記憶相似度超過一定閾值就把舊記憶標(biāo)記為失效并建立指向新記憶的跳轉(zhuǎn)。這種方式比較笨但穩(wěn)定可靠。5.3 記憶膨脹帶來的成本失控長期記憶臃腫最直接的后果是每次對話都帶著一大段歷史摘要token費(fèi)用直線上升。我在一個上線項(xiàng)目里遇到過提示詞被頂?shù)绞畮兹f token 的情況一個月的接口賬單漲了四成。解決思路是分檔先把最常命中的記憶放在本地KV里每次必讀把大段的語義記憶做成摘要索引只有命中關(guān)鍵詞才加載全文再定一個規(guī)則超過多少天沒有被檢索過的記憶轉(zhuǎn)入冷存儲不再參與實(shí)時檢索。另外提醒你一個很多人忽略的隱藏成本每次把記憶寫進(jìn)向量庫也要花一次embedding調(diào)用。如果每輪對話都寫成本一樣不低。我的策略是批量寫入——會話結(jié)束后統(tǒng)一處理而不是對話過程中每條都調(diào)一次embedding接口。5.4 用戶隔離與數(shù)據(jù)邊界這個問題做ToB項(xiàng)目尤其要命。多個用戶的數(shù)據(jù)存在同一個索引里如果查詢時沒有嚴(yán)格帶 user_id 做過濾一旦出了串號事故在合規(guī)上基本無法解釋。這不是技術(shù)細(xì)節(jié)問題是一票否決項(xiàng)。我從一開始就規(guī)定所有寫入和讀取的操作函數(shù)強(qiáng)制要求傳 user_id不允許出現(xiàn)不帶隔離條件的公開查詢接口。寧可代碼冗余一點(diǎn)也不能靠“程序員記得加過濾”來保證數(shù)據(jù)邊界。5.5 把記憶和工具調(diào)用混在一起最后一坑比較隱蔽Agent如果同時有工具調(diào)用和記憶系統(tǒng)你很容易把工具返回的結(jié)果也當(dāng)成記憶存下來。比如查天氣工具返回了“今天晴”這是實(shí)時數(shù)據(jù)明天就失效了不該進(jìn)入長期記憶。我的經(jīng)驗(yàn)是給記憶打上來源標(biāo)簽用戶陳述、模型總結(jié)、工具結(jié)果。不同來源使用不同的有效期工具結(jié)果一般只留在短期記憶里不沉淀到長期記憶。最后補(bǔ)充一個偏實(shí)戰(zhàn)的小技巧聊到這兒我想把記憶系統(tǒng)的可觀測性單獨(dú)拎出來強(qiáng)調(diào)一下。線上跑Agent的時候最難受的不是功能不對而是你沒法判斷它為什么這么回答。是不是記憶檢索錯了還是根本沒檢索到還是檢索到了但提示詞里被別的信息擠掉了我從第一次做帶記憶的Agent起就養(yǎng)成了一個習(xí)慣在每次請求的返回里附帶一個 debug 字段把這個請求用到了哪些記憶、每條記憶的相似度分?jǐn)?shù)、短期記憶裁掉了哪幾條舊消息都打出來。測試階段直接打印在控制臺上線階段寫進(jìn)日志。不要嫌難看記憶系統(tǒng)是Agent里最難調(diào)試的部分沒有可觀測性你只能靠猜越猜越離譜。說白了給Agent裝上記憶從來不只是“加個向量庫”那么簡單。它更像是在模擬人的認(rèn)知過程什么值得記住、什么時候想起來、什么時候該忘。按著寫入、檢索、遺忘這套框架去拆解再一步步落到代碼里你的Agent才算是從“會說話”進(jìn)化到了“記得住”。下一步你就可以在這個基礎(chǔ)上去做自動化的記憶合并策略或者按記憶置信度動態(tài)調(diào)整提示詞權(quán)重那基本就是往更成熟的記憶體系靠近了。