ERC-8183是什麼標準？想解決什麼？ERC-8183和x402、ERC-8004有何不同？

目錄

• 一、ERC-8183是什麼？
• 二、ERC-8183 想解決什麼？
• 三、ERC-8183 工作方案拆解
• 四、ERC-8183和x402、ERC-8004有何不同？

3 月 10 日，以太坊基金會旗下專註於推動“人工智能（AI）與區塊鏈深度整合”的 dAI 團隊與 Virtuals Protocol 聯合推出瞭一項新的標準 ERC-8183。

以太坊基金會 AI 負責人 Davide Crapis 就該標準表示，ERC-8183 是以太坊社區正在構建的開放型 Agent 經濟系統所缺失的組件之一，該標準可與 x402 以及 ERC-8004 組合使用，在 Agent 之間的安全交互方面發揮基礎設施作用。dAI 團隊將支持 ERC-8183 的采用，致力於使其成為中立標準。

一、ERC-8183是什麼？

ERC-8183全稱為「代理商務標準」，是以太坊上無需許可、可編程的鏈上智能合約標準，核心是「Job」原語，本質是為AI代理之間的交易，搭建一套無需信任的完整流程，無需依賴任何中心化平臺，避免單點故障和規則篡改。

通俗來說，ERC-8183就是AI代理之間「放心做生意」的去中心化規則。ERC-8183可以解決不同智能體之間缺乏信任基礎，沒有機制保障交易履行。

其核心邏輯很簡單：每筆代理交易對應一個「Job」，由三方參與，且僅通過錢包地址標識身份，門檻極低，客戶端（發任務、付費用）、提供者（做任務、交成果）、評估者（驗成果、定結果）。

客戶端創建任務並支付費用，資金存入鏈上托管帳戶（避免付瞭錢拿不到成果）；提供者完成後，將成果（或其哈希值）上傳鏈上；評估者審核後，要麼確認完成並向提供者放款，要麼拒絕並將資金退給客戶端；若逾期未操作，資金自動退回客戶端，全程由智能合約強制執行，無需人工幹預。

主觀性任務（如設計、寫作）可由AI代理擔任評估者；確定性任務（如數據轉換）可由零知識證明智能合約擔任；高風險交易則可由DAO或多重簽名驗證器擔任，無需擔心評估不公。

二、ERC-8183 想解決什麼？

根據 Virtuals Protocol 方面所發佈的介紹文章，ERC-8183 專為 AI Agent 之間的商業交易而設計，該標準定義瞭一套鏈上規則，使兩個互不信任的 Agent 能夠完成“雇傭-交付-結算”這樣的商業流程，而不需要依賴中心化平臺。

ERC-8183 試圖解決的核心問題是，當 Agent 彼此雇傭和合作時，如何在沒有平臺、沒有法律、沒有人工仲裁的情況下完成交易？

舉個例子，假如某個偏市場推廣方向的 Agent A 希望雇傭另一個偏圖像生成的 Agent B 來為其制作一批營銷海報，這裡就存在一個商業互信問題 —— 雙方互不認識，也沒有信任基礎，到底該什麼時候付款？假如 A 先付款，B 可能罷工或者返還不合格的工作結果；假如 B 先幹活，A 也有可能拒付報酬……

在傳統的互聯網世界，用戶與商傢也會面臨類似的商業互信，而平臺則在其中承擔瞭關鍵的中介作用 —— 平臺會負責托管 A 的資金，會負責判斷 B 的服務完成與否，也會負責最後的放款。我們熟悉的淘寶、京東、美團、滴滴，本質上都是這種平臺型中介。

而以太坊基金會和 Virtuals Protocol 想要做的，便是通過 ERC-8183 將平臺的職能抽象為鏈上協議，使其由智能合約執行，從而在 Agent 經濟中承擔起一種去中心化的中介角色。

三、ERC-8183 工作方案拆解

ERC-8183 的運行機制並不復雜，該標準引入瞭一個名為 Job（你可以理解為“任務”）的新概念。每一個 Job 都可以視作一筆完整的商業交易，其中會包含三個不同的角色：

• Client：“客戶”，簡單來說就是發佈各類任務的 Agent；
• Provider：“服務商”，就是負責完成任務的 Agent；
• Evaluator：“評估者”，最為特殊的角色，負責判斷任務是否完成。

這裡需要需要著重解釋下 Evaluator，該角色的引入是 ERC-8183 最核心的設計。在該標準中，Evaluator 僅被定義為一個鏈上地址（address），但從更廣義的角度來看，該地址背後可以對應多種不同的執行形態。

• 對於諸如寫作、設計或分析這類具有主觀性的任務，Evaluator 可以是一個 AI Agent，它會讀取所提交的結果，將其與最初的任務要求進行對比，然後作出判斷；
• 而對於計算、證明生成或數據轉換等確定性任務，Evaluator 則可以是一個封裝瞭零知識驗證器（ZK verifier）的智能合約。Provider 提交證明，Evaluator 在鏈上進行驗證，並自動調用「complete」或「reject」來完成或拒絕該任務；
• 在高價值或高風險的任務場景中，Evaluator 還可以是一個多簽賬戶、DAO、或是由質押機制支撐的驗證集群。

ERC-8183 並不會區分這些不同形態。協議層隻關心一點 —— 某個地址是調用「complete」還是「reject」，至於這個地址背後運行的是一個由 LLM 驅動的 AI Agent，還是一個 ZK 電路，都不屬於協議需要關心的范圍。

繼續說回 Job，每一個 Job 的生命周期都會有以下四種狀態，這也對應著 ERC-8183 運轉時的不同流程。

• Open：Client 會在此周期創建 Job，發佈任務並明確要求；
• Funded：Client 會把傭金轉去一個智能合約托管地址，而非直接交給 Provider；
• Submitted：Provider 完成工作並提交證明；
• Terminal（Completed / Rejected / Expired）：Evaluator 負責審核任務，並根據審核結果判斷任務是否完成（Completed 或 Rejected）並將資金分別轉給 Client 或 Provider；若在時間要求內沒有 Provider 響應或完成任務，資金會退還給 Client。

除去上述標準流程外，ERC-8183還可通過模塊化的擴展功能 Hooks 來實現更多衍生功能，以對應現實世界的復雜商業用例。Hooks 是 Job 創建時附加的可選智能合約，可在 Job 各個生命周期的前後執行自定義邏輯，比如信譽門檻、競價機制、費用分配，或是其他特殊要求。

四、ERC-8183和x402、ERC-8004有何不同？

從 x402 到 ERC-8004，再到如今的 ERC-8183，不太熟悉的讀者可能會一頭霧水，納悶為什麼隔一陣子就要做一個新的東西。但其實，這三者分別處在 AI Agent 經濟系統的三個不同環節，想要解決的問題也各不相同。

x402 是一個 HTTP 支付協議，它想要解決的問題是讓 AI Agent 能夠像調用 API 一樣直接付款；ERC-8004 是 AI Agent 身份與聲譽標準，它解決的問題是如何判斷一個 Agent 是否可靠；ERC-8183 則面向瞭商業交易環節，想攻破如何讓兩個不信任的 Agent 完成交易的難題。

如果用一句話概括就是，x402 負責解決“怎麼付錢”；ERC-8004 負責知道“對方是誰、靠不靠譜”；ERC-8183 負責處理“怎麼放心地去交易”。

三者並非競爭關系，而是互補關系，它們共同指向著同一個目標 —— 構建一個去中心化、能夠自主運轉的 AI Agent 經濟系統。

以上就是ERC-8183是什麼標準？想解決什麼？ERC-8183和x402、ERC-8004有何不同？的詳細內容，更多關於一文詳解ERC-8183的資料請關註腳本之傢其它相關文章！