Google Cloud 的 Always-On Memory Agent：用持續的 LLM 整合取代 RAG 和嵌入，基於 Gemini 3.1 Flash-Lite

Google Cloud 的生成式 AI 儲存庫最近釋出了一個名為 Always-On Memory Agent 的參考實現，旨在解決 AI 代理的“遺忘”問題。傳統 AI 代理通常處理請求後即丟棄上下文，而 Always-On Memory Agent 將記憶視為一個持續執行的程序，從而實現了持久的上下文保持。

Always-On Memory Agent 是一個輕量級的後臺代理，它從不停止執行。基於 Google ADK（Agent Development Kit）和 Gemini 3.1 Flash-Lite 構建，該系統全天候執行，而不是一次性呼叫。值得注意的是，它沒有使用向量資料庫或嵌入技術。相反，一個 LLM 負責讀取、思考並將結構化記憶寫入 SQLite。選擇該模型是為了在持續後臺工作中實現低延遲和低成本。

在架構上，一個編排器將每個請求路由到三個專業子代理之一。每個子代理擁有自己的工具來讀取或寫入記憶儲存。首先，IngestAgent 處理傳入的內容。它利用 Gemini 的多模態能力提取摘要、實體、主題和重要性評分，然後將結構化的記錄儲存到 memories 表中。接下來，ConsolidateAgent 按定時器執行，預設每30分鐘一次。它像睡眠週期一樣，回顧未整合的記憶並發現它們之間的聯絡，然後向資料庫寫入綜合摘要、一個關鍵洞察以及這些聯絡。因此，代理在空閒時無需提示即可構建新的理解。最後，QueryAgent 回答問題。它讀取所有記憶和整合後的洞察，然後綜合生成響應。重要的是，它會引用所使用的記憶 ID 作為來源。

除了文本，IngestAgent 還支援 27 種檔案型別，涵蓋五個類別。只需將任何支援的檔案放入 ./inbox 資料夾，系統就會自動拾取。這些型別包括文本（.txt、.md、.json 等）、影像（.png、.jpg 等）、音訊（.mp3、.wav 等）、影片（.mp4、.webm 等）和文件（.pdf）。

為了說明其優勢，Always-On Memory Agent 與常見的記憶方法進行了對比。與向量資料庫 + RAG 相比，後者被動地儲存嵌入並在檢索時使用，而 Always-On Memory Agent 主動處理記憶。與對話摘要相比，後者丟失細節且無交叉引用，該代理透過整合發現連線。與知識圖譜相比，後者需要手動維護且構建成本高，該代理自動且持續地執行。

實際應用中，該模式適用於任何需要持久且不斷發展的上下文的工作負載。例如，研究助理可以持續攝取 PDF、會議音訊和截圖，後來自行將成本目標與可靠性問題聯絡起來。個人知識庫可以持續吸收筆記、文章和影像，整合後浮現出使用者從未明確連線的主題。支援代理將過去的工單作為結構化記憶儲存，然後引用早期案例回答新問題。

設定過程對於初級工程師來說也很簡單。安裝依賴項、設定 API 金鑰，然後啟動程序。執行後，代理監視 ./inbox 資料夾，每30分鐘整合一次，並在埠 8888 上提供 HTTP API。使用者可以透過 curl 命令傳送文本或查詢。此外，API 還提供 /status、/memories、/consolidate、/delete 和 /clear 等端點。可選地，Streamlit 儀表盤提供攝取、查詢、瀏覽和刪除控制。CLI 標誌可以更改監視資料夾、埠和整合間隔。

總之，Always-On Memory Agent 提供了一種無需向量資料庫或嵌入的持續記憶管理方案，基於 Google ADK 和 Gemini 3.1 Flash-Lite，透過三個子代理實現攝取、整合和查詢，支援多種檔案型別，並易於部署和整合。