Google Cloud 常駐記憶代理取代 RAG 與嵌入，透過 Gemini 3.1 Flash-Lite 上的連續 LLM 整合

Google Cloud 近日在其 generative-ai 官方儲存庫中釋出一項備受關注的參考實作——「Always-On Memory Agent」（常駐記憶代理）。這項設計直接挑戰當前 AI 代理的常見限制：大多數代理在處理完一次請求後就會遺忘上下文，無法持續累積知識。Google Cloud 的解決方案將記憶視為一個持續運行的程序，而非一次性呼叫，並以極簡的架構繞過向量資料庫與嵌入技術，實現真正不中斷的記憶能力。 該代理的核心建立在 Google 的 Agent Development Kit（ADK）與 Gemini 3.1 Flash-Lite 模型之上。選擇 Flash-Lite 的關鍵在於其低延遲與低成本特性，非常適合需要長時間背景運作的工作負載。整個系統既不使用向量資料庫，也不依賴嵌入向量，而是讓 LLM 直接讀取、思考並將結構化記憶寫入 SQLite 資料庫中。這項設計大幅降低了基礎設施的複雜度，也讓代理的記憶管理更加透明且易於追蹤。 從架構面來看，Always-On Memory Agent 採用一個調度器（orchestrator）將所有請求路由至三個專門的子代理，每個子代理各自擁有專屬的工具來讀取或寫入記憶儲存區。第一個是「吸入代理」（IngestAgent），負責處理所有新進內容。它利用 Gemini 的多模態能力，從檔案、圖片、音訊或文字中提取摘要、實體、主題與重要性分數，並將這些結構化記錄寫入記憶表格。範例中展示了吸入代理如何處理包含報告、路線圖、錄音檔與筆記等多種來源的資料，並為每一筆記憶建立索引。 第二個是「合併代理」（ConsolidateAgent），預設每 30 分鐘自動觸發一次。如同人類睡眠中的記憶鞏固過程，它會檢查尚未合併的記憶，尋找其中的關聯，然後將綜合摘要、關鍵洞察與連結寫回資料庫。這項機制讓代理能在無需人為提示的情況下，於閒置時自動深化理解，並產生跨記憶的洞察。例如，示範資料中合併代理發現了多筆記憶之間的關聯，並產出一個關鍵洞察：「下一代 AI 工具的瓶頸在於從靜態 RAG 轉向動態記憶系統。」

第三個是「查詢代理」（QueryAgent），負責回答使用者提問。它會讀取所有記憶以及合併後產生的洞察，再綜合生成回應。重要的是，查詢代理會明確引用所使用的記憶 ID 作為來源，讓使用者能夠追溯資訊的原始出處，大幅提升可信度與可驗證性。在示範中，當使用者問「我應該專注於什麼？」時，查詢代理根據記憶優先級建議先完成成本降低計畫，再解決代理可靠性問題，並指出智慧收件匣的概念驗證了持續性 AI 記憶的需求。 這項實作最引人注目的特色在於其完全捨棄了傳統的 RAG（檢索增強生成）與嵌入向量。Google Cloud 選擇以純 LLM 驅動的方式管理記憶，不僅降低了運算成本，也避免了向量資料庫的維護與延遲問題。對於需要長期記憶、多輪對話或知識累積的應用場景，例如個人助理、企業知識庫或自主研究代理，Always-On Memory Agent 提供了一個輕量而強大的參考架構。 值得注意的是，該代理的設計強調「持續性」而非「一次性」。它被設計為 7x24 小時不間斷的背景程序，能夠在執行過程中不斷吸入、合併與查詢資訊。這與傳統的 LLM 呼叫模式截然不同，後者通常在每次對話中從頭開始或在有限的上下文視窗內操作。Google Cloud 透過這種方式，試圖解決 AI 代理普遍存在的「記憶喪失」痛點，讓代理能夠像人類一樣累積經驗並持續成長。 開發者可以從 Google Cloud 的 generative-ai 儲存庫中取得這份參考實作，並根據自身需求進行調整。由於其依賴的元件僅有 Google ADK、Gemini 3.1 Flash-Lite 與 SQLite，部署門檻相對較低。對於研究人員或企業而言，這項技術不僅展示了如何在不使用向量資料庫的前提下實現有效的記憶管理，也為未來更複雜的自主代理系統提供了一個可複製的基礎。 整體而言，Always-On Memory Agent 代表了 Google Cloud 在 AI 代理記憶領域的一次重要嘗試。它將記憶從被動的儲存轉變為主動的運算過程，並透過合併機制讓代理能夠在背景中自我進化。隨著 AI 代理從單純的問答工具邁向長期協作夥伴，這種持續記憶的能力將成為不可或缺的關鍵技術。