AI Agent 經濟基礎設施：研究入門（第一部分）
AI Agent 經濟基礎設施：研究入門（第一部分）
原文來源：OKX Ventures。本文改編自 OKX Ventures 的深度研究報告。因篇幅較長，我們將其分為兩部分發布：第一部分 著重於宏觀背景、x402 協定、ERC-8004 和 Virtuals Protocol； 第二部分 將深入探討 OpenClaw 及更廣泛的行業趨勢——敬請期待。
執行摘要
AI Agent 正在迅速從被動的協同操作員演變成活躍的經濟參與者：它們發現服務、協商條款、觸發交易，並（越來越多地）在鏈上結算價值。關鍵的轉變並非「AI 變得更聰明」，而是「AI 開始獲得報酬且能夠支付」——這將軟體轉化為市場參與者。
OKX Ventures 將此視為機器對機器（M2M）支付網絡和Agent 經濟基礎設施堆疊的興起，其中身份、信任、支付和 Agent 市場成為可組合的基礎。在其 2026 年展望中，他們強調 Agent 式支付正隨著多種標準和行業試點項目進入早期突破階段。（okxventures.medium.com）
在第一部分中，我們將聚焦於在開發者對話中越來越常出現的三個基礎組件：
- x402：一種 HTTP 原生的支付握手協定，為每次請求支付加密結算恢復了長期預留的
402 Payment Required狀態碼。 - ERC-8004：一個以太坊標準提案，用於無需信任的 Agent 發現 + 信譽 + 驗證。
- Virtuals Protocol：一個鏈上生態系統，將 Agent 視為代幣化的經濟參與者，並透過 ACP 標準化 Agent 間的商業行為。
1) 宏觀背景：為何 Agent 經濟需要加密基礎設施
1.1 Agent 正在成為「API 原生企業」
在 Web2 中，軟體通常透過帳戶、訂閱、API 金鑰、發票和退款來獲利。Agent 打破了這些假設：
- Agent 在執行任務過程中不希望「註冊」。
- Agent 無法可靠地通過為人類設計的 KYC/身份驗證。
- Agent 在緊密的循環中運行（檢索數據 → 執行推論 → 執行動作 → 驗證結果），此時每次調用的結算通常比月度帳單更自然。
這就是為什麼穩定幣小額支付、鏈上結算確定性和可程式化授權再次變得重要——特別是對於串連多個服務的 AI 驅動的工作流程。
1.2 標準正在匯聚：工具、身份、信任和支付
現代 Agent 堆疊正在分層標準化：
- 工具連接性（Agent 如何調用外部服務）— 例如：Model Context Protocol (MCP)
- Agent 間通訊（Agent 如何傳送訊息和協調）— 例如：Agent2Agent (A2A)
- 身份與識別符（實體如何在沒有集中目錄的情況下被解析）— 例如：W3C Decentralized Identifiers (DIDs) (w3.org)
- 支付 + 結算（價值如何轉移）— 其中 x402 等協定旨在使支付成為 HTTP 流程的內建部分。
方向很明確：如果 Agent 將要自主進行交易，我們需要一個機器可讀、預設為無須許可且可在敵對條件下進行驗證的基礎設施堆疊。
2) x402：將 HTTP 402 Payment Required 轉化為鏈上支付流程
2.1 「未被使用」的 HTTP 狀態碼突然變得重要
HTTP 狀態碼 402 已存在數十年，但在 HTTP 語義規範中保留供未來使用。（datatracker.ietf.org） 參考：RFC 9110 — HTTP Semantics
x402 利用了這個保留空間，賦予它一個具體、對開發者友好的含義：如果你需要此資源，請附上有效付款並重試。
關於以 HTTP 為中心的快速概覽，請參閱：MDN: 402 Payment Required。
2.2 x402 提出了什麼（以及為何如此引人注目）
在 x402 的設計中，AI Agent（或任何客戶端）請求 API/資源：
- 客戶端請求 → 請求抵達，未附帶付款。
- 伺服器返回 HTTP 402 → 包含定價 + 付款說明。
- 客戶端附帶簽署的付款授權重試。
- 伺服器驗證並廣播付款 → 返回資源。
該流程明確定位為消除按使用付費存取的 API 金鑰、帳戶和訂閱。（x402.org） 主要參考：x402 白皮書 (PDF)
2.3 為何 x402 是「Agent 原生」（而不僅僅是一個新的結帳按鈕）
x402 對於 Agent 經濟基礎設施的討論很有意思，因為它符合 Agent 的實際工作方式：
- 原子意圖循環：「我需要數據 → 我付款 → 我繼續任務」
- 沒有長期存在的機密資訊（如 API 金鑰）：減少了常見的安全漏洞。
- 可組合的貨幣化：任何 API 端點都可以成為一個微型市場。
這就是Agent 式支付的核心：不只是讓用加密貨幣支付成為可能，而是讓支付機器可觸發且協定層面，內嵌在正常的網路流程中。（x402.org）
2.4 x402 本身未能解決的難題
x402 可以優雅地處理支付傳輸，但生產級的 Agent 商業行為需要更多層級：
- 授權與預算：誰授權了該 Agent 花費，花費多少，以及在何種限制下？
- 爭議/品質執行：如果伺服器未交付承諾的結果怎麼辦？
- 服務原子性：我們能否穩健地將付款與執行+交付綁定？
- Agent 身份與信任：我們如何知道對方的 Agent/服務是合法的？
這正是 ERC-8004 等標準和 Virtuals ACP 等生態系統協定變得高度互補而非競爭的地方。
3) ERC-8004：以太坊上的無須信任 Agent（身份、信譽、驗證）
如果 x402 關乎Agent 如何支付，那麼 ERC-8004 則關乎Agent 如何在組織邊界之間被發現和信任。
3.1 ERC-8004 提出了什麼
ERC-8004（「Trustless Agents」）是一個草擬的以太坊標準，提議使用區塊鏈來：
- 發現 Agent
- 選擇 Agent
- 在預先不存在信任的情況下與 Agent 互動
它定義了一個以以下內容為中心的結構：
- 一個身份註冊所
- 一個信譽註冊所
- 一個驗證註冊所
ERC-8004 強調可插拔的信任模型，其安全性與風險價值成正比，從低風險任務到高風險任務（包括聲譽回饋、質押擔保的重新執行、zkML 證明或 TEE 輔助方法等選項）。（eips.ethereum.org） 主要參考：ERC-8004 on EIPs
3.2 這對 AI Agent 經濟有何意義
在真實貨幣情境下，大多數 Agent 的失敗並非關乎「模型智能」——它們關乎信任邊界：
- 我如何驗證是哪個 Agent 執行了什麼？
- 如果 Agent 被攻破，我如何限制其造成的影響範圍？
- 我是否能證明某個結果是根據約定的規則計算/檢查的？
ERC-8004 的註冊所直接嘗試使Agent 信任可組合，而不是在每個封閉的平台中重複構建。
3.3 ERC-8004 + x402：自然組合
一個實際的心智模型：
- x402：「這是按使用付費服務的支付握手。」
- ERC-8004：「這是如何發現 Agent/服務以及評估信任的方法。」
結合兩者，它們勾勒出一條從臨時 Agent 支付到開放式 Agent 經濟的路徑——讓 Agent 能夠找到供應商、評估信任、付款並繼續前進。
4) Virtuals Protocol：代幣化 Agent 社會 + Agent 商業協定 (ACP)
Virtuals Protocol 從生態系統和協調角度處理 Agent 經濟：將 Agent 視為鏈上經濟參與者，能夠產生輸出、賺取收入並協調任務。
4.1 Virtuals 聲稱正在建構什麼
根據其自身的闡述，Virtuals Protocol 是「一個 AI Agent 的社會」：一個鏈上生態系統，Agent 在其中透過區塊鏈無須許可地協調工作、進行交易並結算結果。（whitepaper.virtuals.io） 主要參考：Virtuals Protocol 白皮書
一個值得注意的設計選擇：該協定將 $VIRTUAL 定位為 Agent 互動之間的基本交易貨幣和流動性對。（whitepaper.virtuals.io）
4.2 ACP：Agent 間商業的標準
Virtuals 認為，如果沒有標準化協定，整合 Agent 商業就會變成自訂程式碼和脆弱假設的組合混亂——特別是隨著 Agent 和交易類型的數量不斷增加。（whitepaper.virtuals.io） 參考：Agent Commerce Protocol (ACP)
重要的是，ACP 不僅僅是「支付」。它關乎：
- Agent 供應的可發現性
- 結構化的工作流程
- 鏈上結算路徑
- Agent 商業的共享詞彙
4.3 ACP v2 標誌著向真實世界複雜性邁進
Virtuals 的文件將 ACP v2 描述為一次重大更新，引入了（除其他外）：
- 工作流程的統一職位介面
- 用於領域特定需求的自訂職位發布綱要
- 帳戶作為 Agent 間關係和互動歷史的持久鏈上記錄。（whitepaper.virtuals.io）
這之所以重要，是因為 Agent 商業本質上是異質的：「購買資料集」、「執行審計」、「執行交易」以及「交付媒體資產」不可能嚴格符合單一剛性綱要。
4.4 Virtuals + ERC-8004 + x402：互補角色
一個連貫的堆疊可以出現：
- ERC-8004：跨邊界的發現 + 信任基礎。
- x402：API/服務的無摩擦按使用付費結算。
- ACP (Virtuals)：商業網絡內的協同工作流程、職位結構設計和 Agent 間協調。
2026 年的懸而未決的問題並非 Agent 是否能夠交易——而是我們能否足夠標準化工作流程和信任介面，以防止生態系統分裂成不兼容的孤島。
5) 開發者與使用者檢查清單：2025–2026 年應關注事項
5.1 對開發者而言：缺失的「控制平面」
如果您需要整合 Agent 式支付或鏈上 Agent 互動，請優先考慮：
- 支出政策（按商家、按任務、按時間窗口的限制）
- 金鑰隔離（將營運金鑰與金庫金鑰分開）
- 可審計性（簽署所有意圖並儲存收據）
- 備用方案與斷路器（可暫停的流程、邊緣情況下的人工批准）
這就是「Agent 經濟基礎設施」變得真實的地方：支付很容易；安全支付很困難。
5.2 對使用者而言：自我託管成為 Agent 安全基礎
一旦 Agent 能夠進行交易，錢包安全就不再是狹隘的關注點——它變成了營運風險管理。
許多團隊採用的實際方法是按角色劃分資金：
- 一個小型、受監控的熱錢包，用於有限的日常 Agent 支出。
- 一個冷儲存的金庫錢包，僅在有意為之時才補充預算。
如果您運行與 DeFi 或按使用付費加密服務互動的 Agent，這也是硬體錢包可以自然融入的地方。例如，OneKey 的設計旨在實現自我託管，可以在您刻意簽署交易時支援鏈上工作流程，同時將長期資金離線保存。
後續（第二部分預覽）
在第二部分中，我們將把這個基礎設施地圖擴展到：
- OpenClaw：它在 Agent 運行時/工具層的作用以及對加密貨幣用戶的意義。
- 更廣泛的行業軌跡：互操作性、合規壓力、安全事件，以及開放標準與封閉平台之間的鬥爭。
免責聲明：本文僅供參考，不構成財務建議。
