AI 智能体的验身流程：ERC-8126 五种验证与风险分

能持币、能签名、能在市场上替你竞价的 AI 智能体越来越多，“这个智能体是谁部署的、代码干了什么”成了新问题。ERC-8004 用注册表给智能体发链上身份，ERC-8126 则负责核验：给注册过的智能体做五类体检，每项输出风险分。该提案在 ercs 仓库的状态是 Final（最终），创建于 2026 年 1 月 15 日，依赖 ERC-155、ERC-191、ERC-712、ERC-721、ERC-3009 和 ERC-8004。

验证必须从 agentId 出发

流程的第一条铁律：验证请求必须引用 ERC-8004 身份注册表里的 agentId——也就是那枚 ERC-721 的代币编号。提供者必须调用注册表的 tokenURI(agentId)，取回注册 JSON，再从这份文件里抽钱包地址、链 ID、合约地址、端点 URL、图片、代码等全部字段；绕过 agentId 直接递参数是不被允许的。这条规则堵的是“验证对象与展示对象不一致”的调包空间：验的就不是你以为的那个。

五种验证各查什么

合规提供者必须五项全做。ETV（代币/合约验证）在元数据含合约地址时，用 eth_getCode 确认链 ID 对应链上确实部署了该合约，对照已知漏洞模式，依据 OWASP 智能合约安全验证标准 SCSVS 给 0 到 100 的分。MCV（媒体内容验证）针对 imageUrl：做取证分析检测 AI 生成与深度伪造迹象、核验内容出处与嵌入元数据（建议参照 C2PA 实施指南）、检查数字水印与签名。SCV（Solidity 代码验证）确认声明的代码确实部署在对应链上，并排查重入、闪电贷攻击等常见漏洞。WAV（Web 应用验证）测端点 HTTPS 可达、SSL 证书有效期、常见 Web 漏洞，参照 OWASP WSTG。WV（钱包验证）确认钱包有交易历史、比对威胁情报库。五项分数汇总为整体风险分与风险档，接口提供 calculateOverallRiskScore、getRiskTier、getLatestRiskScore 查询，验证完成发 AgentVerified 事件。

报告能证明什么，不能证明什么

能证明的部分很具体：合约在不在、代码部署对不对、网站证书是否有效、图片有没有合成痕迹——这些是脚本可复跑的客观检查。不能证明的部分同样要讲清：验身通过不等于智能体不会作恶，逻辑合规的合约也能执行坏意图；风险分是提供者按清单打的快照，端点明天被换、代码后天升级，分数不会自动跟随；而取证模型对合成媒体的识别本身有漏检率。读报告的姿势应是“查分项、看时间、认提供者”，三份不同机构的报告本来就可能给同一个智能体打出不同的分。

一次完整的验身会看到什么

把流程走完一遍：客户端向验证提供者提交 agentId；提供者读 ERC-8004 注册表的 tokenURI(agentId)，取回注册 JSON 并按 schema 抽字段；随后五项检查依次展开——对 contractAddress 跑 ETV，对 imageUrl 跑 MCV，对 solidityCode 跑 SCV，对 url 端点跑 WAV，对 walletAddress 跑 WV；每项产出 0 到 100 的分，提供者经 generatePDVProof 生成私有数据校验证明，把结果通过 AttestationPosted 等事件落到链上，链上即可用 getLatestRiskScore 与 getRiskTier 读最新分数与档位。对普通用户，这条流水线的意义在于报告不再是截图：报告哈希与提供者地址都在链上，过期版本会留下事件序列。读报告至少核对三件事——出具报告的提供者地址是否可信、报告时间距离你查看它隔了多久、五项里哪一项分最低，木桶效应适用于一切风险分。

把五项检查当消费维权语言来记更直观：合约与代码两项回答“这东西是不是它自称的程序”，Web 项回答“它给的用户界面归谁管”，媒体项回答“它的形象素材是不是拼贴的”，钱包项回答“它账户的历史乾不干净”。五个角度拼不出完整人格，但缺任何一角都值得警惕。

顺带把阅读节奏给出：日常抽查看风险档，交易前看单项最低分与报告时间，合作前直接找提供者核验原始 agentId 与注册 JSON 的一致性。

对收藏带 AI 属性的 NFT 或授权智能体代操作的用户，这套标准给你的是一条可核验的尽调路径，但决策仍然落在你自己手里：验证是工具，不是背书。本文为机制说明，不构成任何投资建议。