什么是 ERC-8004？无信任代理如何在 Ethereum 上运作

ERC-8004,名为 Trustless Agents,是一个 Ethereum 标准,它为 AI agent 提供链上身份、公开的信誉记录,以及一种让其工作得到验证的方式,使其能够跨组织进行交易,而不需要预先建立信任。本指南介绍其三个注册表如何运作,目前主网上实际部署的内容,该标准如何与 A2A、MCP 和 x402 配合,以及在你基于它构建之前需要注意的事项。

什么是 ERC-8004?

ERC-8004 由来自 MetaMask、Ethereum Foundation、Google 和 Coinbase 的作者于 2025 年 8 月提出,定义了三个注册表。Identity Registry 记录 agent 的身份。Reputation Registry 记录其客户对它的评价。Validation Registry 记录独立验证者是否检查过它的工作。

该规范明确指出,信任不是一刀切的。用规范原话来说,信任模型是"可插拔且分层的,安全性与风险承担的价值成比例,从订披萨这样的低风险任务到医疗诊断这样的高风险任务"。预订晚餐的 agent 可以依赖信誉评分。而管理资金的 agent 则需要由有实际利益风险的一方重新验证其工作。

为什么 AI agent 需要一个信任层?

你今天使用的每一种信任系统都假定中间有一个平台。市场评价存在于某家公司的数据库中。信用卡拒付之所以存在,是因为有一个卡组织处于买卖双方之间。OAuth 登录之所以有效,是因为有一个大型身份提供商为你担保。这种模式对自主 agent 并不适用,因为这些 agent 天生要跨公司、跨云、跨司法辖区运作,且没有共同的运营方。

agent 技术栈的其余部分已经填补了这一空白。Model Context Protocol(MCP)将 agent 连接到工具和数据源。Agent2Agent(A2A)让 agent 相互发现并交换结构化消息。x402 让它们能够通过普通 HTTP 为服务付费。这些方案都假定你已经决定好要与哪个对方合作。它们都无法帮你做出这个决定。

这正是 ERC-8004 要解决的问题,也是这些注册表存在于区块链上而不是任何人的数据库中的原因。一个正在选择执行场所的 DeFi agent、一个雇佣数据标注 agent 的研究 agent,以及一个正在决定是否服务某个未知买家的商家,都需要同样的三项查询。这个 agent 是谁?其他人与它合作时发生了什么?有没有人验证过它的产出?ERC-8004 将这些答案放在了一个不受任何单一方控制的地方,置于每个 agent 都能读取的同一 schema 中。

ERC-8004 的身份注册表如何运作?

每个注册的 agent 都是一个 ERC-721 token,与 NFT 背后的标准相同。注册时会在 Identity Registry 上调用 register(),铸造一个 token,其 ID 成为该 agent 的编号。agent 的完整标识符结合了链和注册表地址以及该 ID,因此"Base 上的 4,205 号 agent"在全局范围内是唯一确定的。

该 token 的 URI 指向一个注册文件,可托管在 IPFS、HTTPS 上,或直接嵌入链上,用于描述该 agent 是什么以及如何联系它。一个简化后的注册文件示例如下:

services 数组是发现负载。它公告该 agent 在其所支持的各种协议上的实时端点,包括 A2A、MCP、ENS 名称和去中心化标识符。supportedTrust 字段声明该 agent 选择接受哪些信任模型。规范指出,如果该字段缺失,则该注册仅用于发现。

基于 ERC-721 构建带来了不少现成的好处。所有权、转移和委托已经可用,钱包和市场已经能够渲染这些 token,生态系统的工具链也可以原样适用。该注册表还将身份与日常执行操作的密钥分离开来。setAgentWallet 通过一个签名授权将一个工作钱包绑定到该 agent,因此身份 token 的所有者和签署交易的钱包可以是拥有不同影响范围的不同密钥。这与我们在为 agent 配置钱包时建议的做法相同,即让 agent 获得限定范围、有时间限制的签名权限,而不是一个原始私钥。

ERC-8004 的信誉注册表如何运作?

任何地址都可以通过在 Reputation Registry 上调用 giveFeedback 来对任何 agent 打分。一条反馈记录携带一个带符号的数值,精度可配置,因此分数可以为负、可以精确,而不是粗糙的一到五分制,另外还可以附带最多两个用于筛选的标签,以及一个指向更详细的链下说明的可选 URI,该说明以其哈希值提交上链。唯一的硬性限制是,agent 的所有者和操作者不能给自己的 agent 打分。

有两个设计选择比函数签名本身更重要。第一,客户端永远不需要注册任何东西,这让留下反馈的门槛降为零,也让服务方能够为用户的评价代付 gas。第二,该注册表有意不计算任何权威分数。它只存储原始信号,提供汇总和读取函数,而将解读留给查询者自行决定。早期关于该提案的讨论就指出,单一的聚合信誉数值会诱发垄断动态和刷分行为,因此评分逻辑放在索引层,让不同的使用方可以对同一份数据赋予不同的权重。

链下反馈文件才是评价真正发挥作用的地方。它可以引用交互中实际用到的具体 MCP 工具或 A2A 任务,还可以嵌入 x402 支付的证明,将评价与一笔可验证确实发生过的交易关联起来。有支付凭证支撑的评价,比一个匿名钱包给出的裸分数信号强得多,而筛选出这类评价正是该注册表的严肃使用者应采用的方式。

ERC-8004 的验证注册表如何运作?

信誉评分告诉你过去的客户怎么想。对于更高价值的工作,这还不够,产出本身需要被检查。Validation Registry 允许一个 agent 请求指定的验证者检查某项具体工作:validationRequest 记录验证者、agent,以及指向该工作的哈希提交指针,验证者则通过 validationResponse 作出回应,给结果打出 0 到 100 的分数,并附上自己的哈希提交证据。

"检查"具体意味着什么取决于验证者。它可以重新执行该任务并比对输出,如果做出不诚实的证明则会损失质押。它可以证明该 agent 是在一个可信执行环境(TEE,一种能够证明其执行了何种代码的硬件)中运行的。它也可以验证一个零知识机器学习证明(zkML,一种能证明特定模型产生了特定输出的密码学证明)。该注册表并不关心具体是哪一种;它只标准化了请求与响应的管线。

一个几乎没有任何报道提到的现状说明。官方的多链部署包含 Identity 和 Reputation 注册表,但 Validation Registry 被撤回以与 TEE 社区一起重新设计,目前并不属于官方主网部署集合的一部分。现在需要验证功能的团队会通过特定的提供方来接入,例如 EigenCloud 的 trustless agents 集成,它将 ERC-8004 身份与自家的可验证计算结合起来。在基于它构建之前,请查看官方合约仓库以了解部署的最新状态。

agent 应该使用哪种信任模型?

规范中按风险承担价值划分的框架,转化为一条相当清晰的决策规则:让验证成本与出错成本相匹配。

这些模型也可以叠加使用。一个生产环境中的 agent 可能同时在 TEE 中运行、携带一段信誉历史,并将高价值的产出提交给带质押的重新执行验证,通过同一个 supportedTrust 声明呈现这三种信号。

ERC-8004、A2A、MCP 和 x402 如何配合?

理解 agent 技术栈最简单的方式,是将其视为由四个不同所有者管理的四层结构。来自 Anthropic 的 MCP 将 agent 连接到工具和上下文。由 Google 发起的 A2A 负责 agent 之间的发现与消息传递。由 Coinbase 推动的 x402 负责资金流转,它是多个相互竞争的 agent 支付协议之一。ERC-8004 锚定信任,而且它有意成为唯一存在于区块链上的一层,因为身份和信誉只有在不受任何对方控制时才真正有用。

一次单独的交互可以涉及这四层。一个买方 agent 在 Identity Registry 中查询公告了自己所需技能的 agent,获取候选方的注册文件,并检查其信誉汇总和验证记录。它开启一个 A2A 会话来协商任务,或者直接调用卖方的 MCP 端点。它支付卖方返回的 x402 发票。工作完成后,它调用 giveFeedback 并附上对该笔支付的引用,卖方的下一个潜在客户就会看到一条附有凭证的评价。

技术栈中没有任何一项要求走完整个流程。有团队在没有 ERC-8004 的情况下采用 x402,也有团队注册了身份却从未请求过验证。但这些层被设计为可以相互引用。注册文件列出了 A2A 和 MCP 端点,反馈文件嵌入 x402 凭证,因此将它们组合起来需要的是配置,而不是粘合代码。

如何基于 ERC-8004 构建?

读取这些注册表不需要任何特殊工具,因为它们就是普通的合约。身份查询是 ERC-721 调用,每个注册表都会发出可供索引的事件。我们支持所有主要的部署链,因此一个标准的 RPC 端点就足以开始。获取一个 agent 的注册文件只需要一次读取:

从那之后,各个环节都能映射到你可能已经在运行的基础设施上。Webhooks 可以将新的注册和反馈事件转化为推送,而不是轮询,关于如何围绕这些事件搭建整个循环,可参阅我们的链上 AI agent 架构指南。agent 的运营钱包应该是一个限定范围的签名者,而不是一个原始密钥,这一模式在我们的链上 agent 指南中有完整讲解。而且 agent 可以自主管理自己与基础设施提供商的关系,因为agent 可以用钱包作为身份自行注册我们的平台,并通过 x402 按调用付费,整个过程无需人工介入。如果你是从一个编程 agent 出发构建,用于 Claude Code 的 Alchemy 插件将我们的 MCP 服务器和技能打包为一次安装。

一个 ERC-8004 agent 在注册表之下所做的一切,包括读取链上状态、监听事件、签署交易,以及为自身的 API 使用付费,都运行在我们专为将 agent 视为头等用户而构建的基础设施之上。通过 Alchemy CLI 获取一个免费端点,或者让你的 agent 自行完成接入。无需 API key 交接,无需合同,注册流程中不需要任何人工介入。

ERC-8004 有哪些局限性?

该标准尚年轻,其存在的问题已在自己的讨论帖中有记录。以下几点应当影响你的设计:

• **伪造反馈成本低。**钱包不需要任何成本,因此原始信誉分数很容易被人为制造。使用反馈时应按已知客户或支付凭证筛选,绝不要使用未经筛选的平均分。
• **身份是可转让的。**一个 agent 身份是标准的 ERC-721,因此一个有着良好历史记录的老身份可以被出售,其信誉也会随之转移。在信任历史记录之前,先追踪所有权变更情况。
• **分数会老化。**agent 是随机的,一次模型更新就可能在一夜之间改变其行为,因此上个月的反馈描述的是上个月的那个 agent。
• **信誉停留在单一链上。**在 Base 上注册的 agent,在 Arbitrum 上要从零开始。跨链聚合是一个索引器层面的问题,该标准目前尚未解决。
• **接口可能仍会变动。**该标准仍处于草案阶段,并且已经被重新设计过一次。将你的集成锚定在已部署的合约上,并在依赖更新的接口之前持续关注规范的变化。

以上这些都没有推翻该标准实际上的主张,因为它从未声称链上信誉是不可伪造的。它的主张是,agent 的信任信号应该存在于一个公开、共享、无需许可的 schema 中,而不是散落在各个私有数据库里。就这一主张而言,它已经上线,并且已经在被真实系统读取。

常见问题

什么是 ERC-8004,它如何实现 trustless AI agent?

ERC-8004 是一个 Ethereum 标准,通过涵盖身份、信誉和验证的三个注册表将 AI agent 注册到链上。agent 获得一个作为 ERC-721 token 的可移植、可验证身份,客户公开发布反馈,验证者对工作质量进行证明,从而使 agent 能够跨组织进行交易,而不需要预先建立信任。

ERC-8004 已经在主网上线了吗?

是的。Identity 和 Reputation 注册表自 2026 年 1 月起已在 Ethereum 主网运行,并以相同地址部署在二十多个网络上。

ERC-8004 有 token 吗?

没有。ERC-8004 是一个智能合约标准,而不是一个带有 token 的项目。注册一个 agent 会铸造一个专属于该 agent 的 ERC-721 身份 token,但不存在同质化的 ERC-8004 资产,任何以此名义营销的资产都与该标准无关。

ERC-8004 的 agent 身份可以出售吗?

可以。agent 身份是标准的 ERC-721 token,因此它们的转让方式与任何 NFT 相同,积累的信誉会随着 token 一起转移。这使得所有权历史成为尽职调查的一部分,因为一份看起来干净的信誉可能是买来的,而不是由当前运营者挣得的。

哪些链支持 ERC-8004?

官方注册表以相同地址部署在二十多个 EVM 网络上,包括 Ethereum、Base、Arbitrum、Optimism、Polygon、BSC 和 Monad。Alchemy 在这些链上提供 RPC 和数据 API,因此 agent 可以在这些注册表部署的任何地方读取和写入。

ERC-8004 与 x402 和 A2A 有什么不同?

它们解决的是同一技术栈中不同的层面。A2A 负责 agent 如何相互发现并通信,x402 负责它们如何通过 HTTP 相互支付,而 ERC-8004 负责它们是否应该相互信任,方式是将身份、信誉和验证记录锚定在链上。生产环境中的 agent 系统通常会将这三者组合起来使用。