---
title: "什麼是 ERC-8004？免信任代理如何在 Ethereum 上運作"
description: "ERC-8004 是 Ethereum 的免信任代理標準。了解其鏈上身分、信譽與驗證註冊表，如何讓 AI 代理安全地進行交易。"
---

# 什麼是 ERC-8004？免信任代理如何在 Ethereum 上運作

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

ERC-8004（標準名稱為 Trustless Agents）是一項 Ethereum 標準，賦予 AI 代理鏈上身分、公開的信譽紀錄，以及讓工作成果獲得驗證的機制，使代理能在沒有既有信任基礎的情況下跨組織進行交易。本指南涵蓋其三個註冊表如何運作、目前主網上實際部署了什麼、這項標準如何與 [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（身分註冊表）記錄代理是誰；Reputation Registry（信譽註冊表）記錄客戶對它的評價；Validation Registry（驗證註冊表）記錄是否有獨立驗證者檢查過它的工作。

規格明確指出信任並非一體適用。用它自己的話說，信任模型「可插拔且分層，安全性與風險價值成正比，從訂披薩這類低風險任務，到醫療診斷這類高風險任務」。負責訂餐廳的代理可以倚賴信譽分數；管理資金庫的代理則需要由有資金利害關係的一方重新驗證其工作。

## 為什麼 AI 代理需要信任層？

你今天使用的每一套信任系統都假設中間有一個平台。市集評價存放在單一公司的資料庫裡；退款機制之所以存在，是因為卡組織位居買賣雙方之間；OAuth 登入之所以可行，是因為有大型身分供應商為你背書。這個模式對自主代理來說並不成立，因為它們生來就要跨公司、跨雲端、跨司法管轄區運作，沒有共同的營運方。

代理堆疊的其餘部分已經圍繞這個缺口補齊。[Model Context Protocol](https://modelcontextprotocol.io/)（MCP，模型情境協定）將代理連接到工具與資料來源；Agent2Agent（A2A）讓代理能彼此發現並交換結構化訊息；x402 讓它們能透過一般 HTTP [支付服務費用](https://www.alchemy.com/overviews/what-are-agent-payments)。這些協定都假設你已經決定要和哪個交易對手合作，卻沒有任何一個能幫你做出這個決定。

這正是 ERC-8004 承擔的工作，也是這些註冊表存放在區塊鏈上、而非任何人的資料庫裡的原因。一個選擇執行場所的 [DeFi 代理](https://www.alchemy.com/overviews/defi-ai-agents)、一個僱用資料標註代理的研究代理，以及一個決定是否服務陌生買家的商家，需要的都是同樣的三個查詢：這個代理是誰？其他人和它合作時發生了什麼？有人驗證過它的產出嗎？ERC-8004 把這些答案放在沒有任何單一方能控制的地方，並以每個代理都能讀取的同一套結構描述（schema）呈現。

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

每個註冊的代理都是一個 [ERC-721 代幣](https://www.alchemy.com/blog/comparing-erc-721-to-erc-1155)，也就是 NFT 背後的同一套標準。註冊時呼叫 Identity Registry 上的 `register()`，鑄造出一個代幣，其 ID 就成為該代理的編號。代理的完整識別碼由鏈、註冊表地址與該 ID 組成，因此「Base 上的 4,205 號代理」在全球範圍內都是明確無歧義的。

該代幣的 URI 指向一份註冊檔案（可託管於 IPFS、HTTPS，或直接內嵌於鏈上），描述這個代理是什麼、以及如何連上它。一份精簡後的註冊檔案如下：

<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` 陣列是探索用的酬載。它公告代理在其支援的各種協定上的即時端點，包括 A2A、MCP、ENS 名稱與去中心化識別碼。`supportedTrust` 欄位宣告代理選擇加入哪些信任模型。規格指出，若此欄位不存在，該註冊僅用於探索。

建立在 ERC-721 之上免費換來很多東西。所有權、轉移與委任本來就能運作，錢包與市集本來就會顯示這些代幣，整個生態系的工具也能原封不動地套用。註冊表同時將身分與日常操作用的金鑰分離開來。`setAgentWallet` 透過簽署的授權將工作錢包綁定到代理，因此身分代幣的擁有者與簽署交易的錢包可以是不同的金鑰，各自的影響範圍也不同。這與我們在[為代理配置錢包](https://www.alchemy.com/blog/agent-wallets-alchemy-cli)時推薦的分離方式相同：代理取得的是受限範圍、有時效的簽署權限，而不是原始私鑰。

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

任何地址都可以呼叫 Reputation Registry 上的 `giveFeedback` 來評價任何代理。一筆回饋帶有一個可設定小數位數的帶正負號數值，因此分數可以是負的、也可以很精確，而不是粗略的一到五分；另外最多可附兩個標籤供篩選，以及一個選填的 URI，指向更完整的鏈下評述，並以其雜湊值提交上鏈。唯一的硬性限制是代理的擁有者與操作者不能評價自己的代理。

有兩個設計決定比函式簽章更重要。第一，客戶完全不需要在任何地方註冊，讓留下回饋的門檻維持在零，也讓服務方可以為使用者的評價[代付 gas](https://www.alchemy.com/gasless-transactions)。第二，註冊表刻意不計算任何標準分數。它儲存原始訊號、提供摘要與讀取函式，並把詮釋工作留給查詢它的人。提案討論中很早就有人主張，單一的信譽總分會招致壟斷動態與操弄，因此計分邏輯放在索引器層，不同的使用方可以用不同方式為同一批資料加權。

鏈下回饋檔案才是讓評價真正有分量的地方。它可以引用該次互動實際使用的 MCP 工具或 A2A 任務，也可以內嵌一筆 x402 付款的證明，把評價與一筆可驗證確實發生過的交易綁在一起。附有付款收據的評價，比匿名錢包留下的單純分數強得多；認真使用這個註冊表的人，預期的用法正是篩選出這類評價。

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

回饋分數告訴你過去的客戶怎麼想。對於價值較高的工作，這並不夠，產出本身需要被檢查。Validation Registry 讓代理可以請求指定的驗證者檢查某一件具體的工作：`validationRequest` 記錄驗證者、代理，以及以雜湊值提交的工作指標，驗證者再以 `validationResponse` 回覆，為結果打 0 到 100 的分數，並附上自己以雜湊值提交的證據。

「檢查」的意思取決於驗證者。它可以重新執行任務並比對輸出，並押上質押，一旦不誠實作證就會損失質押。它可以證明代理是在可信執行環境中執行（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)確認部署進度。

## 代理該選用哪一種信任模型？

規格以風險價值為框架，可以轉化為相當清楚的決策規則：讓驗證的成本與出錯的代價相稱。

<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: "由硬體證明代理實際執行了哪些程式碼",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "重視流程完整性的任務，例如金鑰處理",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        model: { title: "zkML 證明", tooltip: "", icon: "" },
        how: {
          title: "以密碼學證明特定模型產生了該輸出",
          tooltip: "",
          icon: "",
        },
        fits: {
          title: "最高保證等級，目前成本也最高",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

這些模型也能疊加。正式環境的代理可能在 TEE 中執行、累積信譽歷史，並將高價值產出提交給有質押的重新執行，透過同一個 `supportedTrust` 宣告呈現全部三種訊號。

## ERC-8004、A2A、MCP 與 x402 如何搭配？

<ImageBlock
  src="https://media.alchemy.com/blog/erc-8004-agent-stack.png"
  alt="代理堆疊：MCP、A2A 與 x402，以 ERC-8004 作為鏈上信任層"
  width={1600}
  height={900}
/>

把代理堆疊理解為四個層、四個不同的主導者最為容易。MCP 來自 Anthropic，負責將代理連接到工具與情境；A2A 由 Google 發起，處理代理之間的探索與訊息傳遞；x402 由 Coinbase 推動，負責金流，是[多個相互競爭的代理支付協定](https://www.alchemy.com/overviews/x402-vs-mpp-comparing-agent-payment-protocols)之一。ERC-8004 錨定信任，而它刻意是唯一存放在區塊鏈上的一層，因為身分與信譽唯有在沒有任何交易對手能控制它們時才有用。

單一次互動可能觸及全部四層。買方代理向 Identity Registry 查詢公告了所需技能的代理，抓取候選者的註冊檔案，並查看其信譽摘要與驗證紀錄。它開啟一個 A2A 工作階段來協商任務，或直接呼叫賣方的 MCP 端點。它支付賣方回傳的 x402 帳單。工作完成後，它呼叫 `giveFeedback` 並附上該筆付款的參照，賣方的下一位潛在客戶看到的就是一則附有收據的評價。

堆疊中沒有任何部分要求走完整個迴圈。有些團隊採用 x402 而不用 ERC-8004，也有人註冊身分卻從不請求驗證。但這些層在設計上會彼此引用：註冊檔案列出 A2A 與 MCP 端點，回饋檔案內嵌 x402 收據，因此組合它們靠的是設定，而不是黏合程式碼。

## 如何在 ERC-8004 上開發？

讀取這些註冊表不需要特殊工具，因為它們就是一般的合約。身分查詢是 ERC-721 呼叫，每個註冊表都會發出可供你索引的事件。我們支援所有主要的部署鏈，因此一個標準的 RPC 端點就足以起步。取得代理的註冊檔案只需要一次讀取：

<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 代理架構指南](https://www.alchemy.com/overviews/onchain-ai-agent-architectures)有完整說明。代理的操作錢包應該是受限範圍的簽署者而非原始金鑰，這個模式在我們的[鏈上代理指南](https://www.alchemy.com/blog/how-to-build-onchain-agents)中有端到端的完整示範。代理甚至可以自主管理自己的基礎設施關係，因為[代理可以自行註冊我們的平台](https://www.alchemy.com/blog/ai-agents-can-now-sign-up-for-alchemy)，以錢包作為身分並透過 x402 按次付費，全程無需人工介入。如果你是從程式碼代理開發，[Claude Code 專用的 Alchemy 外掛](https://www.alchemy.com/blog/alchemy-claude-plugin-now-live)將我們的 MCP server 與 skills 打包成一次安裝。

一個 ERC-8004 代理在註冊表之後所做的一切（讀取鏈上狀態、監看事件、簽署交易、為自己的 API 用量付費），都運行在我們把代理當作一等使用者打造的基礎設施上。透過 [Alchemy CLI](https://www.alchemy.com/agents) 取得免費端點，或讓你的代理自行完成開通。不需要交付 API key、不需要簽約，註冊流程中也沒有任何需要人工的環節。

## ERC-8004 有哪些限制？

這項標準還很年輕，它的尖銳邊角都記載在自己的討論串裡。以下幾點應該影響你的設計：

- **Sybil 回饋很廉價。** 錢包不用錢，因此原始信譽分數很容易被偽造。使用回饋時要先以已知客戶或付款證明篩選，絕不要用未經過濾的平均值。
- **身分可以轉讓。** 代理身分是標準的 ERC-721，因此帶有乾淨歷史的老身分可以被出售，信譽也隨之轉手。在信任歷史紀錄之前，先追蹤所有權變更。
- **分數會過期。** 代理具有隨機性，一次模型更新就可能讓行為一夕改變，所以上個月的回饋描述的是上個月的代理。
- **信譽只留在單一條鏈上。** 在 Base 上註冊的代理，到 Arbitrum 上要從零開始。跨鏈彙整是索引器層的問題，標準尚未解決。
- **介面仍可能變動。** 標準仍是草案，也已經歷過一次重新設計。將你的整合釘在已部署的合約上，並在依賴較新的介面之前持續關注規格。

這些都沒有推翻標準真正的主張，它從來不是宣稱鏈上信譽無法造假。它的主張是：代理的信任訊號應該放在公開、共享、無需許可的結構描述中，而不是散落在各個私有資料庫裡。以這個主張來評判，它已經上線，也已經有真實系統在讀取它。

## 常見問題

### 什麼是 ERC-8004？它如何實現免信任的 AI 代理？

ERC-8004 是一項 Ethereum 標準，透過涵蓋身分、信譽與驗證的三個註冊表在鏈上註冊 AI 代理。代理以 ERC-721 代幣的形式取得可攜、可驗證的身分，客戶公開發布回饋，驗證者為工作品質作證，因此代理能在沒有既有信任基礎的情況下跨組織進行交易。

### ERC-8004 已經在主網上線了嗎？

是的。Identity 與 Reputation 兩個註冊表自 2026 年 1 月起在 Ethereum 主網運行，並以相同地址部署在超過二十個網路上。

### ERC-8004 有代幣嗎？

沒有。ERC-8004 是智慧合約標準，不是發行代幣的專案。註冊代理會鑄造一個專屬於該代理的 ERC-721 身分代幣，但不存在同質化的 ERC-8004 資產，任何以此名義行銷的代幣都與這項標準無關。

### ERC-8004 的代理身分可以出售嗎？

可以。代理身分是標準的 ERC-721 代幣，因此能像任何 NFT 一樣轉移，累積的信譽也會隨代幣移轉。這使得所有權歷史成為盡職調查的一部分，因為乾淨的信譽可能是現任操作者買來的，而不是自己掙來的。

### 哪些鏈支援 ERC-8004？

官方註冊表以相同地址部署在超過二十個 EVM 網路上，包括 Ethereum、Base、Arbitrum、Optimism、Polygon、BSC 與 Monad。Alchemy 在這些鏈上提供 RPC 與資料 API，因此代理可以在任何有部署的地方讀寫這些註冊表。

### ERC-8004 與 x402、A2A 有什麼不同？

它們解決的是同一個堆疊中的不同層。A2A 處理代理如何彼此發現與傳訊，x402 處理它們如何透過 HTTP 互相付款，ERC-8004 則透過將身分、信譽與驗證紀錄錨定在鏈上，處理它們是否應該互相信任。正式環境的代理系統通常會把三者組合起來。