Executive Summary¶

2026-04-28 摄取 google-memory-bank 调研后，从 Memory Bank 设计中提炼出 4 个对 sentino-memex v2 演进有参考价值的设计点。本报告对每个借鉴点做工程级拆解（现状 / Memory Bank 做法 / 差异本质 / Memex 实施形态 / 工程量 / 业务驱动力 / 优先级），并给出整体排期建议。

核心结论：

1. 4 个借鉴点没有一个是"看到 Memory Bank 这么做就要跟"——都是 Memex 自身业务驱动的演进方向，Memory Bank 只是给了具体的 API 形态参考。脱离业务需求盲目对标是反模式。

2. 推荐 P1 必做： - ① 两种写入姿态（CreateMemory）+ ④ source 字段（一起做）— 约 1 周 - ③ Revision History API + IAM 分级 — 约 2-3 周

3. 推荐 P2 等触发： - ② Scope arbitrary dict — 触发条件是"第二个 agent 类型接入同一客户"或"多 agent 共享平台"出现

4. 反建议：如果姜涛 / 子昕评估"近 3 个月无合规客户、无多 agent 共享需求"，全部缓做也是合理的——Memex 当前的核心瓶颈大概率不在这 4 项上（更可能是 prompt 质量、Reinforce 命中率、合并算法），借鉴点是"给定有空闲产能时排什么"的问题，不是"必须立即对标"。

5. 业务驱动力最强的是 ③（Revision API + IAM）——合规客户场景的硬卡点。当前 Memex 用 DB 直查糊弄审计，金融 / 医疗 / 政府客户进门第一关就过不了。

缘起¶

2026-04-28 用户做完 Google Memory Bank 网络调研并通过 /ingest 落入知识库后，追问"memex 借鉴点详细说明"。

知识库当时已有的内容（sentino-memex "待观察 / 改进点" 第 5 条 + google-memory-bank "对 Sentino Memex 演进的具体启示"段）只列了 4 个借鉴点的标题级摘要（约 4 行），没有： - 对每个借鉴点做工程级拆解（具体改什么 API / 字段 / 工程量评估） - 优先级排序与业务驱动力对比 - "什么前提下不应该做"的反建议

本报告的目标是把 4 个借鉴点从"概念列表"提升到"姜涛 / 子昕可以直接拿去排期的工程提案"。带作者立场（推荐 P1/P2/P3 + 反建议），不适合写入"中立 concept 页"，因此独立成报告。

4 个借鉴点的原始素材¶

来自 google-memory-bank "对 Sentino Memex 演进的具体启示"段的 4 条原文：

1. 两种写入姿态并列（GenerateMemories + CreateMemory）——Memex v2 可考虑增加 memory-as-a-tool 入口，让 agent 在某些场景显式写记忆（如用户说"记住这件事"）
2. Scope 是 arbitrary dict 而非二维固定——Memex 在多客户白标场景下可能需要演进到 arbitrary dict scope（不只是 userId × projectId）
3. Memory revisions + IAM 可审计——客户合规要求场景下，Memex 需要补可审计层（DB 直查不够，需要 API 层暴露 revision 历史）
4. Topic 概念化——Memex 当前的 4 类（event / info / schedule / ai_insight）和 Memory Bank 的 4 个 managed topics 概念近似，可对照看是否漏了重要 topic 类型

下面对每条做完整拆解。

借鉴点 ①：两种写入姿态并列（CreateMemory）¶

Memex 现状¶

单姿态被动提取——所有写入路径都是 POST /blobs/insert/{userId} 入库，靠 flush（手动 / 自动 50 个 / 10 分钟）触发 LLM 三类提取（summary / profile / reinforce）。

LLM Agent 不能主动说"记下这件事"——只能把这句话作为对话内容进 blob，等流水线判断它是否值得提取成 gist。

Memory Bank 做法¶

• GenerateMemories：异步批提取（与 Memex flush 同形态）
• CreateMemory：memory-as-a-tool，Agent 显式调用写一条 memory，绕过提取流水线
• 两条路同一存储后端——consolidate / TTL / scope 隔离都共用

差异本质¶

不是"主动 vs 被动"的二选一，而是承认两种 Agent 行为模式都合法：

Memex 当前两种语义被压扁——用户主动说"记住 X"和 LLM 从对话推断"用户喜欢 X"在 gist 表里没有区别。

Memex 实施形态¶

新增 API：POST /memories/create/{userId} 直接写一条 gist（绕过 blob → summary → gist 流水线）

必填：
  - content（文本）
  - memory_type（event / info / schedule / ai_insight）
  - importance（CORE / IMPORTANT / NORMAL / TRIVIAL）

可选：
  - source = "explicit"（vs 默认 "extracted"）
  - 与借鉴点 ④ 配套：source 字段同时支撑 ai_insight 类型重构

行为：
  - 写入即刻可检索，不进 PENDING 队列
  - 默认 importance=IMPORTANT（用户主动说的比 AI 推断的强）
  - 检索时 source=explicit 给更高权重

用法：
  - Sentino Agent 在 prompt 里加 createMemory tool 描述
  - LLM 检测到"记住 X / 别忘了 Y / 我跟你说过 Z"等触发短语时调用

工程量¶

约 0.5-1 周 开发： - API 端点 + 跳过流水线的写入路径（0.5 天） - gist 表加 source 字段 + 索引（0.5 天） - 检索权重调整（1 天） - Sentino Agent prompt 改造 + tool 描述（1 天） - 测试 + 联调（1-2 天）

业务驱动力¶

• 用户体验：明显感知——"我说记住的事就该被立即记住，不该被流水线判断"
• 风险：Agent 滥写（LLM 见啥都调 createMemory），需要 prompt 严格约束 + 频次限流
• 与现有架构冲突：低——读路径不变，只是写路径多一条
• 撬动比：高（API 简单 + 用户感知强）

优先级建议¶

P1，可与 v2 第一批一起做。

借鉴点 ②：Scope 演进为 arbitrary dict¶

Memex 现状¶

固定二维：userId × projectId。所有 gist 强制挂在某 user 的某 project 下，跨 project 不可见。

Memory Bank 做法¶

Scope 是 arbitrary dictionary，开发者自定义键值对：

同一 scope 内的 memories 才参与 consolidation 和默认检索，跨 scope 仍可显式查询。

差异本质¶

userId × projectId 是写死了多租户语义："客户 = project，终端用户 = user"。

但白标场景的真实结构是三层： - 平台（Sentino） - 客户（Walmart / Yukai / Hotmind） - 终端用户（最终 to C 的人）

当前两维表达不出"同一终端用户在同一客户的不同 agent 实例间"的隔离粒度。具体例子：

Yukai 客户内部有"陪伴 agent"和"日程 agent"两个产品。同一终端用户的"我对花生过敏"是否应当在两个 agent 间共享？现在没有 scope 维度可表达——要么强制共享（隐私问题），要么开两个 project 复制 user（数据冗余）。

Memex 实施形态¶

激进版：把 userId + projectId 重构为 scope JSONB，所有 query 接受任意 scope 字典做隔离过滤。 - 工程量大 - 数据迁移痛 - 兼容性破坏（所有现有 SDK 接口要重做）

保守版（推荐）：保留 userId × projectId 列做主键索引，新增 scope_extra JSONB 字段做扩展维度。

默认行为不变：
  - 按 userId × projectId 隔离（现有客户零迁移）

客户需要更细粒度时：
  - 写入：POST .../insert/{userId} body 带 scope_extra: {agent_id: "companion"}
  - 查询：GET .../context/{userId}?scope_filter={agent_id:"companion"}

不破坏现有客户。

工程量¶

• 保守版 1-2 周：新增字段 + JSONB GIN 索引 + 查询接口扩 scope_filter 参数 + 测试
• 激进版 1-2 月（含数据迁移和兼容性）

业务驱动力¶

• 不紧迫：当前白标客户（Yukai）还在单 agent 单产品阶段，二维 scope 够用
• 预见性需求：一旦客户做"多 agent 共享平台"，没有这个能力会变成销售卡点
• 触发条件：当 sentino-agent 平台开始接入第二个 agent 类型时

优先级建议¶

P2，等触发条件。提前预研数据模型，但不要现在就重构。

借鉴点 ③：Memory Revisions API + IAM 分级¶

Memex 现状¶

Memory Bank 做法¶

• Memory revisions API：每条 memory 的修改历史可见——"这条记忆从'用户喜欢花生酱'变成'用户对花生过敏'是哪次 update 触发的、当时的 LLM 输出是什么"
• IAM Conditions：CEL 表达式细粒度授权，例如"只有 memoryEditor 角色 + 同 scope 的用户能 update"
• 专用角色：memoryViewer（只读）/ memoryEditor（读写）/ memoryUser（读 + 部分写）

差异本质¶

合规客户（金融 / 医疗 / 政府）问 Sentino 三类问题：

第 1 个问题是硬卡点——没有 revision history 不可能事后补。第 2、3 个问题是软卡点——技术上 DB 权限能做，但客户审计要求"应用层 API 暴露权限模型"，DB 层证明不被认可。

Memex 实施形态¶

a) Revision history：

新增 gist_revisions 表：
  - gist_id（FK）
  - revision_no（自增）
  - content
  - importance
  - source
  - change_reason（"merge" / "reinforce" / "ttl_update" / "explicit_update"）
  - llm_output_snapshot（如果是 LLM 触发的变更，存当时 prompt + response 摘要）
  - created_at

写入时机：
  - 每次 update / merge / forget 写一条 revision
  - 不删原 gist
  - 合并后原 5 条 gist 状态改为 MERGED，revision 记录指向新 gist_id

新增 API：
  - GET /memories/{gist_id}/revisions → 返回 history
  - GET /memories/audit?user_id=X&from=Y&to=Z → 时间窗口内的所有变更

b) IAM 分级：

API 层增加 role 概念：
  - user_token + role claim
  - 三个内置角色：
    - viewer（只读，含 revision history）
    - editor（读 + 显式写，禁触发流水线提取）
    - user（默认全权限）

客户接入时 SDK 选 token 类型决定权限。

c) 细粒度 condition（可选）：

类 CEL 表达式（"importance == CORE 时禁止 update"）。通常合规客户不需要，过度设计——除非有具体客户提出再做。

工程量¶

• a) + b) 约 2-3 周：
• gist_revisions 表设计 + 迁移（3 天）
• 所有 gist 修改路径加 revision 写入（3 天）
• 合并任务改造（不删除原 gist）（2 天）
• revision API + audit API（3 天）
• role + token 改造（4 天）
• 测试 + 联调（3 天）
• c) 看具体需求另算

业务驱动力¶

• 非常强：合规客户场景这是硬卡点，没有的话直接销售失败
• 机会成本：Memory Bank 内置这套，Sentino 不补就在合规客户面前裸奔
• 已有客户：yukai-agora-poc（消费级）不需要；预想中的金融 / 政府客户进门第一关
• 附带收益：Reinforce 幻觉风险（LLM 编造 gist_id）有了 revision 历史可以事后追溯（sentino-memex "待观察 / 改进点"第 1 条）

优先级建议¶

P1，第一批合规客户出现前必须做完。建议姜涛优先排——这是 4 个借鉴点里业务驱动力最强的一个。

借鉴点 ④：Topic 概念化对照¶

Memex 现状¶

4 类记忆类型：

切分轴是内容性质——这条记忆描述的是什么类型的事实。

Memory Bank 做法¶

4 个 managed topics（+ custom topics 可扩）：

切分轴是用户视角——这条记忆来自用户的什么意图 / 哪类对话内容。

差异本质¶

两套切分轴不正交、不对偶、不能 1:1 映射。逐对照：

两组都漏了一类：

• Memex 漏 EXPLICIT_INSTRUCTIONS——用户主动说"记住"和 AI 推断的应该不同强度（这与借鉴点 ① 是同一个问题）
• Memory Bank 漏 ai_insight——AI 自己推断的"用户最近压力大"这种合成事实没有归属（Memory Bank 强假设记忆都是事实提取，不是 AI 综合判断）

Memex 实施形态¶

不是"加一类"那么简单——是要重新审视切分轴：

维持现有 4 类不动（event / info / schedule / ai_insight）

新增正交维度 source（与借鉴点 ① 配套）：
  - extracted（流水线提取）
  - explicit（用户明确指令）
  - ai_insight（AI 综合判断）

ai_insight 的角色变化：
  - 从一种 type 变成一个 source 标签
  - 任何 type 的 gist 都可以是 ai_insight（"event 类型 + ai_insight source" = AI 推断的事件）

检索权重调整：
  - source=explicit > source=extracted > source=ai_insight
  - 用户主动说的比 AI 推断的可信

工程量¶

约 1 周（DB 加字段 + 检索权重调整 + prompt 改造让 LLM 区分 source）

业务驱动力¶

• 弱：单独看不值得做。当前 4 类够用
• 但与 ① 配套做时几乎免费：既然要加 explicit 写入姿态，顺手把 source 字段做出来
• 认知收益：让 Memex 团队对"记忆类型 vs 记忆来源"这两个轴的区别有更清晰的概念框架
• 后续扩展性：source 字段是未来"过程数据 vs 产出数据"（process-data-vs-output-data）扩展的预留位

优先级建议¶

P3，不单独做，与 ① 一起做就顺手收益。

论点边界¶

前提敏感性分析¶

本报告的优先级建议依赖以下默认前提。一旦前提变化，结论需要重新评估：

不应该做的事¶

明确不推荐借鉴的 Memory Bank 设计点：

1. 强制绑某个 LLM 厂商：Memory Bank 强制 Gemini 是 Google 战略选择，对 Sentino 是反向警示——Memex "不绑 LLM 厂商"是核心差异化（详见 sentino-memex "对外定位锚点"段）
2. 扔掉 4 级 TTL × 4 类内容二维结构改成 topic 一维：Memory Bank topic 一维是为简化 API 表面做的妥协，丢失了重要度维度的精细控制——Memex 的二维结构是销售差异化论点之一
3. 扔掉 Reinforce 改成 GENERATE_UPDATED_TTL：方向不同——Reinforce 是 prompt 主动指向已有 gist 续期（防新增），GENERATE_UPDATED_TTL 是 update 后被动续期（不防新增）。Reinforce 的抗膨胀机制更主动
4. 扔掉夜间合并改成写入路径自动 contradiction resolution：写入路径合并需要每次写入都跑 LLM，成本高且延迟高；Memex 的夜间合并是工程权衡，不应在 v2 里被替换

反建议的具体场景¶

如果姜涛 / 子昕评估时出现以下任一信号，建议本报告全部 4 个借鉴点缓做：

• 销售 pipeline 里近 3 个月没有合规客户线索
• Memex 当前生产数据里 Reinforce 命中率 < 50%（说明核心机制本身需要先打磨）
• Sentino Agent 平台第二个 agent 类型短期不会上
• 团队产能 < 2 人月可投入到 Memex v2

综合判断¶

推荐排期（如果姜涛 + 子昕只能选 2 个）¶

P1 - 必做（约 1 个月投入）：
  ① 两种写入姿态（CreateMemory）+ ④ source 字段（一起做）— 1 周
  ③ Revision API + IAM 分级 — 3 周

P2 - 等触发：
  ② Scope arbitrary dict — 触发条件是"第二个 agent 类型接入"或"多 agent 共享平台"

撬动两个明确销售卡点：
  - 合规客户（revision + IAM）— ③ 解
  - 用户体验（"记住 X" 立即生效）— ① 解

反建议（与推荐同样重要）¶

4 个借鉴点没有一个是"看到 Memory Bank 这么做就要跟"——都是 Memex 自己业务驱动的、Memory Bank 只是给了具体的 API 形态参考。

如果姜涛说"现在没合规客户、没多 agent 需求"，全部缓做也是合理的。Memex 当前的核心瓶颈大概率不在这 4 项上：

结论：借鉴点是"给定有空闲产能时排什么"的问题，不是"必须立即对标"。Memex 的核心瓶颈优先于借鉴点。

不变量（4 个借鉴点都不应触及）¶

无论选哪个借鉴点做，以下 Memex 设计不应被动摇：

1. 不绑 LLM 厂商 — 客户多模型策略约束
2. 4 级 TTL × 4 类内容二维结构 — 销售差异化论点
3. Reinforce 主动续期机制 — 比 Memory Bank GENERATE_UPDATED_TTL 更主动的抗膨胀
4. 夜间合并显式定时任务 — 写入路径不放 LLM 调用
5. 数据主权（自建 Spring Boot 服务） — 销售根本立场

对知识库的修正记录¶

本报告新建 / 修改的页面：

• 新建本报告 wiki/reports/2026-04-28-memex-v2-design-options.md
• 更新 sentino-memex "待观察 / 改进点"段第 5 条："Memory Bank 启发的 v2 设计选项"补回连本报告（保留简略列表，详细看 report）
• 更新 google-memory-bank "对 Sentino Memex 演进的具体启示"段尾部加回连本报告
• 更新 sentino-agent 相关概念段加回连本报告
• 更新 wiki/index.md "## 研究报告" 章节加新条目
• 更新 wiki/journal/2026-04-28.md 追加本报告新建记录

git commit 哈希：（待审核 git diff 后由用户手动提交，本字段由 commit 后回填）

待验证 / 后续追踪¶

工程评估待办¶

• 姜涛评估借鉴点 ③（Revision API + IAM）的 2-3 周工程量是否准确——重点核对合并任务改造的复杂度（涉及历史数据迁移）
• 子昕评估借鉴点 ① 的 prompt 改造是否会影响现有 flush 流水线提取质量——needs A/B test
• 借鉴点 ② 的"保守版 vs 激进版"决策需要看未来 12 个月 Sentino Agent 平台路线图

数据验证待办¶

• 跑 Memex 当前生产数据里 Reinforce 命中率（决定是否核心瓶颈优先）
• 跑当前 gist 表里"用户主动说记住 vs LLM 推断"的比例（决定借鉴点 ① 撬动比是否成立）
• 模拟金融 / 医疗客户审计场景，看 DB 直查能否过——决定借鉴点 ③ 的紧迫性

外部信号追踪¶

• Memory Bank GA 后的实际企业客户案例（Google 公布的 case studies 多大规模？）
• LongMemEval 之外的横向 benchmark（vs mem0 / MemGPT 实测对比）— 判断 RMM 论文宣称的 +10% 优势在工业场景是否成立
• 2026 内是否有"开源 RMM 实现"出现——决定 Memex 是否值得借鉴 RMM 多粒度反射机制（本报告未列入借鉴点，但若开源实现出现，可考虑作为 v2.5 候选）
• ADK（Google Agent Development Kit）渗透率追踪——决定 Memory Bank 在 Sentino 客户面前的"事实标准"地位

战略层待办¶

• sentino-memex-positioning.md 中英文版补 Memory Bank 列（与本报告并行，但属销售物料工作不是工程工作）
• 第三个对照样本预警：未来一年内可能出现 OpenAI / Anthropic / Microsoft 任一推出托管记忆服务，Memex 销售物料应当从单对照扩到三对照

引用源¶

一手文献¶

• google-memory-bank 调研材料：https://cloud.google.com/blog/products/ai-machine-learning/vertex-ai-memory-bank-in-public-preview
• Memory Bank IAM 文档：https://docs.cloud.google.com/agent-builder/agent-engine/memory-bank/iam-conditions
• ACL 2025 RMM 论文：https://arxiv.org/abs/2503.08026

框架与对照¶

• sentino-memex — Memex 当前架构与设计哲学
• google-memory-bank — Memory Bank 完整技术拆解（本报告 4 个借鉴点的源头）
• auto-memory — Claude Code 单姿态对照（借鉴点 ① 反方向参照）
• mem0 — 向量检索路线对照（借鉴点 ③ 的 mem0 自承未解 governance 问题）
• auto-dream — Claude Code 整合机制对照（借鉴点 "不变量"第 4 条 Memex 夜间合并的对照）

知识库内部 raw 沉淀¶

• raw/notes/google-memory-bank-research-2026-04-28.md — Memory Bank 调研一手素材