- tags
- [AI, Agent, 记忆, Google, 托管服务, 第三方方案]
- created
- 2026-04-28
- updated
- 2026-04-28
- sources
- [raw/notes/google-memory-bank-research-2026-04-28.md, raw/notes/google-agent-platform-research-2026-04-28.md, https://cloud.google.com/blog/products/ai-machine-learning/vertex-ai-memory-bank-in-public-preview, https://docs.cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/memory-bank/overview, https://arxiv.org/abs/2503.08026, https://aclanthology.org/2025.acl-long.413/, https://docs.cloud.google.com/agent-builder/agent-engine/memory-bank/iam-conditions]
本词条在父平台中的位置:Memory Bank 是 Google Gemini Enterprise Agent Platform Scale 柱的子组件之一(与 Agent Runtime / Agent Sandbox / Memory Profiles / Agent Sessions 等并列)。本词条 2026-04-28 首次摄取时调研聚焦在 Memory Bank 单组件,把局部当整体处理;同日补摄取父概念后此说明加入。父平台共 4 pillars × 18 组件(Build / Scale / Govern / Optimize)+ 跨切组件 + 配套 TPU 8t/8i 硬件——完整骨架见父概念页。
Memory Profiles 关系澄清:Memory Profiles 是 Memory Bank 的子能力(schema-based structured profiles 用于低延迟召回),不是平行 Scale 柱组件——本词条之前未明确这层。
定义¶
Google 在 Vertex AI Agent Engine 下推出的托管 Agent 长期记忆服务。2025-07-08 公开预览,2025-12 前后 GA,2026-04-22 Cloud Next 上随 Vertex AI 整体改名 Gemini Enterprise Agent Platform 后正式名称为 Agent Platform Memory Bank(详见 google-agent-platform)。算法根基是 ACL 2025 论文 In Prospect and Retrospect: Reflective Memory Management for Long-term Personalized Dialogue Agents(arxiv 2503.08026)提出的 RMM = Reflective Memory Management 机制。
本词条记录 Memory Bank 的技术形态和它与 sentino-memex / auto-memory / mem0 的对比——是 Sentino 销售姿态需要回答的第二个第三方对照样本(mem0 之外)。与 Memex 同为"后台流水线 + 异步提取"路线,差异在 topic 预定义 + 强制绑 Gemini + scope/IAM 治理内置。
为什么这条值得独立成页¶
Memory Bank 不是 mem0 的轻微变体——它是 mem0 自承 4 大未解问题(staleness / privacy / consent / cross-session identity)里至少 2 个被 Google 给出内置答案的"托管路线代表"。客户面对"我能否用 Memory Bank 替代 Memex" 问题的频率会越来越高,比 mem0 更难回答(mem0 路线代际不同可以差异化,Memory Bank 路线相同必须用具体差异点)。
时间线¶
| 时间 | 事件 |
|---|---|
| 2025-03-11 | RMM 论文 v1 上 arxiv(2503.08026) |
| 2025-07-08 | Memory Bank 在 Vertex AI Agent Engine 下公开预览 |
| 2025-07-28 | RMM 论文 v2 修订 |
| 2025-Q4 | ACL 2025 Vienna 长论文发表(pp 8416-8439) |
| ~2025-12 | Memory Bank + Agent Engine Sessions 一起 GA |
| 2026-04-22 | Google Cloud Next(Las Vegas),Vertex AI 改名 Gemini Enterprise Agent Platform,Memory Bank 正式名称改为 Agent Platform Memory Bank |
| 2026-06-24 | Vertex AI SDK deprecated 模块停止更新 |
算法根基:RMM(Reflective Memory Management)¶
ACL 2025 长论文,Google Research 主导,16 位作者。
解决两个文献痛点: 1. Rigid memory granularity:传统记忆方案在固定粒度上摘要,导致语义结构碎片化 2. Fixed retrieval mechanisms:传统检索策略不适应不同对话上下文和用户交互模式
RMM 的双反射机制:
- Prospective Reflection(前瞻性反射):在 utterance / turn / session 三个粒度做摘要写入个人化 memory bank。"动态摘要 across granularities"
- Retrospective Reflection(回顾性反射):基于 LLM 引用证据用 online RL 迭代优化检索策略
LongMemEval 上 +10%(vs 无记忆基线)。论文不公开 vs mem0 / MemGPT 横向对比数。
系统架构¶
二层结构¶
- Agent Engine Sessions(短期):每次会话存 chronological events
- API:
CreateSession/AppendEvent/ListEvents - Memory Bank(长期):跨会话持久化,从 Sessions 异步提取
Topic 类型架构(Managed + Custom 二分)¶
Managed topics(Memory Bank 预定义、label/instructions 由系统给):
| Topic | 内容 | 例 |
|---|---|---|
USER_PERSONAL_INFO |
姓名/关系/爱好/重要日期 | "I work at Google" / "My wedding anniversary is on December 31" |
USER_PREFERENCES |
明示或暗示的偏好 | "I prefer the middle seat" |
KEY_CONVERSATION_DETAILS |
对话里程碑/任务结论 | "I booked plane tickets for a round trip between JFK and SFO" |
EXPLICIT_INSTRUCTIONS |
用户明确要求记住/忘记的内容 | "Remember that I'm allergic to peanuts" |
Custom topics:开发者自定义;建议同时提供 few-shot examples 演示 memory 应该如何提取。
两种写入模式(同一服务两种姿态——Memex 当前没有)¶
GenerateMemories:异步批提取,按可配置 batching 规则触发——与 sentino-memex flush 模式一致CreateMemory:memory-as-a-tool,Agent 显式控制写入时机——与 auto-memory / mem0 一致
这是 Google 把"被动后台提取"和"主动工具调用"两条路线在同一服务下并列。Memex 当前只支持被动提取一种姿态。这是 Memex 在 v2 演进时可考虑的设计点——不是因为 Memory Bank 这么做就要跟,而是两种写入姿态分别覆盖不同 agent 行为模式(被动学习用户 vs 显式记某事),合并成一个服务的工程负担可控。
检索路径¶
- Simple Lookup:拉所有事实(与 Memex
<500 active gists全量返回类似) - Similarity Search:embedding 检索,按 scope 隔离
Scope(多租户隔离)¶
- Scope 是 arbitrary dictionary,开发者自定义键值对
- 例
{user_id: '123'}或{user_id: '123', session_id: '456'}做 session 级 vs user 级隔离 - 同一 scope 内的 memories 才参与 consolidation —— 跨 scope 不会合并
- 可按 scope keys 分别配置不同的 customization(session 级和 user 级用不同 topics)
比 Memex 的 userId × projectId 二维固定隔离更灵活——Memex 在多客户白标场景下可能需要演进到 arbitrary dict scope。
IAM(治理层,Memex 没有内置对应物)¶
- 默认 project-level IAM
- IAM Conditions 控 memory 资源细粒度访问
- API attribute
aiplatform.googleapis.com/memoryScope+ Common Expression Language 表达式 - 专用角色:
memoryViewer/memoryEditor/memoryUser防止过度授权 - 最佳实践警告:positive condition(等于 / 存在性)优先,negative condition 在空 scope 下可能错误匹配宽范围资源
- 通用角色:
roles/aiplatform.user
抗膨胀机制¶
| 机制 | Memory Bank | Memex 对应物 |
|---|---|---|
| TTL 自动过期 | 按秒级配置,可设 GENERATE_UPDATED_TTL 续期 |
4 级 TTL(CORE/IMPORTANT/NORMAL/TRIVIAL)+ forgetAt |
| Contradiction 自动合并 | Gemini 自动 resolution + consolidation | 夜间 3 AM 定时任务 + Reinforce |
| 多模态理解 | 内置(处理多模态输入生成文本 insight) | 无 |
| Memory revisions 可审计 | 内置(看记忆如何因新事实被修改)+ IAM 可控 | DB 直查 |
框架支持¶
- ADK(Agent Development Kit)一等公民:
VertexAiMemoryBankService是默认接入方式 - LangGraph + CrewAI:通过 API 调用形态支持,GitHub 提供示例 notebook
- Express Mode:Gmail 注册即用 API key(免费额度),可平滑升级到 GCP project
与 Sentino Memex / Auto Memory / mem0 的对比矩阵¶
| 维度 | google-memory-bank | auto-memory | sentino-memex | mem0 |
|---|---|---|---|---|
| 部署形态 | 托管服务(GCP) | 本地文件系统 | 自建 Spring Boot 服务 | 开源库 + 托管 |
| 写入主体 | 后台流水线 + Gemini,或 Agent 显式(两种姿态并列) | LLM 对话中主动 Write | 后台流水线 | LLM 决策 ADD/UPDATE/DELETE/NONE |
| 写入策略 | 异步批提取 + 4 managed + custom topics | 严格、少而精 | 4 级 TTL + Reinforce + 三段流水线 | ADD-only(默认) |
| 检索 | similarity search + scope 过滤 / simple lookup | 文件全量 + system-reminder | <500 active 全量纯文本 | 向量检索 |
| 抗膨胀 | TTL + Gemini 自动 contradiction 合并 | 控写入边界 | 4 级 TTL + 夜间合并 + Reinforce | filter / decay(需配置) |
| 多租户 | scope(arbitrary dict)+ IAM Conditions | cwd 路径 | userId × projectId | metadata filter |
| 时序建模 | 多粒度 reflection(utterance/turn/session) | 无 | 4 级重要度 + forgetAt | 弱(官方自承) |
| 审计性 | memory revisions 可审计 + IAM 可控 | git diff | DB 直查 | 弱 |
| 模型绑定 | 强制绑 Gemini | LLM 无关 | LLM 无关(可换) | LLM 无关 |
| 路线判断 | 托管路线代表 | 文本结构化 + 大模型自判 | 文本结构化 + 大模型自判 | 向量检索路线 |
Memory Bank 把 mem0 的 4 大未解问题给了几个内置答案¶
mem0 官方《State of AI Agent Memory 2026》自承的 4 大未解问题:
| mem0 自承未解 | Memory Bank 内置答案 | 完成度 |
|---|---|---|
| Staleness detection | TTL 自动过期 + GENERATE_UPDATED_TTL 续期 | ✅ 直接答 |
| Privacy governance | IAM Conditions + 专用角色 + scope 隔离 | ✅ 直接答 |
| Consent frameworks | EXPLICIT_INSTRUCTIONS topic + memory revisions 可见 | ⚠️ 部分(有机制但需自己组合) |
| Cross-session identity resolution | Scope arbitrary dict 间接支持 | ⚠️ 部分(不是开箱即用) |
→ mem0 作为"行业代名词"的稳定性会被挤压。但短期内(半年到一年)mem0 在开源社区的代名词地位还在——客户 PRD 写 mem0 仍主要是行业代名词,不是已选型 Memory Bank。
与 Sentino Memex 的差异化清单¶
Memex 仍保留的差异化(Memory Bank 不具备或路径不同):
- Reinforce 机制是 prompt 主动指向已有 gist——Memory Bank 的 GENERATE_UPDATED_TTL 是被动 update 后续期,方向不同
- 4 级 TTL × 4 类内容的二维结构——Memory Bank 是 topic 一维(managed + custom),重要度和内容类型混在一个轴
- 夜间合并是显式定时任务——Memory Bank 没有显式合并任务,靠 Gemini 自动 contradiction resolution(类比 auto-dream 整合机制)
- 不绑 LLM 厂商——Memex 可换 Gemini / Claude / GPT / 国产;Memory Bank 强制 Gemini,对客户多模型策略是约束
- 可深度定制——Spring Boot 服务可改算法、加字段、调阈值;Memory Bank 是托管服务,自定义边界由 topic API 给定
- 数据主权——客户数据合规要求高的场景下 Memory Bank 数据在 GCP 是问题,Memex 自建可控
Memex 失去的"代际差异化"(Memory Bank 与 Memex 同路线): - ❌ "向量检索 vs 文本结构化"——Memory Bank 也走文本结构化路线 - ❌ "后台流水线 vs LLM-in-the-loop"——Memory Bank 也走后台流水线 - ❌ "TTL 自动遗忘"——Memory Bank 也有 TTL
→ 销售姿态调整:sentino-memex-positioning 销售材料应当增加 Memory Bank 列(不只是 mem0 单一对照),并把差异化论点从"路线代际"调整为"自主可控 + 不绑模型 + Reinforce + 4×4 二维 + 数据主权"。
对 Sentino Memex 演进的具体启示¶
Memory Bank 设计中值得 Memex 考虑借鉴的点(不是必须跟,是设计选项):
- 两种写入姿态并列(GenerateMemories + CreateMemory)——Memex v2 可考虑增加 memory-as-a-tool 入口,让 agent 在某些场景显式写记忆(如用户说"记住这件事")
- Scope 是 arbitrary dict 而非二维固定——Memex 在多客户白标场景下可能需要演进到 arbitrary dict scope(不只是 userId × projectId)
- Memory revisions + IAM 可审计——客户合规要求场景下,Memex 需要补可审计层(DB 直查不够,需要 API 层暴露 revision 历史)
- Topic 概念化——Memex 当前的 4 类(event / info / schedule / ai_insight)和 Memory Bank 的 4 个 managed topics 概念近似,可对照看是否漏了重要 topic 类型
完整研究链路:→ 2026-04-28-memex-v2-design-options(4 个借鉴点的工程拆解 + 排期建议 P1/P2/P3 + 反建议 + 4 项不变量不应触及)
何时用 Memory Bank 是合理选择¶
- 客户已深度用 GCP 全栈(Gemini API + Vertex AI + Workspace),Memory Bank 是该栈的一等公民
- 不希望自建记忆服务、不需要深度定制
- ADK 框架开发的 agent,Memory Bank 是默认接入
- 需要内置 IAM/audit 治理且不愿自己实现的合规场景
不适合用 Memory Bank 的场景¶
- 多模型策略(不愿被绑定 Gemini 一家)
- 数据主权要求(客户数据不能进 GCP)
- 需要深度定制 TTL / 重要度算法 / 合并策略
- 需要 Reinforce 这种"主动续期已有记忆"机制
- 单用户低频对话场景(auto-memory Claude Code 路线更合适)
待观察¶
- Memory Bank GA 后的实际企业客户案例(Google 公布的 case studies 多大规模?)
- LongMemEval 之外的横向 benchmark(vs mem0 / MemGPT 实测对比)
- ADK 在企业内的渗透率——决定 Memory Bank 是否成为"企业级 Agent 记忆"事实标准
- 2026 内是否有"开源 RMM 实现"出现(论文公开,复现门槛中等)
相关概念¶
- google-agent-platform — 父平台:Memory Bank 是 Scale 柱的子组件之一;父页含 4 pillars × 18 组件完整骨架 + Sentino 战略含义
- sentino-memex — 同路线(后台流水线 + 异步提取 + 抗膨胀)的自建对照,Memex 是 Memory Bank 的"自建版"
- auto-memory — 反向路线:单姿态(LLM-in-the-loop)+ 严格写入边界 + 本地文件
- auto-dream — Memory Bank 的 "Gemini 自动 contradiction resolution + consolidation" 对应 Auto Dream 整合机制
- mem0 — 路线不同(向量检索)但同为第三方方案,Memory Bank 把 mem0 自承的 4 大未解问题给了部分内置答案
- harness-engineering — Memory Bank 是 Harness Environment 层的托管化版本("记忆系统"组件外包给厂商)
- process-data-vs-output-data — Memory Bank 4 个 managed topics 都属"产出数据"轴(用户偏好 / 对话结论 / 个人信息),未涉过程数据轴
- individual-vs-institutional-ai — Memory Bank IAM/audit/scope 三件套是"组织 AI(Deterministic)"形态的具体落地
- yukai-agora-poc — Memex 首次对外白标客户战;客户从"PRD 写 mem0"到"PRD 写 Memory Bank"的演进路径需销售姿态预警
- sentino-agent — 平台对外定位锚点需补充 Memory Bank 列