作者:小白
本文为作者原创投稿,观点仅代表作者个人理解,ETHPanda 对内容进行编辑整理。
AI Agent 上链以后,问题就不只是“它能不能聊天”了。
它可能会签名、收款、发起交易、部署合约、管理钱包、调用 API,甚至和其他 agent 协作完成任务。这个时候,用户真正关心的不是它有没有一个好听的名字,而是:
这个 agent 到底靠不靠谱?
它的钱包是不是干净?它关联的合约是不是真的存在?它的网站和 API 有没有风险?它发布的媒体内容是不是伪造的?它的 Solidity 代码有没有明显漏洞?它是不是已经被攻击过?
ERC-8126 瞄准的,就是这类验证问题。
简单说,ERC-8126 是 AI Agent 的验证层。它建立在 ERC-8004 的 agent registration(身份注册)之上,让独立的 verification providers 可以围绕同一个 agent 身份做多层验证,并把结果变成钱包、市场、应用和其他 agent 都能消费的风险信号。
它不是要证明某个 agent 永远可信,而是把“怎么验证一个 agent、验证结果怎么表达、其他系统怎么读取这些结果”标准化。
有身份,不等于可信
ERC-8004 解决的是 agent 的身份问题。
你可以把它理解成:先让 AI Agent 在链上有一个可注册、可发现、可索引的身份。这个身份会对应一个 agentId,并通过 metadata 描述这个 agent 的名称、钱包、端点、网站、合约地址等信息。
但身份本身不等于信任。
一个恶意 agent 也可以注册身份。一个钓鱼 agent 也可以写一份漂亮的 metadata。一个 agent 今天正常,不代表明天端点不会被劫持。一个 agent 有头像、有官网、有钱包地址,也不代表它的合约安全、钱包干净、内容真实。
所以,ERC-8004 更像是在回答:
这个 agent 是谁?
ERC-8126 进一步问的是:
这个 agent 值不值得交互?
ERC-8126 怎么做验证?
首先,验证请求会引用 ERC-8004 Identity Registry 中的 agentId。Verification provider 再通过这个 agentId 读取对应的 metadata,并从中解析钱包、合约、网站、端点、媒体内容等信息,最后生成风险评分和验证证明。
这个流程可以拆成四步:
- AI Agent 先通过 ERC-8004 注册身份。
- ERC-8126 provider 读取这个 agent 的 agentId 和 metadata。
- Provider 对 agent 做多层验证。
- 验证结果以 risk score、proof、attestation 等形式被钱包、市场、dApp 或其他 agent 消费。
这里的重点是:ERC-8126 不引入一个唯一的“官方认证机构”。
它更像是一个开放的 verification provider 市场。不同 provider 可以用自己的方法做安全检查,但输出结果要按标准化格式表达。这样钱包、agent marketplace、任务市场和其他应用才能跨平台读取这些信号。
这比“项目方自己说自己安全”更进一步:它把信任判断拆成了可以被第三方检查、记录和读取的信号。
五层验证:把 agent 拆开来看
ERC-8126 主要定义了五类验证,分别覆盖 agent 上链以后最容易出问题的几个面:合约、媒体、代码、网站和钱包。它标准化的是验证类型、结果表达和可消费接口,而不是把每一种安全检查都变成唯一的官方审计方法。不同 verification provider 仍然可以使用自己的检测流程和风险模型。
ETV:Token / Contract Verification
ETV 检查 agent 关联的 token 或合约。
如果 agent metadata 里写了一个 contractAddress,provider 会检查这个地址在对应链上是不是真的有合约代码,是否存在明显风险,是否只是随便填进去的假地址。
对用户来说,ETV 回答的是:
这个 agent 声称关联的链上资产或合约,到底是不是真的?
因为一个 agent 一旦开始收款、发 token、做 staking、执行策略,背后的合约就不再是装饰品,而是用户资金真正会碰到的地方。
MCV:Media Content Verification
MCV 检查 agent 使用的媒体内容,比如头像、图片、品牌素材、证明图片等。
这听起来不像核心问题,但在 AI Agent 场景里很重要。一个假 agent 可以冒用项目 logo,伪造官方截图,甚至用 AI 生成的图片制造背书感。
MCV 要检查的是内容来源、完整性、篡改痕迹、水印、签名等信息。
它回答的是:
这个 agent 展示给用户看的内容,有没有被伪造或篡改?
SCV:Solidity Code Verification
SCV 检查 agent 关联的 Solidity 代码或合约安全。
如果 metadata 里包含相关代码或合约信息,provider 可以检查常见风险,比如重入、权限问题、危险调用、闪电贷攻击面等。
SCV 可以降低一些常见合约风险,但它不等于完整人工审计。
它更像是一套标准化的合约安全检查入口。通过 SCV,不代表合约绝对安全;它说明的是,这个 agent 的代码或合约经过了某个 provider 的检查,并生成了可消费的风险信号。
WAV:Web Application Verification
WAV 检查 agent 的网站、API 和端点。
很多 agent 虽然有链上身份,但真正交互入口仍然在链下,比如官网、API、MCP server、A2A 端点或 dashboard。
这些地方一旦出问题,风险可能不比合约小。网站证书失效,用户可能被中间人攻击;API 被劫持,agent 可能执行错误指令;前端被注入恶意脚本,用户可能签下危险交易。
WAV 回答的是:
这个 agent 的 Web 入口和服务端点是否安全?
WV:Wallet Verification
WV 检查 agent 的钱包风险。
它会看这个钱包有没有交易历史,是否是刚创建的空壳,是否和高风险地址、钓鱼地址、攻击者地址或其他 threat intelligence 数据库里的对象有关联。
WV 回答的是:
这个 agent 的链上行为记录是否干净?
统一风险分:让钱包和应用真正用得上
ERC-8126 会把验证结果转成 0 到 100 的风险分。
分数越低,风险越低;分数越高,风险越高。
- 0-20:低风险
- 21-40:中等风险
- 41-60:风险上升
- 61-80:高风险
- 81-100:严重风险
这个设计的产品意义很直接。
钱包不可能要求普通用户每次都读一份完整安全报告。Marketplace 也不适合只靠项目方自述来排序。一个统一的 risk score,可以成为产品策略的输入。
比如:
- 风险分过高,钱包可以提示或阻止交互。
- 没有验证结果,marketplace 可以降低展示权重。
- 钱包风险异常,任务市场可以限制接单。
- Web 端点风险高,前端可以提示用户谨慎访问。
不过,一个总分不能代表全部情况。
合约风险、钱包风险、网站风险、媒体风险,本来就是不同类型的风险。更好的产品设计,是同时展示总分和分项分数,让用户知道问题具体出在哪里。
PDV 和 ZKP:证明通过验证,不等于公开所有细节
验证 agent 会涉及很多敏感信息。
比如源码、基础设施配置、安全报告、私有日志、钱包画像等。如果全部公开,反而可能扩大攻击面。
所以 ERC-8126 引入了 PDV 和 ZKP。
PDV 是 Private Data Verification,ZKP 是 Zero-Knowledge Proof。它们的作用是:让 agent 可以证明自己通过了某项验证,但不用把底层细节全部公开。
可以把它理解成:
外部世界看到的是“通过了验证、风险分是多少、proof 在哪里”,而不是完整的内部安全材料。
这让 ERC-8126 更像一份可验证的尽调摘要,而不是把所有数据直接摊开给全网看。
ERC-8004 / ERC-8126 / ERC-8183:身份、验证、交易
如果把 AI Agent 经济拆成三层,可以这样理解。这里需要先说明状态:ERC-8126 已进入 Final 状态,而 ERC-8004 和 ERC-8183 仍处于 Draft 阶段,所以三者更适合被理解为一条正在形成的基础设施方向,而不是已经完全定型的协议栈。
- ERC-8004:Identity让 agent 有身份、可注册、可发现。
- ERC-8126:Verification让 agent 的安全和风险信号可验证、可消费。
- ERC-8183:Commerce让 agent 可以接任务、提交结果、进入托管和结算流程。
更直白一点:
- ERC-8004 回答:你是谁?
- ERC-8126 回答:你靠不靠谱?
- ERC-8183 回答:你能不能干活、收钱、结算?
这三者放在一起,呈现出一个比较清晰的 agent economy 叙事:
先有身份,再有验证,最后才更容易进入交易与结算。
这层关系也可以再说得细一点。ERC-8126 确实建立在 ERC-8004 之上;ERC-8183 和 ERC-8126 更像是天然互补,而不是强绑定关系。
换句话说,ERC-8183 这类 agent commerce 协议可以自然消费 ERC-8126 的验证信号,比如在 agent 接任务前检查它的风险分,在 evaluator 放款前验证 proof。但这更像是工程上的组合方向,不是 ERC-8183 对 ERC-8126 的硬性依赖。
对开发者意味着什么?
如果只从市场叙事看 AI Agent,讨论很容易停留在 token、launch、marketplace 和交易热度上。但对真正要做 agent 产品、钱包接入、任务网络或协议基础设施的人来说,更关键的问题是:当一个 agent 开始管理资产、调用服务、提交结果、和其他 agent 协作时,谁来承担信任成本?
过去,这个成本大多被丢给用户。用户自己判断项目靠不靠谱,自己看合约有没有审计,自己查钱包干不干净,自己识别官网是不是假的,最后自己承担被骗或交互失败的后果。
ERC-8126 的价值在于,它试图把这些判断拆成标准化、可组合、可被产品读取的验证信号。
它不会消灭风险,也不能保证某个 agent 永远可信。但如果这类验证信号被更多钱包、marketplace、dApp 和 agent 网络采用,很多产品决策就可以不再只依赖项目方自述。
具体来说:
对钱包来说,risk score 可以成为交易前风控和风险提示的输入。
对 agent marketplace 来说,验证结果可以影响排序、筛选、展示权重和风险标签。
对 AI x ETH 应用来说,它可以成为 agent 接入前的一道安全检查。
对 agent-to-agent 协作来说,它可以帮助 agent 在合作前筛掉明显高风险对象。
这也是 ERC-8126 值得关注的地方:它不是又一个 AI 概念 ERC,而是在尝试把链上 agent 从“可注册”推进到“可验证、可风控”。
它还是一套标准,不是已经运行的网络
这部分可以换个角度看。
ERC-8126 定义的是标准接口和验证框架。它说明验证可以怎么做、结果可以怎么表达,但不等于现在已经有一个跨钱包、跨 marketplace、跨链统一运行的成熟公共验证网络。
从目前的规范看,它已经明确了几件事:
- ERC-8126 定义了 agent verification 的标准流程。
- 它要求验证锚定 ERC-8004 的 agentId。
- 它覆盖 token / 合约、媒体、Solidity、Web、钱包五类风险。
- 它支持风险评分、proof 和 attestation。
- 它为钱包、marketplace、dApp 消费验证信号提供了基础。
这些能力真正发挥作用,还取决于后续有多少 provider、钱包、marketplace 和应用愿意采用。换句话说,它现在还不是下面这样的状态:
- 所有钱包都已经接入。
- 所有 agent marketplace 都已经采用。
- 所有 provider 都在使用完全一致的评分标准。
- 全行业已经形成成熟的 verification network。
- ZKP 和风险评分已经在生产环境里完全统一。
换句话说:
ERC-8126 先把 AI Agent 的验证语言标准化了。它要成为公共信任层,还需要 provider、钱包、市场和应用继续接入。
结语
AI Agent 进入链上经济之后,身份只是起点,后面还会遇到一个更实际的问题:它能不能被验证。
ERC-8004 让 agent 有身份。ERC-8126 让这个身份背后的风险可以被验证。ERC-8183 则让 agent 有机会在任务、托管和结算场景里使用这些验证信号。
所以,ERC-8126 的意义不是给 agent 发一枚“永久可信”的徽章,而是把一个更现实的问题标准化:
当一个 AI Agent 要进入钱包、市场、任务网络和链上交易流程时,我们应该如何检查它?检查结果应该如何表达?其他系统又应该如何消费这些结果?
这也许就是 AI Agent 经济接下来需要补上的信任层。
参考资料
- ERC-8126: AI Agent Verification
- ERC-8126 Raw Markdown
- ERC-8004: Trustless Agents
- ERC-8183: Agentic Commerce
- Ethereum Magicians: ERC-8126 Discussion
- DonJohnson X Thread: Introducing ERC-8126
- Cybercentry Web3 Security & Verification Services
- ERC-8126 Scan
