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

作者：Charlie，OSL美洲負責人，Venture Partner @ Generative Ventures。曾任加密貨幣獨角獸 Strike 副總裁（參與薩爾瓦多比特幣法案，並負責拉美比特幣閃電網絡和穩定幣支付業務），萬億級基金 Franklin Templeton 宏觀與貨幣分析師，全球支付巨頭 Adyen 早期成員。

文章為作者個人觀點，不代表相關公司立場。

最近關注 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。

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

但我這幾天越看，反而越覺得，這種「亂」不是因為市場沒方向，而是因為市場已經很清楚，而且就像我之前 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、商戶關係、憑證共享、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 太多，最後一上生產環境就開始漏。

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 不是這場故事的結尾。

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