先給結(jié)論把 AI Agent 的上下文窗口從 8k 擴(kuò)到 128k大概率不是讓 Agent 變聰明而是讓它在更長的對(duì)話里忘得更體面。真正決定一個(gè) Agent 能不能穩(wěn)定處理長期任務(wù)、跨會(huì)話記住用戶偏好、在信息沖突時(shí)自我修正的不是窗口有多寬而是記憶系統(tǒng)架構(gòu)設(shè)計(jì)。這些年我?guī)蛨F(tuán)隊(duì)做過幾版 Agent從直接懟長文本到接向量庫再到完整的記憶分層和遺忘機(jī)制最深的感受是上下文窗口只是一張工作臺(tái)不是倉庫。工作臺(tái)再大擺不下一個(gè)季度的高價(jià)值信息。這篇文章就圍繞“AI Agent 記憶系統(tǒng)架構(gòu)設(shè)計(jì)全景”展開講清楚為什么更大的上下文窗口救不了你的 Agent以及一套可以落地的分層記憶方案應(yīng)該怎么搭、怎么避坑。1. 為什么“更大的上下文窗口”是治標(biāo)不治本1.1 先搞清楚上下文窗口在 Agent 里的真實(shí)位置很多人會(huì)把“上下文窗口很大”等同于“模型記住了很多”這是行業(yè)里最常見的誤解之一。上下文窗口的本質(zhì)是模型每次推理時(shí)能看到的輸入 token 總量它相當(dāng)于一個(gè)短期緩沖區(qū)或者叫工作記憶。窗口里的內(nèi)容只是被“臨時(shí)塞進(jìn)”了模型的注意力范圍內(nèi)模型處理完這一次生成之后這些 token 不會(huì)自動(dòng)沉淀成任何長期狀態(tài)。我見過不少團(tuán)隊(duì)的做法是把所有歷史會(huì)話記錄、用戶資料、業(yè)務(wù)知識(shí)一股腦拼進(jìn) prompt然后寄希望于大窗口能覆蓋一切。這在 demo 階段確實(shí)行得通但你一旦讓 Agent 跑在真實(shí)業(yè)務(wù)里連續(xù)服務(wù)一個(gè)用戶超過幾十輪或者隔幾天再來一次就會(huì)發(fā)現(xiàn)窗口機(jī)制有三個(gè)繞不開的短板成本爆炸、注意力稀釋、信息無法持久化。這也是為什么我說它治標(biāo)不治本因?yàn)榇翱谠黾又皇菙U(kuò)容了臨時(shí)工作臺(tái)并沒有引入“長期存儲(chǔ)—索引—檢索—更新”這條記憶通路。1.2 注意力稀疏和“丟失在中間”現(xiàn)象長上下文模型有一個(gè)被論文反復(fù)驗(yàn)證的問題當(dāng)輸入序列拉長之后模型對(duì)中間位置信息的注意力會(huì)明顯衰減業(yè)界叫“l(fā)ost in the middle”。也就是說即便你把 128k 歷史全文都塞進(jìn)去模型真正穩(wěn)定關(guān)注的可能還是開頭和最近幾段中間那些關(guān)鍵約束、用戶偏好、歷史結(jié)論很容易被稀釋。我在實(shí)際項(xiàng)目里遇到過很典型的一次客服 Agent 要記住用戶之前說過“不要電話聯(lián)系只發(fā)郵件”同時(shí)又記著另一個(gè)較早期的訴求“要開發(fā)票”。把 60 輪對(duì)話原文塞進(jìn)一個(gè) 128k 窗口后它在第 70 輪時(shí)莫名其妙打電話提醒用戶而不是發(fā)郵件。查下去才發(fā)現(xiàn)最早的這條偏好被淹沒在長文本中間位置模型不是不知道而是沒有分配到足夠注意力權(quán)重。這類問題不是把窗口再放大就能解決的因?yàn)槟惴糯蟠翱诘耐瑫r(shí)需要被注意的信息相對(duì)比例反而更低了。1.3 成本與算力不會(huì)陪你“線性增長”上下文窗口的擴(kuò)容代價(jià)是高成本和高延遲這一點(diǎn)做過線上服務(wù)的團(tuán)隊(duì)?wèi)?yīng)該都有體感。按主流模型輸入價(jià)格粗略算一個(gè) 4k 窗口的輸入如果花 0.015 美元到了 128k 窗口單次請(qǐng)求成本會(huì)增長三四十倍。而 Agent 任務(wù)往往不是單次調(diào)用是循環(huán)決策Agent 每執(zhí)行一步工具調(diào)用、每觀察一次結(jié)果都要重新發(fā)送完整上下文。假設(shè)一個(gè) Agent 完成一次真實(shí)任務(wù)需要 10 次模型調(diào)用每次調(diào)用都帶 80k 歷史 token那一次任務(wù)光輸入就要消耗 800k token。如果這個(gè) Agent 每天服務(wù) 1000 個(gè)用戶成本很容易變成無法接受的數(shù)字。更關(guān)鍵的是其中絕大部分歷史 token 對(duì)當(dāng)前決策根本沒用。所以從工程角度看長期記憶必須做成“按需加載”而不是“全量常駐”。1.4 長上下文評(píng)測(cè)好不代表 Agent 任務(wù)好市面上有很多長文本評(píng)測(cè)集比如 LongBench 這類基準(zhǔn)動(dòng)輒幾十萬字的小說、論文摘要、位置問答。但這類任務(wù)和 AI Agent 的真實(shí)場景差異非常大長文本評(píng)測(cè)主要測(cè)“從長材料里找答案”而 Agent 的難點(diǎn)是“持續(xù)利用分散在歷史中的信息做多步?jīng)Q策”。前者是檢索題后者是狀態(tài)管理題。我見過一個(gè)團(tuán)隊(duì)模型升級(jí)到 200k 窗口后長文本閱讀理解分?jǐn)?shù)漲了不少但一上真實(shí)的訂票 Agent還是會(huì)在第三天忘記用戶“只選靠窗座位”的偏好因?yàn)檫@條偏好藏在第 2 輪而最近 50 輪都在討論航班時(shí)間。長上下文能力評(píng)測(cè)和 Agent 穩(wěn)定性的相關(guān)性遠(yuǎn)比想象中低拿評(píng)測(cè)分?jǐn)?shù)來論證“不用做記憶系統(tǒng)”是站不住腳的。2. Agent 記憶到底在記什么一套分層記憶模型2.1 借用認(rèn)知科學(xué)四種記憶類型做 AI Agent 記憶系統(tǒng)架構(gòu)設(shè)計(jì)時(shí)我建議先忘掉“把所有東西存到一個(gè)倉庫”的想法轉(zhuǎn)而把記憶按生命周期和信息類型分成幾類。認(rèn)知科學(xué)里有個(gè)很樸素的分類法放到 Agent 上正好對(duì)應(yīng)四種需求工作記憶Working Memory對(duì)應(yīng)上下文窗口保存當(dāng)前任務(wù)正在進(jìn)行的事務(wù)、臨時(shí)變量、正在討論的問題。情景記憶Episodic Memory記錄發(fā)生過的事件比如“上周二用戶投訴過物流慢”“上次這個(gè)訂單最后退款處理了”。語義記憶Semantic Memory保存從經(jīng)歷中提煉出來的知識(shí)、偏好和事實(shí)比如“用戶不喜歡電話聯(lián)系”“公司退款政策是 7 天內(nèi)免運(yùn)費(fèi)”。程序記憶Procedural Memory保存技能和流程比如“遇到退貨請(qǐng)求先核查訂單狀態(tài)再判斷是否超過 7 天”。這種分層不是為了學(xué)術(shù)美觀而是為了匹配現(xiàn)實(shí)中的工程問題數(shù)據(jù)量不同、更新頻率不同、檢索方式也不同。如果把用戶的所有對(duì)話原話都堆在一起既不能高效檢索也沒法在用戶糾正之后定點(diǎn)更新某一條事實(shí)。分層記憶的價(jià)值是讓每一類信息的存取邏輯都能獨(dú)立優(yōu)化。2.2 為什么不能只建一張大表“做大表”是很多初版 Agent 記憶系統(tǒng)的通病。把每輪對(duì)話、每個(gè)實(shí)體、每條偏好都寫入一張記憶表然后用關(guān)鍵詞去搜短期跑一跑沒問題等數(shù)據(jù)量上來就會(huì)出現(xiàn)幾個(gè)現(xiàn)象檢索召回大量無關(guān)內(nèi)容、關(guān)鍵字命中但語義不相關(guān)、用戶糾正之后舊數(shù)據(jù)和新數(shù)據(jù)同時(shí)存在模型不知道該信哪個(gè)。更實(shí)際的問題是不同的記憶生命周期不同。情景記憶格式統(tǒng)一適合存時(shí)間戳和事件摘要語義記憶需要去重和沖突處理程序記憶則需要抽成可復(fù)用的動(dòng)作序列。如果把這些東西混在一張表里時(shí)間衰減、事實(shí)更新、摘要壓縮這些策略就都很難實(shí)現(xiàn)。理論上你能靠一個(gè)極寬的表 復(fù)雜過濾實(shí)現(xiàn)同樣效果但工程復(fù)雜度會(huì)嚴(yán)重失控而且排查問題極難。2.3 一個(gè)可直接落地的記憶 Schema 示例我在項(xiàng)目中常用的一種最小記憶結(jié)構(gòu)是四張表關(guān)系型數(shù)據(jù)庫 向量庫混合。這里給你一個(gè)可以直接參考的簡化設(shè)計(jì)表保存內(nèi)容關(guān)鍵字段存儲(chǔ)方式episodes每一輪/每一段會(huì)話的摘要事件id, user_id, ts, summary, embedding摘要進(jìn)向量庫元數(shù)據(jù)進(jìn) SQLitememories從事件中提煉的用戶偏好、事實(shí)、約束id, user_id, content, memory_type, importance, created_at, last_access_at向量庫 關(guān)系表雙寫entities業(yè)務(wù)實(shí)體和關(guān)系id, entity_type, name, properties, relations關(guān)系表復(fù)雜關(guān)系可用圖數(shù)據(jù)庫skills可復(fù)用的操作流程id, trigger, steps, version普通表 / JSON 字段這套結(jié)構(gòu)的核心思想是情景記憶負(fù)責(zé)“記流水賬”語義記憶負(fù)責(zé)“提煉規(guī)則”實(shí)體表負(fù)責(zé)“人和物的關(guān)聯(lián)信息”技能表負(fù)責(zé)“怎么做”。每一次新對(duì)話進(jìn)來先寫 episode 摘要再做記憶提取再更新或新增實(shí)體/事實(shí)。檢索時(shí)再根據(jù)當(dāng)前會(huì)話的 query 去不同表里拉取相關(guān)片段拼成一個(gè)“記憶上下文塊”而不是把所有歷史全部倒進(jìn) prompt。這個(gè)設(shè)計(jì)無論是接 LangChain 還是自己寫調(diào)度都比較容易實(shí)現(xiàn)。3. 外部記憶系統(tǒng)的核心部件寫入、索引、檢索、遺忘3.1 寫入不是存原文而是抽取結(jié)構(gòu)化記憶很多第一次做記憶系統(tǒng)的團(tuán)隊(duì)會(huì)把記憶寫入做成了“聊天記錄備份”。比如把每輪對(duì)話原樣存進(jìn)向量庫檢索時(shí)直接搜原文。這個(gè)做法短時(shí)間有效但后面會(huì)出現(xiàn)兩個(gè)大問題第一原文里大量客套話、噪聲會(huì)被檢索出來第二用戶隨口說一句“我一般晚上有空”和正式申明“請(qǐng)不要在工作時(shí)間聯(lián)系我”在原始文本層面是完全不同粒度的信息向量檢索很難把它們都準(zhǔn)確歸類到“用戶時(shí)間偏好”這個(gè)記憶點(diǎn)。所以我強(qiáng)烈建議在寫入環(huán)節(jié)加一個(gè)“記憶抽取”步驟。說白了就是讓 Agent 在每次對(duì)話結(jié)束后把對(duì)話內(nèi)容提煉成幾條候選記憶并判斷該新增、更新還是刪除。形式上可以讓模型輸出一個(gè) JSON包含操作類型、記憶內(nèi)容、重要度、過期時(shí)間等字段。這一步會(huì)多花一些 token 和延遲但換來的是后續(xù)檢索效率和事實(shí)更新能力。做抽取時(shí)有兩個(gè)小技巧一是給模型指定抽取目標(biāo)比如“只抽取用戶明確表達(dá)的偏好和承諾不要抽取日常寒暄”二是要做一致性去重防止同一條事實(shí)被反復(fù)寫進(jìn)去。3.2 索引與元數(shù)據(jù)向量檢索不是銀彈真正做過基于向量庫的記憶系統(tǒng)的人都知道“embedding 余弦相似度”只是檢索的一個(gè)底座它扛不住精確過濾和歷史篩選。舉個(gè)例子一個(gè)用戶有 3000 條記憶其中有 200 條是關(guān)于“退款”的語義描述單純向量搜索會(huì)把這 200 條里相似度最高的 5 條全撈出來但它們可能分屬完全不同的訂單和時(shí)間段。所以我的做法是向量檢索負(fù)責(zé)“語義召回”關(guān)系型數(shù)據(jù)庫負(fù)責(zé)“過濾和聚合”。每條記憶寫入時(shí)都帶上 user_id、session_id、created_at、memory_type、importance 這些元數(shù)據(jù)檢索時(shí)先按業(yè)務(wù)條件過濾比如只取 user_idxx、memory_typepreference、近 30 天創(chuàng)建再做向量相似度排序。這一套混合檢索比純向量庫穩(wěn)定很多。另外一個(gè)容易被忽略的點(diǎn)是同一個(gè)記憶內(nèi)容可能需要支持多種查詢方式。用戶說“我討厭接電話”是一條偏好用戶投訴“上周客服給他打了三次電話”是一個(gè)事件兩者的查詢方式完全不同用同一套 embedding 去檢索經(jīng)常會(huì)互相干擾。3.3 檢索時(shí)間衰減、重要度和上下文組裝檢索階段的核心不是“查到最相似的一條”而是“組裝一段讓模型可以做出正確決策的記憶上下文”。我用三個(gè)維度給記憶打分語義相似性、時(shí)間新鮮度、重要度。語義相似性靠向量相似度時(shí)間新鮮度用一個(gè)簡單的衰減函數(shù)比如 score base_score * exp(-days / half_life)重要度可以就按 1-5 分級(jí)由抽取模型判斷。把三個(gè)分?jǐn)?shù)加權(quán)求和之后再?zèng)Q定最終選哪些記憶進(jìn)入上下文。關(guān)于權(quán)重我的經(jīng)驗(yàn)是語義相似度占大頭時(shí)間衰減次之重要度作為修正。還有一個(gè)實(shí)操細(xì)節(jié)不要只取 top_k而是分成兩組一組是“當(dāng)前任務(wù)高度相關(guān)”的記憶另一組是“最近頻繁使用但可能不直接相關(guān)”的輔助記憶這樣模型既能抓住直接線索又能保有必要的連續(xù)性。組裝時(shí)把記憶按“事實(shí)—約束—?dú)v史事件—工具技能”四個(gè)區(qū)塊排列而不是單純把一堆向量結(jié)果拼接起來實(shí)測(cè)推理穩(wěn)定性會(huì)好很多。3.4 遺忘與整合記憶系統(tǒng)不膨脹的關(guān)鍵“遺忘”這個(gè)詞在記憶系統(tǒng)里聽著像功能缺陷其實(shí)它是防止 Agent 記憶庫被垃圾信息淹沒的核心機(jī)制。人類的記憶也不是無限存儲(chǔ)所有瑣事而是定期整合、丟棄和抽象。AI Agent 一樣需要這個(gè)步驟。我在自己的系統(tǒng)里做了兩層處理一層是低價(jià)值記憶的軟過期。每條記憶寫入時(shí)如果重要度為 1-2且超過 30 天沒有訪問就會(huì)先被標(biāo)記為“待歸檔”不再參與常規(guī)檢索。另一層是摘要整合對(duì)同一個(gè)主題下超過一定數(shù)量的記憶比如 30 條關(guān)于訂單處理的舊記錄用一次 LLM 調(diào)用生成一篇結(jié)構(gòu)化摘要替換掉這些原始記錄。這個(gè)操作有點(diǎn)像把零碎的日記寫成年報(bào)既壓縮了存儲(chǔ)也保住了高層的規(guī)律性信息。你可能會(huì)擔(dān)心摘要整合會(huì)丟失細(xì)節(jié)。這個(gè)擔(dān)心是對(duì)的所以摘要文檔里我會(huì)留一個(gè)“原始事件時(shí)間范圍”字段當(dāng)檢索發(fā)現(xiàn)摘要不足以回答問題時(shí)再把對(duì)應(yīng)時(shí)間范圍內(nèi)的原始 episodes 撈出來做二次閱讀。這種兩級(jí)檔案設(shè)計(jì)能平衡壓縮率和信息完整度。遺忘機(jī)制不是一次做完的需要定一個(gè)后臺(tái)任務(wù)定期執(zhí)行我一般設(shè)置每天凌晨跑一次避免影響線上響應(yīng)。4. 三條主流實(shí)現(xiàn)路線與踩坑實(shí)錄4.1 路線 AMemGPT/Letta 式上下文分頁管理MemGPT 的思路是把 LLM 的上下文窗口當(dāng)成主存把外部持久化存儲(chǔ)當(dāng)成磁盤讓模型自己決定什么時(shí)候把某些歷史“換出”到磁盤什么時(shí)候從磁盤“換入”到窗口。這套設(shè)計(jì)在概念上很優(yōu)雅尤其適合單個(gè) Agent 需要連續(xù)運(yùn)行很久、但注意力有限制的場景相當(dāng)于給模型配了一個(gè)自動(dòng)內(nèi)存管理器。但實(shí)際踩下來有幾個(gè)坑。第一個(gè)是模型自己管理頁面置換穩(wěn)定性不穩(wěn)定。模型偶爾會(huì)出現(xiàn)“把重要約束換出去了卻把無關(guān)歷史保留”的烏龍決策因?yàn)樗鼈儗?duì)注意力的自我感知并不精確。第二個(gè)是調(diào)試?yán)щy當(dāng) Agent 行為異常時(shí)很難判斷是“該換入的記憶沒換入”還是“換入后模型沒讀懂”。這套方案適合喜歡折騰、愿意接受不確定性、有足夠精力做行為分析和 prompt 調(diào)優(yōu)的團(tuán)隊(duì)不適合指望開箱即用的業(yè)務(wù)方。4.2 路線 BMem0 / LangMem 式記憶提取管理Mem0 和 LangMem 這類框架走的是另一條路線不依賴模型自己管內(nèi)存而是在每次對(duì)話之后用額外的抽取步驟將對(duì)話中的高價(jià)值信息提煉成記憶存到 SQLite、向量庫或圖數(shù)據(jù)庫下一次對(duì)話時(shí)按用戶上下文檢索并注入。這套方案最大的優(yōu)勢(shì)是可控性強(qiáng)記憶寫入、更新、檢索都是顯式的你可以單獨(dú)觀測(cè)每一環(huán)的質(zhì)量。我實(shí)際用它落地過類似系統(tǒng)的簡化版踩過最深的坑是“記憶污染”。假如用戶最開始說“我喜歡在京東買東西”過一個(gè)星期又改成“我最近主要在拼多多買”如果記憶系統(tǒng)只做追加不做更新模型檢索時(shí)就會(huì)同時(shí)拿到兩條沖突記憶然后隨機(jī)選擇一個(gè)執(zhí)行。解決辦法是在抽取階段就要識(shí)別“用戶糾正了先前的偏好”這一類操作主動(dòng)把舊記憶置為失效或刪除只保留最新版本。這一點(diǎn)最好不要依賴模型讀上下文時(shí)自動(dòng)發(fā)現(xiàn)而是在檢索結(jié)果注入時(shí)做一次沖突檢測(cè)一旦發(fā)現(xiàn)同類型同屬性但值不同的記憶立刻把舊的那條降權(quán)。4.3 路線 C知識(shí)圖譜式記憶與關(guān)系推理知識(shí)圖譜式記憶適合信息之間強(qiáng)關(guān)聯(lián)、需要多跳推理的場景比如企業(yè)知識(shí)庫、法律咨詢 Agent、客戶關(guān)系管理。你要記錄“用戶 A 是公司 B 的采購負(fù)責(zé)人公司 B 曾經(jīng)因?yàn)榘l(fā)貨延遲投訴過產(chǎn)品 C”這種復(fù)雜關(guān)系靠向量庫很難表達(dá)Graphiti 和 Zep 這類框架會(huì)直接把記憶建模成節(jié)點(diǎn)和邊。但這條路的成本最高。建圖需要做實(shí)體抽取、關(guān)系抽取、去重、消歧每一步都可能出錯(cuò)而且圖查詢本身對(duì)開發(fā)者的技術(shù)棧要求更高。我見過不少團(tuán)隊(duì)辛辛苦苦建了圖譜最后發(fā)現(xiàn) Agent 回答問題時(shí)根本用不上因?yàn)闄z索入口太復(fù)雜。我的建議是如果當(dāng)前場景用“向量庫 關(guān)系表”已經(jīng)能解決就暫時(shí)不要上圖譜。知識(shí)圖譜是記憶架構(gòu)后期的進(jìn)階選擇不該是第一版的技術(shù)棧。4.4 選型實(shí)操對(duì)照下面這張表是我在項(xiàng)目里用來做技術(shù)選型的一個(gè)簡版判斷表直接照著看就夠判斷維度上下文分頁Letta記憶提取Mem0 式知識(shí)圖譜Graphiti 式適合場景單 Agent 超長會(huì)話多數(shù)業(yè)務(wù) Agent強(qiáng)關(guān)系推理場景實(shí)現(xiàn)復(fù)雜度中低-中高可控性中高中記憶更新與糾錯(cuò)較弱強(qiáng)中調(diào)試難度高低高我推薦的優(yōu)先級(jí)有精力再玩第一版優(yōu)先后期按需引入5. 最小改造方案給已有 Agent 接上外部記憶5.1 第一步先用 Prompt 模擬記憶寫出如果不想一上來就接一堆框架可以先做最小閉環(huán)在 Agent 的系統(tǒng)提示詞里增加一段“記憶管理指令”要求模型在每次生成完正式回復(fù)后額外輸出一個(gè) JSON 塊里面包含需要新增、更新、刪除的記憶。比如這樣請(qǐng)?jiān)谀忝看位貜?fù)之后輸出一個(gè) memory_commands 字段 { memory_commands: [ {op: create, type: preference, content: 用戶更喜歡郵件聯(lián)系, importance: 4, metadata: {}}, {op: update, type: preference, target: old_content_hash, content: 用戶更改為優(yōu)先微信聯(lián)系, importance: 4} ] }這一步的關(guān)鍵作用是讓你先驗(yàn)證“記憶提取”這個(gè)環(huán)節(jié)是否靠譜。把模型輸出的 JSON 解析后先不做任何存儲(chǔ)只打印到日志連續(xù)跑一兩天觀察它抽取的內(nèi)容是否正確、有沒有幻覺、有沒有漏掉關(guān)鍵約束。很多人會(huì)跳過這一步直接上數(shù)據(jù)庫結(jié)果后面所有問題都分不清是提取的錯(cuò)還是檢索的錯(cuò)。先有了可靠的提取再談存儲(chǔ)和檢索。5.2 第二步把記憶落庫并按需檢索等到你覺得提取質(zhì)量可以接受再把它落到本地存儲(chǔ)。最簡單的組合是 SQLite 存結(jié)構(gòu)化字段再加一個(gè)輕量向量庫存 embedding或者干脆本地跑一個(gè)嵌入模型 FAISS。寫入時(shí)注意每條記憶都帶上 user_id 和 session_id這是多用戶 Agent 絕對(duì)不能省的字段。檢索時(shí)構(gòu)造一個(gè)“記憶上下文塊”注入到系統(tǒng)提示詞里不要直接拼原文。我建議在注入前加一條指令告訴模型“以下內(nèi)容是從記憶庫中檢索到的歷史信息可能與當(dāng)前對(duì)話不完全一致請(qǐng)優(yōu)先相信用戶在當(dāng)前對(duì)話中的最新表達(dá)”。這句話能顯著降低錯(cuò)誤記憶和用戶最新意圖之間的沖突率。檢索注入模板不需要花哨但順序要固定先全局約束再用戶偏好再相關(guān)歷史事件最后是業(yè)務(wù)知識(shí)。5.3 第三步加一個(gè)定時(shí)遺忘與整合任務(wù)就算記憶庫只有幾百條沒過多久也會(huì)出現(xiàn)重復(fù)、過期和低價(jià)值內(nèi)容。如果你前面已經(jīng)跑通了“抽取—存儲(chǔ)—檢索”那么接下來唯一能讓系統(tǒng)長期維持穩(wěn)定的就是遺忘與整合任務(wù)?？梢杂靡粋€(gè)每天凌晨兩點(diǎn)運(yùn)行的 cron對(duì)所有超過 30 天且重要度低于 3 的記憶做歸檔同時(shí)對(duì)同一個(gè)“主題標(biāo)簽”下大于 20 條的記憶觸發(fā)一次摘要整合。這個(gè)過程里最容易犯的錯(cuò)是拿線上業(yè)務(wù)庫直接跑批量刪除。我吃過虧因?yàn)閿?shù)據(jù)量上去了一次 delete 操作會(huì)把還在被引用的記憶也清掉導(dǎo)致第二天 Agent 行為突然失憶。正確做法是加一個(gè) archived 標(biāo)記字段先把過期記憶置為非活躍狀態(tài)觀察幾天確認(rèn)沒有副作用后再物理清理。這個(gè)“軟刪除”習(xí)慣在記憶系統(tǒng)里特別重要。6. 我最終會(huì)怎么選一份實(shí)戰(zhàn)決策清單6.1 什么時(shí)候堅(jiān)決不升上下文先做外部記憶以下情況我基本不會(huì)靠擴(kuò)窗口去硬扛Agent 需要長期服務(wù)同一批用戶用戶的歷史偏好和約束會(huì)影響每一次決策Agent 會(huì)跨會(huì)話恢復(fù)狀態(tài)今天中斷的流程明天還要繼續(xù)業(yè)務(wù)對(duì)成本敏感而請(qǐng)求量很大用戶的反饋需要被記憶實(shí)時(shí)更新比如“我改主意了以后不要再發(fā)短信”。只要命中兩條以上就說明你需要的是一個(gè)記憶系統(tǒng)而不是更大的窗口。6.2 什么時(shí)候確實(shí)可以依賴更大窗口外部記憶也不是銀彈。如果 Agent 本身是單次任務(wù)型比如“讀一份合同提取重點(diǎn)”“分析一篇長文”上下文窗口大一點(diǎn)確實(shí)方便因?yàn)檫@時(shí)候信息都在當(dāng)前輸入里不需要跨會(huì)話追蹤。還有代碼補(bǔ)全、長篇翻譯這類場景窗口帶來的是直接收益。另外如果團(tuán)隊(duì)完全沒有時(shí)間維護(hù)記憶鏈路只有一個(gè)低頻內(nèi)部工具那直接用大窗口臨時(shí)撐住也比上一套沒人維護(hù)的記憶系統(tǒng)更穩(wěn)妥。6.3 用成本賬單說服團(tuán)隊(duì)一個(gè)簡單算式我在給團(tuán)隊(duì)做方案評(píng)審時(shí)最常用的說服方式不是講架構(gòu)理論而是算錢。假設(shè)模型輸入價(jià)格是 0.15 美元每百萬 token一個(gè) Agent 每次調(diào)用塞入 60k 歷史 token執(zhí)行一次完整任務(wù)平均要調(diào)用 8 次模型。那么一次任務(wù)的輸入成本是 60000 × 8 / 1000000 × 0.15 0.072 美元。如果每天服務(wù) 5000 個(gè)任務(wù)一個(gè)月就是 0.072 × 5000 × 30 ≈ 10800 美元。而如果走外部記憶每次檢索只注入 2k token 的記憶上下文同樣 8 次調(diào)用輸入成本降為 0.0024 美元每任務(wù)一個(gè)月大約 360 美元。差距接近三十倍足夠說服絕大多數(shù)預(yù)算決策人。這套記憶系統(tǒng)架構(gòu)設(shè)計(jì)的核心思路其實(shí)很簡單別把模型當(dāng)成一個(gè)無限記憶體承認(rèn)它的上下文窗口只是工作臺(tái)然后把記憶拆成寫入、索引、檢索、遺忘四個(gè)環(huán)節(jié)用工程手段把“該記的記住、該忘的忘掉、該更新的更新”。我自己做第一版記憶系統(tǒng)時(shí)也走過彎路最早以為向量庫存了就萬事大吉后來發(fā)現(xiàn)沒有抽取、沒有元數(shù)據(jù)過濾、沒有沖突更新向量庫存得越多反而越擾亂 Agent 的判斷。如果你正在被“上下文窗口再大一點(diǎn)”的幻覺困擾我給的最實(shí)在的建議是反著來先把你的歷史對(duì)話交給一個(gè)抽取模型試著提煉 100 條結(jié)構(gòu)化記憶看看這些記憶能不能支撐 Agent 做出比“全文塞入”更穩(wěn)定的決策。能支撐住說明你已經(jīng)踏上了一條正確路線不能支撐問題大概率出在抽取質(zhì)量而不是記憶容量。