RAG 和向量数据库，这对过去两年 AI 应用落地的黄金搭档，可能正在迎来它们的终结者。
2026年7月，Google Cloud 在它的 generative-ai 仓库里丢进了一个只有几个 Python 文件和一个 SQLite 数据库的参考实现。名叫 Always-On Memory Agent。它的技术主张激进得令人不安：一个 AI 系统不需要向量数据库，不需要 Embedding，不需要 RAG——只需要一个 LLM 持续不断地读、想、写，就能构建出真正可用的长期记忆。
对于过去两年几乎所有 AI 应用都在遵循的“数据→分块→Embedding→向量库→检索→生成”这条铁律来说，这无异于一次直接挑衅。
一个文件，三种智能体，24小时不关机
Always-On Memory Agent 的技术架构并不复杂。它运行在 Google 的 Agent Development Kit 之上，后者是 Google 于 2025 年 4 月在 Cloud NEXT 上开源的多智能体编排框架，已经在 Agentspace、Vertex AI 等产品中承担生产级任务。后端调用的是 Gemini 3.1 Flash-Lite——截至目前 Gemini 系列中成本最低、速度最快的模型，每百万输入 Token 仅 0.25 美元，每百万输出 Token 1.50 美元。
整个系统由三个子智能体构成，由一个编排器统一调度。
IngestAgent 负责处理输入。用户可以把任何格式的文件扔进 ./inbox 目录——文本、图片、音频、视频、PDF——总计支持 27 种文件类型。Gemini 的多模态能力会从中提取出摘要、实体、主题和重要性评分，然后以结构化记录的形式写入 SQLite 数据库的 memories 表。三种方式可以触发摄入：文件监控器自动拾取、Streamlit 仪表盘上传、或者 HTTP API 调用。
ConsolidateAgent 是整个系统的灵魂。它默认每 30 分钟运行一次，像人类大脑在睡眠中重放白天的记忆一样，回顾未整合的记忆，寻找它们之间的关联，生成跨领域的洞察，然后把新的理解写回数据库。这个过程不需要用户输入任何提示词——系统在空闲时自主构建新的认知。GitHub 的 README 里给出了一个生动的例子：当系统同时读到“AI 代理可靠性是个挑战”和“当前 LLM 记忆方法都有缺陷”两条记录时，ConsolidateAgent 会自动生成一条新的洞察——“AI 工具的下一个瓶颈是从静态 RAG 向动态记忆系统的转型”。
QueryAgent 负责回答用户的问题。它读取所有记忆和整合洞察，合成回答，并标注每条信息的来源记忆 ID。不过，它也承认一个限制：当前实现中，查询最多读取最近 50 条记忆。
Gemini 3.1 Flash-Lite 的选择是经过深思熟虑的。这个模型在 2026 年 3 月 3 日发布，5 月 7 日进入 GA 阶段。它的推理能力并不弱——GPQA Diamond 基准上拿到 86.9%，Arena 排行榜 Elo 分数 1432，上下文窗口达到 100 万 Token——但它的核心定位是“成本效率优先”。对于需要 24 小时连续运行的背景进程来说，这是一个性价比几乎量身定做的选择。
RAG 的“被动”困境
过去两年，RAG 已经成为 AI 应用落地的标准范式。开发者把文档切块、Embedding、存入向量数据库，然后在每次查询时做相似度检索，把最相关的片段塞进 LLM 的上下文窗口。
这个思路在运行了两年之后，暴露出的问题越来越明显。
最大的问题是被动性。RAG 是典型的“存一次，查一次”——文档在入库时被 Embedding 一次，之后就再也不会被重新处理。新文档和新信息之间的关联，完全依赖检索时的语义相似度来发现。这意味着系统永远不会主动建立跨文档的认知连接。
其次是信息损耗。分块本身就是一种妥协。一篇 20 页的技术文档被切成 512 Token 的碎片后，原本的结构和层次关系就丢失了。当用户问一个需要跨块推理的问题时，RAG 能做的只是把所有相关碎片塞进上下文，让 LLM 自己去拼——这既浪费 Token，又容易拼错。
还有成本陷阱。向量数据库本身不便宜，特别是当记忆体量达到百万级、千万级时。而且 Embedding 模型、向量检索、上下文拼接共同构成了一个越来越复杂的管线，每增加一个环节，维护成本和故障概率就增加一分。
Google 在 Always-On Memory Agent 的 README 中直接列举了这些痛点：向量 DB 加 RAG 是“被动的”；会话摘要“会丢失细节”；知识图谱“构建和维护成本高昂”。而它的方案——结构化 SQLite 记录加持续 LLM 整合——试图成为那个“像人类大脑一样主动整合信息”的缺失环节。
“持续整合”这个思路，比看起来要深
如果把 Always-On Memory Agent 仅仅看作“一个用 LLM 写 SQLite 的小工具”，那就低估了它的技术意义。
ConsolidateAgent 每 30 分钟运行的“睡眠周期”，实际上是在做一件传统 RAG 完全做不到的事：让 AI 系统在空闲时主动学习和重组知识。
传统 RAG 系统里，知识是静态的。文档入库时是什么样，三个月后还是什么样。新文档进入系统后，除非在检索时恰好与旧文档产生语义重叠，否则它们永远不会被系统视作“有关联”。
而 ConsolidateAgent 的运作方式更像人类的记忆机制：它不只是在存储信息，而是在不断重放、连接、压缩信息。它会在两条看似无关的记忆之间发现联系，然后生成一条新的洞察。这个能力在需要长期知识积累的场景中价值巨大。产品经理的调研笔记、研究员的阅读摘要、咨询顾问的客户访谈记录——如果这些素材只是堆在文件系统里，它们就只是文件。但如果有一个持续运行的智能体在背后不断读、想、关联，它们就会变成一个不断生长的知识网络。
为什么是 Gemini 3.1 Flash-Lite？
选择 Gemini 3.1 Flash-Lite 作为底层模型，本身就是一种战略表态。
这个模型的定价是每百万输入 Token 0.25 美元，仅为 GPT-5.3 Instant 输入价格（1.75 美元每百万）的七分之一。在推理质量上，它却并不含糊：GPQA Diamond 86.9%，Arena 排行榜 Elo 分数 1432，足以胜任结构提取、关联发现和答案合成这类任务。
对于 Always-On Memory Agent 这个场景来说，这个模型几乎是唯一合理的选择。如果一个记忆系统跑在更昂贵的模型上，24 小时连续运行的经济账根本算不过来。而 Gemini 3.1 Flash-Lite 的定价使得“让一个 LLM 每 30 分钟跑一次整合”变得可行。更重要的是，它原生支持多模态输入——文本、图片、音频、视频——这让 IngestAgent 不需要调用额外的模型来处理不同格式的文件，一个模型走完全程。
冲击波：对现有生态意味着什么？
Always-On Memory Agent 的杀伤力，不仅在于它做对了什么，更在于它绕过了什么。
过去两年，围绕 RAG 和向量数据库已经形成了一个庞大的生态：Pinecone、Weaviate、Chroma、Milvus 等向量数据库厂商，LangChain、LlamaIndex 等框架层，以及无数 Embedding 模型服务商。如果“持续 LLM 整合”这条路线被证明在大规模场景下可行，整个 RAG 生态的价值链将被重新评估。
当然，这个方案也有明显的局限性。QueryAgent 最多读取最近 50 条记忆来合成回答。当记忆量级达到数千条甚至数万条时，当前架构无法有效检索深度信息。相比之下，向量数据库在千万级规模下的检索能力仍然是经过验证的。此外，每 30 分钟一次的整合周期意味着知识的更新不是实时的。在需要秒级响应的场景中，这个“睡眠周期”模式可能不够快。
这意味着什么？
Google 的 Always-On Memory Agent 目前只是一个参考实现，MIT 协议开源，任何人都可以克隆、修改、部署。它还不是一个产品，更像是一个技术宣言：AI 系统的记忆不应该被设计成“等你来查”的档案柜，而应该是“一直在想”的思考者。
对于中小团队和个人开发者来说，它提供了一个极其轻量的替代方案。不需要搭建向量数据库，不需要配置 Embedding 管线，不需要维护复杂的 RAG 链路——只需要一个 Gemini API Key、一个 SQLite 文件、一个 Python 进程，就能获得一个 24 小时持续运转的记忆系统。对于大企业来说，这个方案的吸引力在于成本：当记忆体量在百万级 Token 以下时，SQLite 加 Gemini 3.1 Flash-Lite 的组合大概率比任何向量数据库方案都便宜。
当然，这个方案不会也不应该完全取代 RAG。在需要精确检索海量文档的场景中——法律文件审查、代码库搜索——向量数据库的语义检索能力仍然是不可替代的。但在“知识积累和关联发现”这个维度上，Always-On Memory Agent 开辟了一条新的技术路线：AI 系统不再需要被动等待被检索，而是可以在后台主动思考，像人一样闲下来时反而变得聪明。
AI 系统的记忆，终于开始从“存储”走向“思考”了。
快报