AI Agent 的记忆该由谁来管？——从 Memoria 看 Agent Memory 的工程本质

1. 核心定义与全局定位

2025 年，AI Agent 的记忆层（Memory Layer）已经从一个”锦上添花”的功能，演变为一条独立的基础设施赛道。截至 2025 年底，该市场规模触及 62.7 亿美元，预计 2030 年将达到 284.5 亿美元（CAGR 35%）。Mem0 拿下 2400 万美元 A 轮，HydraDB 融资 650 万美元，Letta（前 MemGPT）从 UC Berkeley 实验室走向商业化，MemOS 从学术论文走向开源实现——所有信号都指向同一个判断：无状态的 Agent 是残缺的 Agent。

但如果审视这些产品的核心能力，会发现一个尚未被充分解决的问题：

记忆的可信度由谁保证？记忆的变更历史谁来追踪？当 Agent 基于错误记忆做出决策，谁来回滚？

这正是 Memoria 切入的位置。

Memoria（https://github.com/matrixorigin/Memoria）是 MatrixOrigin 团队开源的 AI Agent 持久化记忆层。它的核心主张用一句话概括：记忆不只是存储问题，更是版本控制问题。它将 Git 的版本管理范式——snapshot、branch、merge、rollback——原生地嫁接到 Agent 的记忆管理中，底层依托 MatrixOne 数据库的 Copy-on-Write 引擎实现零拷贝分支与时间旅行回滚。

在 AI Memory 的知识树中，Memoria 的坐标如下：

  • 大类：AI Agent Memory Infrastructure（与 RAG、Context Window 管理并列的基础设施层）
  • 子类构成：Canonical Storage（规范化存储）+ Pluggable Retrieval（可插拔检索）+ Git-for-Data Engine（数据版本控制引擎）+ Self-Governance（自治理）
  • 与相邻概念的核心区别：Mem0 解决的是”记住”，Letta 解决的是”自主编辑记忆”，MemOS 解决的是”统一调度多类型记忆”，而 Memoria 解决的是”记忆的完整性、可审计性与可逆性”

2. 竞品全景：五种路线，五种取舍

在深入 Memoria 的机制之前，有必要先建立一张清晰的竞品地图。当前 Agent Memory 赛道的主要玩家，各自代表了一条不同的技术路线。

2.1 Mem0：记忆层的”标准答案”

Mem0（读作 mem-zero）是当前赛道的融资冠军和 star 数冠军（截至 2026 年初，GitHub stars 超过 50K）。YC S24 孵化，2025 年完成 2400 万美元 A 轮。

其核心架构是一个三阶段管线：提取（Extract）→ 整合（Consolidate）→ 检索（Retrieve）。对话发生时，Mem0 从中抽取关键事实；当新事实与旧记忆冲突时，执行整合（更新或覆盖）；查询时，通过向量 + 图的混合检索返回相关记忆。

Mem0 的图记忆变体（Graph Memory）引入了实体关系建模，在 LOCOMO 基准测试中比 OpenAI 的内置记忆准确率高出约 26%，同时将 token 用量降低约 90%。

Mem0 的核心取舍：它是一个”记忆的 CRUD 服务”——擅长存取，但不追踪变更历史。记忆被覆盖后，旧版本消失。没有分支隔离，没有回滚机制。对于需要审计合规的企业场景，这是一个结构性缺陷。

2.2 Letta（前 MemGPT）：让 Agent 自己管理记忆

Letta 源自 UC Berkeley 的 MemGPT 论文，提出了一个激进的理念：Agent 应该像操作系统管理虚拟内存一样，自主决定哪些信息驻留在”主存”（context window），哪些换出到”外存”（长期存储）。

其记忆架构分为三层：

  • Core Memory：始终驻留在 prompt 中的结构化信息块，Agent 可以直接读写
  • Recall Memory：近期对话的检索缓存
  • Archival Memory：长期向量存储，按需检索

Letta 的独特之处在于 Agent 对记忆拥有”编辑权”——它不只是被动地被写入记忆，而是主动决定记什么、忘什么、改什么。

Letta 的核心取舍：自主编辑带来了灵活性，但也引入了风险——Agent 可能错误地删除或修改关键记忆，且这些操作缺乏版本追踪。记忆的”自主权”与”可控性”之间存在张力。

2.3 MemOS：学术界的”操作系统”范式

MemOS 是目前学术界对 Agent Memory 最系统化的理论框架，由来自多所高校和研究机构的团队联合提出（arXiv:2507.03724，39 位作者）。其核心主张是：记忆应该像 CPU 和存储一样，被当作可调度的系统资源来管理。

MemOS 统一了三种记忆表示：

  • Plaintext Memory：纯文本形式的事实和偏好
  • Activation Memory：模型中间层的激活状态（KV Cache 等）
  • Parametric Memory：通过 LoRA 等技术注入模型权重的记忆

其三层架构包括 MemScheduler（动态加载调度）、MemLifecycle（状态管理）、MemGovernance（安全合规）。

MemOS 的核心取舍：早期版本更多是理论框架而非生产级工具。但截至 2025 年底，MemOS 已在 GitHub（MemTensor/MemOS）发布 v2.0（代号”星尘”），包含知识库管理、多模态记忆、工具记忆等工程实现，并提供了 OpenClaw 插件的云端和本地两种部署方案。Activation Memory 和 Parametric Memory 的统一管理在工程上仍极其复杂，但 MemOS 正在从论文走向可用产品。它为整个领域提供了一个有价值的思维框架——记忆管理的终局形态，可能确实需要一个”操作系统”级别的抽象。

2.4 Mem9：轻量级的”即插即用”路线

Mem9 走的是极简路线。Apache-2.0 开源，Go 服务端 + TypeScript 插件，主打”零配置持久化记忆”。其核心卖点是：

  • 云端持久化，跨设备、跨会话同步
  • 混合搜索（关键词 + 向量），无需手动配置索引
  • 支持 Context Engine，自动筛选与当前任务相关的记忆注入 prompt

Mem9 的核心取舍：简单即是美，但也意味着功能边界清晰——没有版本控制，没有分支隔离，没有审计追踪，没有自治理机制。它适合个人开发者和轻量场景，但在企业级需求面前会触及天花板。

2.5 HydraDB：图优先的”本体论”路线

HydraDB（usecortex.ai）刚完成 650 万美元融资，其核心差异化在于本体优先的上下文图（Ontology-first Context Graph）。它不只存储记忆的向量表示，而是构建实体之间的关系图谱，追踪偏好的时间线演变。

典型场景：当用户说”Apple”时，HydraDB 能根据上下文图谱区分这是水果还是公司——这是纯向量检索难以做到的。

HydraDB 的核心取舍：图结构带来了更强的语义消歧能力，但本体建模的成本不低。图的维护、更新、一致性保证都是工程难题。且其当前生态较小，与主流 Agent 框架的集成深度有限。

2.6 竞品对比矩阵

维度 Memoria Mem0 Letta MemOS Mem9 HydraDB
核心范式 Git-for-Data 版本控制 提取-整合-检索管线 Agent 自主编辑虚拟内存 OS 级统一调度 云端即插即用 本体优先上下文图
版本控制 原生（snapshot/branch/merge/rollback） 无 无 理论层面有 MemLifecycle 无 无
审计追踪 每次变更自动 snapshot + provenance chain 有限日志 无 MemGovernance 层 无 无
分支隔离 零拷贝分支，验证后合并 无 无 无 无 无
检索方式 向量 + 全文混合 向量 + 图混合 向量检索 多模态统一检索 关键词 + 向量 本体图 + 向量
自治理 矛盾检测 + 低置信度隔离 冲突整合 Agent 自主决策 MemGovernance 无 图一致性维护
多 Agent 共享 共享可信记忆池 按 Agent 隔离 按 Agent 隔离 跨平台协调（理论） 共享空间 共享图
存储后端 MatrixOne（分布式 HTAP + 向量） 向量数据库 + 图数据库 PostgreSQL / SQLite 多后端抽象 云存储 自研图存储
生产就绪度 早期 高（50K+ stars，$24M） 中高（开源 + 商业） 中（v2.0 已发布） 中（Beta） 早期（$6.5M）
开源协议 Apache-2.0 Apache-2.0 Apache-2.0 开源 Apache-2.0 部分开源

3. 机制拆解：Memoria 的三个核心工程决策

3.1 决策一：将 Git 语义映射到数据层

这是 Memoria 最具辨识度的设计。传统的 Agent Memory 系统将记忆视为”可变状态”——写入、覆盖、删除，状态机式的生命周期。Memoria 将记忆视为”不可变历史”——每一次变更都是一个新的 snapshot，旧状态永远可达。

具体实现依赖 MatrixOne 数据库的 Copy-on-Write（写时复制）引擎：

  • Snapshot：对当前记忆状态的命名快照。底层不复制数据，只记录元数据指针。创建成本接近 O(1)。
  • Branch：从某个 snapshot 或时间点创建分支。分支之间完全隔离，写入互不影响。同样基于 CoW，零拷贝。
  • Merge：将分支合并回主线。支持 LCA（Lowest Common Ancestor）算法计算 diff，提供语义级别的变更分类。
  • Rollback：回滚到任意历史 snapshot。时间旅行式的状态恢复。

这套机制的工程价值在于：

  1. 安全实验：Agent 可以在分支上尝试新的记忆策略（比如”如果我把数据库从 PostgreSQL 换成 SQLite 会怎样”），验证无误后再合并。主线记忆不受影响。
  2. 审计合规：每一次 memory_store、memory_correct、memory_purge 操作都自动关联 snapshot 和 provenance chain。在金融、医疗等强监管场景下，这不是”nice to have”，而是硬性要求。
  3. 错误恢复：Agent 基于错误记忆做出了错误决策？回滚到出错前的 snapshot，重新来过。这在其他系统中需要手动重建状态，在 Memoria 中是一条命令。

3.2 决策二：自治理（Self-Governance）

Memoria 内置了三个维护机制，均带有冷却时间以防止过度触发：

  • memory_governance（1 小时冷却）：扫描低置信度记忆，执行隔离（quarantine）。清理过期数据。
  • memory_consolidate（30 分钟冷却）：检测矛盾记忆（比如同时存在”用户偏好 tabs”和”用户偏好 spaces”），修复孤立的图节点。
  • memory_reflect（2 小时冷却）：通过 LLM 对记忆集群进行高层次归纳，生成洞察。

这三个机制构成了一个自维护闭环——不依赖外部干预，自动维护记忆的健康度。

对比之下：Mem0 的冲突整合是被动的（新记忆写入时触发），Letta 依赖 Agent 自身的判断力（不可靠），MemOS 在 MemGovernance 层有初步实现但尚未经过大规模生产验证，Mem9 和 HydraDB 则完全没有这一层。

3.3 决策三：MCP 原生 + 多 Agent 共享

Memoria 通过 Model Context Protocol（MCP）标准暴露所有能力。这意味着任何支持 MCP 的 Agent（Kiro、Cursor、Claude Code 等）都可以直接接入，无需适配层。

更关键的是其多 Agent 共享模型：同一用户下的多个 Agent 共享一个”可信记忆池”（trusted memory pool）。Agent A 在 Kiro 中存储的偏好，Agent B 在 Cursor 中可以直接检索到。

这与 Mem0 和 Letta 的”按 Agent 隔离”模型形成对比。在多工具协作日益普遍的今天（开发者同时使用 Kiro 写代码、Claude 做设计、Cursor 做调试），跨 Agent 的记忆一致性是一个真实的需求。

4. 架构纵剖：从 Agent 到 MatrixOne 的完整数据路径

Memoria 的运行时架构可以拆解为四层：

1
2
3
4
5
6
7
8
9
10
11
12
┌─────────────┐     MCP (stdio)          ┌──────────────────────────┐
│  AI Agent    │ ◄─────────────────────► │  Memoria MCP Server      │
│  (Kiro /     │   store / retrieve      │  ├── Canonical Storage   │
│   Cursor /   │                         │  ├── Retrieval Engine    │
│   Claude)    │                         │  └── Git-for-Data Engine │
└─────────────┘                          └───────────┬──────────────┘
                                                     │ SQL + Vector
                                                     ▼
                                              ┌──────────────┐
                                              │  MatrixOne    │
                                              │  (HTAP + Vec) │
                                              └──────────────┘

第一层：Agent 接口层。通过 MCP 协议（stdio 传输）与任意兼容 Agent 通信。此外，Memoria 提供 Remote 模式，通过 REST API 代理请求，使客户端无需直连 MatrixOne。Agent 调用 memory_store、memory_retrieve 等工具，Memoria 作为 MCP Server 响应。

第二层：记忆语义层。Memoria 将记忆分为六种类型：semantic（项目事实、技术决策）、profile（用户偏好）、procedural（操作流程）、working（当前任务临时上下文）、tool_result（工具执行结果缓存）、episodic（会话摘要）。这种类型化存储使检索时可以按类型过滤，避免无关记忆污染上下文。

第三层：版本控制层。Git-for-Data 引擎在此层运作。每次写操作触发 snapshot 记录；branch/merge/rollback 操作在此层完成。底层利用 MatrixOne 的 CoW 语义，分支创建不涉及数据复制，只是元数据操作。

第四层：存储引擎层。MatrixOne 作为唯一存储后端，同时承担关系型查询（SQL）、向量索引（IVF）和全文检索三重职责。这意味着 Memoria 不需要拼接多个外部服务（向量数据库 + 图数据库 + 关系型数据库），所有状态收敛在一个引擎中。迁移成本为零——没有跨系统的数据同步问题。

这种”单一存储后端”的选择是一个值得展开的 trade-off：

  • 优势：运维简单，事务一致性天然保证，无跨系统数据漂移风险
  • 代价：与 MatrixOne 强绑定。如果用户已有 PostgreSQL 或其他向量数据库的投入，迁移到 MatrixOne 本身就是一个决策成本
  • 缓解：Memoria 提供 Remote 模式（通过 REST API 代理），可以将 Memoria 作为服务部署，客户端无需直接接触 MatrixOne

5. 实战场景：版本控制为什么不是”过度设计”

初看之下，给 Agent 记忆加版本控制似乎是”用大炮打蚊子”。但以下三个场景说明它解决的是真实痛点：

场景一：技术选型的安全评估

你让 Agent 帮你评估”把项目数据库从 PostgreSQL 迁移到 SQLite”的可行性。Agent 需要在记忆中临时修改大量技术决策记录。在 Mem0 或 Letta 中，这些修改直接作用于主记忆——如果评估结论是”不可行”，你需要手动恢复所有被改动的记忆。

在 Memoria 中：memory_branch("eval_sqlite") → 在分支上自由修改 → memory_diff("eval_sqlite") 预览变更 → 评估通过则 memory_merge，否则 memory_branch_delete。主线记忆全程未受影响。

场景二：大规模重构前的记忆快照

你即将对项目进行大规模重构，Agent 的记忆中存储了大量与当前架构相关的技术决策。重构过程中，这些记忆会被逐步更新。如果重构失败需要回退，代码可以 git revert，但 Agent 的记忆呢？

在 Memoria 中：重构前 memory_snapshot("before_refactor") → 重构失败 → memory_rollback("before_refactor")。代码和记忆同步回退，Agent 不会带着”新架构的记忆”去操作”旧架构的代码”。

场景三：合规审计

在金融或医疗领域，AI Agent 的每一个决策都可能需要事后审计。假设一个投资顾问 Agent 在凌晨 3 点基于记忆中的客户风险偏好自动调仓——事后客户投诉，合规团队介入。审计员需要回答：”Agent 在做出调仓决策时，它的记忆状态是什么？它读取了哪条风险偏好记录？这条记录是什么时候、由哪个 Agent 写入的？中间是否被修改过？”

Memoria 的 provenance chain 可以精确回答这些问题。每条记忆的每次变更都有完整的溯源链——谁写入、何时写入、是否被后续操作修改。在其他系统中，这需要额外搭建日志系统和审计管线；在 Memoria 中，这是内置能力。对于受 SEC、FINRA 或 HIPAA 约束的场景，这不是”nice to have”，而是合规底线。

6. 边界、局限与演进

Memoria 不是银弹。以下是它当前的明确局限：

生态成熟度。截至 2026 年初，Memoria 的 GitHub 社区规模与 Mem0 的 50K+ stars 相比差距悬殊。这意味着更少的第三方集成、更少的生产环境验证、更少的边缘场景覆盖。选择 Memoria 的早期用户需要承担”先行者成本”。Gartner 预测超过 40% 的 Agent AI 项目将在 2027 年前被取消——其中许多失败可以追溯到记忆架构这类基础设施决策做得太早或太随意。这既是警示，也意味着在早期做出正确的架构选择有长期价值。

存储后端绑定。MatrixOne 是唯一支持的后端。虽然 MatrixOne 本身是一个能力全面的分布式数据库（HTAP + 向量 + 全文），但”只能用 MatrixOne”这一约束在某些组织中会遇到阻力——尤其是已经在 PostgreSQL + pgvector 或 Pinecone 上有大量投入的团队。

Embedding 配置的不可逆性。Embedding 维度在首次启动时写入数据库 schema，事后修改需要重建列（破坏性操作）。这要求用户在部署前就做好 embedding 策略的决策，容错空间较小。

缺少图记忆。Mem0 的 Graph Memory 和 HydraDB 的 Ontology Graph 在实体关系建模上有明确优势。Memoria 虽然有 memory_extract_entities 和 memory_link_entities 工具，但其图能力更多是辅助性的，而非核心检索路径。对于需要深度语义消歧的场景（如客服系统中区分同名产品），Memoria 的表现可能不如图优先的方案。

演进方向的推演：

Agent Memory 赛道的终局形态，大概率是多种范式的融合。Memoria 的版本控制能力、Mem0 的提取-整合管线、Letta 的自主编辑机制、MemOS 的统一调度框架（已进入工程实现阶段）、HydraDB 的图语义——这些并非互斥，而是可以分层组合的能力。

Memoria 当前最需要补齐的短板是生态宽度（更多存储后端支持、更多 Agent 框架集成）和社区深度（更多生产案例、更多贡献者）。但它选择的”版本控制”这个切入点，恰恰是其他竞品最难后补的能力——因为版本控制需要从存储引擎层原生支持，不是在应用层加一个日志就能实现的。

7. 结语：记忆的工程本质

软件工程有一条被反复验证的规律：任何足够重要的可变状态，最终都会需要版本控制。代码需要 Git，数据库 schema 需要 migration，基础设施需要 Terraform state——现在轮到 Agent 的记忆了。

Mem0 证明了”Agent 需要记忆”这个命题。Letta 证明了”Agent 应该自主管理记忆”。MemOS 证明了”记忆管理需要系统级抽象”。而 Memoria 正在证明的是：记忆管理的工程本质，是版本控制问题。

当你的 Agent 在生产环境中做出一个关键决策，而你需要回答”它当时基于什么记忆做出了这个判断”——这个问题的答案，决定了你需要的是一个记忆存储服务，还是一个记忆版本控制系统。

Memoria 选择了后者。

→ GitHub: https://github.com/matrixorigin/Memoria
→ 官网: https://thememoria.ai/

参考文献

  1. Memoria — MatrixOrigin 开源的 Agent 持久化记忆层，核心创新为 Git-for-Data 版本控制。https://github.com/matrixorigin/Memoria
  2. Mem0 — 当前融资规模最大的 Agent Memory 项目（$24M Series A），提取-整合-检索三阶段管线。https://github.com/mem0ai/mem0
  3. Letta（前 MemGPT） — UC Berkeley 提出的 Agent 自主记忆管理框架，核心论文：MemGPT: Towards LLMs as Operating Systems。https://github.com/letta-ai/letta
  4. MemOS — 多机构联合提出的记忆操作系统框架，统一 plaintext/activation/parametric 三类记忆。论文：arXiv:2507.03724。工程实现：https://github.com/MemTensor/MemOS
  5. Mem9 — 轻量级云端持久化记忆基础设施，Apache-2.0 开源。https://mem9.ai/
  6. HydraDB — 本体优先的上下文图记忆系统（$6.5M 融资）。https://usecortex.ai/
  7. MatrixOne — Memoria 的存储后端，MySQL 兼容的分布式 HTAP 数据库，原生支持向量索引和全文检索。https://github.com/matrixorigin/matrixone
  8. Model Context Protocol (MCP) — Anthropic 提出的开放协议，标准化 LLM 与外部工具的通信。https://modelcontextprotocol.io
  9. Graphlit: Survey of AI Agent Memory Frameworks — 2025 年 Agent Memory 竞品横评。https://www.graphlit.com/blog/survey-of-ai-agent-memory-frameworks
  10. chanl.ai: AI Agent Memory Market Analysis — Agent Memory 市场规模数据（$6.27B in 2025, projected $28.45B by 2030）。https://chanl.ai/blog/voice-ai-memory-build-vs-buy-comparison
技术
#AI Agent #Memory #基础设施 #Memoria
AI Agent 的记忆该由谁来管？——从 Memoria 看 Agent Memory 的工程本质
https://chronosina.pages.dev/2025/12/01/memoria-agent-memory/
Author
ChronoSina
Posted on
December 1, 2025
Licensed under