Coinbase把x402推向中立 Stripe在MPP之外押注兩邊

作者：Charlie Liu，Generative Ventures 合夥人

最近關注 agentic commerce 的朋友越來越多了，但各種協議和玩家也越來越讓大家摸不清頭腦了。

尤其是上週，大家還在忙著了解 Stripe / Tempo 的 MPP，轉眼間 Stripe 居然加入了友商 Coinbase 的 x402 Foundation。

而且 Cloudflare 現在兩套都支援。Google 也在這個局裡，但它自己又有 AP2 和 UCP。

Visa、Mastercard 也都來了，但它們顯然不是來給穩定幣站台的。

Linux Foundation 公開把 x402 定義成一個中立、產業共治的「大本營」，Cloudflare 則明確把 x402 和 MPP 同時放進自己的 Agents SDK，Stripe 也公開寫了自己同時支援 MPP 和 x402。

到底誰和誰在競爭，誰和誰又在疊加？

但我這幾天越看，反而越覺得，這種「亂」不是因為市場沒方向，而是因為市場已經很清楚，而且就像我之前提到的：這件事從第一天起，就不會由一個協議一次性統一。

它更像是網際網路基礎設施裡很常見的一種局面——不同層同時在長，不同公司在不同層下注，最後靠互操作性把整個東西先跑起來。

真正的戰略故事，是誰來定義 agentic web 上 paid machine access 的預設控制層；而且關鍵玩家明顯都在 multi-home，因為大家都還在賭未來真正的瓶頸會落在授權、分發還是結算上。

一、Coinbase 為什麼放手把 x402 基金會交給 Linux？

如果 x402 只是 Coinbase 的協議，它很難成為產業預設選項。

這不是一句政治正確的話，而是很現實的標準化邏輯。

Linux Foundation 這次的表述很明確，它強調的是服務商中立、社群治理、共享基建，而不是「某家公司發布了一個產品新功能」。

更關鍵的是，x402 Foundation 頁面現在還寫著專案處在建立期，治理機制和董事會都還在搭建中。

也就是說，這次動作首先不是在宣布「產品成熟了」，而是在宣布「我們要給這個協議一個中立的家」。

背後的潛台詞其實很簡單。

x402 如果一直長著一張 Coinbase 產品功能的臉（例如現在的 Base），那麼雲端廠商、支付公司、卡組織、平台型玩家即便技術上願意接，也會在政治上猶豫。

誰都不想把未來的 paid access layer 交到單一平台手里。把它放到 Linux Foundation 底下，不是因為 Coinbase 不想控制，恰恰是因為它太想讓 x402 被廣泛採用，所以必須先把「這是 Coinbase 的協議」這層包袱摘掉。

這點其實很重要，因為很多人看基金會這類動作，容易只把它當成 PR 或者開源姿態。

但在協議戰裡，治理就是產品的一部分。

尤其是當一項標準還在早期、還沒有絕對網路效應的時候，所謂「中立可信」並不比技術優雅次要。

相反，如果 x402 未來真的能成為某種 HTTP-native paid access baseline，很可能不是因為它程式碼最漂亮，而是因為它比其他方案更早把政治成本降下來了。

換句話說，這裡治理不是配角，治理本身就是成長引擎。

二、Stripe 的左右互搏到底在幹嘛？

這次最值得盯著看的玩家，絕對是 Stripe，因為 Stripe 的動作最容易讓人困惑。

一方面，它在 3 月 18 日高調推出 MPP，把它包裝成機器支付的開放標準。

另一方面，它又是 x402 Foundation 的 founding contributor，而且自己的文件也在支援 x402 machine payments。

Cloudflare 的文件更直接，甚至明確寫了：MPP 對 x402 的核心支付流程是 backward-compatible 的，MPP client 可以直接消費現有的 x402 服務。

如果只從「協議競爭」這個框架去看，Stripe 像是在左右互搏。

但如果你把視角再抬高一點，這種做法反而最有商業邏輯。

因為 Stripe 真正想守住的，未必只是 402 handshake 本身。

它真正想守住的，是 handshake 之上的那幾層：credentials、compliance、risk、reporting、tax、refunds、merchant integration。

Stripe 看起來不像是某個單一協議的真正信仰者，更像是在確保無論最後哪個 handshake 標準勝出，Stripe 仍然是 agent payments 的預設抽象層。

支援 x402，是為了不缺席開放生態；自己推 MPP，是為了參與定義底層語義；再往上推 ACP 和 Shared Payment Tokens，則是為了守住工作流和支付憑證那一層更厚的價值。

所以 Stripe 這次最「怪」的地方，其實恰恰是最誠實的地方。

它沒有假裝未來很快就只剩一個協議。它是在用行動告訴你：至少在這個階段，誰都不該只押一邊。

三、這其實是一個 B2B 的基礎設施故事

我越來越覺得，很多媒體把這件事的焦點放偏了。

一說 agent payments，最容易想到的總是零售：AI 幫你買機票，幫你訂飯店，幫你下單，幫你走 checkout。

但如果你去看眼下真正已經公開落地、而且真的開始有基礎設施味道的場景，最先跑起來的並不是零售 checkout，而是更無聊、也更真實的 B2B paid access：付費 API、付費資料、付費工具、付費瀏覽器會話、付費 agent workflow。

Cloudflare 現在公開支援用 x402 和 MPP 對 HTTP 內容、API 和 MCP tools 收費。

x402 最強的採用路徑，就是在 developer-to-developer paid APIs 和 tools 上，因為「no account + pay-per-request」在這裡不是噱頭，而是實打實的可操作落地。

背後的改變其實很大。

過去一個 API 要收費，通常要先走一整套「人類友善」的流程：開帳戶、綁 billing、發 API key、設限額、對帳，再處理支付權限。

對人來說已經夠煩了，對 agent 來說更彆扭。

x402 最有吸引力的地方，不是它更 crypto，也不是它更 AI，而是它試圖把「付費存取」重新塞回 HTTP 本身，讓准入控制和支付協商像普通 request-response 一樣發生。

伺服器返回 402，告訴你這次請求值多少錢；用戶端付完錢，再用支付憑證重試同一個請求。

這個模型如果你從 B2B 軟體和 machine-to-machine access 的角度看，會比從零售角度順得多。

而且，越往 B2B 這邊看，x402 的優勢越明顯，短板也越沒那麼致命。

因為在 consumer commerce 裡，退款、拒付、merchant-of-record、consumer protection、責任歸屬，這些全都是硬問題；但在 B2B API 和工具呼叫裡，這些問題的重要性明顯下降。

相反，「無帳號、按呼叫付費、拿到結果就走」才是真需求。

零售當然更大、更熱鬧，也更容易吸引眼球；但真正先定義協議長什麼樣的，往往不是最熱鬧的場景，而是最早暴露出真實需求的場景。

對今天這波 agent payments 來說，那個場景很可能不是購物車，而是越來越多的軟體之間、agent 之間、工作流程之間的 paid access。

四、產業發展驗證了我之前 interoperability 的判斷

我上一篇文章裡最核心的判斷，是 interoperability。

當時這個判斷聽起來多多少少還帶有一點「架構上應該這樣」的味道。

現在看，它越來越像現實約束，因為公開市場已經在用腳投票了。

Cloudflare 沒有選邊站，而是直接同時支援 x402 和 MPP，還明確做了相容映射。

Google 一邊參與 x402，一邊繼續推進 AP2 和 UCP。

Visa 和 Mastercard 也都沒有用「all in one winner」的姿態來表達自己的戰略，而是一邊加入 x402，一邊繼續加碼 agent token、身分驗證、指令校驗和 dispute signals。

巨頭們的多邊押注是理性決策，而不是商業虛偽。

為什麼會這樣？因為這些協議壓根就不在同一層。

至少到目前為止，x402 和 MPP 更接近 paid HTTP handshake 這一層，解決的是「怎麼讓請求帶著支付能力回來」。

AP2 更接近授權和可信意圖，解決的是「這個 agent 到底有沒有資格花這筆錢」。

UCP 和 ACP 則更像 workflow 層，用來處理 discovery、checkout、商戶關係、憑證傳遞這些更上層的問題。

很多公司同時支援 x402、MPP、AP2、UCP，不是因為它們自己想不清楚，而是因為贏到最後的架構本來就很可能跨多層，甚至需要多協議共同組成。

所以如果要用一句話回頭看我上一篇的判斷，我現在更加相信：如果沒有 interoperability，這波生態根本起不來。

現在看，市場正在主動驗證這個判斷。

更進一步說，這個判斷對 B2B vs 零售也很重要。

因為零售世界裡，最後也許真會被少數大平台和少數大工作流程吸進去；但 B2B 世界不是這樣。

企業本來就活在多雲、多支付方式、多工作流程系統、多身分權限系統並存的現實裡。

誰試圖用一個新協議把整個企業堆疊一把推倒重來，誰大概率先死。

B2B 客戶真正願意買單的，往往不是「唯一正確的協議」，而是「讓既有系統在多協議環境下還能工作」的能力。

這個邏輯，恰恰就是 interoperability 在企業情境裡比在 consumer 情境裡更硬一點。

五、這不是單純的協議競爭，而是分層後的 stack 競爭

一旦你把這件事理解成分層 stack，很多原本顯得很亂的現象就會立刻順起來。

最底下一層，是 paid access handshake。

這一層關心的是：HTTP 請求怎麼表達「這裡需要付費」，以及用戶端付完之後怎麼把支付憑證帶回來。

x402 和 MPP 主要在這裡打。MPP 在嘗試把 402 往更正式的 HTTP auth semantics 上收；而 x402 則更像是在把 402 平台化，透過自訂 header、facilitator、鏈上結算抽象和生態整合，讓它先跑起來。

一條更像標準化語義路線，一條更像平台分發路線。

再往上一層，是 authority to spend，也就是「誰授權了這筆錢」。

這一層才是很多人現在還沒完全意識到的關鍵。

機器能付錢這件事沒有那麼難；機器能被可信地授權去付錢，才是真難。

AP2 之所以重要，就因為它不只是「怎麼支付」，而是在解決 mandates、verifiable credentials、authenticity、accountability 這些事情。

Visa 和 Mastercard 最近加碼的那些 agent token、instruction validation、passkeys、dispute signals，本質上也都在這裡。

再往上一層，是 workflow 和 distribution。

也就是 discovery、checkout、商戶關係、credential sharing、AI surface integration 這些更接近「誰掌控流量和交易編排」的東西。

UCP 和 ACP 更像是在爭這一層。

對 B2B 來說，這層短期沒有那麼熱鬧，但從長期看價值可能非常高。

因為如果未來越來越多企業軟體都由 agent 協調、呼叫、採購和支付，那麼誰掌握 workflow language，誰就不只是管一次付款，而是在管整個工作流程。

一旦你把這三層分開，就會發現一個很樸素的事實：根本沒必要期待一個協議把所有問題都包了。

更現實的路徑，是這三層各自先長，再透過互操作性慢慢咬合起來。

也正因如此，多頭下注不是搖擺，而是理性。

六、x402 的真正風險，未必是監管，而是並發下的經濟學

如果我們只是認識到「多協議並存」，其實還不夠深刻。

x402 最大的風險，未必首先是監管，而可能是 verify–settle 兩步分段帶來的 time-of-check/time-of-use 經濟學。

簡單說，就是如果驗證支付和最終結算不是一回事，那在高並發、重試、代理層、快取層這些真實網際網路環境裡，就會出現「pay once, access multiple times」的窗口。

x402 生態現在也在補洞，比如 settlement cache、idempotency extension、payment identifier，但這恰恰說明問題不是理論上的。

這點為什麼尤其值得 B2B 讀者在意？

因為 B2B 世界最怕的，從來都不是漂亮 demo 做不出來，而是 edge case 太多，最後一上 production 環境就開始漏。

API monetization 這種事，表面上看是每次請求付幾分錢，挺輕；可一旦你的產品是按呼叫收費、按結果收費、按工作流程收費，那「付一次拿一次」還是「付一次拿很多次」，就不是產品細節，而是生死線。

所以如果未來 x402 真能在 B2B 裡跑出來，一個重要前提不是 narrative，而是這些 default-safe 的機制得被做得足夠無腦，否則企業不會放心把真實流量接進來。

七、協議可能是免費的，但收費站不會消失

還有一點，我覺得值得在這篇裡講透。

很多開放協議最後都會走到一個很熟悉的地方：協議本身越來越便宜，甚至免費，但真正的收費站會在旁邊長出來。

x402 也一樣。

標準本身當然強調開放、中立、0 fees built into the standard，但這不等於 value capture 會消失。

如果 x402 成功，價值不會主要留在協議裡，而會往 facilitator、錢包和 key management、discovery、policy engine、trust wrapper 這些相鄰層遷移。

這對 B2B 來說尤其重要。

因為企業客戶不會為了一個新協議就大規模改造整套系統，他們真正願意付錢的，是誰能幫他們在多協議環境裡把 orchestration、policy、risk、compliance、audit、settlement、權限邊界這些麻煩事收拾好。

換句話說，協議會越來越像底層語言，但把這些語言翻譯成「企業能放心上線」的能力，那一層反而更容易變成新的平台和新的收費站。

這也是我為什麼會覺得，今天看 x402，不能只盯著 Coinbase、Cloudflare、Stripe 誰更像「主角」。

真正值得盯的，是誰最有機會站到這些相鄰層上。

Cloudflare 有邊緣和流量分發的位置，Stripe 有支付基礎設施和商戶關係的位置，Visa 和 Mastercard 有憑證、網路 token 和 consumer trust 的位置，Google 有 workflow 和 discovery surface 的位置。

真正的價值捕獲，不一定發生在「誰定義了 402」，更可能發生在「誰把 402 接進了更大的企業系統」。

八、結語

x402 Foundation 這件事，不是在宣布 x402 已經在所有 agentic commerce 協議裡勝出。

它是在公開承認，這一代 agent payments 從第一天起就不會是單一協議世界。

Coinbase 把 x402 交給 Linux Foundation，是為了讓它更像中立公共層，而不是獨家產品。

Stripe 一邊推 MPP 一邊加入 x402，不是搖擺，而是因為它知道現在不該只押一邊。

Cloudflare 同時支援兩套，是因為它最接近真實流量。

Google、Visa、Mastercard、Adyen 這些玩家的動作，也都在說明同一件事：先讓系統能互通，再談誰最後占住哪一層。

而如果把視角從零售挪開，這個判斷就更順了。

因為最先需要這些協議的，不一定是購物車，而是越來越多按呼叫、按任務、按結果收費的 B2B 軟體和服務。

零售當然更大，但 B2B 往往更早暴露真實需求，也更早定義基礎設施最後會長成什麼樣。

我上一篇文章裡把 interoperability 放在中心，我覺得現在市場給出的答案其實很明確：對，而且比當時想的還更早。

從這個意義上說，x402 Foundation 不是這場故事的結尾。

它只是讓我們更早看見，真正的主題一直不是「誰會贏」，而是「這個世界注定要先互通，誰又能在互通之後，占住最值錢的那一層」。