1 篇博文 含有标签「protobuf」

第一次痛苦的智能体记忆（agent-memory）迁移总是教会我们同一个教训：存在两个模式（schema），而你只迁移了其中一个。存储层没问题 —— 每一行都已重写，每个键（key）都是新的形态，回填（backfill）作业也记录了成功。但智能体还是坏了。它继续向 user.preferences.theme 写入，却检索不到任何内容，然后从上下文中煞有介事地合成一个默认值，就好像这个键从未存在过一样。迁移操作手册显示一切正常。用户却报告记忆过时。

这种不对称是结构性的。一个依赖于重命名列的传统服务会收到硬错误，然后你进行修复。而一个依赖于重命名记忆键的智能体则会遇到软缺失，并围绕它进行胡编乱造。模式存在于两个地方 —— 你的存储和模型的上下文 —— 而你只能通过 SQL 脚本迁移其中的一个。

Protobuf 在二十年前通过规范化“仅限增加”的准则解决了这类问题的一个变体：字段是永恒的，数字是永恒的，网络类型永远不变，删除被弃用（deprecation）所取代。这一准则是智能体记忆的一个良好起点，但有一个额外的约束使其变得更加困难。Protobuf 接收者在设计上会忽略未知字段。智能体则不会。