memory-core 记忆方案与 Mem0 调研沉淀

8月 19, 2026

脱敏说明：本记录只保留架构与方案级信息，不包含真实数据库连接、密钥、内部地址、租户/用户原始标识、日志片段等敏感数据。

先给结论#

• memory-core 的记忆能力在仓库里已经有较完整的产品级与实现级沉淀，核心是“按需读取 + 后处理写入”的长程记忆闭环。记忆并不替代上下文窗口，而是提供可治理的线程化长期事实。
• 请求层的记忆语义已较完整定义：memory.read/memory.write/tenant_search/enabled 组合可控，可独立读写。
• memory-core 的实现思路已沉淀为：事实抽取（LLM）→ 嵌入（向量化）→ 检索（语义 + 关键词）→ 回放到模型上下文 → 后置写回。
• mem0 方向不是“引用库”而是“规则目标”，关键价值在于你对比了“如何比 Mem0 更聪明更完整”：只从最新一轮抽取、强调原子事实、时间线归并与状态更新。
• 当前仓库未发现对 mem0 的外部官方对比文档、性能指标或 POC 结果的直观证据表，尚有一处空缺：缺少可复现实验对比（latency、召回率、成本、误召回率）。

一、已有沉淀：memory-core 的产品级记忆方案#

1. 记忆职责定位#

• 定位为 Long-term Memory Service，提供 Add 写入和 Search 检索，不试图保存全量对话。
• 与 Agent 生命周期集成：在请求链路中作为“线程化长期记忆”补齐跨轮上下文。
• 与 Volume 并列为状态能力：记忆提供语义检索，Volume 提供文件态持久化。

2. 与 Agent 运行时的集成#

• memory.read 在首个模型决策前做 thread-scoped prefetch，作用域默认是当前线程。
• 预取结果通过 memory context 注入 Prompt，模型在运行中可再用 memory_search tool 做后续查询。
• memory.write 在最终回答后触发，属于确定性收尾步骤，不作为模型决策类型。
• 读写可分离：可只回忆不写入，也可只写入不预取。

3. 作用域与线程语义#

• 默认 thread 作用域，依赖 previous_response_id 进行线程锚定。
• tenant_search 可将搜索从单线程扩展到工作区/租户范围；否则未配置线程上下文时结果为空。
• 线程映射与响应链路要素可保留，即使当前轮不产生新事实也能为后续检索打基础。

二、现有实现沉淀：memory-core/README 与服务文档#

1. 核心能力与接口约束#

• 两个核心 RPC：Add、Search。
• Add：支持 async（快速 ack 后异步）与 AddSync（完整同步调试路径）。
• Search：支持语义检索路径，返回 memory 命中项并用于上下文注入。
• 依赖链路明确：memory-core 依赖 model-core 做生成抽取，嵌入可走专用 endpoint 或 model-core 兜底。

2. 数据与存储策略#

• 生产实现以 Postgres 为主，已有 memory-core migration 版本管理。
• 采用 pgvector/向量语义检索，并保留降级能力（关键词/结构化检索）。
• 事实缩减（reduce）发生在写入前：超长事实会先被模型压缩，缩减前原文保留于 metadata，避免信息丢失。
• 现有 schema 在写回时强调 memory、时间维度与元信息化表达，便于去重与更新。

3. 幂等与治理思路#

• memory 写入有幂等与状态追踪设计，系统中有 pending 处理、审计/可观测对齐。
• 模型调用、内存写入、审计事件会进入统一的 usage 与 trace 口径。

三、mem0 相关调研要点（脱敏后的结论）#

1. 你的 prompt.md 里明确了“比 Mem0 更智能/完整”的方向#

• 目标从“提取事实”升级为“可治理事实系统”：
  • 每次只从最新一轮消息提取新事实，不直接从历史事实再抽新事实。
  • 强调原子化：每条 fact 1-2 句话、可长期复用。
  • 强调高信号：避免过度保守，保留可复用偏好、计划、关系与时间事实。

2. 冲突与更新模型#

• 事实关系动作明确为 ADD / UPDATE / NOOP / LINK。
• 支持时间线修正：未来计划变更时通过时间字段收尾旧 fact（如 is_active=false 与 event_end），同时写入新 fact。
• 处理方式强调“去重、冲突检测、时间线关联”优先于盲目追加。

3. Prompt 生成与模型输入设计#

• 历史 top10 fact 以自然语言 bullet 列表呈现，附带 type、时间、状态，避免模型直接从历史事实再次“抽新”。
• 同时注入 conversation summary 与最近 raw messages，提升抽取准确率。
• 输出要求是结构化 JSON：facts + temporal_updates，便于程序化落库。

4. 结论性判断（关于 Mem0）#

• 当前可确认的是“策略目标是实现比 Mem0 更优的 fact memory pipeline”，并未发现仓库里有完整的 mem0 官方对比实验章节。
• 因此 mem0 在当前可复用材料里属于策略参照锚点而不是“已完成对比报告”。

四、可直接沉淀为文档/评审材料的核心观点#

1. 先定义三层：产品语义（读取/写入/作用域）→ 运行时编排（prefetch + search tool + post-answer write）→ 存储治理（版本化、审计、降级）。
2. 优先将记忆行为保持“显式 opt-in”：不要求无状态场景默认记忆，保障复现性。
3. 写入路径建议默认 async，sync 仅用于 debug 与闭环验证。
4. 记忆 schema 需原子 fact + 时间元信息 + 状态字段（active/事件边界）支撑长期准确性。
5. 明确把 mem0 作为目标模型，而非必须外部依赖：目标是可控、可解释、可维护的事实管理。

五、未落地但建议后续补齐#

• 按时间切片做一版“mem0 对比矩阵”：抽取准确率、召回率、更新正确率、延迟、成本与误用率。
• 补一版“生产回放案例”：同一对话在 mem0-风格和当前策略下各写入/检索结果差异。
• 补充“失败/重试策略”：embedding 失败、模型抽取不稳定、向量维度不一致时的行为界面。

六、参考材料（仅内部链接）#

• docs/design/managed-agent-api-whitepaper.md
• docs/design/managed-agent-api-whitepaper.zh-CN.md
• docs/design/agent-platform-architecture.md
• docs/technical-whitepaper-zh-CN.md
• services/memory-core/README.md
• services/memory-core/docs/prompt.md