為長期執行代理構建上下文修剪管道

在大型語言模型（LLM）基礎上構建的現代AI代理被設計為持續執行。因此，它們的對話歷史會無限增長。將整個歷史作為LLM的上下文視窗會導致高昂的令牌成本、延遲瓶頸以及推理能力的下降。構建一個上下文修剪管道可以透過動態管理近期對話記憶來解決這一問題。本文介紹了實現長期執行代理上下文修剪管道的基本原則，並使用完全可訪問且免費執行的本地解決方案，基於開源嵌入模型而非付費API。

提出的記憶策略

經典的代理記憶策略依賴於滑動視窗，會遺忘舊資訊，包括可能關鍵的細節。超越這一方法，可以構建一個選擇性、更智慧的管道，為LLM提供恰好所需的上下文。本質上，上下文可以被修剪為以下基本元素：當前提示（包含使用者的請求或問題）、最近一輪對話（即上一輪輸入-輸出交換，對保持對話連續性至關重要）、以及基於相似度分數的Top-K語義相關匹配（透過向量嵌入檢索與當前提示密切相關的歷史輪次）。對話歷史中不屬於這三者的內容將從活動提示的上下文中丟棄，從而節省計算和記憶體。

基於模擬的實現

我們的示例實現逐步構建了上下文修剪視窗。使用句子變換器模型模擬長期執行管道，並配合模擬的對話歷史。首先，匯入必要的庫並載入預訓練的嵌入模型（all-MiniLM-L6-v2）。然後建立模擬的代理歷史。核心邏輯封裝在prune_context()函式中，該函式接收當前提示、完整互動歷史和要檢索的語義相關輪次數k。函式首先處理基礎情況（歷史太短時返回完整歷史），然後進行語義修剪：嵌入歷史輪次，計算與當前提示的餘弦相似度，排序並選擇Top-K輪次，最後組裝修剪後的上下文。示例中，當使用者詢問“Can we go back to the fleet math?”時，修剪後的上下文包含了與車隊路線效率相關的歷史輪次。

總結

本文展示瞭如何基於模擬的代理對話歷史實現上下文修剪管道，利用語義相似度選擇最相關的上下文部分。這對於長期執行的代理至關重要，有助於減少記憶體使用和計算成本，同時提高效率。