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，通过三个子代理实现摄取、整合和查询，支持多种文件类型，并易于部署和集成。