---
title: "什么是 ERC-8004？无需信任的 agent 如何在 Ethereum 上运作"
description: "ERC-8004 是 Ethereum 的无需信任 agent 标准。了解其链上身份、声誉与验证注册表如何让 AI agent 安全交易。"
---

# 什么是 ERC-8004？无需信任的 agent 如何在 Ethereum 上运作

<ImageBlock
  src="https://media.alchemy.com/blog/erc-8004-hero.png"
  alt="ERC-8004 指南封面图"
  width={1920}
  height={900}
  priority
/>

ERC-8004 的标题是 Trustless Agents（无需信任的 agent），它是一项 Ethereum 标准，为 AI agent 提供链上身份、公开的声誉记录，以及让工作成果得到验证的途径，使 agent 无需预先建立的信任即可跨组织交易。本指南涵盖它的三个注册表如何运作、目前主网上实际部署了什么、该标准如何与 [A2A](https://github.com/a2aproject/A2A)、MCP 和 [x402](https://www.alchemy.com/blog/how-x402-brings-real-time-crypto-payments-to-the-web) 配合，以及在基于它构建之前需要注意什么。

## 什么是 ERC-8004？

[ERC-8004](https://eips.ethereum.org/EIPS/eip-8004) 于 2025 年 8 月由来自 MetaMask、Ethereum 基金会、Google 和 Coinbase 的作者提出，定义了三个注册表。Identity Registry（身份注册表）记录 agent 是谁。Reputation Registry（声誉注册表）记录其客户对它的评价。Validation Registry（验证注册表）记录是否有独立验证者检查过它的工作。

规范明确指出，信任并非一刀切。用它自己的话说，信任模型是"可插拔且分层的，安全性与风险价值成正比，从订披萨这样的低风险任务到医疗诊断这样的高风险任务"。预订晚餐的 agent 可以依赖声誉分数。管理国库的 agent 则需要由有资金利益攸关的一方对其工作重新验证。

## 为什么 AI agent 需要信任层？

今天你使用的每一个信任系统都假设中间有一个平台。交易市场的评价存在某一家公司的数据库里。拒付机制之所以存在，是因为买卖双方之间有卡组织。OAuth 登录能够运作，是因为有大型身份提供商为你背书。这种模式对自主 agent 不成立——它们生来就要跨公司、跨云、跨司法辖区工作，没有共同的运营方。

Agent 技术栈的其余部分已经围绕这个缺口补齐。[Model Context Protocol](https://modelcontextprotocol.io/)（MCP，模型上下文协议）把 agent 连接到工具和数据源。Agent2Agent（A2A）让 agent 相互发现并交换结构化消息。x402 让它们通过普通 HTTP [为服务付费](https://www.alchemy.com/overviews/what-are-agent-payments)。这些协议都假设你已经决定了与哪个交易对手合作。它们都无法帮你做出这个决定。

这正是 ERC-8004 承担的职责，也是这些注册表存放在区块链上而非任何人的数据库里的原因。一个选择执行场所的 [DeFi agent](https://www.alchemy.com/overviews/defi-ai-agents)、一个雇佣数据标注 agent 的研究 agent、以及一个决定是否服务未知买家的商户，都需要同样的三次查询。这个 agent 是谁？其他人与它合作时发生了什么？有人验证过它的输出吗？ERC-8004 把这些答案放在没有任何单一方控制的地方，以每个 agent 都能读取的统一模式呈现。

## ERC-8004 的 Identity Registry 如何运作？

每个注册的 agent 都是一个 [ERC-721 代币](https://www.alchemy.com/blog/comparing-erc-721-to-erc-1155)，与 NFT 背后是同一个标准。注册时调用 Identity Registry 上的 `register()`，铸造一个代币，其 ID 成为该 agent 的编号。Agent 的完整标识符由链、注册表地址和该 ID 组合而成，因此"Base 上的 4,205 号 agent"在全球范围内没有歧义。

代币的 URI 指向一个注册文件——可托管在 IPFS、HTTPS 上，或直接内嵌在链上——描述该 agent 是什么以及如何访问它。一个精简后的注册文件如下：

<CodeSnippet
  language="json"
  code={`{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "Research Agent",
  "description": "Fetches and summarizes onchain data on request",
  "image": "ipfs://<image-hash>",
  "services": [
    { "name": "A2A", "endpoint": "https://agent.example/a2a" },
    { "name": "MCP", "endpoint": "https://agent.example/mcp" }
  ],
  "supportedTrust": ["reputation", "tee-attestation"]
}`}
/>

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

基于 ERC-721 构建免费带来了很多东西。所有权、转移和委托已经可用，钱包和交易市场已经能渲染这些代币，生态系统的工具链无需修改即可套用。注册表还把身份与日常操作所用的密钥分离开来。`setAgentWallet` 通过签名授权将一个工作钱包绑定到 agent，因此身份代币的所有者和签署交易的钱包可以是不同的密钥，具有不同的影响范围。这与我们在[为 agent 配置钱包](https://www.alchemy.com/blog/agent-wallets-alchemy-cli)时推荐的分离方式一致——agent 获得限定范围、有时限的签名权限，而不是原始私钥。

## ERC-8004 的 Reputation Registry 如何运作？

任何地址都可以通过调用 Reputation Registry 上的 `giveFeedback` 为任何 agent 评分。一条反馈条目携带一个带符号的数值（小数位可配置），因此分数可以为负且精确，而不是粗糙的一到五分；此外还可附最多两个用于筛选的标签，以及一个可选的 URI，指向更丰富的链下评价文本，并以其哈希提交上链。唯一的硬性限制是 agent 的所有者和运营者不能给自己的 agent 评分。

有两个设计选择比函数签名更重要。第一，客户端从不需要在任何地方注册，这让留下反馈的门槛保持为零，并允许服务为其用户的评价[代付 gas](https://www.alchemy.com/gasless-transactions)。第二，注册表刻意不计算任何规范分数。它存储原始信号，提供汇总和读取函数，把解读留给查询它的一方。提案的讨论早期就有人指出，单一的聚合声誉数字会招致垄断动态和刷分行为，因此评分逻辑放在索引器层，不同的使用者可以对同一份数据采用不同的加权方式。

链下反馈文件是评价获得约束力的地方。它可以引用这次交互所使用的具体 MCP 工具或 A2A 任务，也可以嵌入一笔 x402 支付的证明，把评价与一笔可验证确实发生过的交易绑定。有支付凭证背书的评价，远比匿名钱包的裸分数更有说服力，而精确筛选这类评价，正是注册表的严肃使用者被期望的用法。

## ERC-8004 的 Validation Registry 如何运作？

反馈分数告诉你过去的客户怎么想。对于更高价值的工作，这还不够，输出本身需要被检查。Validation Registry 允许 agent 请求指定的验证者检查某项具体工作：`validationRequest` 记录验证者、agent 和一个以哈希提交的工作指针，验证者用 `validationResponse` 作答，以 0 到 100 为结果评分，并附上自己以哈希提交的证据。

"检查"意味着什么取决于验证者。它可以重新执行任务并比对输出，若作证不诚实则损失质押。它可以证明 agent 运行在可信执行环境中（TEE，一种能证明自己执行了什么代码的硬件）。它可以验证零知识机器学习证明（zkML，证明特定模型产生了特定输出的密码学证明）。注册表不关心是哪一种；它标准化的是请求与响应的管道。

一个几乎没有报道提及的现状注意事项。官方多链部署包含 Identity 和 Reputation 注册表，但 Validation Registry 已被撤回，正与 TEE 社区一起重新设计，如今不在官方主网集合之内。目前需要验证的团队通过特定提供商接入，例如 [EigenCloud 的 trustless agents 集成](https://docs.eigencloud.xyz/products/eigenai/howto/build-trustless-agents)，它把 ERC-8004 身份与自己的可验证计算配对。在基于它构建之前，请查看[官方合约仓库](https://github.com/erc-8004/erc-8004-contracts)了解部署进展。

## Agent 应该使用哪种信任模型？

规范的"风险价值"框架可以转化为一条相当清晰的决策规则：让验证的成本与出错的成本相匹配。

<EmbeddedTable
  table={{
    columns: [
      { key: "model", width: 200, title: "信任模型", dataType: "object" },
      { key: "how", width: 320, title: "运作方式", dataType: "object" },
      { key: "fits", width: 260, title: "适用场景", dataType: "object" },
    ],
    data: [
      {
        model: { title: "声誉", tooltip: "", icon: "" },
        how: {
          title: "客户在每次交互后将签名反馈发布上链",
          tooltip: "",
          icon: "",
        },
        fits: { title: "低风险、高频的任务", tooltip: "", icon: "" },
        id: 0,
      },
      {
        model: { title: "加密经济验证", tooltip: "", icon: "" },
        how: {
          title: "有质押的验证者重新执行工作，虚假作证会损失质押",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "输出可校验的较高价值任务",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        model: { title: "TEE 证明", tooltip: "", icon: "" },
        how: {
          title: "硬件证明 agent 实际运行了哪些代码",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "过程完整性至关重要的任务，如密钥处理",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        model: { title: "zkML 证明", tooltip: "", icon: "" },
        how: {
          title: "证明特定模型产生了该输出的密码学证明",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "最高保证级别，目前成本也最高",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

这些模型还可以叠加。一个生产环境的 agent 可以运行在 TEE 中、携带声誉历史，并将高价值输出提交给有质押的重新执行，通过同一个 `supportedTrust` 声明呈现全部三种信号。

## ERC-8004、A2A、MCP 和 x402 如何协同？

<ImageBlock
  src="https://media.alchemy.com/blog/erc-8004-agent-stack.png"
  alt="Agent 技术栈：MCP、A2A 和 x402，ERC-8004 作为链上信任层"
  width={1600}
  height={900}
/>

把 agent 技术栈理解为四层、四个不同的主导者最为容易。来自 Anthropic 的 MCP 把 agent 连接到工具和上下文。由 Google 发起的 A2A 处理 agent 之间的发现和消息传递。由 Coinbase 推动的 x402 负责资金流转，是[多个相互竞争的 agent 支付协议](https://www.alchemy.com/overviews/x402-vs-mpp-comparing-agent-payment-protocols)之一。ERC-8004 锚定信任，而且它刻意是唯一存在于区块链上的一层，因为身份和声誉只有在没有任何交易对手控制它们时才有用。

一次交互可以触及全部四层。买方 agent 查询 Identity Registry，寻找宣传其所需技能的 agent，获取候选者的注册文件，并检查它的声誉摘要和验证记录。它打开一个 A2A 会话协商任务，或直接调用卖方的 MCP 端点。它支付卖方返回的 x402 账单。工作完成后，它调用 `giveFeedback` 并附上对该笔支付的引用，卖方的下一个潜在客户看到的就是一条附带凭证的评价。

技术栈中没有任何部分要求走完整个闭环。有团队采用 x402 而不用 ERC-8004，也有团队注册了身份却从不请求验证。但这些层在设计上就相互引用。注册文件列出 A2A 和 MCP 端点，反馈文件嵌入 x402 凭证，因此把它们组合起来需要的是配置而非胶水代码。

## 如何基于 ERC-8004 构建？

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

<CodeSnippet
  language="typescript"
  code={`import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";
const client = createPublicClient({
  chain: mainnet,
  transport: http("https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"),
});
// The Identity Registry is an ERC-721; tokenURI returns the agent's registration file URI
const agentURI = await client.readContract({
  address: "0x8004A169FB4a3325136EB29fA0ceB6D2e539a432",
  abi: [
    {
      name: "tokenURI",
      type: "function",
      stateMutability: "view",
      inputs: [{ name: "tokenId", type: "uint256" }],
      outputs: [{ type: "string" }],
    },
  ],
  functionName: "tokenURI",
  args: [1n],
});`}
/>

从这里开始，各个部分都能映射到你可能已经在运行的基础设施。[Webhooks](https://www.alchemy.com/webhooks) 把新注册和反馈事件从轮询变为推送，而如何围绕这些事件组织循环，见我们的[链上 AI agent 架构指南](https://www.alchemy.com/overviews/onchain-ai-agent-architectures)。Agent 的操作钱包应该是一个限定权限的签名者而非原始私钥，这一模式在我们的[链上 agent 指南](https://www.alchemy.com/blog/how-to-build-onchain-agents)中有端到端的讲解。Agent 还可以自主管理它自己的基础设施关系，因为 [agent 可以注册我们的平台](https://www.alchemy.com/blog/ai-agents-can-now-sign-up-for-alchemy)——以钱包作为身份，通过 x402 按调用付费，全程无需人工参与。如果你从编码 agent 出发，[Alchemy plugin for Claude Code](https://www.alchemy.com/blog/alchemy-claude-plugin-now-live) 把我们的 MCP server 和技能打包为一次安装。

ERC-8004 agent 在注册表下游做的一切——读取链上状态、监听事件、签署交易、为自己的 API 用量付费——都运行在我们把 agent 作为一等用户来构建的基础设施上。通过 [Alchemy CLI](https://www.alchemy.com/agents) 获取一个免费端点，或者让你的 agent 自行完成注册。无需交接 API key，无需合同，注册流程中没有任何环节需要人工。

## ERC-8004 有哪些局限？

这个标准还很年轻，它的尖锐边缘在自己的讨论帖中都有记录。以下几点应当影响你的设计：

- **Sybil 式反馈成本低廉。** 钱包不花钱，原始声誉分数很容易被批量制造。只使用按已知客户或支付证明筛选后的反馈，绝不要用未经过滤的平均值。
- **身份可以转让。** Agent 身份是标准 ERC-721，一个历史干净的老身份可以被出售，声誉随之转移。在信任历史记录之前，先追踪所有权变更。
- **分数会过时。** Agent 具有随机性，一次模型更新可能让行为一夜之间改变，上个月的反馈描述的是上个月的 agent。
- **声誉停留在单条链上。** 在 Base 上注册的 agent 到了 Arbitrum 就从零开始。跨链聚合是一个标准尚未解决的索引器问题。
- **接口可能还会变动。** 标准仍是草案，且已经重设计过一次。把集成固定在已部署的合约上，在依赖较新的接口之前先关注规范动向。

这些都不构成对该标准实际主张的否定——它从未声称链上声誉不可伪造。它的主张是：agent 信任信号应该放在公开、共享、无需许可的统一模式中，而不是散落在各个私有数据库里。以这个主张来评判，它已经上线，并且已经被真实系统读取。

## 常见问题

### 什么是 ERC-8004？它如何实现无需信任的 AI agent？

ERC-8004 是一项 Ethereum 标准，通过覆盖身份、声誉和验证的三个注册表把 AI agent 注册上链。Agent 获得作为 ERC-721 代币的可移植、可验证身份，客户公开发布反馈，验证者对工作质量作证，从而让 agent 无需预先建立的信任即可跨组织交易。

### ERC-8004 已在主网上线了吗？

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

### ERC-8004 有代币吗？

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

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

可以。Agent 身份是标准 ERC-721 代币，像任何 NFT 一样可以转让，累积的声誉随代币一起转移。这使得所有权历史成为尽职调查的一部分，因为干净的声誉可能是当前运营者买来的，而非挣来的。

### 哪些链支持 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 系统通常将三者组合使用。