Stripe用WebMCP取代DOM推測完成結帳
Stripe Dot Dev Blog · 2026-09-22
背景：AI代理結帳靠「看畫面、猜按鈕」
Stripe於2026年9月22日發布的技術文章指出，過去AI代理要完成網頁結帳，得同時解析畫面與DOM（Document Object Model），推測頁面上有哪些可執行的動作，再規劃並執行點擊與填表。這種做法被形容為緩慢、間接且極度消耗token，因為代理得把整段HTML塞進LLM的context視窗，逐一猜測元素的id或class才能操作。Stripe測出的基準相當驚人：單筆交易平均消耗180萬個token、呼叫工具38.83次、耗時超過2.5分鐘。
這些代理要應付的，是一個服務780萬家商家、經手約占全球GDP0.45%交易額的Checkout介面，Muse、Instinct、Grokbot等產品都已經在用瀏覽器代理嘗試下單。這正是Stripe決定改採WebMCP的出發點。
核心改動：WebMCP與漸進式工具揭露
WebMCP是一項仍在提案階段的瀏覽器技術，讓網站能在客戶端把功能包裝成結構化的MCP（Model Context Protocol）工具直接暴露給代理呼叫，而不必再靠代理自行解讀畫面。相關討論放在GitHub的webmachinelearning/webmcp專案，Chrome從149版起以origin trial方式提供實驗支援。Stripe把它疊加在既有的Checkout UI之上，商家端不需要任何整合異動就能受益。
Stripe設計了兩種工具型態：命令式（imperative）工具如get_order_summary、select_payment_method、submit_payment，用來讀取狀態或觸發流程轉換；另一種是宣告式工具，直接從已渲染的HTML表單衍生欄位，新增欄位時不必手動維護。更關鍵的是「漸進式工具揭露」，代理在每個結帳階段只看得到當下適用的工具：
- 先呼叫工具檢視訂單摘要與可用付款方式；
- 選定付款方式後，才會出現只含相關欄位的填表工具；
- 表單填完後，submit_payment才會被揭露。
Stripe以60組測試、橫跨六種模型、以50比50比例對照WebMCP與原本做法，結果顯示token消耗減少42%、工具呼叫次數減少38%、完成時間快了39%，執行時間縮短了60秒。
影響範圍：商家、支付工程師與消費者授權要注意什麼
對於想讓自家Checkout被代理下單的商家來說，最大利多是不需要更動既有整合，因為WebMCP是疊加在Stripe既有Checkout UI之上運作。支付整合工程師則要留意宣告式工具依賴表單欄位命名與結構是否穩定，一旦頁面大幅改版，衍生出的工具定義也可能跟著跑掉，這與過去DOM爬蟲會遇到的維護問題本質上仍然相似，只是換了一層抽象。
文章本身並未著墨明確的用戶授權或風控機制，只提到漸進式工具揭露會把代理在任一時間點能呼叫的操作，限制在當前結帳步驟所需的最小集合。換句話說，安全邊界目前是靠「能看到的工具變少」來實現，而不是額外的支付前確認流程。這對於評估代理購物風險的商家與工程團隊而言，會是接下來要持續追蹤的落差。
原始來源：Stripe Dot Dev Blog