Agent 记忆体系研究：从 Gbrain 到数字永生

调研日期：2026-04-15 调研方法：WebSearch + WebFetch 原始资料整理 覆盖范围：Agent Memory 主流框架、记忆调用机制、数字永生技术与商业化

1. 执行摘要

Agent Memory 已经从"向量库 + RAG"的朴素范式，演化为**分层（Hot/Warm/Cold）+ 多模态存储（向量 / 图 / 文件）+ 异步重整理（Sleep-time Compute）**的系统工程。2025-2026 年的主流路线出现了明显分化：Mem0 走"向量为主 + 可选图"的轻量路线，Zep/Graphiti 走"双时态知识图谱"的强结构化路线，Letta 走"Memory Block + 自编辑"的 LLM-OS 路线，Hermes/GBrain 走"Prompt 稳态缓存 + 工具化检索 + 目录文件"的工程化路线。

核心洞察是：入库处理逻辑必须与检索逻辑严格对应——如果入库时只做 chunk embedding，却期望检索时获得关系推理与时间感知，必然失败；反过来若入库大量抽取实体关系却仅用向量相似度检索，图结构同样被浪费。

记忆的调用时机也从"每轮 RAG"向"工具化按需调用 + 后台异步整理"转变。数字永生赛道则在技术上高度依赖这套记忆基础设施——典型产品 = 语音/视频克隆 + LLM 对话引擎 + 人物记忆图谱。本报告给出对个人助理升级、"AI 记得我"产品选型、以及企业 Agent 平台记忆层的具体建议。

2. 主题一：Agent 记忆存储与检索架构

2.1 三种存储方式对比

生产共识是混合架构（Maxim AI、HydraDB）：向量负责"What is relevant"，图谱负责"What do we know"，文件目录负责"agent 和人类共用的工作记忆"。

2.2 主流框架横评

Letta（前身 MemGPT）

• 定位：把 LLM context 当 OS 内存来管理（"LLM OS"）。
• 入库逻辑：不做预先的实体抽取，而是用函数调用让 agent 自己决定写入哪一层——Core Memory（系统提示中的 Memory Block，字符上限）、Recall Memory（消息历史 + FTS 检索）、Archival Memory（向量库）。
• 检索逻辑：Memory Block 常驻 system prompt（无需检索）；Recall/Archival 由 agent 主动 conversation_search、archival_memory_search 工具调用召回。
• 亮点：Sleep-time Agent（2025-04）——后台异步代理在 idle 时反思原始上下文，refactor memory blocks；Agent File（.af）实现 stateful agent 序列化；Letta Filesystem 在 LoCoMo 上达 74%（Letta Blog）。
• 2025-10 重构：新的 Agent Loop 合并了 ReAct、MemGPT、Claude Code 的经验。

Mem0（mem-zero）

• 定位：通用记忆层，向量为主 + 可选图（Mem0g）。
• 入库逻辑（两阶段）：
  1. Extract：用 FACT_RETRIEVAL_PROMPT 从（最新对话 + rolling summary + 最近 10 轮消息）中抽取"事实原子"。
  2. Update（冲突消解）：检索语义相似的 top-k 已有记忆，LLM 通过 function-call 决定 ADD / UPDATE / DELETE / NOOP。
• 2026-04 新算法：转向 Single-pass ADD-only 抽取（不再做 UPDATE/DELETE），把去重/合并推迟到检索阶段；引入跨记忆的 entity linking。
• 检索逻辑：v3 默认多信号混合——semantic + BM25 + entity match，并行打分融合；rerank 默认关闭（~100–150ms），可选 Cohere/BGE rerank（+150–200ms）。
• Benchmark：LoCoMo 91.6，LongMemEval 93.4，p95 延迟 1.44s（相比 full-context baseline 降 91%）(Mem0 paper)。

Zep / Graphiti

• 定位：双时态知识图谱（bi-temporal KG），专为 agent 记忆设计。
• 入库逻辑（8 步 pipeline）（见 Zep Docs）：
  1. 创建 Episode（text/message/json，带 valid_at + created_at）
  2. 拉取最近 N 个 Episode 作为消歧上下文
  3. LLM 抽取实体（支持自定义 Pydantic entity types）
  4. 节点去重（精确匹配 + LLM 判重，产出 uuid_map）
  5. LLM 抽取边（关系三元组）
  6. 边消解与 invalidation——矛盾事实仅标记 expired_at / invalid_at，不删除
  7. 节点属性抽取（由边汇总）
  8. 原子化持久化
• 检索逻辑：语义 embedding + BM25 + 图遍历的 hybrid 召回，sub-200ms。支持 valid_at 过滤做"时间穿越"查询。
• Benchmark：DMR 94.8%（超 MemGPT 93.4%），LongMemEval +18.5% acc，-90% latency。
• 架构差异化：Episode / Entity / Community 三层子图层级；支持 Neo4j/FalkorDB/Kuzu/Neptune。

Graphiti 相关的 GBrain（Garry Tan）

• 定位：个人 agent 的自动化"记忆操作系统"，基于 PGLite/Postgres + pgvector，29 个 Skill + 30+ MCP tools。
• 入库逻辑：每次写一页自动抽取实体引用并创建类型化链接（attended / works_at / invested_in / founded / advises），零 LLM 调用的自动 wiring；以"Compiled Truth + Timeline"结构存储（当前状态在上方被 LLM 重写，证据 timeline 在下方 append-only）。
• 检索逻辑：keyword + vector + graph traversal 三路混合，backlink-boosted ranking。
• Benchmark（BrainBench）：P@5 49.1% / R@5 97.9%，较 BM25+vector baseline +31.4pt。
• 工程亮点：Minions（Postgres 原生 durable job queue，替代脆弱的 sub-agent spawn，753ms vs 10s+）；强制 [Source: who, channel, date, time, tz] 引用；Originals folder 单独保管用户自己的思考原文。

2.3 核心洞察：入库处理逻辑与检索逻辑的对应关系

这是整个调研最重要的一条结论。可以整理成一个映射表：

实操三条铁律：

1. 入库精度 ≥ 检索精度：查询粒度决定存储粒度。要答"某天某小时的事"，就必须在入库时保留小时级时间戳。
2. 冲突消解方向决定更新策略：Mem0 在入库期做（UPDATE/DELETE），Graphiti 在入库期标记失效但保留历史，Letta 让 agent 自己在运行期决定——三者不可混用。
3. 检索通道数量 ≤ 入库通道数量：写了向量没写图，就不能指望图查询；反之亦然。

2.4 长短期记忆分层与遗忘机制

遗忘/压缩代表性方案：

• FadeMem（arXiv:2601.18642）：Ebbinghaus 遗忘曲线启发的指数衰减，跨 LML/SML 双层迁移，45% 存储压缩。
• AgeMem：把 store/retrieve/update/summarize/discard 作为工具暴露，用 RL 学习策略。
• Hermes Compression Flush：在压缩长对话前单独调度一次仅开放 memory 工具的模型调用，专门让 agent 蒸馏"持久事实"。

3. 主题二：记忆在 Agent 中的使用时机（Hermes 为主要参照）

3.1 Hermes Agent 的分层记忆调度机制

Hermes（Nous Research 出品）的设计原则一句话概括：keep the prompt stable for caching, push everything else to tools。其五层架构：

3.2 三个关键时机问题的答案

① 知识什么时候入库？

2026 趋势：从"同步阻塞 extract"转向"异步 + sleep-time 重整理"（Letta Blog 2025-04），以及"压缩触发式"入库（Hermes）。前者降延迟，后者降 token 成本。

② 知识什么时候被调用？

③ 如何调用（prompt 注入 vs tool return vs RAG）？

生产上的最佳实践组合：

• 用户画像 / 核心偏好 → 直接 prompt 注入（稳定且缓存友好）
• 对话历史检索 → 工具调用（session_search、conversation_search，结果进消息流而非 system prompt，保护 prefix cache）
• 世界知识 / 结构化实体 → 工具调用 → 图谱查询（gbrain query、Graphiti search）
• 技能/工作流 → 预加载索引 + 按需 load 全文
• 原文 chunk → 向量 RAG（仅当语义模糊、需要大语料时）

3.3 推荐的技术模式（Hermes+Letta 融合版）

System Prompt (frozen, prefix-cacheable)
├── USER.md  (谁是用户)
├── MEMORY.md (agent 长期学到的约定)
├── Skills Index (只有索引)
└── Tool Schemas

Working Context (每轮变化)
├── Message Buffer
├── Tool Return 中携带的召回记忆（session_search、graph_query）
└── 动态加载的 Skill 全文

后台异步（Sleep-time）
├── Memory Block 重整理
├── 旧 session 蒸馏成事实
└── 图谱 community detection / 摘要更新

三条核心设计原则：

1. Prompt 稳态：系统提示里只放长期稳定内容，保护 KV cache。
2. 工具化检索：所有动态召回通过 tool call，确保 agent 能自主控制精度/成本。
3. 异步重整理：入库的昂贵工作（抽取、合并、去重）推到 idle 时段，避免阻塞用户。

4. 主题三：AI 数字永生案例与技术方案

4.1 2025-2026 最具影响力的案例

① "超级头脑工作室"（张泽伟，南京）——已完成 1500+ 宗订单。2026-04 报道中最震撼的案例：一位 90 多岁老母亲在不知情下与 AI 复刻的已故儿子视频通话一年多。技术是"真人扮演者 + AI 换脸变声"。收费 5000–20000 元/宗（unwire.hk）。

② 商汤"如影"——汤晓鸥逝世后的首次年会上，用 3D 投影 + AI 音频重建，让"汤晓鸥"进行了 10 分钟的脱口秀，期间还"喝了一口水"。

③ 帕克兰校园枪击案受害者 Joaquin Oliver（2025-08）——前 CNN 主播 Jim Acosta 在 Substack "采访"了罹难 17 岁少年的 AI 数字分身，用受害者声音呼吁控枪。

④ Reddit 联合创始人 Alexis Ohanian 复活母亲（2025-06）——用 Midjourney 图生视频工具基于老照片生成"母亲抱着幼年的自己哄睡"视频，X 上引发大规模共鸣。

⑤ 中国"Roro 与 Xia"（Phys.org 2026-01）——用户在平台 Xingye（星野）公开部署已故母亲 Xia 的聊天机器人，引发中国网信办介入起草"类人交互 AI 服务"监管。

⑥ Meta 专利 US 12513102B2（2025-12-30 授权）——模拟已故用户的社交媒体活动。

4.2 技术栈拆解

数字永生产品的通用架构 = 记忆库 + 性格建模 + 对话/渲染引擎，三层映射到本报告前两部分的技术积累：

技术路线两派：

• 检索派（HereAfter AI、StoryFile）：用预录制的真人回答做规则匹配，LLM 只做 intent routing——真实但不灵活。
• 生成派（You Only Virtual、Project December、超级头脑）：LLM 基于记忆库自由生成——灵活但会 drift / 幻觉。

与本报告主题 1/2 的关系：数字永生产品的核心就是一个高度定制的 Memory System——

• 记忆库需要双时态图谱（那个人 50 岁时对政治的看法 vs 70 岁时）；
• 需要Compiled Truth + Timeline（人设的静态版本 + 原始语料流）；
• 需要Memory Block（永久注入"我是谁、我的口头禅、我爱的人"）；
• 需要Sleep-time 重整理（新语料入库后的人设重汇聚）。

4.3 商业化现状

来源：Futuro Prossimo 2026-03、ReLiveable.ai、TheirVoice.ai

市场规模预测 $610 亿（2030）。商业模式争议：订阅制"激励持续使用和依赖"，与"帮助哀悼闭环"在逻辑上相悖。

4.4 伦理争议核心点

1. 逝者同意问题——逝者未必授权自己被 AI 复刻。
2. 哀悼闭环被打断——Mary-Frances O'Connor 的研究把哀悼视作学习过程；griefbot 可能制造"生而复活"的认知不协调。
3. 人格漂移（drift）——时间越长越不像逝者本人。
4. 数据可持续性——所谓"永生"实际只到公司运营周期结束。
5. 诈骗风险——香港已出现 AI 换脸视频会议诈骗 2 亿港元的案例。
6. 中国监管动态——网信办 2026 年起草针对"类人交互 AI 服务"的新规；需要消费者告知、年龄分级、自杀/自伤检测。

5. 整合建议

5.1 对个人助理 Agent 的升级建议（基于 Claude + 当前文件系统记忆）

当前瓶颈推断：纯文件目录是"冷记忆"——语义检索弱、关系与时间推理无；agent 每轮 prompt 也难承载全量。

三步升级方案：

Step 1（2 周内，低成本）——引入 Hermes 式分层

• 把文件拆为三类：USER.md（身份 + 稳定偏好，≤1500 字符）+ MEMORY.md（agent 学到的约定，≤2200 字符）进 system prompt；其余进可检索目录。
• 加 SQLite + FTS5 做 session archive，通过 session_search 工具暴露。
• 压缩触发的 memory flush（压缩前专用一次 LLM call 提取持久事实）。

Step 2（1–2 月，中等成本）——接入 Mem0 v3 或 Graphiti

• 若需求以"记住用户偏好、人物关系"为主 → Mem0 v3（安装快、hybrid 默认开、图可选）。
• 若需求以"复杂时间线、会议纪要、项目状态演变"为主 → Graphiti（双时态、图查询强）。
• 二者均可通过 MCP 暴露给 Claude Code，零侵入集成。

Step 3（3 月+，高价值）——Sleep-time Compute

• 加一个后台 worker：每晚把当天会话 / 新增文件批量入库到图谱；定期做 community detection 生成"本月摘要"Memory Block。
• 成本敏感场景用 Gemini 2.5 Flash 做 extractor（Letta Leaderboard 显示性价比最高），最终问答用 Claude。

5.2 对"AI 记得我"产品底座选型

这是最需要时间精度和关系精度的场景。建议：

底座：Graphiti（自托管）+ Neo4j/FalkorDB

• 原因：双时态（逝者不同年龄段的观点演变）、边 invalidation（事实更新不失历史）、Community Node（自动形成"家庭"、"同事圈"、"爱好群"）。
• MCP 对接前端对话引擎。

辅助：Letta 的 Memory Block 机制

• 为每个 digital persona 维护一块 ≤2000 字符的"人设卡"（口头禅、核心价值观、标志性故事）常驻 prompt。
• 用 Letta Sleep-time Agent 在用户上传新资料后，后台 refactor 这块人设卡。

语料入库管道（关键差异化）：

1. 原文优先——像 GBrain 的 Originals folder 一样，单独保留逝者本人说过/写过的原话（不压缩、不摘要）。
2. 三元组抽取——用 LLM 在 bulk 模式下生成实体/关系（家人、经历、观点）。
3. 时序标签——所有事实必须带 valid_at（尽量到年月）。
4. 多源融合——短信、语音、视频转写、第三方访谈各自作为 Episode type 进入同一图谱。

人格保真度技巧：

• USER.md 类 Memory Block 用逝者自己的第一人称语气写，而非"他喜欢 X"。
• few-shot 示例用逝者的原话，不要 paraphrase。
• 每当 LLM 生成疑似 drift 的内容，触发"人设校验 agent"（参考 Letta Sleep-time）回滚重写。

伦理 / 合规内建：

• 家属授权链上链或强存证。
• Persona 明确标识为 AI，禁止自称"真人"。
• 自杀/自伤检测、年龄分级、哀悼期敏感话题兜底（参考中国网信办方向）。
• 订阅到期数据导出义务（规避 TheirVoice.ai 指出的"lifetime = 公司 lifetime"陷阱）。

5.3 对比心 Agent 平台记忆层建设建议

企业内部 Agent 平台的诉求和个人助理不同——多 agent 协作 + 多租户隔离 + 可审计是硬需求。

推荐架构：

[业务 Agent]  [业务 Agent]  [业务 Agent]
      ↓            ↓            ↓
    ┌─────────────────────────────┐
    │   Memory Gateway (MCP)       │   ← 统一入口，鉴权 + 限流
    ├─────────────────────────────┤
    │ Core Memory Block Service    │   ← Letta 风格，按 agent/user 维度
    │ Episode Store (Postgres)     │   ← 原始对话，FTS5
    │ Knowledge Graph (Graphiti)   │   ← 企业实体：员工/客户/项目/订单
    │ Vector Index (pgvector)      │   ← 文档/知识库
    │ Skill Registry               │   ← 可复用 workflow 的 procedural memory
    └─────────────────────────────┘
            ↓ 后台 worker ↓
     [Sleep-time 抽取/整理/community detection]

关键工程建议：

1. 多租户维度 至少 user_id / agent_id / app_id / run_id 四层（Mem0 方案），防止数据串通。
2. Memory Block 共享机制（Letta "share blocks across agents"）——让"客服 agent"和"销售 agent"共享同一个客户画像块。
3. 审计与溯源：每条事实必须带 [Source: channel, timestamp, author]（GBrain 做法），这对企业合规至关重要。
4. 入库异步化——业务 Agent 立即返回用户，记忆抽取推到后台 job queue（参考 GBrain 的 Minions，Postgres 原生 durable queue）。
5. 工具化暴露（MCP）——业务 Agent 通过标准工具调用 memory.search / memory.write / graph.query / session.archive，不直接读写底层存储。
6. 遗忘策略：按公司数据留存合规（例如离职员工对话 6 个月后自动迁入冷库）。

6. 参考链接

框架与技术文档

• getzep/graphiti GitHub
• Zep 论文 arXiv:2501.13956
• Graphiti Adding Episodes 文档
• Letta 官方文档
• Letta Leaderboard
• Letta: Anatomy of a Context Window
• Letta: Agent Memory Blog
• Letta Sleep-time Agents
• mem0ai/mem0 GitHub
• Mem0 研究页 / 论文 arXiv:2504.19413
• Mem0 Architecture 参考
• Mem0 Platform v2→v3 Migration
• garrytan/gbrain GitHub
• Hermes 官方文档

记忆研究论文

• Task Memory Engine arXiv:2504.08525
• MemPO: Self-Memory Policy Optimization arXiv:2603.00680
• SideQuest: Model-Driven KV Cache Management arXiv:2602.22603
• Memex(RL) arXiv:2603.04257
• FadeMem: Biologically-Inspired Forgetting arXiv:2601.18642
• SimpleMem arXiv:2601.02553
• Agentic Memory (AgeMem) arXiv:2601.01885
• Memory for Autonomous LLM Agents Survey arXiv:2603.07670

架构对比

• AI Agent Memory: From RAG to Knowledge Graphs (paperclipped.de)
• Knowledge Graph vs Vector Database (AgentsLed)
• Maxim AI: Comparing Agent Memory Architectures
• HydraDB: Vector DB vs Memory Layer
• Chanl: Graph Memory for AI Agents

数字永生案例与伦理

• Nature: Ready or not, the digital afterlife is here
• arXiv 2502.10924: AI Afterlife as Digital Legacy
• Springer AI & Ethics 2026: Death bots, grief bots, posthumous avatars
• Phys.org 2026-01: Should AI be allowed to resurrect the dead?
• Philosophy & Technology: Griefbots
• Schwartz Reisman Institute: From mourning to machine
• unwire.hk: AI 复活亲人（中国）
• 36氪：超级头脑工作室
• 36氪：商汤"如影"复活汤晓鸥
• Futuro Prossimo 2026: Digital mourning by subscription
• NovaKnown: AI Deathbots Sell Memory
• Cambridge/Oxford: On Grief and Griefbots