AI Agent經濟基礎設施研究報告(下)
- 核心觀點:本文深入剖析了OpenClaw項目及其引發的AI Agent經濟浪潮,指出Crypto基礎設施(如x402支付協議、ERC-8004身份協議)在解決跨平台、無信任協作場景下的獨特價值,但其大規模採用取決於Agent間經濟活動是否從個人工具演變為多Agent協作網絡。
- 關鍵要素:
- OpenClaw的爆發與意義:該項目在四個月內成為GitHub歷史Star數最多的軟件,其核心是讓AI Agent主動在用戶已有平台上工作,為觀察Agent與鏈上經濟設施的互動提供了大規模真實場景。
- 技術架構的四大挑戰:OpenClaw架構揭示了身份識別、安全管控、執行非確定性與記憶持久性等核心問題,其安全約束依賴自然語言,存在被壓縮或注入攻擊的風險。
- Agent經濟的結構性瓶頸:核心問題是「上下文不流動」,導致Agent的知識、信任與價值被鎖定在單機環境,缺乏跨組織、可驗證的發現、定價與協作機制。
- Crypto的不可替代場景:當需要跨組織、跨平台、無預先信任關係的Agent間進行互操作與經濟活動時,鏈上身份、支付和聲譽系統比任何中心化方案更合適。
- 安全威脅與鏈上方案:Agent的廣泛權限帶來巨大攻擊面。鏈上基礎設施(如可審計日誌、可編程權限、聲譽系統)能緩解後果,提供結構性安全機制,但需與運行時安全層結合。
- 競爭與採用路徑:真正的競爭是Crypto方案與Web2方案(如Stripe虛擬卡)的競爭。Crypto方案需在開發者體驗上超越對手,其大規模採用可能在未來3-5年傳統方案痛點爆發時到來。
- 商業模式變革:「Product-Agent Fit」將取代「Product-Market Fit」,商業模式可能轉向「按爬取付費」的微交易,API穩定性和鏈上可驗證記錄將成為新護城河。
本文為 OKX Ventures 出品的深度研報。由於篇幅較長,將分為上下兩篇發布:上篇聚焦宏觀背景、x402 協議、ERC-8004 與 Virtuals Protocol,點此跳轉;下篇將重點分析 OpenClaw 及整體行業趨勢。
第五章 OpenClaw:應用生態專項研究
5.1 項目背景與爆發
2025 年 11 月,奧地利開發者 Peter Steinberger 把一個週末項目發到 GitHub。四個月後的 2026 年 3 月,這個項目超過 React 成為 GitHub 歷史上 Stars 最多的軟體項目——25 萬+ Stars,React 用了 13 年才達到同樣數字。
在 AI 產品從被動工具向主動 Agent 演進的大趨勢下,OpenClaw 做的改變是:AI 不再等用戶去找它,而是主動在用戶已有的平台上幫用戶做事。它住在用戶的電腦上,同時接入 WhatsApp、Telegram、Slack、Discord、Signal、iMessage、飛書等超過 20 個渠道,通過 MCP 協議操作郵箱、日曆、瀏覽器、檔案系統、程式碼編輯器。Andrej Karpathy 為這類系統造了一個詞:Claws;在後台循環運行、能自主決策和執行任務的本地 AI Agent。這個詞很快在矽谷成了本地託管 AI Agent 的通用說法。
每一個主流模型發布都把 Agent 能力作為頭版,因為 Agent 是證明 AI 基礎設施投資合理性的需求乘數:一次聊天查詢消耗幾百個 token,一次帶工具調用和多步推理的 Agent 運行消耗幾萬到幾十萬個 token。
雖然創始人在 Discord 禁止討論加密貨幣。但 Crypto 社群在 OpenClaw 之上自發構建了一整套鏈上經濟基礎設施:代幣發射、身份註冊、支付協議、社交網路、聲譽系統等。OpenClaw 的爆發讓我們第一次可以在一個真實的、大規模的場景中觀察 Agent 和鏈上基礎設施的互動方式並且給 Crypto 社群提供了一個有真實用戶基礎的宿主來附著經濟活動。
5.2 技術架構分析
第一層:訊息渠道——身份問題
OpenClaw 同時接入 20+ 平台,從 Agent 內部看,它知道自己是同一個,有統一的記憶、統一的配置、統一的 SOUL.md。但從外部看,別人怎麼知道 Telegram 上的這個 Agent 和 Discord 上的那個 Agent 是同一個?每個平台有自己的用戶 ID 系統,平台之間不互通且無法查看行為記錄。這正是 ERC-8004 試圖解決的核心問題。
第二層:閘道——安全問題
Gateway 是 OpenClaw 的大腦調度中心:把用戶訊息路由到正確 Agent、載入該 Agent 的會話歷史和可用 Skills、在 Agent 開始思考之前劃定權限邊界(白名單機制:當一條訊息到達 Gateway 時,系統基於訊息來源渠道、用戶 ID、群組 ID 等資訊,動態產生一個工具白名單。只有在白名單上的工具才會被注入到 Agent 的上下文中。Agent 根本看不到白名單之外的工具,所以也不可能調用)
這個設計的好處是安全性前置。但其權限管控完全依賴 Gateway 單點,如果被攻破或配置有誤,Agent 可能獲得不該有的權限。
第三層:Agent 核心(ReAct 循環)——可預測性問題
Agent 的運行邏輯是 ReAct(Reasoning + Acting)循環:接收輸入 → 思考(調用 LLM)→ 決定行動 → 調用工具 → 獲取結果 → 再思考 → 循環。OpenClaw 做的工程優化包括:高頻訊息調度(Steer/Collect/Followup/Interrupt 四種策略)、LLM 雙層容錯(認證輪轉 + 模型降級)以及可選思考分級機制(6 個等級)。
但 LLM 是機率性本質、輸出是不確定的。Agent 是非確定性的執行者,在非確定的環境中做出不可逆的動作。
首先是上下文壓縮導致的約束丟失:安全約束本身也是上下文的一部分,當上下文被有損壓縮時安全約束可能被丟棄。其次是 prompt injection:有人故意在 Agent 會處理的內容中嵌入隱藏指令,讓 Agent 把內容當成用戶命令來執行。兩者的共同根源是:Agent 的行為邊界是用自然語言定義的,而自然語言是模糊的、可被操縱的、可被有損壓縮的。
一個例子是 Meta 超級智能實驗室對齊主管 Summer Yu 要求 Agent「建議一些可以刪除的郵件」,但 Agent 直接刪除了數百封郵件(上下文視窗溢出後觸發壓縮,「建議」這個關鍵約束被丟掉)。
在這種情況下,我們需要的不是更好的 prompt engineering 而是結構性的安全機制:可審計的操作日誌、可編程的權限邊界、以及在出錯時可以追責和補償的經濟系統。這些東西恰好是智能合約和鏈上基礎設施擅長的。
第四層:記憶系統——持久性與可遷移性問題
OpenClaw 實現兩類記憶:每日工作記憶(YYYY-MM-DD.md 檔案)和長期精華記憶(MEMORY.md,去重歸類提煉的關鍵偏好)。檢索時用向量檢索 + BM25 混合模式。
會話預設每天凌晨 4 點重置。上下文視窗不斷被壓縮和摘要。當上下文逼近 token 上限時,OpenClaw 的做法是觸發會話壓縮,用 LLM 把之前的對話摘要成更短的版本。在壓縮前先執行一次 Memory Flush,給 Agent 一次機會把關鍵資訊寫入持久記憶。這本質上是在賭 Agent 自己知道什麼資訊是關鍵的。一個非確定的系統來判斷什麼是關鍵資訊,這本身就是不確定的。
OpenClaw 所有記憶存在本地檔案系統,換電腦就沒了;與其他 Agent 協作時沒有共享記憶機制;Agent 的知識和經驗被鎖死在運行的那台機器上。Sub-Agent 協作僅限於同一個 OpenClaw 實例內部,一旦涉及跨實例、跨組織的 Agent 協作,系統無能為力。GitHub 上開發者的回饋:決策記錄在聊天歷史中但沒有持久化 artifact,交接模糊,知識傳遞不完整。
5.3 Agent 經濟結構性問題
上下文不流動:所有問題的根源
- 空間鎖定:Agent 的記憶和知識存在運行它的那台機器上,換台電腦就沒了
- 信任隔離:Agent A 聲稱「用戶上週說了偏好 X」,Agent B 沒有任何方式驗證真偽
- 無法發現:想找一個「擅長 DeFi 分析」的 Agent?沒有標準化的發現機制
- 價值未定價:Agent 積累的領域知識和用戶偏好顯然有經濟價值,但目前沒有定價或交易的方式
- 預設臨時:上下文隨時可能被壓縮、摘要,或在會話重置時丟失
要讓上下文真正流通,它需要同時具備五種屬性:能跨信任邊界、有經濟屬性、無需 gatekeeper 可被發現、保留決策痕跡、適應消費者需求。目前沒有任何單一協議能同時提供這五種屬性。MCP 解決「AI 模型怎麼調用工具」。A2A 解決「Agent 怎麼和 Agent 通話」。x402 解決「Agent 怎麼付錢」。但「Agent 怎麼在不可信環境中自主發現、評估和使用上下文數據」還沒有答案。
協調悖論
Agent 只需要足夠的上下文就能推理。但跨組織協調需要所有的歷史上下文。
一個 Agent 在想「該不該訂這趟航班」,當前會話的精簡資訊就夠了。但當它需要和供應鏈 Agent、財務 Agent、日曆 Agent 協調(可能在不同平台上、由不同組織運營)時:它們共享哪些上下文?怎麼驗證?所有權歸誰?
Gartner 預測到 2027 年超過 40% 的 Agentic AI 項目將因成本不斷攀升、商業價值不明或風險控制不足而被取消。但 70% 的開發者反映,核心問題是與現有系統存在整合問題。根本原因是,Agent 是非確定性的執行者,企業要確定性結果。一個不確定的執行者在不確定環境中和不確定的合作者協作,沒有可驗證的信任層,這個組合不可能產生可靠輸出。
目前跨平台 Agent 協作的需求還非常小。用戶只是想要一個能幫他們幹活的 AI,不在乎它能不能和別的 Agent 協作。協調悖論是一個真實的技術問題,但它是否會演變成一個大規模的商業問題,取決於 Agent 的使用方式是否從個人工具進化到多 Agent 協作網路。
把上面的分析組合起來,就得到一個架構概念:
底層是Agent進行推理的地方,短暫的、token-bound的。OpenClaw、Claude Code、Cursor 都在這裡。需要快速響應,專注當前任務。
上層是協調發生的場所:持久的、可驗證的、有經濟定價的。跨組織知識在此積累,溯源鏈在此維護,信譽在此運作。
兩層有不同的需求:Agent需要簡潔性,而組織需要歷史記錄。Agent需要速度,而審計追蹤需要永久性。Agent以機率方式運行,而企業需要確定性的結果。當前大多數架構試圖合併兩層,不可能成功。
那是否可以添加一個模組化的附加元件,無需許可即可橫向部署,適用於所有代理系統——具有可信的中立性、持久性和可驗證性?這個元件提供上下層之間的受控介面, 允許context在需要時向下流動,並允許做出承諾時向上流動。執行前,從去中心化知識圖譜解析並注入相關上下文子圖;執行後,將操作作為可驗證交易提交到鏈上,附帶溯源(provenance) 和聲譽更新。這一層的核心假設也是上下文流動性有價值: 如果大多數Agent用戶不需要跨平台協作(比如一個人只用一個OpenClaw處理一切),那中間層就沒有真實需求。
中間層如果只做上下文可攜帶性,大概率失敗。但如果聚焦多方互不信任場景下經濟活動的可驗證性和聲譽的可遷移性這些有明確經濟激勵驅動的用例,成功機率高得多。IronClaw也是朝抽象中間層方向走的一種嘗試——把執行環境和憑證管理分離到可驗證的安全層中。但它仍然是Near生態內部的方案,缺乏跨平台的通用性。
Crypto 的真實切入點
大部分 Agent 經濟的需求其實都能用 Web2 方案解決。Crypto 在 Agent 經濟中的不可替代性只存在於一個場景:當你需要跨組織、跨平台、無需許可的互操作性,且參與方之間沒有預先建立的信任關係時。比如:Agent A(運行在 OpenClaw 上,owner 是用戶甲)需要僱傭 Agent B(運行在 Claude Code 上,owner 是用戶乙)完成一個任務。它們之間沒有共同的平台、沒有共同的帳號體系、沒有預先的商業關係。在這個場景下,鏈上身份(8004)、鏈上支付(x402)、鏈上聲譽確實比任何中心化方案更合適——因為沒有一個中心化平台能同時覆蓋所有 Agent 框架。
並且,Agent 能付錢了不代表它該付錢。F500 公司因為 Agent 在 retry loop 裡重複付費損失了 4 億美元。在 Agent 能自主支付之後,最有價值的是幫 Agent 判斷該不該付這筆錢的決策基礎設施。
目前 Crypto 對 Agent 經濟是「nice to have」,除非 Agent 間的跨平台經濟互動達到足夠的規模,但當足夠多的 Agent 不再綁定到某個特定人類的銀行帳戶時(Agent 本身變成了獨立的經濟實體而非人類工具),傳統金融軌道就覆蓋不了它們了,此時穩定幣是它們大規模資金交易的最佳(甚至可以說是唯一的)方式。變成 must have 可能的三個觸發條件:
- Agent 開始大規模僱傭其他 Agent:比如企業 IT 環境中不同供應商的 Agent 系統需要互操作(類似今天的企業 API 整合,但更複雜)
- Agent 開始 24/7 跨國交易:一個 Agent 編排的工作流可能同時調用美國的 LLM 端點、歐洲的數據提供商、東南亞的算力叢集,不應該需要三套不同的支付軌道。穩定幣是全球性的、7×24 小時的。這個優勢在 Agent 的 always-on、跨時區場景中對比人類更突出。
- 微支付達到傳統軌道無法承受的頻率:目前 Agent 在鏈上做的微交易(API 調用、數據查詢、計算資源)平均每筆只有 $0.09,而 Stripe 光手續費就 $0.35+2.5%,比交易本身貴 4 倍;當一個 Agent 需要調用幾萬次 API,傳統支付處理商無法承保這類商戶風險並且費用結構會成為真正瓶頸。
安全威脅與鏈上基礎設施的必要性
「Siri 悖論」是理解整個 Agent 賽道的關鍵框架:Siri 安全是因為它被閹割了,OpenClaw 有用是因為它危險。要讓 AI 真正做事(處理郵件、預訂航班、部署程式碼),它必須擁有廣泛的系統權限。廣泛的權限天然意味著更大的攻擊面。
OpenClaw上最著名的正面案例是:用戶讓Agent訂餐廳,但OpenTable沒空位,Agent沒有放棄,而是自己找到AI語音軟體,下載安裝,打電話給餐廳成功預訂。這種自主解決問題的能力是人們夢寐以求的。但同樣的自主性也意味著如果判斷出錯,後果以機器速度擴散。
有人把 Steinberger 加入 OpenAI 稱為「AI Agent 的 iPhone 時刻」。但在那之前,必須有一個安全基礎設施就緒的階段。否則大規模使用就是大規模損失。Chopping Block 預測的「AI-generated $100M+ hacks」如果真的發生,有兩種走向:要麼公眾恐慌導致 Agent 採用倒退(類似 2016 年 DAO 事件後的以太坊低谷),要麼催生出真正的 Agent 安全基礎設施(類似 DAO 事件後智能合約審計行業的爆發)。我們傾向於後者。因為 Agent 的需求是真實的:
- 惡意 Agent 識別 >> 8004 聲譽系統。如果每個 Agent 有鏈上身份和公開聲譽記錄,惡意行為會留下不可篡改的記錄。其他 Agent 在信任之前可以查鏈上聲譽。當然需要聲譽系統足夠成熟——不是簡單評分,而是多維度、時間加權、有反刷榜機制的信任模型。
- 惡意 Skills 審核 >> Validation Registry。如果 Skills 的程式碼審計結果記錄在 8004 的 Validation Registry 中——由獨立驗證者(staked 服務、zkML 驗證者、TEE 預言機)審核——typosquatting 的效果大幅降低。安裝 Skill 前查鏈上驗證狀態就行。
- 憑證洩露 >> x402 的「付款即授權」。x402 消除了 API Key 管理問題。Agent 不需要儲存長期憑證——每次需要服務時直接付款獲取臨時存取權。結合 EIP-712 簽名綁定(把服務使用權和付款地址綁定),即使 token 洩露也無法被他人使用。
- 行為失控 >> 鏈上審計日誌 + 可編程權限。無論是外部攻擊者注入指令(prompt injection),還是系統自己在壓縮時丟掉約束(context loss),結果都是 Agent 執行了超出預期的操作。智能合約可以定義 Agent 的行為邊界——比如「單筆交易不超過 X 金額」、「刪除操作需要多簽確認」。鏈上操作日誌不可篡改,出問題可以追溯。這比在 prompt 裡加「請先徵求同意」可靠得多,因為 prompt 級別的約束會被壓縮丟掉,但智能合約級別的約束不會。
當然,鏈上基礎設施只能緩解安全問題的後果,不能預防。智能合約可以限制「單筆不超過 X 金額」,但 Agent 被 injection 後在限額內持續做壞事呢?每筆 $0.09 的惡意交易做一萬次也是 $900。安全的真正解決需要在 Agent runtime 層(TEE/沙箱)和鏈上層(權限/審計)雙管齊下。只做鏈上一層是不夠


