原始來源：Waterdrop Capital

摘要

大型模型正從回答問題的工具，演進為具備規劃、調用工具與交付結果能力的智能代理。與此同時，穩定幣結算、HTTP 原生支付協議（HTTP 402）與智慧錢包正逐步整合成專為機器設計的支付基礎設施。程式可在執行期間即時取得報價、簽署授權並完成微支付——這在數年前僅是概念，如今已成為可行技術路徑。

然而，「機器能付款」不等於「機器能完成交易」。當智能代理需採購搜尋、資料、運算力、內容生成或專業分析等服務時，仍面臨諸多挑戰：端點發現、報價比對、跨協議支付、預算管控、交付驗證與統一對帳。支付軌道解決價值如何流動，卻無法自動解決需求如何匹配供應，亦無法保證付款後確實獲得正確服務。

這意味著，在下一階段的「代理支付」中，競爭焦點可能不再僅限於協議吞吐量、結算速度或支援鏈數量，而更在於能否真正建構出「機器買方基礎設施」。本文試圖從需求結構、協議演進、現實瓶頸與市場分工四方面，探討為何代理支付將成為獨立賽道，並指出實現規模化採用前尚缺的關鍵環節。

引言：智能代理正獲得受限的「可支配預算」

過去兩年，智能代理能力快速演進。早期大型模型主要處理資訊生成——使用者提問，模型產出文字；隨後，工具調用功能使模型得以搜尋網頁、查詢資料庫、執行程式碼及操作軟體；更進一步，智能代理開始分解目標、擬定計畫，並根據外部結果在多輪執行中調整行動。

當執行目標限於免費工具或企業內部系統時，開發者可預先設定調用權限；但開放市場中的高品質能力通常需付費：即時財經資料按次計費、網路爬蟲消耗積分、推論與 GPU 運算依用量計費、影音生成與專業資料庫均有明確定價。智能代理若要自主完成任務，勢必於執行期間成為買方。

傳統 API 商業模式並非為此類買方設計：須由人先訪問網站、註冊帳號、綁定銀行卡、選擇方案、妥善保管 API Key，再將金鑰置入程式環境。購買決策與實際調用被分割於兩個時點：人類於任務發生前完成購買，軟體僅負責消耗已購配額。

代理往往直至任務執行某一步驟才知所需服務，無法預先判斷最終調用哪個資料源，也不應要求使用者逐一為所有潛在服務開立帳號。其採購特徵為即時、低金額、多商家、高頻率且以結果為導向。對它而言，最自然的體驗不是「先訂閱、再呼叫」，而是「發現服務→取得報價→授權付款→取得結果」。

因此，代理支付不僅是在聊天機器人中加一個付款按鈕，而是軟體開始擁有受控的支出權限，並形成屬於機器的採購流程。人類設定目標、預算與風險邊界，代理則於此範圍內分配資金。支付因而從結算動作，轉為代理決策系統的一環。

1. 為何代理支付將成為獨立賽道

1.1 從工具調用到經濟行為

代理與一般自動化指令碼的差異，不僅在推理能力。指令碼執行預定流程，所需資源與供應商通常已寫死於程式碼中；代理則依據環境動態選擇路徑。同一研究任務中，它可能先購買搜尋結果，再據結果決定是否需調用產業資料庫，最後另喚模型交叉驗證。每次採購步驟均影響後續決策。

這種「邊執行、邊採購」模式，將經濟選擇引入軟體執行期。代理不僅須判斷工具是否可用，更要評估是否值得購買：價格是否超預算、回應速度是否符合任務需求、歷史履約是否可靠、替代服務是否更適切。傳統工具路由聚焦能力匹配，而機器採購則須同步處理價格與交易對手風險。在此類交易中，承擔風險者正是代理自身：付款或可成功，服務卻未必交付。

因此，代理支付的核心需求並非無條件自動付款，而是可控地將採購權委託給軟體。使用者不會輕易將整個錢包交予代理，但願意為明確任務設定數美元預算，允許其進行數分錢級別的多次採購。大額授權或需長期建立信任，但小額授權已能創造真實價值。

1.2 微支付、高頻次與多商家重塑支付經濟模式

人類網際網路的支付基礎設施擅長處理相對低頻、高價值交易。信用卡網絡、支付閘道與訂閱系統皆具固定成本，因此商家常將大量請求打包為月度方案。針對單次僅數美分的API請求，傳統支付的手續費、退貨風險與帳戶維護成本，可能超過商品本身價值。

機器消費則恰好相反：一個代理可在數分鐘內向多家商家發起多次採購，以完成單一交付成果。每筆交易金額極低，但請求頻率極高，總交易量甚至遠超人類消費者。穩定幣與鏈上可程式化結算，為此類場景提供全新經濟基礎：資金可全天候流動、付款授權可由軟體簽署、服務可依每次呼叫直接定價。

更重要的是，多商家採購將改變API市場的競爭邏輯。訂閱模式鼓勵用戶長期綁定單一供應商；按次付費則讓代理能針對每項任務動態選擇服務。服務提供商不再僅爭奪年度合約，更需競逐瞬時需求——價格、效能與履約紀錄，皆可能即時影響路由決策。

1.3 穩定幣正從交換媒介轉型為結算基礎設施

早期加密市場中，穩定幣需求主要來自交易與避險性資金外流。隨著發行、託管、合規及跨鏈基礎設施逐步成熟，穩定幣已開始進入跨境結算、企業財庫管理與原生網際網路支付領域。對機器支付而言，穩定幣另有一項獨特優勢：它既是貨幣，亦是程式可直接操作的數位資產。

信用卡支付仰賴持卡人身分、銀行帳戶與地域性網絡。代理本身不具自然人身份，無法獨立完成傳統開戶流程。然而，政策管控型錢包可成為代理的資金介面：營運者注入限額餘額、設定單筆與單次會話上限，並保留凍結與撤銷權限；代理僅於授權範圍內簽署付款。

這並非意味鏈上支付天然優於所有傳統支付。消費者保護、退款機制、隱私、金鑰管理與監管責任仍待解決。但在機器對機器、低價值按次付費、全球服務採購等場景中，可程式化穩定幣具明確相容性——首次實現「呼叫介面」與「支付介面」壓縮至同一網路互動中。

2. 支付軌道已然成形：x402、MPP與HTTP原生交易

2.1 將402狀態碼轉化為商業介面

HTTP早已預留402 Payment Required（需付款）狀態碼，但近三十年來未形成通用工作流程。機器支付協定重新啟用此語意：客戶端請求付費端點，伺服器回傳402及機器可讀付款條款；客戶端選取可接受選項、完成簽署或付款後，再攜帶憑證重試請求。

此流程關鍵在於消除人工註冊頁面。價格發現、付款要求與內容交付，全發生於程式可理解的協定層。對開發者而言，付費API無須圍繞帳戶、方案與金鑰建構完整SaaS入口；對代理而言，服務可如一般網頁般被發現，並於實際需要時購買。

x402是此路徑上最受矚目的開放協定之一，其圍繞HTTP 402組織付款挑戰與憑證，使服務商得以按請求收取費用。MPP則源自不同生態系，探索面向機器的付款方式（如扣款與會話計費）。二者設計細節雖異，卻共同驗證同一方向：機器支付可融入應用協定，無需在應用之外另行建置人工結算流程。

2.2 支付軌道多元化的長期必然性

產業常預期最終僅存單一標準協定、單一結算網絡與單一支付方案。但從商家觀點看，多元化具長期合理性：一次性資料查詢適用按次計費，持續推論或串流服務則更適合會話計費；高價值服務需強力保障與爭議處理，低價值請求則更重速度與成本；不同區域與企業亦將選擇差異化的合規與結算網絡。

協定層將持續創新。商家可採用直接扣款、預先授權、第三方託管、串流付款或批次結算；網絡則於成本、最終性、流動性與生態工具間做出不同權衡。對賣方而言，這是選擇自由；對買方而言，每種新組合皆增添一層整合介面。

下方圖表所示配置矩陣，即此多元化的一個橫截面：協定／支付方案構成欄位，區塊鏈構成列，每一交叉點皆為需獨立整合的支付配置，且該矩陣仍在持續擴張。

圖1：碎片化下的支付軌道配置矩陣

因此，碎片化未必隨市場成熟而自然消失。銀行卡市場經長期發展仍未僅存單一卡組織，雲端運算亦未收斂至單一廠商。成熟市場通常不消除差異，而是於差異之上構建聚合、路由與清算層。代理支付極可能遵循相同演化路徑。此分裂現象已可量化：依據兩大公開探索器（x402scan與mppscan）過去30日（截至2026年9月3日）數據，MPP協定於Tempo鏈有65,591個活躍買方錢包，x402於Base鏈有19,472個，僅365個錢包同時出現在兩條軌道上（不足MPP買方的0.6％、x402 Base買方的2％）；其中僅112個錢包於兩條軌道各完成逾十筆交易，且多數為雙軌聚合商，以其同一密鑰代用戶付款，而非買方自身採用第二條支付軌道。買方並未跨軌流通，各軌道正各自累積獨立買方群體。

2.3 賣方入駐僅完成交易一半

支付協議首先降低商家接受付款的門檻。一旦端點能發布報價、驗證憑證並回傳服務，即具備機器導向商務的基本條件。越來越多的開發者工具、資料服務與內容介面因此可被機器直接購買。

然而，供應端具備可付費性，並不意味需求端會自動跟進。商家解決了『如何向機器收款』的問題，但代理程式仍須回答：『該向誰購買？該使用哪種付款方式？付款後如何確認交付？』若每位買方都需各自整合每套協議、於不同網路預存資金，並維護獨立帳本，機器付款將重蹈早期 API 整合的複雜性——僅把 API 金鑰換成錢包與協議轉接器。

實際採用率取決於整體交易摩擦，而不只是結算步驟的摩擦。

3. 產業真正的瓶頸：交易缺乏閉環

圖 2：機器採購的完整流程

3.1 第一關：發現可購買服務

代理程式需要機器可讀的服務目錄。有效的目錄不能只包含名稱與網址，還須描述端點能力、輸入／輸出格式、計價單位、支援協議、延遲、地理限制及更新狀態；亦需建立自然語言意圖與 API 參數間的對應關係，否則代理程式雖知『需要宏觀經濟資料』，卻無法判斷哪個端點能完成任務。

開放市場中的目錄亦面臨重複、過期與虛假宣稱等問題。任何商家皆可聲稱提供高品質資料，但代理程式無法像人類採購人員般耗費數日進行背景調查。發現層必須持續驗證端點是否可呼叫、報價是否真實、描述是否與回傳內容一致。

這使得服務發現迥異於傳統搜尋：搜尋引擎優化資訊相關性，而機器採購目錄還須優化可交易性——能力是否匹配、價格是否可接受、付款是否相容、商家能否交付。

3.2 第二關：理解與比較報價

表面看來，類似 API 均可按次計費，但實際報價難以直接比較：有的按請求次數收費，有的按結果項目計費；有的已含模型推論費用，有的則需額外支付；其他服務更依輸入長度、執行時間或成功結果動態計費。

代理程式不能單純選擇名目價格最低的端點，而須綜合評估總成本、交付成功率、延遲與結果品質。若廉價介面頻繁失敗，重試成本與任務延宕可能使其實際價格更高。故報價應結合服務水準、歷史表現與任務情境一併評估。

機器可讀報價亦須明確標示有效期與最終金額。在動態定價環境中，代理程式簽署的必須是明確承諾，而非模糊的價格區間；營運者亦須清楚費用組成（含服務費、網路成本與路由費），方能設定可信的預算。

3.3 第三關：資金分配與跨鏈流動性

若代理程式需同時跨多條鏈與多套協議購買服務，最直接做法是於各網路預存餘額。但此舉將少量資金碎片化：閒置資金滯留於未使用網路，熱門網路卻可能餘額不足；補充餘額更涉及跨鏈橋接、代幣兌換、Gas 費與安全操作。

對單一使用者而言已十分繁瑣；對管理大量代理程式的企業，問題更為放大：各代理程式應持有多少餘額？由誰負責補充？如何防止資金誤用？如何跨網路彙整資產與手續費？缺乏統一資金層時，支付管道愈多，財務複雜度愈高。

理想情況下，代理程式所見應為單一可支用預算，而非多個網路餘額。底層系統應自動處理結算路徑選擇、流動性管理與透明報價。原理類似旅客持一張卡於多國消費：使用者只關心總信用額度與匯率，無需為每個目的地預先開立本地帳戶。

3.4 第四關：基於策略的授權

自主付款最易引發的擔憂，即是代理程式失控支出。解決方案並非簡單二選一『全面禁止』或『完全授權』，而是建構多層級策略。

單筆交易上限可限制單一錯誤損失；任務階段預算可管控整體花費；商家白名單／黑名單可管控交易對象；類別規則可限制可購項目；速率限制可防範短時間異常呼叫。高風險或高價值交易亦可觸發人工確認。策略應由營運者設定，代理程式僅能在既定範圍內執行，不得自行提高上限。

錢包不僅應具備簽署功能，更需整合任務、身分與稽核紀錄，以回答「哪位代理者基於何項任務、依循何種政策批准此筆付款？」否則企業僅能獲得一串鏈上交易雜湊，無法滿足內部管控與成本歸屬需求。

3.5 第五階段：結算成功不等於服務交付

區塊鏈擅長證明資金已從一地址轉移至另一地址，但無法原生驗證API是否回傳正確內容。交易雖完成結算，伺服器仍可能逾時、回傳錯誤狀態，或提供與廣告不符之資料。對代理者而言，此非邊緣案例，而是採購風險的核心。

傳統電子商務透過物流、評價與退貨機制串聯付款與交付；機器服務則無實體物流——交付可能僅是一次短暫的HTTP回應。若付款系統僅記錄資金流向，商家僅記錄自身回應，市場便缺乏橫跨商家與協定的統一履約視圖。

須謹慎的是：記錄回應不等同於證明品質。但將付款與回應關聯，至少可區分「已付款且取得結果」、「已付款但服務失敗」及「未結算」等基本狀態，這是建構機器交易可信度的第一層事實基礎。

3.6 第六階段：統一對帳與責任界定

單一任務可能涵蓋十餘筆微採購。若各筆交易分散於不同錢包、協定與商家後端，使用者難以釐清最終交付成果之成本構成。企業亦需將支出歸屬至專案、團隊、客戶與成本中心，並保留可稽核之證據。

統一帳本應同時記錄採購意圖、商家、報價、授權政策、結算結果、回應狀態與失敗原因。其服務對象不僅限於財務部門，亦支援代理者最佳化：系統可分析哪些資料來源頻繁失敗、哪些路徑成本較高，以及特定類型任務的典型採購組合。

當付款嵌入推理鏈中，成本即成為模型決策的回饋訊號。缺乏統一對帳，代理者僅能優化答案，無法優化取得答案的經濟流程。Agent Payment 的長期價值，正源於此類可觀測性。

4. 從支付協定邁向機器採購層

4.1 未來的核心抽象概念並非「付款」，而是「採購」

付款是物件與價格明確後的動作，而採購涵蓋從需求產生到成果驗收的完整流程。向代理者暴露 pay() 函式，僅允許其將資金轉至已知地址；暴露 buy() 能力，則代表系統可接收需求、發掘服務、比對選項、執行付款，並回傳可驗證之結果。

此差異決定產業分工：協定提供標準化付款訊息，錢包管理簽署與資產，結算網路轉移價值，目錄彙整供給，而採購層則將這些元件整合為單一任務。任一元件皆重要，但無一能獨立代表完整交易。

機器採購層須保持開放：不強制所有商家遷移至同一協定，亦不透過封閉目錄決定可採購對象。更具永續性的模式，是相容多重支付軌道、於報價中揭露路由成本，並允許代理者依政策自主選擇。

4.2 買方聚合可能比賣方聚合更重要

網際網路平台通常先聚合供給再吸引消費者；在機器市場中，供給已廣泛存在於API形式，欠缺的是具連續採購能力的標準化買方。具備能力的代理者，可將零散、偶發的需求轉化為穩定交易流。

買方聚合亦提升長尾服務能見度。人類開發者傾向使用熟悉的大品牌，因評估新供應商的時間成本高昂；若代理者能解讀標準化的能力、價格與履約訊號，即可針對每項任務選取更適配的服務。這可能降低新商家的客戶取得成本，亦迫使既有商家以實際表現競爭。

但買方入口點亦可能催生新型平台權力。掌控預設目錄、排序與付款路徑者，可能影響流量分配。因此產業需透明的排序規則、可解釋的費用結構，以及可攜帶的交易紀錄。聚合可降低摩擦，但不應將開放協定重新包裝為封閉通道。

4.3 基於真實交易資料建立聲譽

機器買方決策極快，無法仰賴冗長盡職調查，需於報價出現時同步取得交易對手訊號。傳統評分與用戶評論雖具參考價值，卻易受刷量、女巫帳號及關聯方操弄。若評論毋須真實付款，攻擊成本尤其低廉。近期關於ERC-8004（首個面向代理者的無許可鏈上信任層）之實證研究已證實此點［6］。該協定規範明文指出「付款與本協定正交」——評論預設無需綁定任何真實付費交易，付款證明僅為選填欄位。結果顯示：截至2026年5月13日，在以太坊、BSC與Base上，分別有73.5%、59.2%與90.6%的評論者呈現協作式女巫行為。

更可靠的基礎，是綁定實際付費呼叫的結果記錄：某服務端點已完成多少筆結算、回應成功率為何、常見延遲為何，以及付款後無回應的比例有多高。這些指標雖仍無法完整代表內容品質，但比起自我申報，更接近可驗證的事實。

隨著資料累積，市場可能發展出分層聲譽機制：第一層為客觀交易狀態，第二層為可重現的服務指標，第三層則針對特定任務的品質評估。代理程式可依金額與風險，選擇所需證據強度——例如幾分錢的資料查詢可仰賴統計信號，而高價值採購則需保證、審計或爭議解決機制。

4.4 預算策略將成為代理程式的關鍵能力

目前代理程式主要以答案品質、任務完成率與工具呼叫準確率評估；一旦進入付費環境，經濟性指標必須納入：達成同等品質所耗費用、是否於預算內完成任務、何時值得購買更高價資料，以及如何平衡速度、成本與可靠性。

這將催生訓練與評估的新方向：代理程式不僅學習「哪個工具能回答問題」，更要判斷「基於當前任務價值，購買此工具是否划算」。它可能先用低成本服務篩選，再針對關鍵結論購買高品質驗證；也可能在預算即將耗盡時降低呼叫頻率，或向使用者請求額外授權。

在此意義上，代理程式支付並非模型能力之外的財務外掛，而是決策智慧的一部分。真正成熟的代理程式，不僅懂得運用資源，更須具備為資源定價的能力。

5. 代理程式支付的可能演進路徑

5.1 第一階段：開發者工具與數位服務率先推動

最早大規模應用場景，很可能仍是純數位交付類型，例如搜尋、資料、代理爬蟲、模型推論、程式碼執行、儲存與內容生成。此類服務本即透過 API 提供，邊際交付成本低，可於同一網路會話中同步完成付款與回應，且不涉及複雜物流。

此階段典型金額極小，使用者聚焦於開發便利性與任務完成率。市場將快速驗證協定，但交易量可能高度碎片化。許多呼叫仍由傳統 API 金鑰與訂閱制處理，機器支付則多用於臨時需求、跨商家採購，以及無法事先開戶的長尾服務。

5.2 第二階段：企業預算管理與多代理協作

當企業開始部署多個代理程式，資金管理將從個人錢包升級為組織層級帳戶系統。企業需為不同角色分配預算、管控可採購類別、設定核准門檻，並將支出記入財務系統。代理間內部結算亦可能形成：研究代理採購資料、分析代理購買運算力、執行代理呼叫外部服務。

此時，安全性與合規性重要性遠高於支付新穎性。企業關注金鑰保管、權限隔離、交易監控、廠商審查與稽核軌跡。唯有能整合既有財務流程的基礎設施，方能自實驗階段邁入正式生產。

5.3 第三階段：由數位服務延伸至實體經濟

機票、飯店、物流、廣告與專業服務等，皆可能成為代理程式的採購目標；但實體交易需更複雜的身份驗證、退貨、課稅與爭議處理機制。穩定幣僅能部分解決結算問題，無法取代消費者權益保障與商業契約。

因此，產業不應誤解「自主支付」為全面消除中介。相反地，隨交易價值提升，保證、保險、信用與仲裁機制將重新浮現——只不過須轉型為機器可呼叫的服務。未來代理程式支付堆疊，可能同時涵蓋開放支付協定與傳統金融連接，而非單一路徑取代另一路徑。

5.4 第四階段：由跨協定路由邁向跨市場執行

長期而言，代理程式所購買的不只是 API 回應，而是最終成果。例如使用者要求「產製一份可信的產業報告」，系統便自動整合搜尋、資料庫、翻譯、模型與驗證等服務。底層發生多重交易，使用者僅看見總預算、證據來源與最終交付成果。

這將使支付路由升級為市場執行：系統須將複雜目標拆解為採購組合、動態替換失敗廠商，並在總成本與品質間最佳化。協定相容性僅為基礎；真正的護城河，來自對需求的理解、交易資料累積與執行回饋。

6. 風險與開放性問題

代理付款具備龐大的創意潛能，但現實世界的限制不容忽視。首要的是安全性：提示注入可能誘使代理購買惡意服務；供應鏈攻擊可能竄改收款地址；政策缺陷可能導致大量重複付款。付款操作必須與不可信內容隔離，並配備限額、模擬、撤銷及異常偵測機制。

其次是隱私性：採購紀錄會揭露代理執行的任務類型，而鏈上公開資料可能將使用者身分與商業意圖關聯。系統須最小化敏感中繼資料外洩，並在稽核需求與隱私權之間取得平衡。

第三是責任歸屬：當代理錯誤採購、商家未履約或協定轉換失敗時，損失該由誰承擔？低價值交易可接受自動化風險，但高價值交易需明確劃定責任邊界；缺乏爭議處理機制的支付網路，難以直接進入高價值商務領域。

第四是法規遵循：穩定幣發行、錢包管控、跨境轉帳與商家收款等，均受不同司法管轄區法規規範。機器僅為執行者，非法律責任主體；基礎設施必須能追溯每一筆自主交易至明確的操作者、授權政策與資金來源。

第五是商業永續性：微支付收入易遭網路成本、流動性及風險控管費用侵蝕；若平台透過隱藏加價補貼體驗，將損害買方信任。費用必須透明，且須藉由規模效應、路由效率與增值服務建立穩健商業模式。

這些課題並非否定該領域，而是凸顯「代理付款」無法單靠一項協定完成；最終將演變為整合支付、身分、權限、發現、聲譽與對帳功能的複合式基礎設施。

7. SELAT：賦能機器原生商務之買方側

『SELAT』源自馬來語『海峽』一詞（如馬六甲海峽 Selat Melaka）。數世紀以來，無論貨物來自何港、駛向何市，東西貿易主流皆經此水道。SELAT 旨在成為機器原生商務中的這條海峽：不論商家接軌哪種支付通道，代理需求皆可由此流通。

SELAT 是一家以 AI 為原生的公司，選擇從買方側切入機器支付領域。SELAT 即機器原生商務的買方層，其核心目標並非另建需商家遷移的支付通道，而是讓代理能在既有通道上完成採購。它聚焦兩大核心問題：一是支付設定碎片化——各通道、協定、鏈與憑證皆異，每接入一商家即須重新整合；二是交易對手風險缺乏衡量——成功結算不等同服務已交付。

圖3：SELAT 買方層示意圖

為解決碎片化問題，SELAT CLI 將協定、支付方案與結算網路差異留於基礎設施層，使代理僅需單一指令即可完成跨通道採購。服務發現、報價、授權、付款、交付狀態記錄與對帳皆整合於同一採購流程，且每次呼叫亦同步記入同一帳本。

• 單一金庫，支援 N 種支付通道

代理持有自託管 USDC 餘額，無需依鏈預先充值，亦不需為不同協定維護多套客戶端。

• 整合式端點目錄

SELAT CLI 整合 Circle、MPP、Apify 及 pay.sh 四家第三方服務註冊中心，並納入 SELAT 自有目錄，使代理可依據即時意圖，發現並比對逾 4,000 個服務端點。

• 嚴格支出上限

營運者可設定單筆交易限額與會話預算，並隨時凍結支出權限；代理無法自行提高限額。

• 零商家遷移

商家可保留慣用支付通道，無需向 SELAT 重新註冊，即可被代理發現與採購。

在資金端，SELAT 相容任何代理錢包（含 Circle 與 MetaMask 代理錢包），並依即時報價，將每筆採購路由至 x402、MPP 等支付通道。

7.1 ERC-8004：正確的原語，可疑的信號

ERC-8004 定義三種註冊類型——身分、聲譽與驗證，並允許買方對賣方提交評論。方向正確，但明確將付款與聲譽分離：評價未必來自真實交易，附加付款證明亦為可選。

針對已部署生態系的實證研究顯示，在 Base 上，93.8% 的評論者從未進行過 x402 付款，卻貢獻了 94.9% 的評論；其中大量評論更呈現協同女巫行為 [6]。註冊表僅記錄主張，而買方真正需要的是結果。

7.2 與真實交易資料連結的聲譽，才是買方所需

支付通道可確認資金是否結算，但無法得知服務實際回傳內容；商家僅能看見自身回應，無法掌握整體市場；註冊表雖可列出端點，卻無法證明評論源自真實購買。

執行採購的買方層級最適於串接交易兩端：所有透過 SELAT 完成的採購，均記錄所付端點、結算金額及付款後交付狀態元資料（2xx、4xx、5xx）。這些記錄依商家與支付通道持續累積，構成「結算－交付圖譜」的資料基礎。

須明確區分：連結付款與交付狀態的紀錄，不等同於獨立證明交付品質或報價準確性；但它提供了基於註冊表之聲譽所缺乏的關鍵基礎——綁定真實付費調用的結果資料。

7.3 交易前取得交易對手可信度

當各界於 X 平台討論如何為第四代網際網路設計類似 Google PageRank 的信任機制時，SELAT 已在其結算－交付圖譜之上推出「可交易性指數」，旨在為代理程式提供即時存取、由真實交易結果支撐的交易對手可信度資料。

該指數隨報價一併回傳，無需代理程式暫停任務另行調查商家。它標示風險，但不為市場設立門檻：端點仍可被發現與購買，代理程式則依預算、任務重要性與風險偏好自主決策。

代理程式沒時間閱讀品牌故事。它需要在付款前即知悉：此端點於真實交易中的表現如何？機器原生商業中的可信度，不應來自主張，而應來自結果。

圖 3：報價階段的可交易性信號

目前 SELAT CLI 已適配 Claude Code、Codex、Cursor、Gemini CLI、OpenClaw、Hermes 及 Grok Bot 等代理程式執行環境。

8. 總結：機器經濟所需，不僅是更快的支付通道

代理付款正處於易被高估亦易被低估的階段。易被高估，因技術上完成穩定幣付款並不等同代理程式具備成熟的商業自主權；易被低估，因一旦軟體能在明確約束下採購外部能力，機器經濟的組織方式、定價模型與競爭邊界便將全面改變。

支付協定已證實機器可接收報價並完成結算。下一步關鍵，是將孤立的付款擴展為完整採購流程：讓代理程式能尋找合適服務、理解真實成本、跨通道於預算內付款、確認交付，並使每筆交易皆成為可稽核、可學習的紀錄。

未來機器經濟不會只有一條鏈、一種協定或一個錢包。多源供應將長期存在，真正有價值的基礎設施，將協助買方駕馭此複雜性。代理付款須整合通道、供應、預設付款與信任機制，方能將技術能力轉化為真實需求。

當軟體開始扮演買方角色，付款僅是其踏出的第一步；更重要的問題始終是：它能否以可控、透明且可驗證的方式，完成真正具實質效用的交易？

參考文獻

[1] Circle，《建構開放代理經濟》，2026 年。https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT，《代理支付中的交易對手風險：未被衡量的另一半》，2026年。https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud，《以全新代理支付協議（AP2）驅動AI電商》，2025年。https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] x402基金會，《x402：一個開放且原生於網際網路的支付標準》。https://github.com/x402-foundation/x402

[5] 機器支付協議（MPP），《基於HTTP 402的機器支付協議》。https://mpp.dev/

[6] 熊等人，《無需信任的代理能否被信任？ERC-8004去中心化AI代理生態系統之實證研究》，arXiv，2026年。https://arxiv.org/abs/2606.26028

[7] SELAT官方網站：https://www.selat.ai

本文由投稿者撰寫，不代表BlockBeats立場。