戰(zhàn)：構(gòu)建具備反思能力的LLM記憶系統(tǒng))
1. 從“hindsight”說起為什么我們需要給Agent裝上“后視鏡”“hindsight”這個(gè)詞直譯過來就是“后見之明”或者更通俗一點(diǎn)——“馬后炮”。但在Agent Memory和LLM工程化的語境里它指向的是一個(gè)非常具體且要命的問題當(dāng)你的Agent在完成一輪對(duì)話、一次任務(wù)、一個(gè)工作流之后它到底記住了什么它能不能在后續(xù)的交互中像人一樣“回想”起之前發(fā)生過的事情并且用這些記憶來指導(dǎo)當(dāng)下的決策我接觸過不少做Agent落地的團(tuán)隊(duì)大家一開始都興致勃勃地接入了LLM搭好了MCP協(xié)議用Docker把服務(wù)跑起來覺得萬事大吉。結(jié)果上線沒幾天就發(fā)現(xiàn)用戶問“上次你幫我查的那個(gè)訂單到哪了”Agent一臉茫然用戶說“還是按我昨天說的那個(gè)方案來”Agent又開始重新問一遍需求。這不是模型不夠聰明而是記憶系統(tǒng)沒有設(shè)計(jì)好。“hindsight”這個(gè)項(xiàng)目標(biāo)題本質(zhì)上就是在解決這個(gè)問題。它不是一個(gè)簡(jiǎn)單的“把對(duì)話歷史塞進(jìn)上下文”的粗暴方案而是一套圍繞Agent Memory構(gòu)建的、帶有反思和回溯能力的記憶管理機(jī)制。結(jié)合熱搜詞里出現(xiàn)的agent memory、LLM、MCP、Docker這些關(guān)鍵詞可以很清楚地看到這個(gè)項(xiàng)目要處理的是在LLM驅(qū)動(dòng)的Agent系統(tǒng)中如何通過MCP協(xié)議和容器化部署實(shí)現(xiàn)一套可持久化、可檢索、可反思的記憶層讓Agent具備“回頭看”的能力。這篇文章適合誰看如果你正在做Agent開發(fā)或者你已經(jīng)在用MCP協(xié)議搭建工具鏈又或者你只是單純好奇“為什么我的Agent總是記不住事”那接下來的內(nèi)容應(yīng)該能給你一些可以直接抄作業(yè)的思路和實(shí)操方案。我會(huì)從整體設(shè)計(jì)、核心細(xì)節(jié)、實(shí)操過程、問題排查幾個(gè)維度把“hindsight”這個(gè)項(xiàng)目背后的技術(shù)邏輯和落地經(jīng)驗(yàn)拆開來講。2. 整體設(shè)計(jì)與思路拆解Agent Memory到底該怎么分層2.1 為什么“把歷史對(duì)話全塞進(jìn)Prompt”是條死路很多人第一次做Agent記憶想都不用想直接把最近N輪對(duì)話拼接到System Prompt后面。這個(gè)方案在Demo階段沒問題一旦進(jìn)入真實(shí)場(chǎng)景就會(huì)撞上三堵墻。第一堵墻是Token成本。LLM的上下文窗口再大也是有上限的而且大部分API是按Token計(jì)費(fèi)的。你把幾十輪對(duì)話全塞進(jìn)去每次請(qǐng)求都在燒錢而且響應(yīng)延遲會(huì)明顯上升。第二堵墻是信息稀釋。上下文里塞的東西越多模型對(duì)關(guān)鍵信息的注意力就越容易被分散。你明明在第三輪對(duì)話里說了“我對(duì)花生過敏”結(jié)果到第二十輪的時(shí)候模型已經(jīng)把這個(gè)信息淹沒在大量無關(guān)對(duì)話里了。第三堵墻是跨會(huì)話失憶。用戶今天關(guān)掉頁面明天再回來你的Agent完全不知道昨天發(fā)生過什么因?yàn)閷?duì)話歷史根本沒有持久化?！癶indsight”的設(shè)計(jì)思路本質(zhì)上就是要解決這三個(gè)問題。它把記憶拆成了不同的層次每一層有不同的存儲(chǔ)介質(zhì)、檢索策略和生命周期。這不是過度設(shè)計(jì)而是被真實(shí)場(chǎng)景逼出來的。2.2 三層記憶架構(gòu)Working Memory、Episodic Memory、Semantic Memory參考認(rèn)知科學(xué)里對(duì)人類記憶的分類結(jié)合熱搜詞里提到的“agent 存儲(chǔ) working memory”我把“hindsight”的記憶體系拆成三層來理解。第一層是Working Memory工作記憶。這一層對(duì)應(yīng)的是當(dāng)前會(huì)話的上下文窗口生命周期最短通常只保留最近幾輪對(duì)話或者當(dāng)前任務(wù)相關(guān)的信息。它的作用是讓Agent在單次交互中保持連貫性。實(shí)現(xiàn)上你可以用一個(gè)滑動(dòng)窗口來管理窗口大小根據(jù)模型上下文長(zhǎng)度和任務(wù)復(fù)雜度來定。比如你用的是128K上下文的模型那Working Memory可以控制在8K到16K Token之間留出足夠的空間給System Prompt和工具調(diào)用結(jié)果。第二層是Episodic Memory情景記憶。這一層記錄的是“什么時(shí)候發(fā)生了什么”。比如用戶在某次會(huì)話中提到了自己的偏好、完成了一個(gè)訂單、反饋了一個(gè)問題。這些信息需要被持久化存儲(chǔ)并且在后續(xù)會(huì)話中能夠被檢索出來。熱搜詞里提到的“l(fā)lm的token三個(gè)點(diǎn)key我是誰、query我在找什么、value我能提供什么”其實(shí)就是在描述這種記憶的索引結(jié)構(gòu)Key是身份標(biāo)識(shí)Query是檢索意圖Value是具體內(nèi)容。Episodic Memory通常用向量數(shù)據(jù)庫來存因?yàn)槟阈枰稣Z義檢索而不是精確匹配。第三層是Semantic Memory語義記憶。這一層存儲(chǔ)的是從多次交互中抽象出來的、去除了時(shí)間屬性的知識(shí)。比如“這個(gè)用戶偏好簡(jiǎn)潔的回答風(fēng)格”、“這個(gè)項(xiàng)目的代碼規(guī)范要求用TypeScript”。Semantic Memory的更新頻率更低但一旦形成就比較穩(wěn)定。它可以通過對(duì)Episodic Memory的定期總結(jié)和歸納來生成也可以由人工顯式注入。這三層記憶不是孤立的它們之間有一個(gè)寫入和讀取的流轉(zhuǎn)機(jī)制。Working Memory里的信息在會(huì)話結(jié)束后經(jīng)過篩選和壓縮寫入Episodic MemoryEpisodic Memory里的多條記錄經(jīng)過歸納沉淀為Semantic Memory。反過來當(dāng)Agent需要做決策時(shí)會(huì)先從Semantic Memory里拉取長(zhǎng)期偏好再從Episodic Memory里檢索相關(guān)歷史最后和Working Memory里的當(dāng)前上下文合并形成最終的Prompt。2.3 為什么選MCP和Docker作為基礎(chǔ)設(shè)施熱搜詞里MCP和Docker的出現(xiàn)頻率非常高這不是偶然的。MCP協(xié)議解決的是工具調(diào)用標(biāo)準(zhǔn)化的問題而Docker解決的是環(huán)境一致性和部署效率的問題。先說MCP。在沒有MCP之前你要讓Agent去查數(shù)據(jù)庫、調(diào)API、讀文件每個(gè)工具都要寫一套適配代碼而且不同LLM框架之間的工具定義格式還不一樣。MCP把這件事標(biāo)準(zhǔn)化了你只需要按照MCP協(xié)議定義一個(gè)Server暴露Tools和Resources任何支持MCP的Client都可以直接調(diào)用。對(duì)于“hindsight”這樣的記憶系統(tǒng)來說這意味著你可以把記憶的讀寫操作封裝成MCP Tools比如memory_write、memory_search、memory_summarize然后讓Agent在需要的時(shí)候自主調(diào)用。這樣記憶系統(tǒng)就和Agent的核心邏輯解耦了換模型、換框架都不影響。再說Docker。Agent Memory系統(tǒng)通常需要依賴向量數(shù)據(jù)庫、關(guān)系型數(shù)據(jù)庫、緩存服務(wù)等多個(gè)組件。如果你在本地開發(fā)環(huán)境跑通了部署到服務(wù)器上發(fā)現(xiàn)各種依賴版本沖突那就很頭疼。Docker把每個(gè)組件打包成獨(dú)立的容器用docker-compose或者Kubernetes編排環(huán)境一致性有保障。而且熱搜詞里提到了“docker安裝mysql8.0并使用”、“docker安裝redis主從”這些具體操作說明很多開發(fā)者已經(jīng)在用Docker來搭建Agent的基礎(chǔ)設(shè)施了。注意如果你在Windows上安裝Docker Desktop時(shí)遇到“virtualization support not detected”的報(bào)錯(cuò)大概率是BIOS里的虛擬化支持沒有開啟。重啟進(jìn)入BIOS找到Intel VT-x或者AMD-V選項(xiàng)設(shè)為Enabled即可。這個(gè)問題在“docker desktop安裝教程”相關(guān)的搜索里出現(xiàn)頻率極高但很多人會(huì)誤以為是軟件問題。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)記憶的寫入、檢索與反思3.1 記憶寫入不是所有對(duì)話都值得記住Working Memory里的內(nèi)容在會(huì)話結(jié)束時(shí)不能一股腦全寫進(jìn)Episodic Memory。你需要一個(gè)篩選和壓縮的過程。我的做法是在會(huì)話結(jié)束前讓LLM對(duì)當(dāng)前對(duì)話做一次總結(jié)提取出關(guān)鍵信息點(diǎn)然后按照固定的Schema寫入。這個(gè)Schema通常包含以下字段字段名類型說明memory_idstring唯一標(biāo)識(shí)通常用UUIDuser_idstring用戶標(biāo)識(shí)用于隔離不同用戶的記憶session_idstring會(huì)話標(biāo)識(shí)用于追溯來源timestampdatetime記憶產(chǎn)生的時(shí)間contentstring記憶的具體內(nèi)容經(jīng)過壓縮和總結(jié)embeddingvector內(nèi)容的向量表示用于語義檢索tagslist標(biāo)簽用于分類和過濾importancefloat重要性評(píng)分0到1之間ttlint過期時(shí)間單位秒0表示永不過期這里面的importance評(píng)分很關(guān)鍵。不是所有記憶都同等重要。用戶說“今天天氣不錯(cuò)”和用戶說“我對(duì)青霉素過敏”這兩條記憶的價(jià)值天差地別。我的做法是讓LLM在總結(jié)時(shí)給每條記憶打一個(gè)重要性分?jǐn)?shù)低于閾值的直接丟棄高于閾值的才寫入Episodic Memory。閾值設(shè)多少根據(jù)我的經(jīng)驗(yàn)0.6是一個(gè)比較合理的起點(diǎn)你可以根據(jù)實(shí)際效果微調(diào)。Tags的設(shè)計(jì)也很有講究。你可以用標(biāo)簽來標(biāo)記記憶的類型比如preference、fact、event、instruction。這樣在檢索的時(shí)候可以先按標(biāo)簽過濾再做向量相似度搜索效率和準(zhǔn)確率都會(huì)更高。3.2 記憶檢索Key-Query-Value的三元組邏輯熱搜詞里有一句很精辟的總結(jié)“l(fā)lm的token三個(gè)點(diǎn)key我是誰、query我在找什么、value我能提供什么”。這其實(shí)就是在描述記憶檢索的核心邏輯。當(dāng)Agent需要檢索記憶時(shí)它首先要明確三個(gè)問題我是誰Key身份標(biāo)識(shí)、我在找什么Query檢索意圖、我能提供什么Value返回內(nèi)容。映射到技術(shù)實(shí)現(xiàn)上Key對(duì)應(yīng)的是user_id和session_id用來限定檢索范圍。你不能讓用戶A的記憶被用戶B檢索到這是基本的安全隔離。Query對(duì)應(yīng)的是當(dāng)前對(duì)話的上下文或者用戶的最新輸入用來生成檢索向量。Value對(duì)應(yīng)的是Episodic Memory里存儲(chǔ)的content字段也就是最終返回給Agent的記憶內(nèi)容。檢索的流程通常是這樣的先用user_id過濾出該用戶的所有記憶然后用Query生成embedding在向量數(shù)據(jù)庫里做相似度搜索返回Top-K條結(jié)果。K值設(shè)多少我一般設(shè)5到10太多了會(huì)稀釋上下文太少了可能漏掉關(guān)鍵信息。但純向量檢索有一個(gè)問題它只能找到語義相似的記憶找不到時(shí)間相關(guān)的記憶。比如用戶問“我上周讓你幫我查的那個(gè)東西”向量檢索可能找不到因?yàn)椤吧现堋笔且粋€(gè)時(shí)間概念不是語義概念。所以你需要結(jié)合時(shí)間過濾。在檢索時(shí)先根據(jù)Query里的時(shí)間信息如果有的話縮小時(shí)間范圍再做向量搜索。3.3 記憶反思讓Agent學(xué)會(huì)“回頭看”“hindsight”這個(gè)名字本身就暗示了反思的能力。記憶系統(tǒng)不能只是被動(dòng)地存儲(chǔ)和檢索它還需要定期做反思和歸納。具體來說你可以設(shè)置一個(gè)定時(shí)任務(wù)每天或者每周跑一次把Episodic Memory里最近一段時(shí)間的記憶拉出來讓LLM做一次總結(jié)提取出穩(wěn)定的偏好和模式寫入Semantic Memory。比如Agent發(fā)現(xiàn)用戶在過去兩周里三次提到了“不要用Markdown格式回復(fù)”那就可以在Semantic Memory里生成一條“該用戶偏好純文本回復(fù)”的長(zhǎng)期記憶。這個(gè)反思過程還可以用來清理過期記憶。有些記憶是有時(shí)效性的比如“用戶明天要開會(huì)”過了明天這條記憶就沒用了。你可以在寫入時(shí)設(shè)置TTL到期自動(dòng)刪除?；蛘咦孡LM在反思時(shí)判斷哪些記憶已經(jīng)過時(shí)主動(dòng)標(biāo)記刪除。提示反思任務(wù)的頻率不要太高否則會(huì)浪費(fèi)Token而且可能引入噪聲。我的經(jīng)驗(yàn)是對(duì)于個(gè)人助手類的Agent每天一次足夠了對(duì)于企業(yè)級(jí)應(yīng)用可以每周一次。另外反思生成的Semantic Memory最好保留一個(gè)“置信度”字段因?yàn)長(zhǎng)LM的歸納不一定總是準(zhǔn)確的。3.4 MCP Tools的設(shè)計(jì)把記憶操作暴露給Agent把記憶系統(tǒng)封裝成MCP Server之后你需要定義一組Tools讓Agent調(diào)用。以下是我在實(shí)際項(xiàng)目中常用的幾個(gè){ tools: [ { name: memory_write, description: 寫入一條新的記憶, parameters: { content: string, 記憶內(nèi)容, tags: list, 標(biāo)簽, importance: float, 重要性評(píng)分 } }, { name: memory_search, description: 檢索相關(guān)記憶, parameters: { query: string, 檢索意圖, top_k: int, 返回條數(shù), tags_filter: list, 標(biāo)簽過濾 } }, { name: memory_summarize, description: 對(duì)近期記憶進(jìn)行總結(jié)歸納, parameters: { time_range: string, 時(shí)間范圍, target: string, 總結(jié)目標(biāo) } } ] }Agent在對(duì)話過程中可以根據(jù)需要自主決定什么時(shí)候?qū)懭胗洃?、什么時(shí)候檢索記憶。比如用戶說“記住我對(duì)花生過敏”Agent就應(yīng)該調(diào)用memory_write用戶問“我之前說過什么偏好”Agent就應(yīng)該調(diào)用memory_search。這種設(shè)計(jì)的好處是解耦。記憶系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)對(duì)Agent透明Agent只需要知道有哪些Tools可用就行了。你后面想換向量數(shù)據(jù)庫、想調(diào)整檢索策略都不需要改Agent的核心邏輯。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)從零搭建一套可用的記憶系統(tǒng)4.1 環(huán)境準(zhǔn)備Docker Compose一鍵拉起依賴服務(wù)假設(shè)你現(xiàn)在要從零開始搭建這套系統(tǒng)第一步是把基礎(chǔ)設(shè)施跑起來。你需要的東西不多一個(gè)向量數(shù)據(jù)庫我用Qdrant輕量且API友好、一個(gè)關(guān)系型數(shù)據(jù)庫PostgreSQL用來存結(jié)構(gòu)化數(shù)據(jù)、一個(gè)緩存Redis用來做Working Memory的快速讀寫。創(chuàng)建一個(gè)docker-compose.yml文件version: 3.8 services: qdrant: image: qdrant/qdrant:latest ports: - 6333:6333 - 6334:6334 volumes: - qdrant_data:/qdrant/storage postgres: image: postgres:16 environment: POSTGRES_USER: memory POSTGRES_PASSWORD: memory_pass POSTGRES_DB: agent_memory ports: - 5432:5432 volumes: - pg_data:/var/lib/postgresql/data redis: image: redis:7-alpine ports: - 6379:6379 volumes: - redis_data:/data volumes: qdrant_data: pg_data: redis_data:然后在終端里執(zhí)行docker compose up -d三個(gè)服務(wù)就都跑起來了。這里有幾個(gè)細(xì)節(jié)需要注意Qdrant的6333端口是HTTP API6334是gRPC。如果你用Python客戶端默認(rèn)走6333就行。PostgreSQL的密碼不要用默認(rèn)的生產(chǎn)環(huán)境一定要改。我這里寫memory_pass只是為了演示。Redis我用了alpine版本體積小啟動(dòng)快。如果你需要持久化記得配置appendonly yes。注意如果你在Windows上跑Docker Desktop確保WSL2后端已經(jīng)啟用。另外如果之前裝過Docker Toolbox可能會(huì)有端口沖突建議先清理干凈再裝Docker Desktop。4.2 記憶寫入的完整代碼實(shí)現(xiàn)基礎(chǔ)設(shè)施跑起來之后接下來寫記憶寫入的邏輯。我用Python來演示因?yàn)樯鷳B(tài)最成熟。import uuid import datetime from qdrant_client import QdrantClient from qdrant_client.models import PointStruct, VectorParams, Distance from openai import OpenAI client QdrantClient(hostlocalhost, port6333) openai_client OpenAI() COLLECTION_NAME episodic_memory # 初始化Collection client.recreate_collection( collection_nameCOLLECTION_NAME, vectors_configVectorParams(size1536, distanceDistance.COSINE) ) def get_embedding(text: str) - list: response openai_client.embeddings.create( modeltext-embedding-3-small, inputtext ) return response.data[0].embedding def write_memory(user_id: str, session_id: str, content: str, tags: list, importance: float, ttl: int 0): if importance 0.6: return None memory_id str(uuid.uuid4()) embedding get_embedding(content) timestamp datetime.datetime.now().isoformat() payload { user_id: user_id, session_id: session_id, content: content, tags: tags, importance: importance, timestamp: timestamp, ttl: ttl } client.upsert( collection_nameCOLLECTION_NAME, points[ PointStruct( idmemory_id, vectorembedding, payloadpayload ) ] ) return memory_id這段代碼的核心邏輯是先判斷重要性低于閾值的直接丟棄然后生成embedding把內(nèi)容和元數(shù)據(jù)一起寫入Qdrant。user_id和session_id放在payload里檢索時(shí)可以用來過濾。4.3 記憶檢索的實(shí)現(xiàn)與參數(shù)調(diào)優(yōu)檢索的邏輯比寫入稍微復(fù)雜一點(diǎn)因?yàn)橐幚磉^濾條件和相似度排序。def search_memory(user_id: str, query: str, top_k: int 5, tags_filter: list None, time_range: tuple None): query_embedding get_embedding(query) # 構(gòu)建過濾條件 must_conditions [ {key: user_id, match: {value: user_id}} ] if tags_filter: must_conditions.append({ key: tags, match: {any: tags_filter} }) if time_range: must_conditions.append({ key: timestamp, range: { gte: time_range[0], lte: time_range[1] } }) results client.search( collection_nameCOLLECTION_NAME, query_vectorquery_embedding, query_filter{must: must_conditions}, limittop_k, with_payloadTrue ) return [ { content: hit.payload[content], score: hit.score, timestamp: hit.payload[timestamp], tags: hit.payload[tags] } for hit in results ]這里有幾個(gè)調(diào)優(yōu)的點(diǎn)值得展開說。Top-K的選擇。我默認(rèn)設(shè)5但這不是固定的。如果Agent的任務(wù)比較復(fù)雜需要更多背景信息可以調(diào)到10。但不要超過15否則上下文里塞太多記憶反而會(huì)干擾模型判斷。相似度閾值。Qdrant返回的score是余弦相似度范圍在-1到1之間。我一般會(huì)設(shè)一個(gè)最低閾值比如0.7低于這個(gè)值的直接丟棄。不然你可能會(huì)檢索出一堆不相關(guān)的記憶反而誤導(dǎo)Agent。時(shí)間衰減。越久遠(yuǎn)的記憶相關(guān)性可能越低。你可以在排序時(shí)引入一個(gè)時(shí)間衰減因子讓新記憶的權(quán)重更高。具體做法是在score上乘以一個(gè)衰減系數(shù)比如score * exp(-lambda * days_ago)lambda取0.01到0.05之間。4.4 反思任務(wù)的定時(shí)調(diào)度反思任務(wù)可以用APScheduler或者Celery來調(diào)度。我一般用APScheduler輕量且夠用。from apscheduler.schedulers.background import BackgroundScheduler def reflect_memory(user_id: str): # 拉取最近7天的Episodic Memory recent_memories search_memory( user_iduser_id, query, top_k50, time_range( (datetime.datetime.now() - datetime.timedelta(days7)).isoformat(), datetime.datetime.now().isoformat() ) ) if len(recent_memories) 5: return # 讓LLM做總結(jié) memory_text \n.join([m[content] for m in recent_memories]) prompt f請(qǐng)對(duì)以下用戶記憶進(jìn)行總結(jié)提取出穩(wěn)定的偏好和模式 {memory_text} 請(qǐng)以JSON格式返回包含以下字段 - preferences: 用戶偏好列表 - facts: 關(guān)于用戶的事實(shí)列表 - patterns: 行為模式列表 response openai_client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], response_format{type: json_object} ) # 將總結(jié)結(jié)果寫入Semantic Memory semantic_content response.choices[0].message.content write_memory( user_iduser_id, session_idreflection, contentsemantic_content, tags[semantic, reflection], importance0.9 ) scheduler BackgroundScheduler() scheduler.add_job(reflect_memory, cron, hour3, minute0, args[user_123]) scheduler.start()這個(gè)反思任務(wù)每天凌晨3點(diǎn)跑一次對(duì)指定用戶最近7天的記憶做總結(jié)?？偨Y(jié)結(jié)果寫入Semantic Memory標(biāo)簽設(shè)為semantic和reflection重要性設(shè)為0.9確保不會(huì)被輕易丟棄。提示反思任務(wù)的Prompt設(shè)計(jì)很關(guān)鍵。我試過讓LLM自由發(fā)揮結(jié)果它經(jīng)常生成一些模棱兩可的總結(jié)。后來改成強(qiáng)制JSON格式并且明確要求提取preferences、facts、patterns三類信息效果穩(wěn)定了很多。5. 常見問題與排查技巧實(shí)錄5.1 記憶檢索不準(zhǔn)確怎么辦這是最常見的問題。你明明存了一條記憶但檢索的時(shí)候就是找不到。排查思路按以下順序來第一步檢查embedding模型是否一致。寫入時(shí)用的模型和檢索時(shí)用的模型必須是同一個(gè)。如果你寫入用的是text-embedding-3-small檢索時(shí)換成了text-embedding-ada-002那向量空間都不一樣肯定搜不到。第二步檢查過濾條件是否過嚴(yán)。有時(shí)候user_id或者tags_filter寫錯(cuò)了導(dǎo)致過濾掉了正確的記憶。你可以先把過濾條件去掉只做純向量檢索看看能不能搜到。如果能搜到那就是過濾條件的問題。第三步檢查相似度閾值。如果你設(shè)了0.7的閾值但實(shí)際相似度只有0.65那就會(huì)被丟棄。可以先把閾值降到0.5看看結(jié)果如何。第四步檢查記憶內(nèi)容的質(zhì)量。如果寫入的記憶本身就是一堆廢話那embedding的質(zhì)量也不會(huì)高。確保寫入前做了充分的壓縮和總結(jié)。問題現(xiàn)象可能原因解決方法完全搜不到embedding模型不一致統(tǒng)一寫入和檢索的模型搜到但不相關(guān)相似度閾值過低提高閾值到0.7以上搜到但排序不對(duì)缺少時(shí)間衰減引入時(shí)間衰減因子搜到但內(nèi)容過時(shí)TTL未生效檢查TTL字段和清理任務(wù)5.2 Docker環(huán)境下的網(wǎng)絡(luò)問題熱搜詞里出現(xiàn)了“docker網(wǎng)絡(luò)不通”這在Agent Memory系統(tǒng)里很常見。因?yàn)槟愕膽?yīng)用容器需要訪問Qdrant、PostgreSQL、Redis如果網(wǎng)絡(luò)配置不對(duì)就會(huì)連不上。最常見的坑是容器間通信用了localhost。在Docker Compose里每個(gè)服務(wù)的主機(jī)名就是服務(wù)名。比如你的應(yīng)用容器要連Qdrant應(yīng)該用qdrant:6333而不是localhost:6333。因?yàn)閘ocalhost在容器內(nèi)部指向的是容器自己不是宿主機(jī)。另一個(gè)坑是端口映射和容器內(nèi)部端口混淆。比如Qdrant在容器內(nèi)部監(jiān)聽6333你映射到宿主機(jī)的6333。如果你的應(yīng)用跑在宿主機(jī)上用localhost:6333沒問題但如果應(yīng)用也跑在容器里就要用qdrant:6333。注意如果你在Windows上跑Docker Desktop有時(shí)候WSL2的網(wǎng)絡(luò)會(huì)有問題。可以嘗試重啟WSLwsl --shutdown或者重啟Docker Desktop。如果還是不行檢查一下防火墻設(shè)置。5.3 MCP連接失敗的排查熱搜詞里提到了“谷歌瀏覽器擴(kuò)展設(shè)置中啟用mcp連接”和“l(fā)lm request failed: provider rejected the request schema or tool payload”。MCP連接失敗通常有幾個(gè)原因Schema不匹配。MCP協(xié)議對(duì)Tools的定義有嚴(yán)格的Schema要求。如果你的參數(shù)類型寫錯(cuò)了比如該用string的地方用了integerServer端會(huì)拒絕請(qǐng)求。建議用MCP官方提供的Schema驗(yàn)證工具先校驗(yàn)一遍。Token過期。如果你用的是帶認(rèn)證的MCP ServerToken過期后所有請(qǐng)求都會(huì)被拒絕。檢查Token的有效期必要時(shí)實(shí)現(xiàn)自動(dòng)刷新。網(wǎng)絡(luò)隔離。如果MCP Server跑在Docker容器里Client跑在宿主機(jī)上確保端口映射正確并且防火墻沒有攔截。5.4 記憶膨脹導(dǎo)致成本失控這是很多團(tuán)隊(duì)上線一段時(shí)間后才會(huì)發(fā)現(xiàn)的問題。記憶越存越多每次檢索都要掃描大量向量Token成本和時(shí)間成本都在上升。我的做法是分級(jí)存儲(chǔ)。重要性高的記憶存在Qdrant里重要性低的轉(zhuǎn)移到冷存儲(chǔ)比如S3或者本地文件只在需要時(shí)才加載。另外定期做記憶合并把多條相似的記憶合并成一條減少總量。還有一個(gè)技巧是設(shè)置記憶上限。每個(gè)用戶的Episodic Memory最多保留1000條超過之后按重要性和時(shí)間排序淘汰最差的。這樣既能控制成本又不會(huì)丟失關(guān)鍵信息。6. 一些踩坑之后的個(gè)人體會(huì)這套記憶系統(tǒng)我在幾個(gè)項(xiàng)目里跑過有做個(gè)人助手的也有做企業(yè)知識(shí)管理的。最大的體會(huì)是記憶系統(tǒng)的核心不是技術(shù)而是策略。你用什么向量數(shù)據(jù)庫、用什么embedding模型這些都可以換。但“什么該記、什么該忘、什么時(shí)候該回想”這些策略層面的決策才是決定系統(tǒng)好不好用的關(guān)鍵。另外不要一開始就追求完美。我見過有人花了兩周時(shí)間設(shè)計(jì)了一套極其復(fù)雜的記憶架構(gòu)結(jié)果上線后發(fā)現(xiàn)用戶根本不買賬。不如先用最簡(jiǎn)單的方案跑起來收集真實(shí)數(shù)據(jù)再根據(jù)反饋迭代。記憶系統(tǒng)是一個(gè)需要持續(xù)調(diào)優(yōu)的東西沒有一勞永逸的方案。最后分享一個(gè)小技巧在寫入記憶時(shí)讓LLM同時(shí)生成一個(gè)**“反事實(shí)”版本**也就是“如果這條記憶不成立會(huì)是什么情況”。這個(gè)反事實(shí)版本可以幫助Agent在檢索時(shí)做更精準(zhǔn)的判斷避免誤用記憶。這個(gè)技巧是我在一次調(diào)試中偶然發(fā)現(xiàn)的后來在多個(gè)項(xiàng)目里驗(yàn)證過效果確實(shí)不錯(cuò)。 基于MCP與Docker的Agent Memory實(shí)戰(zhàn)：構(gòu)建具備反思能力的LLM記憶系統(tǒng)
1. 從“hindsight”說起為什么我們需要給Agent裝上“后視鏡”“hindsight”這個(gè)詞直譯過來就是“后見之明”或者更通俗一點(diǎn)——“馬后炮”。但在Agent Memory和LLM工程化的語境里它指向的是一個(gè)非常具體且要命的問題當(dāng)你的Agent在完成一輪對(duì)話、一次任務(wù)、一個(gè)工作流之后它到底記住了什么它能不能在后續(xù)的交互中像人一樣“回想”起之前發(fā)生過的事情并且用這些記憶來指導(dǎo)當(dāng)下的決策我接觸過不少做Agent落地的團(tuán)隊(duì)大家一開始都興致勃勃地接入了LLM搭好了MCP協(xié)議用Docker把服務(wù)跑起來覺得萬事大吉。結(jié)果上線沒幾天就發(fā)現(xiàn)用戶問“上次你幫我查的那個(gè)訂單到哪了”Agent一臉茫然用戶說“還是按我昨天說的那個(gè)方案來”Agent又開始重新問一遍需求。這不是模型不夠聰明而是記憶系統(tǒng)沒有設(shè)計(jì)好。“hindsight”這個(gè)項(xiàng)目標(biāo)題本質(zhì)上就是在解決這個(gè)問題。它不是一個(gè)簡(jiǎn)單的“把對(duì)話歷史塞進(jìn)上下文”的粗暴方案而是一套圍繞Agent Memory構(gòu)建的、帶有反思和回溯能力的記憶管理機(jī)制。結(jié)合熱搜詞里出現(xiàn)的agent memory、LLM、MCP、Docker這些關(guān)鍵詞可以很清楚地看到這個(gè)項(xiàng)目要處理的是在LLM驅(qū)動(dòng)的Agent系統(tǒng)中如何通過MCP協(xié)議和容器化部署實(shí)現(xiàn)一套可持久化、可檢索、可反思的記憶層讓Agent具備“回頭看”的能力。這篇文章適合誰看如果你正在做Agent開發(fā)或者你已經(jīng)在用MCP協(xié)議搭建工具鏈又或者你只是單純好奇“為什么我的Agent總是記不住事”那接下來的內(nèi)容應(yīng)該能給你一些可以直接抄作業(yè)的思路和實(shí)操方案。我會(huì)從整體設(shè)計(jì)、核心細(xì)節(jié)、實(shí)操過程、問題排查幾個(gè)維度把“hindsight”這個(gè)項(xiàng)目背后的技術(shù)邏輯和落地經(jīng)驗(yàn)拆開來講。2. 整體設(shè)計(jì)與思路拆解Agent Memory到底該怎么分層2.1 為什么“把歷史對(duì)話全塞進(jìn)Prompt”是條死路很多人第一次做Agent記憶想都不用想直接把最近N輪對(duì)話拼接到System Prompt后面。這個(gè)方案在Demo階段沒問題一旦進(jìn)入真實(shí)場(chǎng)景就會(huì)撞上三堵墻。第一堵墻是Token成本。LLM的上下文窗口再大也是有上限的而且大部分API是按Token計(jì)費(fèi)的。你把幾十輪對(duì)話全塞進(jìn)去每次請(qǐng)求都在燒錢而且響應(yīng)延遲會(huì)明顯上升。第二堵墻是信息稀釋。上下文里塞的東西越多模型對(duì)關(guān)鍵信息的注意力就越容易被分散。你明明在第三輪對(duì)話里說了“我對(duì)花生過敏”結(jié)果到第二十輪的時(shí)候模型已經(jīng)把這個(gè)信息淹沒在大量無關(guān)對(duì)話里了。第三堵墻是跨會(huì)話失憶。用戶今天關(guān)掉頁面明天再回來你的Agent完全不知道昨天發(fā)生過什么因?yàn)閷?duì)話歷史根本沒有持久化?！癶indsight”的設(shè)計(jì)思路本質(zhì)上就是要解決這三個(gè)問題。它把記憶拆成了不同的層次每一層有不同的存儲(chǔ)介質(zhì)、檢索策略和生命周期。這不是過度設(shè)計(jì)而是被真實(shí)場(chǎng)景逼出來的。2.2 三層記憶架構(gòu)Working Memory、Episodic Memory、Semantic Memory參考認(rèn)知科學(xué)里對(duì)人類記憶的分類結(jié)合熱搜詞里提到的“agent 存儲(chǔ) working memory”我把“hindsight”的記憶體系拆成三層來理解。第一層是Working Memory工作記憶。這一層對(duì)應(yīng)的是當(dāng)前會(huì)話的上下文窗口生命周期最短通常只保留最近幾輪對(duì)話或者當(dāng)前任務(wù)相關(guān)的信息。它的作用是讓Agent在單次交互中保持連貫性。實(shí)現(xiàn)上你可以用一個(gè)滑動(dòng)窗口來管理窗口大小根據(jù)模型上下文長(zhǎng)度和任務(wù)復(fù)雜度來定。比如你用的是128K上下文的模型那Working Memory可以控制在8K到16K Token之間留出足夠的空間給System Prompt和工具調(diào)用結(jié)果。第二層是Episodic Memory情景記憶。這一層記錄的是“什么時(shí)候發(fā)生了什么”。比如用戶在某次會(huì)話中提到了自己的偏好、完成了一個(gè)訂單、反饋了一個(gè)問題。這些信息需要被持久化存儲(chǔ)并且在后續(xù)會(huì)話中能夠被檢索出來。熱搜詞里提到的“l(fā)lm的token三個(gè)點(diǎn)key我是誰、query我在找什么、value我能提供什么”其實(shí)就是在描述這種記憶的索引結(jié)構(gòu)Key是身份標(biāo)識(shí)Query是檢索意圖Value是具體內(nèi)容。Episodic Memory通常用向量數(shù)據(jù)庫來存因?yàn)槟阈枰稣Z義檢索而不是精確匹配。第三層是Semantic Memory語義記憶。這一層存儲(chǔ)的是從多次交互中抽象出來的、去除了時(shí)間屬性的知識(shí)。比如“這個(gè)用戶偏好簡(jiǎn)潔的回答風(fēng)格”、“這個(gè)項(xiàng)目的代碼規(guī)范要求用TypeScript”。Semantic Memory的更新頻率更低但一旦形成就比較穩(wěn)定。它可以通過對(duì)Episodic Memory的定期總結(jié)和歸納來生成也可以由人工顯式注入。這三層記憶不是孤立的它們之間有一個(gè)寫入和讀取的流轉(zhuǎn)機(jī)制。Working Memory里的信息在會(huì)話結(jié)束后經(jīng)過篩選和壓縮寫入Episodic MemoryEpisodic Memory里的多條記錄經(jīng)過歸納沉淀為Semantic Memory。反過來當(dāng)Agent需要做決策時(shí)會(huì)先從Semantic Memory里拉取長(zhǎng)期偏好再從Episodic Memory里檢索相關(guān)歷史最后和Working Memory里的當(dāng)前上下文合并形成最終的Prompt。2.3 為什么選MCP和Docker作為基礎(chǔ)設(shè)施熱搜詞里MCP和Docker的出現(xiàn)頻率非常高這不是偶然的。MCP協(xié)議解決的是工具調(diào)用標(biāo)準(zhǔn)化的問題而Docker解決的是環(huán)境一致性和部署效率的問題。先說MCP。在沒有MCP之前你要讓Agent去查數(shù)據(jù)庫、調(diào)API、讀文件每個(gè)工具都要寫一套適配代碼而且不同LLM框架之間的工具定義格式還不一樣。MCP把這件事標(biāo)準(zhǔn)化了你只需要按照MCP協(xié)議定義一個(gè)Server暴露Tools和Resources任何支持MCP的Client都可以直接調(diào)用。對(duì)于“hindsight”這樣的記憶系統(tǒng)來說這意味著你可以把記憶的讀寫操作封裝成MCP Tools比如memory_write、memory_search、memory_summarize然后讓Agent在需要的時(shí)候自主調(diào)用。這樣記憶系統(tǒng)就和Agent的核心邏輯解耦了換模型、換框架都不影響。再說Docker。Agent Memory系統(tǒng)通常需要依賴向量數(shù)據(jù)庫、關(guān)系型數(shù)據(jù)庫、緩存服務(wù)等多個(gè)組件。如果你在本地開發(fā)環(huán)境跑通了部署到服務(wù)器上發(fā)現(xiàn)各種依賴版本沖突那就很頭疼。Docker把每個(gè)組件打包成獨(dú)立的容器用docker-compose或者Kubernetes編排環(huán)境一致性有保障。而且熱搜詞里提到了“docker安裝mysql8.0并使用”、“docker安裝redis主從”這些具體操作說明很多開發(fā)者已經(jīng)在用Docker來搭建Agent的基礎(chǔ)設(shè)施了。注意如果你在Windows上安裝Docker Desktop時(shí)遇到“virtualization support not detected”的報(bào)錯(cuò)大概率是BIOS里的虛擬化支持沒有開啟。重啟進(jìn)入BIOS找到Intel VT-x或者AMD-V選項(xiàng)設(shè)為Enabled即可。這個(gè)問題在“docker desktop安裝教程”相關(guān)的搜索里出現(xiàn)頻率極高但很多人會(huì)誤以為是軟件問題。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)記憶的寫入、檢索與反思3.1 記憶寫入不是所有對(duì)話都值得記住Working Memory里的內(nèi)容在會(huì)話結(jié)束時(shí)不能一股腦全寫進(jìn)Episodic Memory。你需要一個(gè)篩選和壓縮的過程。我的做法是在會(huì)話結(jié)束前讓LLM對(duì)當(dāng)前對(duì)話做一次總結(jié)提取出關(guān)鍵信息點(diǎn)然后按照固定的Schema寫入。這個(gè)Schema通常包含以下字段字段名類型說明memory_idstring唯一標(biāo)識(shí)通常用UUIDuser_idstring用戶標(biāo)識(shí)用于隔離不同用戶的記憶session_idstring會(huì)話標(biāo)識(shí)用于追溯來源timestampdatetime記憶產(chǎn)生的時(shí)間contentstring記憶的具體內(nèi)容經(jīng)過壓縮和總結(jié)embeddingvector內(nèi)容的向量表示用于語義檢索tagslist標(biāo)簽用于分類和過濾importancefloat重要性評(píng)分0到1之間ttlint過期時(shí)間單位秒0表示永不過期這里面的importance評(píng)分很關(guān)鍵。不是所有記憶都同等重要。用戶說“今天天氣不錯(cuò)”和用戶說“我對(duì)青霉素過敏”這兩條記憶的價(jià)值天差地別。我的做法是讓LLM在總結(jié)時(shí)給每條記憶打一個(gè)重要性分?jǐn)?shù)低于閾值的直接丟棄高于閾值的才寫入Episodic Memory。閾值設(shè)多少根據(jù)我的經(jīng)驗(yàn)0.6是一個(gè)比較合理的起點(diǎn)你可以根據(jù)實(shí)際效果微調(diào)。Tags的設(shè)計(jì)也很有講究。你可以用標(biāo)簽來標(biāo)記記憶的類型比如preference、fact、event、instruction。這樣在檢索的時(shí)候可以先按標(biāo)簽過濾再做向量相似度搜索效率和準(zhǔn)確率都會(huì)更高。3.2 記憶檢索Key-Query-Value的三元組邏輯熱搜詞里有一句很精辟的總結(jié)“l(fā)lm的token三個(gè)點(diǎn)key我是誰、query我在找什么、value我能提供什么”。這其實(shí)就是在描述記憶檢索的核心邏輯。當(dāng)Agent需要檢索記憶時(shí)它首先要明確三個(gè)問題我是誰Key身份標(biāo)識(shí)、我在找什么Query檢索意圖、我能提供什么Value返回內(nèi)容。映射到技術(shù)實(shí)現(xiàn)上Key對(duì)應(yīng)的是user_id和session_id用來限定檢索范圍。你不能讓用戶A的記憶被用戶B檢索到這是基本的安全隔離。Query對(duì)應(yīng)的是當(dāng)前對(duì)話的上下文或者用戶的最新輸入用來生成檢索向量。Value對(duì)應(yīng)的是Episodic Memory里存儲(chǔ)的content字段也就是最終返回給Agent的記憶內(nèi)容。檢索的流程通常是這樣的先用user_id過濾出該用戶的所有記憶然后用Query生成embedding在向量數(shù)據(jù)庫里做相似度搜索返回Top-K條結(jié)果。K值設(shè)多少我一般設(shè)5到10太多了會(huì)稀釋上下文太少了可能漏掉關(guān)鍵信息。但純向量檢索有一個(gè)問題它只能找到語義相似的記憶找不到時(shí)間相關(guān)的記憶。比如用戶問“我上周讓你幫我查的那個(gè)東西”向量檢索可能找不到因?yàn)椤吧现堋笔且粋€(gè)時(shí)間概念不是語義概念。所以你需要結(jié)合時(shí)間過濾。在檢索時(shí)先根據(jù)Query里的時(shí)間信息如果有的話縮小時(shí)間范圍再做向量搜索。3.3 記憶反思讓Agent學(xué)會(huì)“回頭看”“hindsight”這個(gè)名字本身就暗示了反思的能力。記憶系統(tǒng)不能只是被動(dòng)地存儲(chǔ)和檢索它還需要定期做反思和歸納。具體來說你可以設(shè)置一個(gè)定時(shí)任務(wù)每天或者每周跑一次把Episodic Memory里最近一段時(shí)間的記憶拉出來讓LLM做一次總結(jié)提取出穩(wěn)定的偏好和模式寫入Semantic Memory。比如Agent發(fā)現(xiàn)用戶在過去兩周里三次提到了“不要用Markdown格式回復(fù)”那就可以在Semantic Memory里生成一條“該用戶偏好純文本回復(fù)”的長(zhǎng)期記憶。這個(gè)反思過程還可以用來清理過期記憶。有些記憶是有時(shí)效性的比如“用戶明天要開會(huì)”過了明天這條記憶就沒用了。你可以在寫入時(shí)設(shè)置TTL到期自動(dòng)刪除?；蛘咦孡LM在反思時(shí)判斷哪些記憶已經(jīng)過時(shí)主動(dòng)標(biāo)記刪除。提示反思任務(wù)的頻率不要太高否則會(huì)浪費(fèi)Token而且可能引入噪聲。我的經(jīng)驗(yàn)是對(duì)于個(gè)人助手類的Agent每天一次足夠了對(duì)于企業(yè)級(jí)應(yīng)用可以每周一次。另外反思生成的Semantic Memory最好保留一個(gè)“置信度”字段因?yàn)長(zhǎng)LM的歸納不一定總是準(zhǔn)確的。3.4 MCP Tools的設(shè)計(jì)把記憶操作暴露給Agent把記憶系統(tǒng)封裝成MCP Server之后你需要定義一組Tools讓Agent調(diào)用。以下是我在實(shí)際項(xiàng)目中常用的幾個(gè){ tools: [ { name: memory_write, description: 寫入一條新的記憶, parameters: { content: string, 記憶內(nèi)容, tags: list, 標(biāo)簽, importance: float, 重要性評(píng)分 } }, { name: memory_search, description: 檢索相關(guān)記憶, parameters: { query: string, 檢索意圖, top_k: int, 返回條數(shù), tags_filter: list, 標(biāo)簽過濾 } }, { name: memory_summarize, description: 對(duì)近期記憶進(jìn)行總結(jié)歸納, parameters: { time_range: string, 時(shí)間范圍, target: string, 總結(jié)目標(biāo) } } ] }Agent在對(duì)話過程中可以根據(jù)需要自主決定什么時(shí)候?qū)懭胗洃?、什么時(shí)候檢索記憶。比如用戶說“記住我對(duì)花生過敏”Agent就應(yīng)該調(diào)用memory_write用戶問“我之前說過什么偏好”Agent就應(yīng)該調(diào)用memory_search。這種設(shè)計(jì)的好處是解耦。記憶系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)對(duì)Agent透明Agent只需要知道有哪些Tools可用就行了。你后面想換向量數(shù)據(jù)庫、想調(diào)整檢索策略都不需要改Agent的核心邏輯。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)從零搭建一套可用的記憶系統(tǒng)4.1 環(huán)境準(zhǔn)備Docker Compose一鍵拉起依賴服務(wù)假設(shè)你現(xiàn)在要從零開始搭建這套系統(tǒng)第一步是把基礎(chǔ)設(shè)施跑起來。你需要的東西不多一個(gè)向量數(shù)據(jù)庫我用Qdrant輕量且API友好、一個(gè)關(guān)系型數(shù)據(jù)庫PostgreSQL用來存結(jié)構(gòu)化數(shù)據(jù)、一個(gè)緩存Redis用來做Working Memory的快速讀寫。創(chuàng)建一個(gè)docker-compose.yml文件version: 3.8 services: qdrant: image: qdrant/qdrant:latest ports: - 6333:6333 - 6334:6334 volumes: - qdrant_data:/qdrant/storage postgres: image: postgres:16 environment: POSTGRES_USER: memory POSTGRES_PASSWORD: memory_pass POSTGRES_DB: agent_memory ports: - 5432:5432 volumes: - pg_data:/var/lib/postgresql/data redis: image: redis:7-alpine ports: - 6379:6379 volumes: - redis_data:/data volumes: qdrant_data: pg_data: redis_data:然后在終端里執(zhí)行docker compose up -d三個(gè)服務(wù)就都跑起來了。這里有幾個(gè)細(xì)節(jié)需要注意Qdrant的6333端口是HTTP API6334是gRPC。如果你用Python客戶端默認(rèn)走6333就行。PostgreSQL的密碼不要用默認(rèn)的生產(chǎn)環(huán)境一定要改。我這里寫memory_pass只是為了演示。Redis我用了alpine版本體積小啟動(dòng)快。如果你需要持久化記得配置appendonly yes。注意如果你在Windows上跑Docker Desktop確保WSL2后端已經(jīng)啟用。另外如果之前裝過Docker Toolbox可能會(huì)有端口沖突建議先清理干凈再裝Docker Desktop。4.2 記憶寫入的完整代碼實(shí)現(xiàn)基礎(chǔ)設(shè)施跑起來之后接下來寫記憶寫入的邏輯。我用Python來演示因?yàn)樯鷳B(tài)最成熟。import uuid import datetime from qdrant_client import QdrantClient from qdrant_client.models import PointStruct, VectorParams, Distance from openai import OpenAI client QdrantClient(hostlocalhost, port6333) openai_client OpenAI() COLLECTION_NAME episodic_memory # 初始化Collection client.recreate_collection( collection_nameCOLLECTION_NAME, vectors_configVectorParams(size1536, distanceDistance.COSINE) ) def get_embedding(text: str) - list: response openai_client.embeddings.create( modeltext-embedding-3-small, inputtext ) return response.data[0].embedding def write_memory(user_id: str, session_id: str, content: str, tags: list, importance: float, ttl: int 0): if importance 0.6: return None memory_id str(uuid.uuid4()) embedding get_embedding(content) timestamp datetime.datetime.now().isoformat() payload { user_id: user_id, session_id: session_id, content: content, tags: tags, importance: importance, timestamp: timestamp, ttl: ttl } client.upsert( collection_nameCOLLECTION_NAME, points[ PointStruct( idmemory_id, vectorembedding, payloadpayload ) ] ) return memory_id這段代碼的核心邏輯是先判斷重要性低于閾值的直接丟棄然后生成embedding把內(nèi)容和元數(shù)據(jù)一起寫入Qdrant。user_id和session_id放在payload里檢索時(shí)可以用來過濾。4.3 記憶檢索的實(shí)現(xiàn)與參數(shù)調(diào)優(yōu)檢索的邏輯比寫入稍微復(fù)雜一點(diǎn)因?yàn)橐幚磉^濾條件和相似度排序。def search_memory(user_id: str, query: str, top_k: int 5, tags_filter: list None, time_range: tuple None): query_embedding get_embedding(query) # 構(gòu)建過濾條件 must_conditions [ {key: user_id, match: {value: user_id}} ] if tags_filter: must_conditions.append({ key: tags, match: {any: tags_filter} }) if time_range: must_conditions.append({ key: timestamp, range: { gte: time_range[0], lte: time_range[1] } }) results client.search( collection_nameCOLLECTION_NAME, query_vectorquery_embedding, query_filter{must: must_conditions}, limittop_k, with_payloadTrue ) return [ { content: hit.payload[content], score: hit.score, timestamp: hit.payload[timestamp], tags: hit.payload[tags] } for hit in results ]這里有幾個(gè)調(diào)優(yōu)的點(diǎn)值得展開說。Top-K的選擇。我默認(rèn)設(shè)5但這不是固定的。如果Agent的任務(wù)比較復(fù)雜需要更多背景信息可以調(diào)到10。但不要超過15否則上下文里塞太多記憶反而會(huì)干擾模型判斷。相似度閾值。Qdrant返回的score是余弦相似度范圍在-1到1之間。我一般會(huì)設(shè)一個(gè)最低閾值比如0.7低于這個(gè)值的直接丟棄。不然你可能會(huì)檢索出一堆不相關(guān)的記憶反而誤導(dǎo)Agent。時(shí)間衰減。越久遠(yuǎn)的記憶相關(guān)性可能越低。你可以在排序時(shí)引入一個(gè)時(shí)間衰減因子讓新記憶的權(quán)重更高。具體做法是在score上乘以一個(gè)衰減系數(shù)比如score * exp(-lambda * days_ago)lambda取0.01到0.05之間。4.4 反思任務(wù)的定時(shí)調(diào)度反思任務(wù)可以用APScheduler或者Celery來調(diào)度。我一般用APScheduler輕量且夠用。from apscheduler.schedulers.background import BackgroundScheduler def reflect_memory(user_id: str): # 拉取最近7天的Episodic Memory recent_memories search_memory( user_iduser_id, query, top_k50, time_range( (datetime.datetime.now() - datetime.timedelta(days7)).isoformat(), datetime.datetime.now().isoformat() ) ) if len(recent_memories) 5: return # 讓LLM做總結(jié) memory_text \n.join([m[content] for m in recent_memories]) prompt f請(qǐng)對(duì)以下用戶記憶進(jìn)行總結(jié)提取出穩(wěn)定的偏好和模式 {memory_text} 請(qǐng)以JSON格式返回包含以下字段 - preferences: 用戶偏好列表 - facts: 關(guān)于用戶的事實(shí)列表 - patterns: 行為模式列表 response openai_client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], response_format{type: json_object} ) # 將總結(jié)結(jié)果寫入Semantic Memory semantic_content response.choices[0].message.content write_memory( user_iduser_id, session_idreflection, contentsemantic_content, tags[semantic, reflection], importance0.9 ) scheduler BackgroundScheduler() scheduler.add_job(reflect_memory, cron, hour3, minute0, args[user_123]) scheduler.start()這個(gè)反思任務(wù)每天凌晨3點(diǎn)跑一次對(duì)指定用戶最近7天的記憶做總結(jié)?？偨Y(jié)結(jié)果寫入Semantic Memory標(biāo)簽設(shè)為semantic和reflection重要性設(shè)為0.9確保不會(huì)被輕易丟棄。提示反思任務(wù)的Prompt設(shè)計(jì)很關(guān)鍵。我試過讓LLM自由發(fā)揮結(jié)果它經(jīng)常生成一些模棱兩可的總結(jié)。后來改成強(qiáng)制JSON格式并且明確要求提取preferences、facts、patterns三類信息效果穩(wěn)定了很多。5. 常見問題與排查技巧實(shí)錄5.1 記憶檢索不準(zhǔn)確怎么辦這是最常見的問題。你明明存了一條記憶但檢索的時(shí)候就是找不到。排查思路按以下順序來第一步檢查embedding模型是否一致。寫入時(shí)用的模型和檢索時(shí)用的模型必須是同一個(gè)。如果你寫入用的是text-embedding-3-small檢索時(shí)換成了text-embedding-ada-002那向量空間都不一樣肯定搜不到。第二步檢查過濾條件是否過嚴(yán)。有時(shí)候user_id或者tags_filter寫錯(cuò)了導(dǎo)致過濾掉了正確的記憶。你可以先把過濾條件去掉只做純向量檢索看看能不能搜到。如果能搜到那就是過濾條件的問題。第三步檢查相似度閾值。如果你設(shè)了0.7的閾值但實(shí)際相似度只有0.65那就會(huì)被丟棄。可以先把閾值降到0.5看看結(jié)果如何。第四步檢查記憶內(nèi)容的質(zhì)量。如果寫入的記憶本身就是一堆廢話那embedding的質(zhì)量也不會(huì)高。確保寫入前做了充分的壓縮和總結(jié)。問題現(xiàn)象可能原因解決方法完全搜不到embedding模型不一致統(tǒng)一寫入和檢索的模型搜到但不相關(guān)相似度閾值過低提高閾值到0.7以上搜到但排序不對(duì)缺少時(shí)間衰減引入時(shí)間衰減因子搜到但內(nèi)容過時(shí)TTL未生效檢查TTL字段和清理任務(wù)5.2 Docker環(huán)境下的網(wǎng)絡(luò)問題熱搜詞里出現(xiàn)了“docker網(wǎng)絡(luò)不通”這在Agent Memory系統(tǒng)里很常見。因?yàn)槟愕膽?yīng)用容器需要訪問Qdrant、PostgreSQL、Redis如果網(wǎng)絡(luò)配置不對(duì)就會(huì)連不上。最常見的坑是容器間通信用了localhost。在Docker Compose里每個(gè)服務(wù)的主機(jī)名就是服務(wù)名。比如你的應(yīng)用容器要連Qdrant應(yīng)該用qdrant:6333而不是localhost:6333。因?yàn)閘ocalhost在容器內(nèi)部指向的是容器自己不是宿主機(jī)。另一個(gè)坑是端口映射和容器內(nèi)部端口混淆。比如Qdrant在容器內(nèi)部監(jiān)聽6333你映射到宿主機(jī)的6333。如果你的應(yīng)用跑在宿主機(jī)上用localhost:6333沒問題但如果應(yīng)用也跑在容器里就要用qdrant:6333。注意如果你在Windows上跑Docker Desktop有時(shí)候WSL2的網(wǎng)絡(luò)會(huì)有問題。可以嘗試重啟WSLwsl --shutdown或者重啟Docker Desktop。如果還是不行檢查一下防火墻設(shè)置。5.3 MCP連接失敗的排查熱搜詞里提到了“谷歌瀏覽器擴(kuò)展設(shè)置中啟用mcp連接”和“l(fā)lm request failed: provider rejected the request schema or tool payload”。MCP連接失敗通常有幾個(gè)原因Schema不匹配。MCP協(xié)議對(duì)Tools的定義有嚴(yán)格的Schema要求。如果你的參數(shù)類型寫錯(cuò)了比如該用string的地方用了integerServer端會(huì)拒絕請(qǐng)求。建議用MCP官方提供的Schema驗(yàn)證工具先校驗(yàn)一遍。Token過期。如果你用的是帶認(rèn)證的MCP ServerToken過期后所有請(qǐng)求都會(huì)被拒絕。檢查Token的有效期必要時(shí)實(shí)現(xiàn)自動(dòng)刷新。網(wǎng)絡(luò)隔離。如果MCP Server跑在Docker容器里Client跑在宿主機(jī)上確保端口映射正確并且防火墻沒有攔截。5.4 記憶膨脹導(dǎo)致成本失控這是很多團(tuán)隊(duì)上線一段時(shí)間后才會(huì)發(fā)現(xiàn)的問題。記憶越存越多每次檢索都要掃描大量向量Token成本和時(shí)間成本都在上升。我的做法是分級(jí)存儲(chǔ)。重要性高的記憶存在Qdrant里重要性低的轉(zhuǎn)移到冷存儲(chǔ)比如S3或者本地文件只在需要時(shí)才加載。另外定期做記憶合并把多條相似的記憶合并成一條減少總量。還有一個(gè)技巧是設(shè)置記憶上限。每個(gè)用戶的Episodic Memory最多保留1000條超過之后按重要性和時(shí)間排序淘汰最差的。這樣既能控制成本又不會(huì)丟失關(guān)鍵信息。6. 一些踩坑之后的個(gè)人體會(huì)這套記憶系統(tǒng)我在幾個(gè)項(xiàng)目里跑過有做個(gè)人助手的也有做企業(yè)知識(shí)管理的。最大的體會(huì)是記憶系統(tǒng)的核心不是技術(shù)而是策略。你用什么向量數(shù)據(jù)庫、用什么embedding模型這些都可以換。但“什么該記、什么該忘、什么時(shí)候該回想”這些策略層面的決策才是決定系統(tǒng)好不好用的關(guān)鍵。另外不要一開始就追求完美。我見過有人花了兩周時(shí)間設(shè)計(jì)了一套極其復(fù)雜的記憶架構(gòu)結(jié)果上線后發(fā)現(xiàn)用戶根本不買賬。不如先用最簡(jiǎn)單的方案跑起來收集真實(shí)數(shù)據(jù)再根據(jù)反饋迭代。記憶系統(tǒng)是一個(gè)需要持續(xù)調(diào)優(yōu)的東西沒有一勞永逸的方案。最后分享一個(gè)小技巧在寫入記憶時(shí)讓LLM同時(shí)生成一個(gè)**“反事實(shí)”版本**也就是“如果這條記憶不成立會(huì)是什么情況”。這個(gè)反事實(shí)版本可以幫助Agent在檢索時(shí)做更精準(zhǔn)的判斷避免誤用記憶。這個(gè)技巧是我在一次調(diào)試中偶然發(fā)現(xiàn)的后來在多個(gè)項(xiàng)目里驗(yàn)證過效果確實(shí)不錯(cuò)。