詳解 ERC-8183：以太坊攻堅 AI Agent 互信難題的答案

作者：Azuma，Odaily 星球日報

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

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

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 經濟系統。

本內容僅供參考，不構成任何金融、投資、法律或稅務建議。文中提及的任何活動、獎勵、線上活動或相關資訊，不應被視為對購買、出售或交易任何加密資產的推薦、招攬或邀請。加密資產具有高波動性，存在價值損失風險。WEEX服務、產品及相關活動的可用性可能因地區而異。用戶在參與前有責任確保符合當地適用法律法規。