Memanto：面向长程 Agent 的带类型语义记忆 + 信息论检索

关联论文：2604.22085
作者：spark
更新：2026-07-08

一句话结论

Memanto 用一个十三类带类型的记忆 schema + 自动冲突解决 + 时间版本控制，配 Moorcheh 的"无索引、确定性、亚 90ms"信息论检索引擎，在 LongMemEval 拿到 89.8%、LoCoMo 拿到 87.1% 的 SOTA 准确率，同时只需一次检索查询、零入库延迟——正面打脸"agent 记忆必须靠复杂知识图谱"的主流假设。

解决的真问题

把语言模型从"无状态推理"推到"持久化、多会话、自主 agent"后，业内普遍认为：agent 记忆 = 知识图谱。于是入库侧要 LLM 做实体抽取、关系归一、schema 维护；检索侧要多路召回 + 多查询改写 + graph traversal；GPU 时间、token 费用、运维复杂度一起爆炸。

论文挑战的"真问题"是：能不能用更轻的语义结构 + 一个不需要预索引的检索引擎，达到或超过知识图谱的记忆保真度？

答案：能，前提是 (1) 记忆类型被显式约束；(2) 冲突和版本被显式处理；(3) 检索是确定性、信息论意义上的，而非 ANN 近似。

核心方法

三大组件

Typed Semantic Memory Schema (13 类)：用户偏好 / 角色 / 关系 / 任务 / 事件 / 计划 / 偏好 / 事实 / 信念 / 约束 / 资源 / 结果 / meta 等 13 个预定义类别。每条记忆带 type + 时间戳 + 来源。入库走 LLM 分类 + 写库。
Conflict Resolver + Temporal Versioning：同 type / 跨 type 冲突路由；每次写入生成新版本，旧版本保留但不参与主检索。
Moorcheh 信息论检索引擎（ITS）：无索引、确定性、信息论相似度、亚 90ms 延迟，单次检索即可。

1. 带类型的语义记忆 Schema（13 类）

Memanto 不让 LLM 自由写"任意内容"，而是约束到 13 个预定义类别（user profile、role、relationship、task、event、plan、preference、fact、belief、constraint、resource、outcome、meta 之类——具体 13 类的完整命名以原文表 1 为准）。好处：

检索语义对齐：先判 query 意图类型，再只在该类型子空间里检索，避免跨类型误召。
冲突可控：同 type 内冲突可走统一合并策略（LWW、CRDT-ish）。
可观测：每条记忆有 type + 时间戳 + provenance，可审计、可回放。

2. 自动冲突解决 + 时间版本控制

同一 type 出现"互相打架"的记忆时，由 resolver 按规则合并（不是简单 LLM 自由发挥）。
每次写入生成新版本，旧版本可查询但不参与主检索（read-your-writes 行为可控）。
这一层对长程 agent 至关重要——同一个用户偏好在不同会话被反复提到，没有 versioning 就是定时炸弹。

3. Moorcheh 信息论检索引擎（ITS）

这是 Memanto 区别于所有 vector DB / hybrid graph 方案的关键：

无索引（no-indexing）：不需要离线建 embedding index，"入一条就能查一条"——零入库延迟。
确定性（deterministic）：基于信息论相似度（论文没指明是 KL / JS / total variation 中的哪一个或自研变体，原文未明确具体形式），同一 query 同一库结果完全可复现，区别于 ANN 近似。
亚 90ms 延迟：benchmark 规模下端到端单次检索 < 90ms。
系统意义：单次检索就够，不必 multi-query rewrite、不必 graph traversal。

关键伪代码（按论文描述还原）

# 1. 入库
mem = Memory(
    type=classify(raw_utterance, schema=13_TYPES),  # 13 类
    payload=raw_utterance, ts=now(), src=message_id,
)
mem = conflict_resolver.resolve(mem, store)         # 同/跨 type 合并
store.append_versioned(mem)                         # 保留旧版本

# 2. 检索
q = agent_query
qtype = infer_query_type(q)                         # 路由到 1~多个 type
hits = moorcheh_its.search(
    store.filter(type__in=qtype), q, metric="it", top_k=K,
)
# 一次检索即可，不必 multi-hop / multi-query
answer = llm.generate(q, context=hits)

关键实验与数据

基准：LongMemEval（长程记忆评测套件）、LoCoMo（长上下文记忆评测）——都是考察"多会话、过千轮级"记忆保真度的标准尺。
结果：
LongMemEval：89.8%（SOTA）
LoCoMo：87.1%（SOTA）
基线：所有被评测的 hybrid graph + vector 系统（具体名单以原文 Table 为准）。
消融：5 阶段渐进式 ablation，量化每个架构组件的贡献。
系统开销：单次检索查询、零入库成本、显著更低的运行复杂度（相对 hybrid graph 方案的关键优势）。

亮点

范式翻转：从"图谱即记忆"翻到"类型化语义记忆 + 信息论检索"，系统开销曲线完全不一样。
零入库延迟：Moorcheh ITS 不预建索引 → 入一条就能查一条，实时性极强，特别适合 streaming / interactive agent。
确定性检索：信息论度量是 exact match 而非 ANN 近似，可复现性 / 调试性大幅提升。
Schema 化的工程美学：13 类强类型 + resolver + versioning 对长期可维护性极其友好。
双基准 SOTA：LongMemEval + LoCoMo 同时 SOTA。
可审计：type + ts + provenance 天然可追溯，合规 / 调试都受益。

局限

13 类是否够用取决于领域：通用对话够，垂直行业可能要扩 schema——扩了之后 routing 是否仍稳定，原文未明确。
信息论相似度的可解释性：相对 cosine / dot product，信息论距离在不同类型记忆上的"语义匹配质量"需要更多案例验证（原文未明确给出细分对比数据）。
冲突解决策略细节未充分公开：resolver 是规则、LLM 还是 learned，论文没在摘要级别点透（原文未明确具体实现形态）。
规模边界：亚 90ms 是"benchmark 规模"下的数字；库规模到百万、千万级是否仍保持，原文未明确。
依赖 Moorcheh：检索引擎是论文自带的（Moorcheh's Information Theoretic Search engine），外部团队复现需要先拿到 / 自实现一个无索引信息论检索器，门槛不低。
多模态记忆不在范围内：定位是文本对话 / 任务型 agent，多模态 / 视频 / 音频记忆没覆盖。

对工程落地的启发

先类型化，再聊图谱：把"先抽实体、构关系、入图"换成"先分类、入带类型的语义记录"，80% 的 agent 场景够用。
入库延迟是隐藏瓶颈：实时对话 / 工具调用中"写完不能立即读"会引发 race condition，零入库延迟值得抄。
确定性 > 近似：踩过 ANN 召回不稳的坑时，确定性检索比换更好的 embedder 更划算。
冲突 / 版本是必备件：长程 agent 必须显式处理，否则用户偏好类信息就是雷。
可观测性模板：每条记忆带 type + ts + src，是 agent memory 的最低可观测性标准。
别过度工程化：13 类 + 一次检索能解决，不必上 graph DB + multi-hop。

与同方向工作的关系

vs. Knowledge graph 派（A-Mem、Zep、GraphRAG、Mem0、LangGraph Memory）：用"显式类型 + 信息论"对抗"图结构 + ANN"，长程记忆 benchmark 上同时 SOTA。
vs. 向量库 + metadata（Milvus / Qdrant / Weaviate）：把 metadata 从"过滤辅助"提升为"一等公民 + 路由信号"。
vs. MemGPT / Letta 的"虚拟上下文管理"派：MemGPT 关心"记忆怎么压进 context window"，Memanto 关心"记忆怎么组织、怎么查"，互补。
vs. RAG 经典派：RAG 是"无状态问答 + 临时检索"，Memanto 是"持久记忆 + 持续检索 + 类型治理"。

适合谁读

Agent 平台架构师——决定 memory layer 用 graph / vector / typed semantic 时的反方证据。
AI 产品经理（C 端助手、企业 agent、客服）——89.8 / 87.1 是直接对标的数字。
LLM-infra 工程师——想找"确定性、低延迟、零入库延迟"记忆层的实现思路。
RAG 重度玩家——当 RAG 系统"记不住历史 / 反复犯同样错"时，是明确的升级路径。
学术研究者——graph-based memory 的护城河正在被信息论 + typed schema 攻破，是方向性信号。
不适合：单轮 / 短上下文场景，typed memory 的工程开销不划算。

工程落地与核查（Jay）

事实核查注记

✅ 89.8% / 87.1% 双基准 SOTA：原文有据，但基线系统列表未在摘要中披露，建议对照原文 Table 对比具体对手名称。
⚠️ 13 类 schema 实际名称：原文表 1 有完整列表，本解读用"用户偏好 / 角色 / 关系…"做英文别名混写，存在小概率与原文语义略有出入（如"preference"出现两次可能对应不同子类）。
⚠️ Moorcheh ITS 的信息论相似度形式：KL / JS / total variation / 其他，原文未在摘要层面明确，实现前需读原论文 §3 确定度量形式；不要假设是标准 cosine 或 dot-product。
⚠️ 亚 90ms 的库规模：benchmark 规模未说明具体是多少条记忆——如果只是万级，百万级的性能曲线是未知的。
❌ 未发现明显事实错误；Resolver 是规则型还是 LLM 型未披露（已在局限节标注）。

工程落地路径

推荐起步实现（不依赖 Moorcheh）

Moorcheh ITS 未开源，外部团队需要用现有组件替代。以下是可工作的等效组合：

写入路径：
  LLM(classify) → typed memory record → resolver → versioned store
  可用：PostgreSQL（jsonb 存 payload + type 索引）/ SQLite + 业务逻辑

检索路径（替换 Moorcheh ITS）：
  方案 A（确定性近似可接受）：向量库（Qdrant / Milvus）+
    metadata filter(type==qtype)，用 cosine 近似信息论相似度
  方案 B（严格确定性）：BM25 / 关键词 + type filter，延迟低但语义泛化能力弱
  方案 C（自研 ITS）：如果对亚 90ms + 确定性有硬需求，需自己实现
    Moorcheh——大概率是类似「token 集合的信息增益」度量，
    实现难度中等，但需要与向量库方案做对比 benchmark

实际系统怎么用

# 极简起步：用 Postgres + pgvector
CREATE TABLE memories (
  id UUID PRIMARY KEY,
  type TEXT NOT NULL,           -- 13 类之一
  payload TEXT NOT NULL,
  ts TIMESTAMPTZ NOT NULL,
  src TEXT,
  version INT DEFAULT 1,
  parent_id UUID REFERENCES memories(id)
);

CREATE INDEX ON memories USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 100) WHERE is_active = true;

# 查询时：先判 type，再在子空间内检索
SELECT * FROM memories
  WHERE type = $1
    AND is_active = true
  ORDER BY vector_cosine_distance(embedding, $query)
  LIMIT $top_k;

坑在哪

分类 LLM 调用是写入延迟的主要来源：Memanto 声称零入库延迟，但 LLM classify 这一步通常 200–500ms。要在 streaming 场景用，需要异步写入（write-behind）或缓存已有类型分类结果。
13 类不够就要改 schema，但改了旧记忆不自动迁移：扩 schema 之后已有记忆的类型标签不会自动更新，需要一次性的 migration script，否则新旧 type 混用导致路由失效。
冲突 resolver 的实现质量直接决定记忆一致性：如果用 Last-Write-Wins（LWW），用户在不同设备 / session 的冲突写入会直接覆盖——对「偏好」类记忆可接受，对「事实」类记忆是坑。建议对不同 type 配置不同合并策略（可参考 CRDT 库 yjs）。
Moorcheh 未开源导致的复现门槛：团队如果无法接入 Moorcheh，用向量库替代时本质上是把「确定性」换回了「近似」——需要明确这个取舍对业务的影响。
版本积累导致的存储膨胀：每次更新写新版本，旧版本不删除。百万级 agent 场景下，活跃记忆子集和全量版本历史需要分开存储（冷热分离），否则查询性能会退化。

工程选型建议

场景	推荐起步	关键取舍
快速验证 / POC	Postgres + pgvector + 13 类	确定性换近似，分类有延迟
生产级低延迟	Qdrant（metadata filter）	需要额外运维；ANN 近似不可避免
强确定性需求	SQLite + BM25 + type filter	语义泛化弱，适合结构化强的 domain
追求极致（愿意自研 ITS）	基于 token 集合的信息增益度量	实现成本高；建议先 benchmark 对比向量库