检索日志≠审计追踪：6款Supermemory替代方案横评

当Agent答错问题时，多数人第一反应是打开检索日志。日志会返回一堆从存储中召回的记忆ID，但它不会告诉你：哪些ID在排序后真正进入上下文、哪些因token预算被截断、当时记忆的正文是什么、有没有策略规则在组装前把某条记忆踢掉。

三周后情况更糟。一次compile任务可能已经重写了部分记忆，你手里的日志变成了一串指向“已变更内容”的指针，解释力归零。这个缺口正是本文横向对比六款开源Supermemory替代方案的唯一轴线——其他对比维度已被写烂了。

Supermemory替代方案对比

为什么团队先上Supermemory，再找出路

Supermemory把对话记忆、文档检索、用户画像和本地编码Agent记忆收拢在一个API后面，本地版原型验证速度确实快：SDK指向localhost、改base URL，同一套代码就能跑在云端。对希望单一供应商接管整个上下文栈的团队来说，这是合理起点，文档处理广度也是下面多数替代品比不了的。

真正让人寻找替代品的，很少是API，而是部署限制那条线。据supermemory-server 0.0.7发布说明，自托管版本授权上限为1万份文档，且在API层强制执行、启动时展示；0.0.8版本未重申该限制。官方定价页显示支持的自主托管出现在399美元/月的Scale套餐，气隙部署仅限企业版。两个开放issue值得在规划容量前阅读：#1366报告约5000条记忆、2GB存储却占用约7GB常驻内存；#1413描述每十秒一次的全库快照。这是两个环境的两份bug报告而非基准测试，宜当作提问清单而非定论。

日志与审计追踪之间的四个属性

“我们记录检索”是多数工具的终点。真正的审计追踪需要满足四点：

记录的是组装后的集合，而非候选集合：经过排序、截断和策略过滤后真正进入prompt的内容。
不可变且可寻址：能扛过下一次compile，六个月后还能按ID取回。
防篡改：对字节做哈希，争议时记录才有价值。
可重放：能拿记录的输入重跑组装，看行为是否变化。

一份最小回执长这样：包含receipt_id、subject_id、task、created_at、token预算（max_tokens/used_tokens）、included数组（含memory_id、kind、来源episode、token数与排名）、excluded数组（含剔除原因如policy:deny:pii或budget），以及integrity字段（HMAC-SHA256摘要）。

excluded数组是最常被跳过、却最能回答事后复盘问题的字段——复盘真正想问的往往是“Agent本该知道的事为什么没送到”。

HMAC-SHA256 是一种基于 SHA-256 哈希函数和密钥的消息认证码，用于验证消息的完整性和真实性。在审计回执中，它并非简单地对数据做哈希，而是将回执内容与一个只有服务端持有的密钥一起计算摘要。这样，任何对已存储回执的字节改动都会导致摘要不匹配；同时，不知道密钥的一方无法伪造一份看似有效的回执。与普通哈希相比，HMAC 额外提供了对抗恶意篡改的能力，适合在争议场景下作为不可抵赖的证据。代价是密钥管理成为安全边界的一部分：密钥泄露意味着回执的防篡改属性失效。

六款方案逐一拆解

1. Statewave：在自有Postgres上实现可重放上下文

Apache-2.0协议，依赖Postgres 14+与pgvector、Python 3.11+。交互以追加式episode落地，compile步骤将其转为带置信度、有效期和来源episode ID的类型化记忆。组装在token预算下排序，YAML策略先评估deny与redact规则（支持log_only与enforce模式）。每个bundle发出带HMAC-SHA256签名的回执，并提供重放端点。

可重建上述全部四个属性。代价是自备Postgres，外加compile时的LLM调用。

2. OpenViking：补上Supermemory用户真正缺的文档广度

AGPL-3.0服务端。上下文被组织成viking://URI下的可浏览文件系统，三级读取模型让Agent先拉摘要再取全文。文档与多模态广度是这份清单里最强的，也正是Supermemory其他替代品补不上的部分。它能让Agent的读取路径可读——比一串ID强——但没有针对组装后prompt的签名记录。代价是自备基础设施，另需法务确认copyleft许可，或选择授权自管版本。

3. Hindsight：为“形成信念”而非“召回行”的Agent设计

MIT服务端，跑在Postgres或嵌入式pg0上。它把事实与经验同整合后的观察、心智模型分开，reflect步骤跨层合成，四条召回路径并行。如果你要的Agent结论有证据支撑而非单纯检索所得，这份清单里没有更接近的。可重建的是观察追溯至背后的经验——面向信念的来源追溯，而非面向prompt的追溯。代价是明显更多的模型调用，因为反思本身就是推理。

4. Mem0：团队大概率已用过的记忆API

核心Apache-2.0，另有托管平台。形态最熟悉：add、search、按用户划定作用域。自v3开源SDK起，图记忆仅限Platform版本，迁移前务必确认目标特性落在哪个版本。它能给你的是搜索返回的记忆，日志得自己记——拿到的是候选集而非组装集。代价是自备向量存储，外加抽取调用。

5. Graphiti：实体间带时间感知的事实

Apache-2.0，支持Neo4j、FalkorDB或Amazon Neptune。时序知识图谱，实体与关系各带有效区间，可以问“某日什么是真的”。实体间时间建模无出其右。它以引擎而非服务形式交付，身份、鉴权、队列、备份和应用API都得自己搭。可重建的是边的有效性——强大的事实历史，但没有prompt记录。代价是你得运维一个图数据库。

6. Letta：愿意采用整套运行时的团队

可编辑记忆块与对话记录，外加Git版本化的记忆文件系统，全部装在一个有状态Agent运行时里。六者中记忆设计最激进，代价也在范围：采用它意味着采用它的运行时。记忆文件系统有版本，能读到某次提交时某个块的内容。可部分重建，但替换掉的栈比新增的还多。

pgvector 是 PostgreSQL 的一个开源扩展，为 Postgres 增加了向量数据类型、近似最近邻索引（如 IVFFlat、HNSW）以及距离操作符。它让原本只存关系数据的 Postgres 能够直接存储和检索嵌入向量，从而把向量搜索与事务、行级安全、备份等数据库能力合并在同一套系统里。Statewave 依赖 Postgres 14+ 与 pgvector，意味着记忆的存储与向量召回可以在同一个数据库实例内完成，减少了独立向量数据库带来的运维复杂性和数据同步问题。代价是向量索引的规模上限和性能调优仍受 Postgres 本身约束，超大规模语料通常需要专门的向量数据库。

自家方案的短板

既然这是供应商对比里常被裁掉的那一半，不妨直说。Statewave没有托管云，得有人运维Postgres；没有实体关系图，实体按记忆逐个抽取，彼此无连接、不可遍历——若产品核心是实体间时序推理，选Graphiti；没有多模态RAG，PDF、媒体抽取、网页爬取和大规模文档语料恰是它替代不了Supermemory的部分，OpenViking更合适；租户隔离在应用层而非Postgres行级安全；服务端仅在Linux上做过CI测试。

四个问题定大半评估

第一，记忆的单元是什么：用户、账户、案件还是文档？先定这个，清单自动砍掉一半。第二，答错时谁来解释、向谁解释？若答案是“写代码的工程师”，日志够用，可以合上文章了。第三，部署边界在哪，免费构建够得着吗？读发布说明里的许可条款，别只看仓库徽章。第四，迁移后账单长什么样？自托管把按文档计费换成LLM抽取调用加某人的值班表，成本很少消失。

切换读取路径之前，先用影子模式把自家对话跑过两个候选方案，diff它们组装出的上下文。