AI 代理會用銀行卡嗎?Agentic Payment 為什麼繞不開穩定幣和區塊鏈

作者:Yokiiiya

上週在香港參加 Web3 Festival,一個很明顯的感受是:現在幾乎每一個論壇、每一場 panel,都繞不開 AI。

不管原本聊的是支付、穩定幣、RWA、錢包、交易所,還是合規和基礎設施,最後幾乎都會回到同一個問題:當 AI 不再只是生成內容,而是開始替人執行任務、調用服務、做決策、甚至處理資金流時,現有的金融和支付系統還夠用嗎?

在我參加的一個 panel 裡,也有人直接抛出了一個問題:Web3 是不是在蹭 AI?我覺得並不是。當然,蹭熱點的項目一定會有。但如果只把 AI × Web3 理解成敘事拼貼,可能也會錯過一個更底層的變化:AI 負責理解、決策和行動,Web3 提供資產、帳戶、結算和可驗證執行環境。兩者不是簡單疊加概念,而是在重新分工。

香港財政司司長陳茂波在 Web3 Festival 2026 的演講裡也提到,AI agent 未來會以機器速度分析資訊並採取行動,同時在後台充分利用 blockchain 基礎設施,從而提高交易效率,並重塑金融、貿易、財富管理、供應鏈和物流等場景。當 AI 開始行動,問題就不只是“智能”本身,而是這些行動如何被授權、如何被結算、如何被記錄、如何被追責。

其中,Agentic Payment 是一個越來越難被忽略的話題。但我一開始也有一個很樸素的疑問:為什麼大家一聊 Agentic Payment,或者 Agentic Commerce,就好像默認它一定會和 Crypto、Stablecoin、Blockchain 绑在一起?

AI Agent 不能用銀行卡嗎?不能用信用卡嗎?不能用 Apple Pay、Visa、Mastercard、Stripe、PayPal 嗎?

如果 Agent 只是幫我買一張機票、訂一家酒店、續費一個 SaaS,理論上它完全可以調用現有支付體系。用戶授權一次,Agent 在額度和規則內執行付款,背後走銀行卡、虛擬卡、企業帳戶或者第三方支付錢包,聽起來並沒有什麼不合理。

所以問題不是“銀行卡能不能用”。當然能用。真正的問題是:銀行卡和信用卡到底適合解決 Agentic Payment 的哪一部分,又解決不了哪一部分?AI Agent 到底會不會用銀行卡?以及為什麼 Agentic Payment 發展到一定階段,幾乎一定繞不開穩定幣和區塊鏈。


一、銀行卡解決的是 checkout,不是 Agent Economy

如果 Agentic Payment 只是讓 AI Agent 幫人完成最後一步付款,比如買一張機票、訂一家酒店、續費一個 SaaS,背後走銀行卡、信用卡、虛擬卡、Apple Pay、Stripe、PayPal,都沒有什麼本質障礙。銀行卡當然可以用,信用卡當然也可以用。

用戶提前授權,Agent 在額度和規則內執行付款。這件事並不難理解,本質上有點像更聰明的自動扣款、企業虛擬卡、差旅卡或者自動化採購系統。

所以,Visa、Mastercard、Stripe 這些傳統支付玩家不會消失。它們甚至會成為早期 Agentic Commerce 的重要入口。

Stripe 和 Tempo 推出的 Machine Payments Protocol 就很能說明這一點。它不是單押穩定幣,而是讓商戶可以直接接受來自 agents 的付款,既支持 stablecoins,也支持 cards、BNPL 等 fiat payment methods。也就是說,在 agent payment 的早期階段,傳統支付和穩定幣更可能是共存關係,而不是誰立刻取代誰。但這只解決了 Agentic Commerce 裡的一部分:checkout

Checkout 的前提是,商品、商戶、訂單、支付按鈕、退款和爭議處理流程都已經存在。Agent 只是站在用戶旁邊,幫用戶更自動化地完成一次購買。

真正的問題發生在另一類場景裡:Agent 不再只是進入一個已經搭好的購物車,而是在開放網絡裡連續調用資源、組合服務、完成任務。

比如,一個 AI research agent 為了完成一份行業報告,可能要調用多個資料庫、購買幾份付費資料、訪問不同模型 API、調用一次爬蟲服務、支付圖表生成工具,甚至向另一個 Agent 購買一段分析結果。這裡面可能沒有一個傳統意義上的“商店”。也未必有一個完整的 checkout 頁面。它面對的可能是 API、資料接口、模型服務、算力節點、內容資源、自動化工具,甚至是另一個 Agent。

我自己最近也遇到過一個很具體的例子。我想做一個流量分析助手,讓它可以在需要的時候自動去調用類似 Semrush 這樣的資料源,幫我分析一個網站的流量、關鍵詞、競品和市場趨勢。但真正開始整理方案時,我發現問題不是“AI 能不能分析”,而是“它怎麼拿到資料”。很多商業資料源並不是按照“單次調用、單次付費、即時返回”的方式設計的。以 Semrush 為例,它的 API 體系更接近帳號、套餐和 API units 模式。每次 API request 會消耗一定數量的 API units,使用者需要有對應的 API access 或購買 API unit package;Trends API 雖然可以單獨購買 access,也仍然是基於 API units 請求資料。

但對於 Agent 來說,這個模式就不夠自然。如果一個 Agent 只是偶爾需要調用一次流量資料,它真正需要的可能不是註冊一個 SaaS 帳號,也不是購買一整包 API units,而是像訪問網頁一樣發起一次請求:這個資料多少錢?我是否被授權購買?如果在預算範圍內,就付款,然後馬上拿到結果。

這就是 Agentic Payment 和傳統 API 商業模式之間的斷層。今天大量 API 的收費方式,仍然是為“人類公司採購軟體”設計的,而不是為“機器按需購買資源”設計的。

所以,Agentic Payment 的問題不是最後一步能不能扣款,而是整個任務鏈條裡,機器如何持續獲得授權、發起付款、驗證交付、完成結算。

這裡才是銀行卡體系的邊界。

不是因為銀行卡落後,而是因為它原本服務的是人類消費場景:一個人進入商戶環境,選擇商品,確認訂單,完成支付,後面再由銀行、卡組織、收單機構和支付服務商完成授權、清算、風控和爭議處理。

但 Agent Economy 面對的是另一組問題:這個 Agent 憑什麼有權花這筆錢?服務方如何確認這不是惡意 bot,而是用戶真實意圖的延伸?Agent 能不能在沒有人工確認每一步的情況下,完成小額、高頻、跨平台付款?服務方收到付款後,能不能立刻釋放對應資源?如果 Agent 買錯了、越權了、被攻擊了,責任應該落在誰身上?

這也是為什麼 Google 做 AP2 時,沒有把重點放在“用哪種支付方式”上,而是放在一套更通用的 agent payment 信任框架上。Google 官方介紹裡,AP2 被定義為一個 payment-agnostic framework,讓用戶、商戶和支付服務商可以在不同支付方式之間更有信心地完成 agent-led payments。AP2 規範也明確提出,Agent 需要一種安全、簡單的方式獲得 scoped permissions,代表用戶執行動作;協議的安全性依賴用戶和商戶對相關資訊進行 cryptographic signing。

所以,Agentic Payment 的第一層問題,並不是:錢從哪裡扣? 而是:Agent 憑什麼有權花這筆錢?

這個問題,銀行卡體系可以解決一部分。比如虛擬卡、tokenized credentials、額度管理、企業費用控制、風控規則,都能讓 Agent 在現有商戶體系裡完成交易。

Visa 也在沿著這個方向推進。它的 Intelligent Commerce 和 Trusted Agent Protocol,本質上就是讓 AI Agent 能在現有商戶網絡裡被識別、被信任、被允許代表消費者或企業完成交易。Visa Developer 對 Trusted Agent Protocol 的描述也很直接:AI agents 會幫助用戶瀏覽商戶網站、發現產品、比較價格和做選擇,而商業旅程早在 checkout 之前就已經開始;過去這些自動化訪問經常會被商戶、CDN 或 bot mitigation 服務當成 bot 拦截。

這說明傳統支付網絡也看到了同一個問題:Agentic Commerce 不是只發生在付款按鈕那一刻,而是從搜尋、比較、選擇、授權,到最終支付的整條鏈路。但卡網更擅長解決的是:Agent 如何進入現有的 commerce flow,並完成一筆被授權的交易。它不天然解決的是:Agent 如何在開放網絡裡,為 API、資料、模型、算力、內容、工具和另一個 Agent 持續發起小額支付。

所以,銀行卡不是不行。更準確地說:銀行卡解決的是 Agentic Commerce 的 checkout 問題,但 Agent Economy 需要的是一套更底層的支付協議。

這就把問題推到了下一層:如果交易對象不是一個傳統商戶,而是一個 API、一個模型、一個資料接口,甚至另一個 Agent,機器之間應該如何發起和完成一筆支付?這也是 x402、L402、T402 這些協議開始被討論的原因。


二、Agent 真正需要的,是機器可讀的支付協議

如果交易對象是傳統商戶,Agent 當然可以進入現有 checkout 流,用信用卡、借記卡、虛擬卡或者錢包完成支付。但如果交易對象不是一個商戶,而是一個 API、一個模型、一個資料接口、一道內容資源,甚至另一個 Agent,問題就變了。

這時候,機器之間需要的不是一個“付款按鈕”,而是一套機器可以理解的支付流程:Agent 請求一個資源。服務方告訴它:這個資源需要付款,價格是多少,收款地址是什麼,支持什麼支付方式。Agent 判斷這筆付款是否在用戶授權範圍內。如果符合規則,就完成支付。服務方驗證付款後,立即釋放資源。

這個流程聽起來很簡單,但它其實是在補充互聯網過去一直缺失的一層能力:原生支付層。過去,互聯網天生支持資訊流動。網頁可以被請求,郵件可以被發送,API 可以被調用,檔案可以被下載。但“付款”通常不是互聯網協議本身的一部分,而是被掛在另一個系統裡:註冊帳號、綁定銀行卡、接入支付閘道、購買套餐、管理 API key、月底對帳。

這對於人類來說可以忍受。人可以註冊、登入、綁卡、審批、採購、報銷。但對於 Agent 來說,這個流程太重了。

Agent 不應該每調用一次 API 都註冊一個帳號,不應該每訪問一次資料都買一整包 API units,也不應該為了幾美分、幾毛錢的小額調用,走一套完整的人類支付和採購流程。這就是 x402 這類協議出現的原因。

x402 重新激活了 HTTP 402 Payment Required 這個長期存在但很少被真正使用的狀態碼。它讓服務方可以在 HTTP 層直接告訴客戶端:你要訪問這個資源,需要先付款。客戶端可以是人,也可以是機器。付款完成後,服務方驗證支付,再返回對應的 API、內容或者數字服務。Coinbase 對 x402 的定義很直接:它是一個通過 HTTP 實現即時、自动穩定幣支付的開放協議,讓 human and machine clients 可以在不需要帳號、session 或複雜認證的情況下,程式化支付並獲得存取權。

這裡真正重要的不是“用不用 Coinbase”,也不是“是不是一定用 USDC”。真正重要的是,x402 把付款嵌回了互聯網的請求-回應流程裡。

過去是:

  • 先註冊帳號。

  • 再買套餐。

  • 再拿 API key。

  • 再調用服務。

  • 月底再對帳。

x402 想變成:

  • 請求資源。

  • 收到 402 Payment Required。

  • 完成付款。

  • 獲得資源。

這對 Agentic Payment 很關鍵。因為 Agent 的交易不是少數幾次大額購買,而可能是大量小額、即時、按需的服務調用。

  • 一個寫作 Agent 可能為一篇文章購買一次資料查詢。

  • 一個投研 Agent 可能為一個問題調用一次鏈上分析服務。

  • 一個旅行 Agent 可能同時向多個價格 API 詢價。

  • 一個開發 Agent 可能按次購買模型推理、程式碼審查或者測試環境。

  • 一個流量分析 Agent 可能只想為某一個網站買一次 Semrush 類資料,而不是先買一整套 SaaS 套餐。

如果每一個服務都要求帳號、訂閱、API key、套餐和人工審批,Agent 的執行能力會被卡在支付和採購流程上。所以,x402 的意義不是讓支付變得“更 crypto”,而是讓支付變得更像互聯網協議:可請求、可返回、可驗證、可自動執行。

L402 是另一條類似的路線。

它同樣圍繞 HTTP 402 展開,但結合的是 Bitcoin Lightning Network、macaroons 這類存取憑證和小額支付。Lightning Labs 對 L402 的定義是:它用於促進 API endpoint、計算資源等服務的認證和交易,並且讓服務可以向 API endpoint 收費,讓 AI agents 更容易參與其中。

L402 說明,這個問題並不是 x402 才突然發明出來的。更早就有人在嘗試把三件事揉在一起:HTTP 存取控制、小額支付、數字服務權限。只是過去缺少一個足夠強的需求方。

人類用戶不會為存取一個 API endpoint 付幾分錢。但 Agent 會。人類不會在一天裡自動調用幾百個資料源。但 Agent 會。人類不會為完成一個任務,在不同服務之間實時組合調用、詢價、付款、驗證交付。但 Agent 會。

所以,AI Agent 的出現,讓 HTTP-native payment 這條路線突然變得有意義了。

圍繞 USDT / Tether 生態,也開始出現類似方向。Tether WDK 的 x402 文件明確寫到,x402 對 AI agents 很重要,因為 agents 需要程式化地為資源付款;x402 讓付款成為 web stack 的一等公民,使 agent 可以在一次 request-response cycle 裡發現價格、簽署付款並獲得資源。同時,t402 項目也把自己描述為 internet native payments 的開放標準,目標是支持 crypto、fiat、stablecoins、tokens 等多種價值形式,並且和 Tether WDK 兼容。這裡需要謹慎一點:我不建議直接說它已經成為 Tether 官方標準,更穩妥的說法是,圍繞 USDT / Tether 生態,正在出現類似 x402 的協議探索。

這背後其實是一個值得關注的趨勢:Agentic Payment 不是單一公司的產品競爭,而是在形成一套新的協議棧。

  • AP2 更像是在回答:Agent 憑什麼被授權付款?

  • x402、L402、T402 這類協議更像是在回答:當 Agent 請求一個數字資源時,服務方如何發起付款要求,Agent 又如何完成付款並拿到資源?

  • 穩定幣和區塊鏈則更像是在回答:這筆錢最終用什麼資產結算,在哪裡驗證,如何做到低成本、即時、可程式化和跨平台?

所以,Agentic Payment 和 Crypto 被放在一起討論,不是因為 Web3 想硬蹭 AI。更準確地說,是因為 Agentic Payment 把互聯網過去沒有解決好的“支付原生性”問題重新翻了出來。

資訊可以原生地在互聯網上流動。但價值長期不能。Agent 的出現,正在倒逼互聯網補上這一層。

這也是為什麼 x402、L402、T402 這些協議值得關注。它們並不是簡單說“讓 AI 用加密貨幣付款”,而是在嘗試定義一種新的交互方式:機器請求資源,機器理解價格,機器驗證授權,機器完成支付,機器獲得服務。

如果說銀行卡解決的是 checkout,那麼這些協議解決的是:機器之間如何發起一筆支付。而一旦進入這個問題,穩定幣和區塊鏈就不再只是支付工具,而會變成 Agentic Payment 的底層結算語言和執行環境。


三、為什麼是穩定幣:Agent 需要穩定的計價單位,而不是波動資產

如果 Agent 真的需要一種機器可讀、可以自動執行的支付協議,那為什麼大家討論最多的是 stablecoin?為什麼不是 BTC?為什麼不是 ETH?為什麼不是普通銀行卡?

這裡的關鍵,不在於“crypto asset”本身,而在於 Agent 到底需要一種什麼樣的支付資產。如果一個 Agent 只是長期持有資產,那它可能會關心漲跌、收益、風險敞口。但如果一個 Agent 是為了完成任務而付款,它最需要的不是投機資產,而是一個穩定的計價單位。

一個 research agent 調用一次資料 API,可能是 0.1 美元。一個 coding agent 調用一次模型推理,可能是 0.03 美元。一個 marketing agent 購買一次流量資料,可能是 1 美元。一個 procurement agent 自動比價、下單、支付,可能需要在預算範圍內控制每一筆支出。

在這些場景裡,Agent 不是在做交易,也不是在炒幣。它是在完成任務。所以,它需要知道:這個資源到底多少錢?這次調用會不會超過預算?這筆付款是不是在用戶授權範圍內?服務交付之後,成本能不能被準確記錄?

如果支付資產本身每天劇烈波動,Agent 的預算管理就會變得很奇怪。今天一個 API 調用值 0.1 美元,明天因為幣價波動變成 0.12 美元或者 0.08 美元,這對於交易市場可能沒什麼,但對於機器按需購買資源來說,會增加很多不必要的複雜度。

這就是為什麼 Agentic Payment 裡更自然出現的是穩定幣,而不是高波動的 crypto asset。

穩定幣的第一層價值,是提供一個更接近現實商業世界的計價單位。今天大量 API、SaaS、資料服務、模型服務、雲服務,本來就是以美元計價的。Agent 如果要按需購買這些服務,用美元穩定幣作為支付資產,就可以直接把預算、價格、授權和帳單放在同一個單位裡。

這件事聽起來很普通,但對 Agent 很重要。因為 Agent 不只是“付錢”,它還要做判斷。它要判斷這次調用值不值得。它要判斷預算夠不夠。它要判斷是否需要回到用戶確認。它要記錄任務成本。它還要在出錯時解釋:為什麼花了這筆錢。

所以,Agentic Payment 需要的是一種低波動、機器可讀、可以被程式直接調用的支付資產。穩定幣剛好比 BTC、ETH 這類波動資產更接近這個需求。

第二層價值,是穩定幣更適合小額、高頻、即時結算。前面講 x402 時,其實已經能看到這個趨勢。Coinbase 對 x402 的定義就是通過 HTTP 實現即時、自动的 stablecoin payments,讓 API、數字內容和服務可以向 human 和 machine clients 收款,而且不需要帳號、session 或複雜認證。這句話背後有一個很關鍵的變化:支付不再一定要發生在完整的 checkout 頁面裡,而可以發生在一次 API 請求裡。

Agent 請求一個資源。服務方返回 402 Payment Required。Agent 判斷價格和授權。Agent 支付穩定幣。服務方驗證後釋放資源。

這套流程天生適合小額、高頻、按需調用的場景。比如一次資料查詢、一次模型調用、一次內容解鎖、一次鏈上分析、一次圖表生成。Tether WDK 的 x402 文件也把這個點說得很直白:AI agents 需要以程式化方式為資源付款,而 x402 讓 agent 可以在一次 request-response cycle 裡發現價格、簽署付款並獲得資源。

這和銀行卡不是一個使用語境。銀行卡更適合人類消費裡的 merchant checkout。穩定幣更適合作為機器調用資源時的即時結算資產。當然,這不代表銀行卡會消失。Stripe 和 Tempo 的 Machine Payments Protocol 就明確支持兩條路徑:一條是 direct on-chain crypto payments,另一條是 cards、wallets 等 fiat payments。Stripe 官方也提到,商戶可以通過 MPP 接受來自 agents 的付款,既可以用 stablecoins,也可以用 cards 和 BNPL 等 fiat payment methods。

所以更準確的判斷不是“穩定幣取代銀行卡”,而是:銀行卡適合已經存在的商戶網絡和 checkout 場景。穩定幣更適合開放網絡裡的機器按需支付場景。

第三層價值,是穩定幣天生更適合跨平台和跨境。Agent 不一定只在一個平台裡工作。一個 Agent 可能調用美國的資料 API、歐洲的模型服務、亞洲的內容接口、鏈上的分析工具,再和另一個 Agent 發生交易。如果每一層都依賴不同國家的銀行帳戶、收單機構、本地支付方式和結算週期,整個任務鏈會被支付系統切碎。但穩定幣是互聯網原生資產。它可以 7×24 小時流轉,可以跨平台、跨錢包、跨應用調用,也可以被智能合約或支付協議直接處理。這對於人類用戶來說可能只是“更快到賬”。但對於 Agent 來說,意義更大。因為 Agent 的執行不是按照銀行營業時間發生的。

它不應該因為週末、跨境、銀行清算窗口、商戶帳戶體系而中斷任務。它需要的是一種隨時可用、可自動調用、可被驗證的結算資產。

這也是為什麼 x402、Tether WDK 對 x402 的支持,以及圍繞 USDT / Tether 出現的 t402 探索,都在朝同一個方向:把穩定幣支付變成機器可以直接調用的 web stack 元件,而不是讓 Agent 先進入一個人類設計的支付頁面。

但這裡也需要潑一盆冷水。穩定幣不是沒有問題。

不同穩定幣的儲備透明度、發行主體、監管狀態、贖回能力、鏈上流動性都不一樣。BIS 在 2025 年《年度經濟報告》裡也明確批評過穩定幣,認為它們在 singleness、elasticity、integrity 這些貨幣體系關鍵標準上存在不足,不應該被簡單視為現代貨幣體系的完整替代品。

更準確的說法是:穩定幣不是完美貨幣,但它是目前最接近 Agentic Payment 需求的互聯網原生結算資產之一。

它的價值不在於“去中心化敘事”,而在於它同時滿足了幾個條件:價格相對穩定。可以被程式調用。可以跨平台流轉。可以 7×24 小時結算。可以和 HTTP-native payment、錢包、智能合約、鏈上審計結合。

這就是為什麼 Agentic Payment 一討論到開放網絡裡的資源調用,穩定幣就會自然出現。因為 Agent 需要的不是一張“會刷卡的手”,而是一種可以被軟體直接理解和使用的錢。

如果說信用卡是為人類消費設計的支付憑證,那麼穩定幣更像是為機器經濟準備的結算語言。

當然,這個語言還不成熟。它需要更好的合規框架、更穩定的發行機制、更清晰的風控、更完善的錢包權限管理,也需要和 AP2、x402、MPP 這類協議結合,才能真正進入大規模使用的 Agentic Payment 場景。

但方向已經很清楚:Agent 需要穩定的價格單位,需要即時的結算資產,需要可以被程式調用的錢,還有跨平台、跨國界、跨服務的支付能力。

這就是穩定幣在 Agentic Payment 裡不可忽視的原因。不是因為所有支付都要變成 crypto payment。而是因為當交易對象從“人類消費者”變成“軟體主體”,穩定幣第一次讓“錢”變得更像互聯網協議的一部分。

但穩定幣只回答了一個問題:Agent 用什麼錢付款。它還沒有回答另一個問題:當 Agent 在開放網絡裡花錢之後,這筆錢是誰授權的、花在哪裡、是否越權、服務是否交付。這個問題,就會把我們帶到 blockchain。


四、為什麼需要區塊鏈:不是為了上鏈,而是為了讓 Agent 的行為可驗證

就算 Agent 需要穩定幣付款,為什麼一定要 blockchain?不能是中心化帳本嗎?不能是 Stripe、Visa、銀行,或者某個平台自己記帳嗎?

當然可以。如果這個 Agent 只在一個封閉平台裡活動,比如只在 Amazon 里購物,只在某個 SaaS 裡調用服務,只在一個企業內部系統裡做採購,那中心化帳本完全夠用。平台自己知道用戶是誰,Agent 是誰,權限是什麼,花了多少錢,服務有沒有交付。

但 Agentic Payment 真正有意思的地方,恰恰不是 Agent 在一個封閉平台裡幫你點付款按鈕,而是它可能會跨平台、跨服務、跨錢包、跨國家,甚至跨不同 Agent 去完成一個任務。到了這個階段,問題就不只是“錢能不能付出去”,而是這筆錢為什麼付出去、是誰授權的、Agent 有沒有越權、服務方有沒有交付、如果出錯了責任應該落在哪裡。

這幾個問題,才是區塊鏈在 Agentic Payment 裡真正有價值的地方。不是因為所有交易都必須上鏈,也不是因為鏈上一定比銀行高級,而是因為當 Agent 開始替人執行任務、調用服務、處理資金流時,它的每一個經濟動作都需要留下可以被驗證的記錄。

人類付款的時候,其實可以忍受很多不透明。買了個服務沒收到,可以找客服;公司採購出了問題,可以翻合同、找財務、查郵件、開會扯皮;銀行卡扣錯了,可以找銀行走爭議處理。這些機制很笨,但人類社會長期就是這樣運行的。

Agent 不一樣。Agent 的交易頻率可能更高,金額可能更小,服務方可能更多,執行鏈條也更長。如果每一筆都要靠人工事後查帳、截圖、對郵件、找客服,那 Agentic Payment 就失去了意義。所以,Agent 需要的不是一個更酷的錢包,而是一條更清楚的責任鏈。

比如,用戶給 Agent 一個任務:這周最多花 100 美元,幫我做一份市場分析,只能購買資料、模型調用和圖表生成服務。然後 Agent 去請求一個資料 API,服務方返回這次查詢 0.2 美元。Agent 判斷這筆錢在預算內,於是完成付款,服務方收到錢後釋放資料。這個過程裡,真正重要的不是“用了哪條鏈”,而是事後我們能不能回答幾個問題:用戶當時給過什麼授權,Agent 買的是什麼,這筆錢有沒有超過預算,服務方有沒有真的返回資料,如果後面發現 Agent 被 prompt injection 誘導買了不該買的東西,能不能追溯。

這也是為什麼我覺得,討論 Agentic Payment 時重新看 Bitcoin 白皮書,其實不是為了懷舊。Satoshi Nakamoto 當年要解決的核心問題,不是“發明一種可以交易的資產”,而是如何在沒有可信第三方的情況下,讓一筆電子現金的轉移被網絡驗證、排序和記錄。白皮書裡寫得很清楚:網絡會把交易透過哈希寫進一條持續增長的 proof-of-work 鏈,形成一份如果不重做工作量就無法更改的記錄。

Agentic Payment 面對的問題不完全一樣。它不只是 double-spending,而是 Agent 的授權、越權、交付和責任。但它們有一個共同點:一旦經濟行為發生在開放網絡裡,可驗證的交易記錄就不再是附屬品,而是基礎設施本身。

這就是區塊鏈的意義。它不是讓支付變得玄學,而是讓一部分原本藏在平台資料庫裡的狀態,變成可以被外部驗證的狀態。至少在理想情況下,付款記錄、授權憑證、服務存取、退款條件、預算消耗,都可以被更標準化地記錄和驗證。對人類用戶來說,這可能只是“帳更清楚”;但對 Agent 來說,這可能是它能不能被信任的基礎。

因為 Agent 不是人。它不能靠“我記得我當時是這麼想的”來解釋行為。它需要一套外部可驗證的證據鏈。

這也是為什麼 AP2、x402、穩定幣和 blockchain 經常會被放在同一張圖裡討論,但它們其實不是一回事。AP2 本身不是去中心化協議,也不是區塊鏈協議。Google 對 AP2 的定位,是一個 payment-agnostic 的開放框架,讓用戶、商戶和支付服務商可以在不同支付方式之間,更有信心地完成 agent-led payments;AP2 規範也明確提出,Agent 需要一種安全、簡單的方式獲得 scoped permissions,代表用戶執行動作;協議的安全性依賴用戶和商戶對相關資訊進行 cryptographic signing。

所以更準確地說,Agentic Payment 的第一層問題,並不是:錢從哪裡扣? 而是:Agent 憑什麼有權花這筆錢?

這個問題,銀行卡體系可以解決一部分。比如虛擬卡、tokenized credentials、額度管理、企業費用控制、風控規則,都能讓 Agent 在現有商戶體系裡完成交易。

Visa 也在沿著這個方向推進。它的 Intelligent Commerce 和 Trusted Agent Protocol,本質上就是讓 AI Agent 能在現有商戶

查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 打賞
  • 回覆
  • 轉發
  • 分享
回覆
請輸入回覆內容
請輸入回覆內容
暫無回覆