政策不上链、结论先验证：ERC-8354 的保密策略裁决接口

智能体要替人执行链上操作之前，谁来拦一道？ERC-8354 给出了一个结构独特的答案，创建于 2026 年 7 月 16 日，仓库状态 Draft。它定义一份“保密策略裁决”的接口：链下策略引擎把一个候选动作对照规则集评估后，产出一个零知识证明，证明里绑定了动作承诺、执行地址、过期时间与一次性销毁标记，守卫合约只验这份证明，规则本身从头到尾不上链。它依赖 165、712、721、1271、7812 与 8004 六份标准，是智能体标准簇里最新一层闸门。

原文点名的两种授权模型都不够用

提案的动机部分把现有做法分成两类。一类是事后型：ERC-8004 在智能体行动之后登记身份、声誉与验证证明，适合用来挑选合作方，对拦截单笔操作无能为力。另一类是授权书型：验证者确认智能体的批量操作与用户预先签名的意图一致，授权额度计量智能体还能花多少。两类都把权限的来源设定为“某个主体签了某份授权”。但原文举了个反例说明现实里还有第三种形状：企业费用卡。持卡人没有逐笔签名，卡组织的反欺诈规则也不对持卡人和商户公开——权限来自一个第三方维护的常设规则集，每笔交易都被它检查，规则每周更新而没人重新签名，并且规则刻意保密，因为公开的欺诈规则等于公开的规避指南。

合规环境里的智能体部署同理：运营方维护筛查规则，规则对每个智能体生效而无需任何一方签署过它。原文据此排除两条捷径——把政策放上链，等于把规则发给它本要防范的对手；让链下预言机口头宣布“允许”，则没有任何证据证明确实执行过某个政策，裁决与随手一个签名无法区分。零知识恰好填进这个缝：验证者学到“某个已承诺的政策被正确评估并放行了”，除此以外一无所知。

接口层看到的东西很少

这份标准的自我定位写得很克制：不定义政策语言，不指定证明系统，不管传输方式，只定义裁决信封和验证接口。接口面一侧是 Policy Domain 把自己的规则集承诺登记进 ERC-7812 证据注册表；另一侧是守卫合约调用 verify 与 consume 两个入口，后者附带一次性 nullifier 的消耗检查（isConsumed），确保同一份裁决不能被用两次。审计历史决策时，原文特意要求注册表按版本分键存储、永不覆盖历史条目——否则每份证明依然能通过，审计线索却断了。这句话是整份文件里对运营方最硬的一条约束。

对 NFT 与智能体交集的意义

对追踪 ERC-8004 智能体登记生态的读者，这份草案的价值在结构而非落地：它说明智能体权限正在从“签名授权”单轨走向“授权加政策”双轨，前者管用户给了多少额度，后者管运营方的红线。将来遇到某个声称受治理的链上智能体，可以按这个框架追问：额度模型是什么、政策引擎由谁运行、政策版本在链上有无承诺、裁决一次性机制怎么实现。四个问题都答得出合约地址的，才是把闸门建在了可验证的地基上；答不出政策版本承诺的，其“合规”仅是流程外包的口径。本文为机制说明，不构成任何投资建议

与近邻标准的分工线

这份草案站在几条标准线的交汇处，把线划清有助于理解它的位置。ERC-8004 管智能体的公开身份与声誉登记，回答“这是谁、干得怎么样”；ERC-7812 管 blinded 语句的注册与状态证明，回答“某个承诺在不在册、变没变”；ERC-8354 则把两者接到执行时刻，回答“这一笔动作被某个在册政策放行过没有”。三份叠起来恰好是事前、事中、事后各一层，缺任何一层都会留下盲区：只有登记没有闸门，智能体可以顶着好声誉干坏事；只有闸门没有登记，裁决绑定的身份无从锚定。读智能体赛道的新提案时，先用这三层检查表定位它补的是哪个洞，比读它的营销标题有效得多。

本文为机制说明，不构成任何投资建议。