在上一篇文章《从 0 到 1：我用 300 行代码给 AI 记忆加上了“不可篡改的收据”》中，我开源了 AMP (Attestation Memory Protocol) 的 v0.1 版本。
v0.1 解决了一个核心痛点：审计追踪。通过 Hash Chain，我们能向用户证明“AI 没有偷偷篡改你的记忆”。但很多朋友在评论区提出了新的疑问：
“如果服务端被攻破，数据是明文的，那哈希链只能证明没被改，不能证明没被偷看啊！”
为了解决这个问题，我把协议升级到了 v0.2.0，核心引入了 AES-256-GCM 端到端加密。
但工程上最棘手的点来了：在引入加密的同时，必须保证完全向后兼容（即不能破坏原有的 8 个黑盒一致性测试）。 既然数据加密了，那原来基于明文算出来的哈希值怎么办？
今天就来聊聊我在这套架构设计中的核心思路。
核心设计：密文存储，明文哈希
在传统的数据库加密中，通常加解密是在数据库层面（透明数据加密 TDE），但对应用层来说，返回的依然是一串密文。如果直接把整串密文扔进 Hash Chain 里，由于加密算法引入了随机 IV，相同的明文每次加密出的密文都不一样，这就直接破坏了“证据声明”的确定性。
因此，我采用了 “密文存储，明文哈希” 的设计：
- 在写入时：如果客户端传入
encrypted: true，AMP 会对内容进行 AES-256-GCM 加密，生成iv、encryptedData和authTag，将它们打包成 JSON 存入content字段。但用于计算contentHash的，依然是用户最初传入的明文内容。 - 在读取时：只有拿到了合法
Grant权限的客户端，请求到数据后，守护进程才会用派生密钥（scrypt）解密，并将明文返回给客户端。 - 在验证时：任何人依然可以用明文的
contentHash去和 Hash Chain 里的记录进行比对。
为什么这样设计是安全的？
因为哈希算法（SHA-256）是单向的。即使外部攻击者拿到了完整的 contentHash 和加密的事件日志，他们也绝对无法通过哈希值反推出明文内容。这既保证了隐私（防偷窥），又维持了不可篡改性（防篡改）。
跨设备同步：只追加，不覆盖
除了加密，v0.2 还引入了跨设备同步。
为此新增了两个接口：
GET /v1/sync/export：导出本地的完整事件链和记忆数据。POST /v1/sync/import：接收其他节点的数据。
同步的最难点在于“冲突处理”。我的设计是只追加合并：
当导入一个事件列表时，程序会遍历检查。如果该事件的 hash 在本地已经存在，说明是同源数据，直接跳过；如果不存在，则按序追加到本地的事件链中。这样保证了多个设备的审计链即使存在网络延迟，最终也能收敛成一条最长链。
测试与向后兼容：用结果说话
架构设计得再好，不能跑通也是白搭。我立刻用 v0.1 时期的黑盒测试套件重新跑了这套 v0.2 的代码。
测试用例没有修改哪怕一个字符。
PASS write without attestation rejected
PASS grant work scope to app-a
PASS write with full attestation succeeds
PASS read without grant forbidden
PASS read with grant returns attestation
PASS revoke grant
PASS read after revoke forbidden
PASS verify chain ok
8 passed, 0 failed
看到这满屏的 PASS，我才确信这次的协议升级是平滑、安全且完全向后兼容的。
下一步规划：v0.3 与 Merkle Tree
目前 AMP 协议依然保持着 Node.js / Go / Python 三套零依赖实现，以及全绿的 GitHub Actions 自动化流水线。
下一个版本（v0.3），我计划引入 Merkle Tree（默克尔树） 。现在的 Hash Chain 适合单机验证，但如果未来设备节点变多（比如你的手机、电脑、车机都在跑 AMP），我们需要一个更高效的数据结构来验证同步事件的一致性，而 Merkle Tree 就是最优解。
- GitHub 仓库：github.com/doujiaozh/a… （求个 Star ⭐）
- MCP 接入：目前已经支持通过 Model Context Protocol 接入 Cursor 等工具。
如果你对“让 AI 拥有可验证、可携带的隐私记忆”感兴趣，欢迎来仓库提 Issue 交流！
