詳解 ERC-8183：以太坊攻堅 AI Agent 互信難題的答案
作者：Azuma，
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 試圖解決的核心問題是，當 Agent 彼此僱用和合作時，如何在沒有平台、沒有法律、沒有人工仲裁的情況下完成交易？
舉個例子，假如某個偏市場推廣方向的 Agent A 希望僱用另一個偏圖像生成的 Agent B 來為其製作一批行銷海報，這裡就存在一個商業互信問題 —— 雙方互不認識，也沒有信任基礎，到底該什麼時候付款？ 假如 A 先付款，B 可能罷工或返還不合格的工作結果；假如 B 先幹活，A 也有可能拒付報酬…
在傳統的網路世界，使用者與商家也會面臨類似的商業互信，而平台則在其中承擔了關鍵的中介作用 —— 平台會負責託管 A 的資金，會負責判斷 B 的服務完成與否，也會負責最後的放款。 我們熟悉的淘寶、京東、美團、滴滴，本質上都是這種平台型中介。
ERC-8183 工作方案拆解
ERC-8183 的運作機制並不複雜，該標準引入了一個名為 Job（你可以理解為「任務」）的新概念。 每一個 Job 都可以視為一筆完整的商業交易，其中會包含三個不同的角色：
- Client：“客戶”，簡單來說就是發佈各類任務的 Agent；
- Provider：“服務商”，就是負責完成任務的 Agent；
- Evaluator：“評估者”，最為特殊的角色，負責判斷任務是否完成。
這裡需要著重解釋下 Evaluator，該角色的引入是 ERC-8183 最核心的設計。
- 對於諸如寫作、設計或分析這類具有主觀性的任務，Evaluator 可以是一個 AI Agent，它會讀取所提交的結果，將其與最初的任務要求進行對比，然後作出判斷；
- 而對於計算、證明產生或資料轉換等確定性任務，Evaluator 則可以是一個封裝了零知識驗證器（ZK verifier）的智慧合約。 Provider 提交證明，Evaluator 在鏈上進行驗證，並自動呼叫「complete」或「reject」來完成或拒絕該任務；
- 在高價值或高風險的任務場景中，Evaluator 也可以是一個多簽帳戶、DAO、或是由質押機制支撐的驗證群集。
ERC-8183 並不會區分這些不同形態。
繼續說回 Job，每個 Job 的生命週期都會有以下四種狀態，這也對應著 ERC-8183 運作時的不同流程。
- Open：Client 會在此週期建立 Job，發布任務並明確要求；
- Funded：Client 會把佣金轉去一個智慧合約託管地址，而不是直接交給 Provider；
- Submitted：Provider 完成工作並提交證明；
- Terminal（Completed / Rejected / Expired）：Evaluator 负责审核任务，并根据审核结果判断任务是否完成（Completed 或 Rejected）并将资金分别转给 Client 或 Provider；若在时间要求内没有 Provider 响应或完成任务，资金会退还给 Client。
除去上述標準流程外，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 負責處理「怎麼放心地去交易」。
