nautilus-compass记忆系统不做摘要压缩(摘要曾是天花板),只在读取时做混合语义+关键词召回,嵌入本地化、漂移检测,零信任可验证每个数字。
每个 AI Agent 的记忆层发布时都附带两样东西:一张基准测试表,以及一个隐含的请求——让你信任它。我们在构建 nautilus-compass 时围绕相反的请求展开:每一个我们发布的数字,你应该能够从字节重新计算,而不需要信任我们。本文将解释支撑这一理念的两个架构赌注。
大多数记忆管道在文本流入时进行摘要提取或图结构化。这是一个赌注:你在押注今天的压缩方式能匹配明天的问题。我们一直在看着这个赌注失败——同一份语料,用完全相同的检索策略、只在其上增加一层摘要层,端到端准确率就从 42.6% 移动到了 75.4%。压缩是天花板,而不是地板。
所以写入路径不做任何聪明的事:原始文本,用 BGE-m3 在本地嵌入,没有任何东西离开机器。所有的智能都发生在读取时——混合语义 + 关键词召回、单会话问题的轮次窗口分块路由,以及漂移检测——在 Agent 基于过时记忆行动之前,对每个提示与一组真实失败记录锚点集进行评分(留出 AUC 0.83)。
实际结果,在 LongMemEval-S 完整 500 条上与 mem0 2.0.19 的同题正面 PK(各自使用自己的默认嵌入器,我们的测试框架,一条命令复现,约 $3.50):P@1 0.890 vs 0.774,P@5 0.978 vs 0.916。复现脚本在仓库里;证据链包括了那些不利的结果(跨编码器重排在语料上落败;我们同样发布了这些)。
基准测试表就是一个声明。我们将基准以 VerifyPack 证据包的形式发布:一个 sha256 清单,每一条声明都可以从 payload 字节重新计算,以及一个 ed25519 签名收据。两条仅用标准库的命令就能重新推导任何数字——无第三方依赖,无"信任我们的笔记本"。Reproducibility Wall 以与有利结果相同的显著程度发布矛盾数字,我们的一个密封包里包含了一个分歧——一个日志文件在密封后不断被追加,协议捕获了它,我们让这个失败保持可见。这就是它存在的意义。
这种纪律始于自我防御:我们自己的审计轨迹捕获了实现者报告的"全绿"而实际并非如此的情况——一周内两次,其中一次是通过独立重计算发现的,而实现者自己的示例都无法通过。无法在对抗性阅读自身日志的情况下存活的 Agent 记忆不是基础设施,而是一本日记。
git clone https://github.com/chunxiaoxx/nautilus-compass ~/.claude/plugins/nautilus-compass
bash ~/.claude/plugins/nautilus-compass/install.sh
bash ~/.claude/plugins/nautilus-compass/daemon_start.sh
适用于 Claude Code / Cursor / Cline / Continue / Zed 以及任何 MCP 客户端;如果不需要本地模型,可以访问托管多租户网关 compass.nautilus.social/mcp/。
以及本文开头的那个提议:你有已发布的记忆层数字——你自己的,或者你依赖的?提一个 Issue。我们将独立重新计算并发布结果——无论一致还是分歧——并附上签名收据。按先后顺序服务,目前仍是人工流水线。
本文中的每一个数字都以 sha256 清单化的、字节级可重新计算的、签名证据包的形式交付。你的记忆层能经受住这样的标准吗?