AI Agent 鏈上身分是指利用區塊鏈上的可查詢記錄,為人工智慧智能體建立能夠跨應用程式識別、關聯與管理的數位身分。隨著 AI Agent 從簡單的對話助理逐漸發展為能夠呼叫工具、存取資料、執行任務及參與經濟活動的自主系統,智能體身分正成為開放協作網路的重要基礎設施。ERC-8004 正是因應這項需求所提出的以太坊標準,嘗試透過鏈上註冊表建立智能體身分、聲譽與驗證資訊的通用介面。
在傳統軟體系統中,服務身分通常依賴平台帳戶、API 金鑰及企業內部的權限管理。對於在同一組織或平台內運作的智能體而言,這些方式能夠滿足大部分需求。但當多個 AI Agent 來自不同開發者、運作於不同基礎設施,且需要彼此委託任務時,如何發現服務、確認控制關係、評估過往表現及驗證執行結果,就成為新的技術挑戰。
ERC-8004、MCP(Model Context Protocol)及 A2A(Agent2Agent)分別從不同角度回應這些問題。MCP 讓智能體能夠連接工具與資料,A2A 讓不同智能體能夠進行通訊與協作,而 ERC-8004 則為跨平台環境提供身分發現及信任訊號。了解三者的技術邊界與協作方式,有助於判斷開放式 AI Agent 網路如何從單一工具呼叫,發展為可組合的多智能體系統。
AI Agent 的身分問題並不只是為程式分配一個名稱,而是需要建立能夠被其他系統識別與核驗的身分關聯。
在中心化平台中,Agent 通常依靠平台帳號、API 金鑰或開發者提供的服務位址進行識別。平台可以管理使用者權限、維護服務目錄,並對違規行為採取限制措施。這種模式適合單一平台內的業務,但當智能體需要跨組織合作時,就可能面臨身分資訊無法共享、歷史評價難以移轉,以及服務可信度依賴特定平台等問題。
例如,一家企業開發的市場分析 Agent 已經在某個平台累積大量服務記錄。當它接入另一個智能體網路時,新平台可能無法直接驗證這些記錄,開發者需要重新建立身分與聲譽。
鏈上身分試圖改善這種割裂。透過公共區塊鏈記錄身分識別碼、控制權及部分信任訊號,不同應用程式可以查詢相同的註冊資訊,並在此基礎上建立自己的服務發現與風險評估系統。
但鏈上身分並不要求 AI 模型本身運作於區塊鏈上。實際推理、資料庫存取及工具呼叫仍可在鏈下完成,區塊鏈主要負責共享註冊、可驗證記錄及信任協調等功能。
這也代表鏈上身分無法取代傳統身分驗證。某個位址可以證明特定金鑰擁有某項操作權限,卻不一定能證明該位址背後的開發者具備真實資格。對於金融、醫療等高風險場景,仍需要額外的法律身分核驗及業務授權。
ERC-8004 的正式名稱為 Trustless Agents,是以太坊生態系針對開放式智能體網路所提出的標準。其目標是在缺乏預先信任關係的情況下,為智能體提供跨組織的發現與信任基礎設施。
ERC-8004 的身分註冊機制建立在 ERC-721 之上。開發者註冊智能體後,可以取得一個 agentId,並透過對應的註冊資訊關聯 Agent 名稱、功能說明、服務端點及支援的通訊協定。
這種設計使智能體身分可以與具體服務位址分離。例如,一個 Agent 可以更換伺服器或更新 A2A 介面,同時保留其註冊身分。其他應用程式只需查詢相關註冊資訊,就能取得更新後的服務入口。
ERC-8004 也允許註冊資訊關聯 MCP、A2A、ENS、DID 及錢包位址等不同類型的端點,讓鏈上身分能夠連接現有的 Web3 與 AI 基礎設施。
其核心由三個註冊表組成:
| 註冊表 | 主要功能 | 應用價值 |
|---|---|---|
| Identity Registry | 註冊 Agent 身分並關聯中繼資料 | 支援跨平台身分發現 |
| Reputation Registry | 提供標準化回饋記錄介面 | 協助評估過往服務表現 |
| Validation Registry | 記錄獨立任務驗證請求與結果 | 為高價值任務提供額外信任訊號 |
其中,Reputation Registry 不負責自動判斷哪些評價真實可信,而是提供可查詢的回饋記錄。不同應用程式可以自行設計評分、篩選及風險評估演算法。
Validation Registry 則允許第三方驗證者檢查特定任務結果。驗證方式可以包括重複執行、可信任執行環境(TEE)或零知識機器學習(zkML)等技術。
需要注意的是,ERC-8004 在以太坊 EIP 頁面上的狀態仍為 Draft。這不妨礙開發者進行部署與實驗,但代表其規範狀態應與實際應用情況區分開來。
MCP(Model Context Protocol)是一種用於連接 AI 應用程式與外部工具、資料及上下文資源的開放協定。
在沒有統一介面的情況下,開發者可能需要為每種資料庫、檔案系統或 API 分別撰寫整合邏輯。隨著智能體使用的工具數量增加,這種方式容易造成重複開發,並提高維護成本。
MCP 透過用戶端與伺服器之間的標準化通訊,降低不同 AI 應用程式接入外部能力的複雜度。
在 MCP 架構中,伺服器可以向用戶端提供三類主要能力:
例如,一個加密研究 Agent 可以透過 MCP 連接市場行情資料庫、鏈上資料介面及研究資料庫。面對使用者提出的分析任務時,Agent 可以呼叫相應工具,取得資料後再產生研究結果。
MCP 的重點是標準化工具存取,而不是建立公共鏈上身分。
MCP 也可以結合傳統授權機制,保護受限制的服務。對於 HTTP 傳輸,相關規範支援基於 OAuth 的授權流程。因此,不能將 MCP 理解為完全不具備身分識別或存取控制能力。
MCP 與 ERC-8004 的差異在於,MCP 的授權主要服務於具體工具連接與資源存取,而 ERC-8004 更關注跨平台環境下可共享的智能體身分與信任記錄。
A2A(Agent2Agent)是一種面向不同智能體系統的開放通訊協定,最初由 Google 推動開發,後來進入 Linux Foundation 生態系。
與主要用於連接工具的 MCP 不同,A2A 的目標是讓由不同開發者、不同框架建構的 AI Agent 能夠發現彼此的能力,並透過統一方式交換訊息、委託任務及管理執行狀態。
A2A 的重要機制之一是 Agent Card。這是一種機器可讀取的中繼資料文件,用於描述智能體的名稱、能力、技能、服務位址及驗證要求。
當一個 Agent 需要委託任務時,可以先讀取對方的 Agent Card,判斷其是否具備所需能力,再依照協定發起請求。
A2A 也支援任務生命週期管理。例如,一項複雜的研究任務可能需要較長時間才能完成,發起方可以查詢任務狀態、接收進度更新,並在執行結束後取得結果。
這與一般 API 請求有所不同。傳統 API 通常針對單次操作設計,而 A2A 更強調不同智能體之間持續性的任務互動。
不過,A2A 本身也具備能力發現與驗證相關機制。因此,ERC-8004 並不是要為 A2A 補上完全缺失的身分功能,而是為其增加可跨平台共享的鏈上身分、聲譽及驗證資訊。
A2A 負責通訊與任務協作,ERC-8004 則可以協助呼叫方在建立合作之前,評估服務提供者的過往表現及相關信任訊號。
ERC-8004、MCP 與 A2A 分別處理智能體系統中的不同問題。三者可能出現在同一個業務流程中,但不要求所有 AI Agent 同時使用。
| 比較面向 | ERC-8004 | MCP | A2A |
|---|---|---|---|
| 核心定位 | 鏈上身分與信任 | 工具與資料連接 | 智能體通訊與協作 |
| 主要解決的問題 | 如何發現並評估 Agent | 如何呼叫外部能力 | 如何與其他 Agent 共同完成任務 |
| 核心機制 | 身分、聲譽、驗證註冊表 | Tools、Resources、Prompts | Agent Card、Messages、Tasks |
| 是否依賴區塊鏈 | 是 | 否 | 否 |
| 是否支援身分相關功能 | 鏈上身分註冊與關聯 | 具體連接中的身分及授權機制 | Agent Card 與通訊驗證 |
| 是否提供聲譽機制 | 提供標準化回饋介面 | 不提供通用鏈上聲譽體系 | 不提供通用鏈上聲譽體系 |
| 典型應用 | 服務發現、聲譽查詢、結果驗證 | 資料查詢、工具呼叫、資源存取 | 多 Agent 分工、任務委託、狀態管理 |
可以將三者理解為開放式智能體網路中的三個層次。
ERC-8004 提供跨平台可查詢的身分與信任訊號,MCP 為智能體連接執行任務所需的工具,A2A 則協助多個智能體交換任務與結果。
這種劃分也代表,ERC-8004 不會取代 MCP 的工具呼叫能力,MCP 不會取代 A2A 的任務協作機制,而 A2A 也不需要依靠區塊鏈才能完成通訊。
三者的價值在於可以根據業務需求組合,而不是必須形成固定的技術依賴關係。
假設一家機構希望透過 AI Agent 自動產生某種加密資產的研究報告。整個任務可能涉及市場行情、鏈上資料、新聞資訊及風險分析,需要多個智能體共同完成。
首先,主要研究 Agent 需要尋找能夠提供鏈上分析服務的專業 Agent。它可以透過 ERC-8004 的 Identity Registry 查詢相關註冊資訊,取得服務說明與 A2A 端點。
接著,主要研究 Agent 可以讀取 Reputation Registry 中的歷史回饋,判斷候選服務提供者是否具備相應的服務經驗。對於要求較高的分析任務,還可以參考獨立驗證記錄。
完成篩選後,主要研究 Agent 透過 A2A 向目標 Agent 發起任務,要求分析某項資產近期的鏈上資金流向。
受委託的 Agent 接收任務後,透過 MCP 呼叫區塊鏈資料工具、資料庫或外部 API,取得所需資訊並執行分析。
任務完成後,受委託的 Agent 透過 A2A 傳回研究結果。主要研究 Agent 可以繼續整合其他資訊,產生最終報告。
如果應用程式已整合 ERC-8004 的回饋機制,也可以在任務結束後記錄服務品質評價,供未來合作方參考。

這個情境的關鍵並不是將所有資料寫入區塊鏈,而是將不同功能放在適合的基礎設施上。
身分與信任訊號可以透過鏈上註冊表共享,複雜的任務通訊由 A2A 處理,資料存取與工具執行則透過 MCP 完成。
這種分層設計既保留了傳統網際網路系統的執行效率,也讓不同組織之間的協作能夠利用公共信任基礎設施。
開放式智能體網路中的一項重要挑戰,是如何讓 Agent 在不同平台累積的服務表現獲得重複使用。
如果聲譽完全由中心化平台管理,智能體離開原平台後,可能無法繼續使用既有的評價記錄。新平台也難以獨立檢查歷史資料的來源。
ERC-8004 的 Reputation Registry 為此問題提供標準化介面,使客戶端回饋能夠關聯至相應的鏈上身分。
但公開記錄並不代表評價會自動可信。惡意開發者可能建立大量關聯帳戶,為自己控制的 Agent 提供虛假回饋;競爭對手也可能嘗試操縱評分。
因此,應用程式仍需要結合評價來源、歷史行為及異常模式,對聲譽訊號進行篩選與加權。
對於更重要的任務,僅依靠聲譽可能不足以建立信任。例如,一個 Agent 提供智慧合約風險分析時,客戶不僅需要了解它過去的評價,也可能希望確認其使用的偵測方法與分析結果是否經過獨立檢查。
Validation Registry 允許相關系統記錄驗證請求與結果,並將其與特定 Agent 身分建立關聯。
不過,驗證品質取決於所使用的方法及驗證者本身。TEE 證明特定執行環境的屬性,zkML 證明特定計算過程符合相應條件,但這些都不代表最終商業判斷必然正確。
因此,ERC-8004 的優勢在於支援多種信任機制組合,而不是提供一個能夠自動判定所有 Agent 安全性的統一評分。
中心化 Agent 目錄並非沒有價值。對於企業內部系統而言,統一管理平台通常更容易實現存取控制、服務審核與安全維護。
但在跨組織環境中,不同平台可能採用不同的註冊標準與評價體系。某個平台擁有的身分資訊與聲譽資料,不一定能被其他平台直接查詢或重複使用。
區塊鏈提供了一種共享記錄的方式,使不同應用程式可以圍繞同一套公開註冊資訊建立服務。
ERC-8004 採用 ERC-721 作為身分註冊基礎,使 Agent 身分能夠與鏈上所有權及控制關係建立關聯。註冊資訊還可以指向鏈下中繼資料,避免將所有描述與服務資料直接儲存在區塊鏈上。
這種方式具有一定的可組合性。例如,第三方開發者可以建構 Agent 搜尋引擎、聲譽分析平台或任務驗證服務,而不必完全依賴原始註冊平台。
不過,區塊鏈也會引入新的成本與複雜度,包括交易費用、不同網路之間的身分協調,以及公開記錄可能帶來的隱私問題。
此外,鏈上身分雖然可以被查詢,但相關服務端點仍可能失效,中繼資料也可能包含錯誤或誤導性內容。公共註冊表不能取代持續的服務監控。
因此,區塊鏈更適合解決跨組織共享與信任協調問題,不一定適合承擔智能體的全部執行與管理功能。
ENS(Ethereum Name Service)與 DID(Decentralized Identifier)同樣涉及數位身分,因此容易與 ERC-8004 混淆。
ENS 主要提供人類可讀名稱與相關記錄解析能力。例如,以太坊位址可以關聯便於識別的 ENS 名稱,降低使用者使用複雜位址的難度。
DID 則是一類去中心化識別碼規範,可結合不同 DID 方法與驗證機制,建立數位身分體系。
ERC-8004 更專注於 AI Agent 的應用需求。它不僅需要身分識別碼,還要關聯服務能力、通訊端點、歷史回饋及任務驗證資訊。
| 標準 | 核心定位 | 主要用途 |
|---|---|---|
| ENS | 名稱與記錄解析 | 將可讀名稱關聯至位址或其他資訊 |
| DID | 去中心化身分識別框架 | 建立可驗證的數位身分關聯 |
| ERC-8004 | Agent 身分與信任註冊 | 發現 Agent、查詢聲譽及驗證任務 |
這些機制並不互相排斥。
一個 Agent 可以同時擁有 ERC-8004 身分、ENS 名稱與 DID 識別碼,並在註冊資訊中關聯相關資料。
差異在於,ENS 與 DID 並不專門提供 ERC-8004 所定義的智能體聲譽與任務驗證註冊表。
鏈上身分可以提高記錄的可查詢性,但無法天然解決開放網路中的安全問題。
首先是身分濫用風險。建立鏈上身分不一定需要嚴格的現實世界身分審核,因此惡意參與者可能註冊大量 Agent,製造虛假的服務網路或聲譽記錄。
其次是身分控制權風險。如果 Agent 的控制金鑰遭竊,攻擊者可能修改註冊資訊或執行未經授權的操作。對於高價值智能體,開發者需要採用更嚴格的金鑰管理與權限分離機制。
第三是中繼資料安全風險。ERC-8004 註冊資訊可以關聯外部服務端點,但這些端點可能遭受攻擊、替換或停止運作。客戶端不能僅因某個位址出現在註冊表中,就直接信任其回傳內容。
第四是隱私問題。鏈上回饋與驗證記錄可能長期公開。如果開發者將客戶身分、敏感任務內容或商業資料直接寫入鏈上,就可能造成不可逆的資訊暴露。
因此,更合理的設計是將必要的身分識別碼、摘要及信任訊號記錄在鏈上,並將敏感業務資料保留在具備適當存取控制的鏈下系統中。
最後是信任模型本身的限制。某個 Agent 在簡單資料查詢任務中表現良好,不代表它能夠安全執行複雜的金融操作。應用程式需要根據任務價值、錯誤後果及資料敏感程度,選擇不同的驗證強度。
對於涉及資產轉移或交易執行的智能體,也應單獨設定錢包權限、資金限額及人工審批條件,不能將鏈上身分視為資金操作授權。
ERC-8004、MCP 與 A2A 的發展,反映出 AI Agent 基礎設施正從單一應用程式內部的工具呼叫,逐步延伸至跨平台、跨組織的協作網路。
MCP 降低了智能體連接外部資料與工具的複雜度,A2A 為不同智能體之間的任務互動提供通用方式,而 ERC-8004 則嘗試讓身分與信任資訊不再完全依賴單一平台。
對於 Web3 生態系而言,這種架構可能催生新的應用,包括去中心化 Agent 目錄、鏈上聲譽分析、智能體任務驗證,以及面向機器服務的支付與結算系統。
如果再結合 x402 等支付協定,智能體還可以在取得授權後,為資料、運算及其他數位服務付款,形成從服務發現、任務執行到支付與回饋的更完整流程。
但這些標準的採用並不代表所有 AI Agent 都需要發行代幣,或所有智能體活動都必須在區塊鏈上執行。
真正有價值的應用,仍需證明其在成本、效率、安全性及跨平台互通性方面優於現有方案。
從長期來看,開放式智能體網路的發展可能使區塊鏈從單純的資產記錄與結算基礎設施,進一步承擔機器身分與信任協調的角色。
AI Agent 需要鏈上身分,主要是因為開放式智能體網路正面臨跨平台身分發現、聲譽移轉及任務驗證等問題。
傳統平台帳戶與 API 金鑰可以解決特定系統內的身分與授權需求,但在多個組織之間,相關資訊往往難以共享。ERC-8004 透過鏈上身分、聲譽及驗證註冊表,為不同平台建立可組合的信任基礎設施。
MCP 與 A2A 則分別解決智能體的工具連接與跨系統協作問題。MCP 讓 Agent 能夠存取資料並執行工具操作,A2A 讓不同 Agent 可以發現能力、委託任務並交換結果。
三者並非替代關係,而是可以根據實際需求組合使用。
未來,隨著 AI Agent 逐漸參與資料採購、金融研究、企業營運及自動化服務,身分、信任、通訊與支付可能形成更完整的技術體系。但鏈上身分不等於真實可信,公開聲譽也不等於服務品質保證,實際應用仍需要完善的安全驗證、權限管理與風險控制。
ERC-8004 解決開放網路中的身分與信任協調,MCP 連接工具與資料,A2A 連接不同智能體。三者共同為跨平台 AI Agent 協作提供基礎。
鏈上身分能夠為智能體提供跨平台可查詢的識別碼,並關聯服務資訊、歷史回饋及驗證記錄,減少對單一中心化目錄的依賴。
ERC-8004 是面向 AI Agent 的以太坊標準提案,透過身分、聲譽及驗證註冊表,支援智能體發現與信任評估。
ERC-8004 主要處理跨平台身分與信任資訊,MCP 主要解決 AI 應用程式如何連接外部工具、資料與上下文資源。
MCP 側重智能體與工具之間的互動,A2A 側重不同智能體之間的通訊、任務委託與協作。
Agent Card 可以描述智能體的能力與服務端點,但 ERC-8004 進一步提供跨平台共享的鏈上身分、聲譽回饋及任務驗證介面。
不要求。AI 模型推理與工具執行可以繼續在鏈下完成,區塊鏈主要用於身分註冊及相關信任記錄。
不代表。鏈上註冊只能證明特定身分與註冊記錄之間的關聯,仍需結合服務驗證、聲譽分析及安全控制來評估風險。
可以。ERC-8004 提供身分與信任訊號,MCP 與 A2A 負責工具存取及任務協作,而 x402 則可以為付費服務提供支付能力。
* 投資有風險,入市須謹慎。本文不作為 Gate 提供的投資理財建議或其他任何類型的建議。
* 在未提及 Gate 的情況下,複製、傳播或抄襲本文將違反《版權法》,Gate 有權追究其法律責任。





