一个正在替你订机票、管理日程的 AI 代理，它的”记忆”存在哪里？答案多半是某个私有数据库。以太坊上有一份 2026 年 7 月提交的草案提案 ERC-8350，想解决的问题很具体：怎么在不公开记忆内容的前提下，为代理记忆的每一次状态变化留下可验证的链上凭证。它是标准的 ERC 轨道草案，还在征求意见阶段，但机制骨架已经值得一读，因为它把”链上登记私有状态”这件事的最小必要结构提炼得很干净。
先立概念。提案给每段变化起了名字：ExperienceDelta，一次”经验增量”，指代理记忆从状态 A 到状态 B 的那一步迁移。链上不存 A 和 B 的内容，只存一个 EIP-712 结构哈希——用以太坊成熟的结构化数据签名标准把这次迁移的身份唯一化。任何人质疑”这个代理在某个阶段记忆到了第几版”，注册表合约能回答的不是内容，而是版本序列与先后关系：第 17 号状态是不是第 16 号的唯一合法后继。
登记簿的每个”记忆空间”配两个角色：控制者负责空间的运维与规则，授权者是能代表记忆主人签名的地址——外部账户和 ERC-1271 合约账户都支持当授权者，意味着代理可以挂在一个智能钱包底下完成签名。这套双角色设计回应了提案在动机部分列举的哈希方案缺陷：随手发一个内容哈希上链，回答不了三个问题——这个哈希推进的是哪个前置状态、它是不是当前状态的唯一后继、命名空间的控制与签名权在谁手里。ERC-8350 的答案是用一个线性状态机把这三问都变成接口函数。
读这类草案，同样重要的是读它”故意不管什么”。原文写得很克制：负载语义、存储方案、记忆的类别学、推理证明、删除证明、交易市场——全部划出核心接口之外。这不是能力不足，而是协议设计的常见自保：先让”可验证的状态序”成为公共品，语义之争留给上层生态。理解这条边界，你就知道拿它比较”AI 记忆能不能全上链”是问错了问题——它的定位类似账本，不类似仓库。
普通用户什么时候会碰到它？大概率不是直接使用，而是在两类产品里间接相遇：声称记忆可审计的个人 AI 助理，和需要证明行为链路的自治代理服务。那时可以问出的有效问题包括：这个记忆空间的控制者是谁、更换授权者需不需要我确认、给我看的”状态哈希”能不能在登记合约上查到并且与它宣称的前一状态构成连续序列。三个问题的答案都能从链上直接验证，不需要听服务商叙述。
草案阶段需要打的预防针也必须打足：ERC 编号不等于任何链已启用，Draft 状态意味着接口随时可能改动，甚至可能最终搁浅。把它当”已发生的基础设施”向别人转述，是把提案状态读错了档。
把一个还在草案阶段的标准读成一份风险清单，是普通读者最划算的读法。第一问状态：草案意味着接口还会改，今天按它写成的任何流程，下个月可能对不上，把草案级标准用于生产系统之前，先确认自己依赖的是哪个版本、变更公告盯在哪里。第二问边界：这份提案把内容验证和状态可信切得很开——链上凭证只能证明登记过的状态按规则推进过，内容的真假、模型有没有胡说，凭证一概不管；拿它宣传记忆绝对可信是对机制的误读。第三问角色：控制者与授权者的分工决定了谁有权让登记簿继续运转，接入前弄清这两个角色在合作架构里归谁，服务方中途变更授权关系会影响已接入系统的可用性。第四问迁移：登记簿设计为无状态可替换，合约被替换后旧记录的读取路径是否延续，要在合作协议里写明白。把四问答完，你不需要同意这项提案的每一个设计，也能判断它现在适不适合承载你的场景——对草案标准，判断何时不该依赖它比抢早接入更有价值。
本文为机制说明，不构成任何投资建议。提案内容以 Ethereum ERCs 仓库原文为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。