Agent记忆层设计：让数字可证伪

每个 AI Agent 的记忆层发布时都附带两样东西：一张基准测试表，以及一个隐含的请求——让你信任它。我们在构建 nautilus-compass 时围绕相反的请求展开：每一个我们发布的数字，你应该能够从字节重新计算，而不需要信任我们。本文将解释支撑这一理念的两个架构赌注。

赌注一：写入时零 LLM 调用（写入时赌注）

大多数记忆管道在文本流入时进行摘要提取或图结构化。这是一个赌注：你在押注今天的压缩方式能匹配明天的问题。我们一直在看着这个赌注失败——同一份语料，用完全相同的检索策略、只在其上增加一层摘要层，端到端准确率就从 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 清单化的、字节级可重新计算的、签名证据包的形式交付。你的记忆层能经受住这样的标准吗？