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

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 或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 則面向了商業交易環節,想破如何讓兩個不信任的攻題。

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

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

分享至:

作者:Odaily星球日报

本文為PANews入駐專欄作者的觀點,不代表PANews立場,不承擔法律責任。

文章及觀點也不構成投資意見

圖片來源:Odaily星球日报如有侵權,請聯絡作者刪除。

關注PANews官方賬號,一起穿越牛熊