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

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

提出的記憶策略

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

基於模擬的實現

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

總結

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