1. 從“臃腫”到“精干”一次Agent上下文管理的實戰(zhàn)復(fù)盤最近在折騰一個基于LangChain的智能客服Agent項目遇到了一個典型問題隨著對話輪次增加上下文Context像滾雪球一樣越來越大。每次調(diào)用大模型都得把過去十幾輪甚至幾十輪的對話歷史一股腦塞進去Token消耗直線上升成本看著心疼。更糟的是我發(fā)現(xiàn)Agent的“記憶力”反而變差了——它開始混淆不同用戶的訴求甚至把幾天前的舊指令當(dāng)作當(dāng)前任務(wù)來執(zhí)行出現(xiàn)了典型的“記憶亂竄”現(xiàn)象。這讓我意識到單純地堆疊歷史對話并不是構(gòu)建長期記憶的好方法反而是一種資源浪費和性能負(fù)擔(dān)。于是我啟動了一個代號為“Agent Harness”的優(yōu)化項目目標(biāo)很明確給Agent的上下文“瘦身”。不是簡單地截斷或丟棄而是通過更智能的結(jié)構(gòu)化與壓縮讓有限的Token承載更精準(zhǔn)、更持久的記憶。經(jīng)過幾輪迭代最終實現(xiàn)了Token用量下降約40%同時任務(wù)完成準(zhǔn)確率和上下文關(guān)聯(lián)度顯著提升的效果。這個過程涉及對上下文本質(zhì)的重新思考、多種工程化手段的嘗試以及記憶架構(gòu)的設(shè)計。如果你也在為Agent的上下文膨脹和記憶混亂而頭疼希望這篇實戰(zhàn)復(fù)盤能給你帶來一些直接的思路和可操作的代碼。2. 診斷為什么你的Agent上下文會“虛胖”且“健忘”在動手優(yōu)化之前我們必須先搞清楚問題出在哪里。Agent的上下文通常指的是為了完成當(dāng)前任務(wù)需要提供給大模型LLM的所有相關(guān)信息。在對話系統(tǒng)中這幾乎就等于完整的對話歷史。這種設(shè)計簡單粗暴但隱藏著幾個致命缺陷。2.1 Token消耗的“元兇”冗余與低信息密度首先最直觀的問題是冗余。想象一下人類對話我們不會在每次開口前都把之前的對話全文復(fù)述一遍。但在大多數(shù)Agent實現(xiàn)中正是這么做的。用戶問“今天的天氣怎么樣”Agent回答“北京晴15-25度”。五分鐘后用戶又問“那明天呢”標(biāo)準(zhǔn)的做法是把第一輪問答完整地再次輸入。這里面“今天的天氣怎么樣”和“北京晴15-25度”對于回答明天天氣這個問題信息價值極低但它們卻占據(jù)了寶貴的Token。這種逐輪追加的模式使得上下文長度呈線性甚至更快的速度增長。其次是信息的低密度化。自然語言本身就有大量的冗余比如語氣詞、重復(fù)性描述、客套話等。在長上下文中這些低信息密度的內(nèi)容會不斷累積稀釋了真正關(guān)鍵信息如用戶意圖、實體、決策點的濃度。大模型需要花費額外的“注意力”去處理這些噪音影響了核心任務(wù)的表現(xiàn)。2.2 記憶“亂竄”的根源缺乏結(jié)構(gòu)化與隔離記憶混亂是另一個棘手問題。其根源在于平鋪直敘的對話歷史是一種“非結(jié)構(gòu)化”的記憶。當(dāng)Agent需要回答“我上次提到的那個項目進度如何”時它需要在冗長的文本中尋找“項目”這個關(guān)鍵詞并關(guān)聯(lián)到“上次”這個模糊的時間點。這個過程極易出錯可能關(guān)聯(lián)到錯誤用戶的項目或者錯誤時間點的項目。更深層的原因是缺乏記憶隔離。一個服務(wù)于多用戶的Agent其上下文在邏輯上應(yīng)該是多個獨立“會話線程”的集合。但如果簡單地將所有對話拼接不同用戶的信息就會在Token序列中相互“污染”。模型可能會把用戶A對產(chǎn)品的抱怨錯誤地應(yīng)用到用戶B的咨詢中。這就是為什么你的WorkBuddy一個假設(shè)的AI助手的記憶會“亂竄”——因為沒有在底層為不同用戶、不同會話建立清晰的隔離邊界。2.3 重新定義“上下文”從聊天記錄到知識圖譜因此優(yōu)化的第一步是轉(zhuǎn)變思維上下文不等于聊天記錄。上下文應(yīng)該是為完成當(dāng)前任務(wù)所必需的、經(jīng)過提煉的知識狀態(tài)。這引出了兩個關(guān)鍵概念工作記憶Working Memory處理當(dāng)前任務(wù)直接需要的、高度活躍的信息。它應(yīng)該是精簡、聚焦的。長期記憶Long-term Memory存儲歷史經(jīng)驗、用戶畫像、領(lǐng)域知識等。它需要被結(jié)構(gòu)化存儲并能按需精準(zhǔn)檢索而非全量加載。我們的目標(biāo)就是建立一套機制將原始的、冗長的對話流動態(tài)地轉(zhuǎn)化為“工作記憶”“按需檢索的長期記憶”的組合。這正是“上下文工程”的核心。3. 瘦身方案一無損壓縮與智能摘要直接對原始文本進行壓縮是減少Token最立竿見影的方法。這里有幾個層次的操作。3.1 對話輪次合并與關(guān)鍵信息提取不要逐條存儲用戶和AI的發(fā)言。我們可以按“話題”或“意圖”對對話進行分組和摘要。# 示例一個簡單的對話摘要函數(shù) from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI def summarize_conversation_turn(user_input, ai_response, llm): 將一輪對話壓縮為一條結(jié)構(gòu)化記錄。 prompt ChatPromptTemplate.from_messages([ (“system”, “你是一個高效的對話記錄員。請將以下一輪對話提煉成一條簡潔的記錄包含用戶核心意圖、AI回復(fù)的要點、以及涉及的關(guān)鍵實體如人名、地點、任務(wù)名。以JSON格式輸出?！?, (“human”, “用戶: {user_input}\nAI: {ai_response}”) ]) chain prompt | llm result chain.invoke({“user_input”: user_input, “ai_response”: ai_response}) # 假設(shè)LLM返回了合法的JSON字符串 import json summary_record json.loads(result.content) return summary_record # 使用示例 llm ChatOpenAI(model“gpt-3.5-turbo”) record summarize_conversation_turn(“幫我訂一張明天北京飛上海的機票”, “好的已為您查詢。明天上午9點國航CA1501航班有余票經(jīng)濟艙價格1200元。請問需要預(yù)訂嗎”, llm) print(record) # 輸出可能類似{“intent”: “預(yù)訂機票”, “user_query”: “明天北京飛上?！? “ai_action”: “查詢航班CA1501并報價”, “entities”: {“date”: “明天”, “departure”: “北京”, “arrival”: “上海”, “flight”: “CA1501”, “price”: “1200”}}通過這種方式原來需要幾十個Token的一輪對話被壓縮成了一個包含關(guān)鍵信息的JSON對象可能只需要十幾個Token。歷史對話不再是一堆文本而是一個結(jié)構(gòu)化的記錄列表。注意摘要的粒度需要權(quán)衡。過于粗略會丟失細(xì)節(jié)如具體航班號過于詳細(xì)則壓縮效果不佳。通常針對任務(wù)類型設(shè)計不同的摘要模板。3.2 利用大模型自身的上下文窗口管理工具一些先進的大模型API或框架提供了原生的上下文管理功能。例如Anthropic的Claude Code或類似工具可能支持“上下文分層”或“標(biāo)記重要片段”。雖然我們不能直接使用未經(jīng)確認(rèn)的工具但思路可以借鑒在發(fā)送請求前對長上下文進行分析識別出與當(dāng)前問題最相關(guān)的段落并為其添加高權(quán)重標(biāo)記同時將不相關(guān)的段落移至低優(yōu)先級或排除在外。這需要利用LLM本身做一個輕量的預(yù)處理。# 概念性代碼相關(guān)性篩選 def filter_relevant_context(full_history, current_query, llm): 從完整歷史中篩選出與當(dāng)前問題最相關(guān)的部分。 prompt f“”” 給定以下對話歷史和一個當(dāng)前問題請從歷史中選出最直接相關(guān)的1-3輪對話。僅輸出所選對話的索引號從0開始用逗號分隔。 對話歷史 {full_history} 當(dāng)前問題{current_query} “”” response llm.invoke(prompt) relevant_indices [int(i.strip()) for i in response.content.split(‘,’)] relevant_context “\n”.join([full_history[i] for i in relevant_indices]) return relevant_context這個方法可以將萬字符的上下文動態(tài)縮減到千字符以內(nèi)顯著節(jié)省Token。4. 瘦身方案二結(jié)構(gòu)化記憶與向量檢索如果說壓縮是“節(jié)流”那么建立結(jié)構(gòu)化的長期記憶系統(tǒng)就是“開源”。它允許我們存儲海量信息但只在需要時精準(zhǔn)提取徹底告別全量加載。4.1 構(gòu)建記憶圖譜從文本到向量我們不再保存原始對話文本而是將其核心信息轉(zhuǎn)換為向量Embeddings存入向量數(shù)據(jù)庫如Chroma, Pinecone, Weaviate。這就是構(gòu)建Agent的“長期記憶庫”。記憶單元設(shè)計每條記憶不應(yīng)是一整段對話而是一個個細(xì)粒度的“事實”或“事件”。例如“用戶偏好靠窗座位”、“項目A的截止日期是2024-06-01”、“用戶曾反饋過登錄頁面加載慢”。每個單元包含內(nèi)容事實的文本描述。元數(shù)據(jù)來源會話ID、用戶ID、時間戳、類型偏好、事實、任務(wù)等、重要性分?jǐn)?shù)。向量內(nèi)容的嵌入表示。存入向量庫當(dāng)一輪對話被摘要和結(jié)構(gòu)化后將其拆解成多個記憶單元生成向量并存入數(shù)據(jù)庫。from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings() vectorstore Chroma(embedding_functionembeddings, persist_directory“./mem_db”) def create_memory_units(summary_record, session_id, user_id): units [] # 示例從摘要記錄中創(chuàng)建多個記憶單元 if “entities” in summary_record: for key, value in summary_record[“entities”].items(): content f“用戶提到了{(lán)key}: {value}” metadata {“session_id”: session_id, “user_id”: user_id, “type”: “entity”, “source”: “conversation”} # 這里可以更精細(xì)地處理比如“預(yù)訂機票”作為一個意圖單元 units.append({“content”: content, “metadata”: metadata}) # 將意圖也作為一個單元 intent_content f“用戶意圖是: {summary_record.get(‘intent’, ‘N/A’)}” units.append({“content”: intent_content, “metadata”: {“session_id”: session_id, “user_id”: user_id, “type”: “intent”}}) return units def store_memories(units, vectorstore): texts [u[“content”] for u in units] metadatas [u[“metadata”] for u in units] vectorstore.add_texts(textstexts, metadatasmetadatas)4.2 精準(zhǔn)檢索讓記憶“隨用隨取”當(dāng)新的用戶查詢到來時我們不再拼接全部歷史而是將當(dāng)前查詢轉(zhuǎn)換為向量。在向量數(shù)據(jù)庫中嚴(yán)格限定檢索范圍例如通過元數(shù)據(jù)過濾session_id和user_id搜索最相關(guān)的K條記憶。將這些檢索到的記憶作為“補充上下文”或“長期記憶片段”與當(dāng)前的“工作記憶”即最近一兩輪對話一起構(gòu)成最終的提示詞。def retrieve_relevant_memories(query, vectorstore, session_id, user_id, k5): # 關(guān)鍵使用元數(shù)據(jù)過濾器實現(xiàn)記憶隔離 filter_dict {“session_id”: session_id, “user_id”: user_id} relevant_docs vectorstore.similarity_search(query, kk, filterfilter_dict) # 將檢索到的記憶文本組合起來 memory_context “\n”.join([doc.page_content for doc in relevant_docs]) return memory_context這種方法完美解決了“記憶亂竄”。因為檢索時通過session_id和user_id進行了強制隔離用戶A的記憶絕不會出現(xiàn)在用戶B的上下文中。同時由于只檢索相關(guān)的幾條記憶上下文的長度是可控的通常只有幾百個Token而不是幾千個。4.3 關(guān)于向量庫中詞義統(tǒng)一的思考在構(gòu)建記憶單元時一個常見問題是像“上下文理解”和“語境推測”這類意思相近的詞需要統(tǒng)一嗎我的經(jīng)驗是不需要強制統(tǒng)一但可以增強關(guān)聯(lián)。大模型的嵌入模型如OpenAI的text-embedding-3本身對同義詞和近義詞就有很好的語義捕捉能力?！吧舷挛睦斫狻焙汀罢Z境推測”的向量在空間上應(yīng)該是接近的。當(dāng)你用其中一個查詢時很可能也會檢索到另一個。如果你追求極致的精確度可以做一些后處理同義詞擴展在檢索時不僅用原始查詢也用其同義詞進行查詢合并結(jié)果。知識圖譜關(guān)聯(lián)在元數(shù)據(jù)中記錄這兩個概念是相關(guān)的但這會引入額外的復(fù)雜度。對于大多數(shù)應(yīng)用相信嵌入模型的能力就夠了。過度工程化反而可能引入新的問題。5. 瘦身方案三記憶的分層、衰減與更新人的記憶是會遺忘的Agent的記憶也應(yīng)該有生命周期。一個只增不減的記憶庫最終會變得臃腫且充滿過時信息。5.1 設(shè)計三層記憶架構(gòu)我借鑒了認(rèn)知科學(xué)中的一些概念為Agent設(shè)計了一個簡單的三層記憶架構(gòu)感官記憶/工作記憶保存當(dāng)前正在處理的對話輪次最近1-3輪。信息鮮活但容量極小隨著對話推進快速被覆蓋或轉(zhuǎn)移到下一層。短期記憶存放近期活躍的、與當(dāng)前會話高度相關(guān)的記憶單元通過向量檢索得到。這些是當(dāng)前任務(wù)的“背景板”會話結(jié)束后其活性會逐漸降低。長期記憶向量數(shù)據(jù)庫中存儲的所有記憶單元。容量大但信息處于“休眠”狀態(tài)需要時通過檢索激活。在每次交互中Agent的上下文主要由“工作記憶”和“短期記憶”即檢索結(jié)果構(gòu)成長期記憶庫是背后的支撐。5.2 實現(xiàn)記憶衰減與重要性加權(quán)不是所有記憶都同等重要。我們可以為每個記憶單元引入“重要性”分?jǐn)?shù)和“最后訪問時間”。重要性可以在創(chuàng)建時由LLM初步判斷例如用戶明確說“這很重要”也可以根據(jù)后續(xù)被檢索到的頻率動態(tài)更新。高頻被檢索的記憶重要性提高。最后訪問時間每次該記憶被檢索到就更新這個時間戳。我們可以定期運行一個“記憶整理”后臺任務(wù)def cleanup_memories(vectorstore, decay_factor0.9, retention_threshold0.1): # 這是一個概念性函數(shù)實際實現(xiàn)可能需要遍歷所有記憶 # 模擬衰減邏輯新分?jǐn)?shù) 舊重要性分?jǐn)?shù) * decay_factor # 如果分?jǐn)?shù)低于retention_threshold則考慮歸檔或刪除 pass通過這種機制長期不用的、不重要的記憶會逐漸“淡出”從而控制記憶庫的總規(guī)模和質(zhì)量。對于關(guān)鍵記憶如用戶的核心偏好可以通過手動標(biāo)記或高頻訪問保持其高重要性避免被衰減。5.3 記憶的更新與沖突解決當(dāng)新信息與舊記憶沖突時怎么辦例如用戶之前說“我喜歡藍(lán)色”現(xiàn)在又說“我其實更喜歡綠色”。時間戳優(yōu)先最簡單的策略是相信最新的信息。在存儲新記憶“喜歡綠色”的同時可以降低舊記憶“喜歡藍(lán)色”的重要性分?jǐn)?shù)或在元數(shù)據(jù)中標(biāo)記其為“已過時”。事實融合對于更復(fù)雜的情況可以引入一個“記憶融合”步驟。當(dāng)檢測到?jīng)_突時觸發(fā)一個LLM調(diào)用分析這兩條記憶生成一條更準(zhǔn)確的新記憶例如“用戶對顏色的偏好可能從藍(lán)色轉(zhuǎn)變?yōu)榱司G色或視上下文而定”然后替換或補充舊記憶。6. 工程集成打造Agent Harness框架將上述所有策略組合起來就需要一個輕量的框架來“駕馭”HarnessAgent的上下文和記憶。這個框架負(fù)責(zé)在每次調(diào)用LLM前智能地組裝上下文。6.1 上下文組裝流水線我設(shè)計了一個處理流水線它的工作流程如下輸入當(dāng)前用戶查詢 用戶ID 會話ID。檢索長期記憶用當(dāng)前查詢?nèi)ハ蛄繋鞕z索嚴(yán)格過濾user_id和session_id得到N條相關(guān)記憶。獲取工作記憶從緩存或數(shù)據(jù)庫中取出最近2-3輪原始對話或它們的摘要。生成摘要/壓縮可選如果工作記憶較長可以對其進行一輪壓縮摘要。組裝最終提示將系統(tǒng)指令、檢索到的記憶、壓縮后的工作記憶、當(dāng)前查詢按順序組合成最終的提示詞。調(diào)用LLM發(fā)送組裝好的提示詞獲得回復(fù)。更新記憶將本輪交互的核心信息創(chuàng)建為新的記憶單元存入向量庫。同時更新工作記憶緩存。class AgentHarness: def __init__(self, llm, vectorstore, memory_manager): self.llm llm self.vectorstore vectorstore self.memory_manager memory_manager # 負(fù)責(zé)記憶的存儲、檢索、衰減 def process_query(self, user_query, user_id, session_id): # 1. 檢索相關(guān)長期記憶 long_term_memories self.memory_manager.retrieve(user_query, user_id, session_id) # 2. 獲取工作記憶最近對話 working_memory self.memory_manager.get_working_memory(session_id) # 3. (可選)壓縮工作記憶 if len(working_memory) 3: # 假設(shè)超過3輪則壓縮 working_memory self._compress_working_memory(working_memory) # 4. 組裝提示詞 prompt self._assemble_prompt(system_msg, long_term_memories, working_memory, user_query) # 5. 調(diào)用LLM response self.llm.invoke(prompt) # 6. 更新記憶 self.memory_manager.store_turn(user_id, session_id, user_query, response.content) return response.content6.2 關(guān)鍵配置參數(shù)與調(diào)優(yōu)在實際使用中有幾個參數(shù)對效果影響巨大需要仔細(xì)調(diào)優(yōu)檢索數(shù)量 (k)每次從向量庫取多少條記憶太少可能信息不全太多則引入噪音。通常從3-5條開始測試。工作記憶長度保留最近幾輪原始對話對于需要緊密跟隨上下文的任務(wù)如代碼調(diào)試可能需要3-5輪對于開放式聊天1-2輪可能就夠了。記憶衰減因子決定舊記憶被遺忘的速度。需要根據(jù)業(yè)務(wù)場景調(diào)整。摘要的粒度摘要得太粗會丟失細(xì)節(jié)太細(xì)則壓縮效果差?？赡苄枰獮椴煌愋偷膶υ捲O(shè)計不同的摘要模板。我的經(jīng)驗是建立一個簡單的評估體系在測試集上同時監(jiān)控Token消耗、任務(wù)完成準(zhǔn)確率、以及人工評估的“記憶相關(guān)性”。通過A/B測試找到最適合你場景的參數(shù)組合。7. 實戰(zhàn)效果與避坑指南經(jīng)過上述改造我的智能客服Agent煥然一新。最明顯的效果是平均每次API調(diào)用的Token輸入量下降了約40%因為上下文從完整的“史記”變成了精煉的“摘要”加“相關(guān)史料”。成本壓力驟減。更驚喜的是效果提升。由于記憶檢索是精準(zhǔn)的、隔離的Agent混淆用戶和任務(wù)的情況基本消失。當(dāng)用戶問起“我上次咨詢的那個問題”時Agent能準(zhǔn)確找到對應(yīng)會話中的相關(guān)記憶而不是胡亂抓取一個相似話題。任務(wù)完成的準(zhǔn)確率提升了約15%。當(dāng)然踩坑是必不可少的摘要失真早期使用的摘要Prompt不夠好導(dǎo)致關(guān)鍵信息如訂單號、具體時間丟失。對策設(shè)計Prompt時明確列出必須保留的信息類型。最好能用一批樣本進行測試檢查摘要的保真度。向量檢索不準(zhǔn)當(dāng)用戶使用模糊指代如“那個”、“這東西”時直接檢索效果很差。對策在檢索前先用LLM對當(dāng)前查詢進行一次“查詢重寫”將其擴展成更完整、包含更多實體信息的描述再用這個描述去檢索。記憶更新延遲存入向量庫的記憶并非立即可用于下一次檢索取決于向量化的批次和索引更新策略。對策對于當(dāng)前會話中剛產(chǎn)生的、極其重要的信息可以同時放在工作記憶和一份“臨時記憶緩存”中確保下一輪對話能立刻用到。系統(tǒng)復(fù)雜度增加引入了向量數(shù)據(jù)庫、記憶管理模塊系統(tǒng)架構(gòu)變復(fù)雜了。對策做好模塊化設(shè)計并將記憶相關(guān)的操作封裝成獨立服務(wù)便于維護和升級。這次“瘦身”實踐讓我深刻體會到對于AI Agent而言“更多”并不總是意味著“更好”。尤其是在上下文窗口有限、Token成本高昂的現(xiàn)實約束下如何高效、智能地組織和使用信息比盲目地堆砌信息更重要。通過結(jié)構(gòu)化記憶、精準(zhǔn)檢索和動態(tài)管理我們完全可以讓Agent在更小的“腦容量”下表現(xiàn)出更強大的“記憶力”和“專注力”。這不僅僅是成本的優(yōu)化更是Agent智能體健壯性和實用性的關(guān)鍵一步。