當電商有了自己的 DNS：UCP 技術架構的產業史觀

1983 年，Paul Mockapetris 發明了 DNS。在此之前，網際網路上的每台電腦都需要維護一份 hosts 檔案，手動記錄 IP 位址與主機名稱的對應關係。這套系統在網路規模小的時候運作良好，但隨著節點數量增長，N x N 的維護成本讓整個體系瀕臨崩潰。

DNS 的解決方案看似簡單，就是建立一套去中心化的階層式命名系統，讓任何人都能透過標準化的查詢協議找到任何主機。這個設計決策的影響遠超過技術層面。它讓網際網路從一個需要人工協調的封閉網路，轉變為一個可以無限擴展的開放平台。沒有 DNS，就不會有後來的 World Wide Web，也不會有建立在其上的數位經濟。

2026 年 1 月，Google 發布了 Universal Commerce Protocol（UCP）。當我第一次讀到這份技術規格時，腦中浮現的就是 DNS 的故事。這個協議正在嘗試對電子商務做同樣的事。

從 N x N 到單一整合點

理解 UCP 的技術意義，需要先理解當前代理商務面臨的困境。當 ChatGPT、Gemini、Claude 等 AI 助理開始具備購物能力，每個商家都面臨一個棘手的問題，那就是要讓 AI 代理能夠在你的商店購物，你需要為每一個 AI 平台建立獨立的整合。

這正是 1980 年代 hosts 檔案的困境重現。如果有 100 個 AI 平台和 10,000 個商家，理論上需要建立 100 萬個獨立的整合關係。這種 N x N 的複雜度不僅在技術上不可行，更會在商業上形成嚴重的不對稱。只有大型零售商有資源完成這些整合，中小商家將被排除在 AI 電商的浪潮之外。

UCP 的核心設計正是要打破這個瓶頸。商家只需要在自己的網站上發布一個標準化的端點（/.well-known/ucp），任何遵循 UCP 協議的 AI 代理都能自動發現這個商家的能力、商品、支付方式。這與 DNS 的 /.well-known/ 機制如出一轍，也與 OAuth 的發現文件、OpenID Connect 的 configuration endpoint 遵循相同的設計哲學。

從技術史的角度來看，這類「去中心化發現機制」往往是產業轉折的關鍵。HTTP 讓任何人都能發布內容，DNS 讓任何人都能被找到，OAuth 讓任何人都能授權第三方應用。每一次，看似純粹的技術決策都重新定義了價值鏈上的權力分配。

支付的四方模式與歷史的迴響

UCP 在支付架構上的設計同樣值得深究。協議將「消費者使用的支付工具」（Instruments）與「支付處理商」（Payment Handlers）明確分離，這個看似技術性的決策，其實是對過去三十年支付產業演進的深刻回應。

1990 年代，信用卡產業經歷了一場結構性變革。Visa 和 Mastercard 從銀行聯盟轉型為獨立的網路營運商，確立了後來被稱為「四方模式」的產業結構，由發卡行、收單行、卡組織、商家各司其職。這個結構的核心洞見是，將「誰發行支付工具」與「誰處理交易」分開，可以讓整個系統更具彈性，也能促進各層級的競爭。

UCP 的 Instruments 與 Handlers 分離，正是將這個邏輯帶入 AI 代理商務的時代。在 UCP 的架構下，消費者可以使用 Google Pay、Shop Pay 或任何其他支付工具，而商家可以選擇 Stripe、Adyen 或其他處理商來完成交易。支付工具與處理商之間不存在綁定關係。

這對現有的支付巨頭意味著什麼？我注意到一個有趣的現象。Stripe 在 OpenAI 的 ACP 中享有近乎獨佔的地位，因為 ACP 的設計本質上將結帳流程與 Stripe 的基礎設施綁定。但在 UCP 的世界裡，Stripe 只是眾多 Payment Handlers 之一。這解釋了為什麼 Stripe 同時出現在 ACP 和 UCP 兩個陣營的合作夥伴名單上，它無法承擔被排除在任何一個標準之外的風險。這種「兩邊押注」的策略，本身就說明了這場標準之爭的重要性。

從商家的角度來看，支付處理商的競爭意味著議價能力的提升。當切換成本降低，手續費率就有了下降的空間。這與 1990 年代四方模式確立後，商家獲得更多支付選擇的歷史如出一轍。

模組化的賭注，從 EDI 到 Capabilities

UCP 的 Capabilities 與 Extensions 架構是另一個值得關注的技術決策。協議將電商功能拆解為可組合的模組。結帳（checkout）是核心能力，折扣（discount）和履約（fulfillment）則是擴展這個核心的延伸模組。商家可以選擇性地開放這些能力，AI 代理則能動態發現哪些功能可用。

這種模組化設計讓人想起 1970 年代的 EDI（Electronic Data Interchange）。EDI 試圖標準化企業間的電子文件交換，定義了訂單、發票、運輸通知等文件格式。它的成功與失敗都值得借鑒。EDI 確實成為大型企業供應鏈的基礎設施，但它的複雜性和實施成本也讓中小企業望而卻步。

UCP 的設計者顯然意識到了這個教訓。Capabilities 架構的核心是「漸進式採用」。商家可以從最基本的結帳能力開始，隨著需求增長再逐步開放折扣、履約、會員綁定等進階功能。這降低了進入門檻，讓不同規模的商家都能以適合自己的節奏加入。

更重要的是，Extensions 機制為協議的未來演進預留了空間。當 UCP 從購物擴展到旅遊預訂、餐廳訂位、專業服務時，核心協議不需要修改，只需要定義新的 Capabilities 和 Extensions。這與 HTTP 的設計哲學一致，核心協議保持精簡穩定，新功能透過擴展機制實現。

Merchant of Record 與權力的歸屬

在所有技術細節中，「Merchant of Record」（交易記錄商家）的設計最直接地觸及商業權力的核心問題。

過去十年，Amazon Marketplace 模式成為電商平台的主流範式。在這個模式下，第三方賣家在 Amazon 的平台上銷售商品，但交易記錄往往歸屬於 Amazon。消費者認知的是「在 Amazon 買東西」，而不是「向某個品牌購買」。這讓平台獲得了對消費者關係的控制權，也讓賣家逐漸淪為可替換的供應商。

UCP 在技術規格中明確保障商家的 Merchant of Record 身份。這意味著即使消費者透過 Gemini 或其他 AI 代理完成購買，交易記錄仍然歸屬於商家。消費者的會員積分、購買歷史、售後服務都由商家直接處理，AI 代理只是促成交易的中介。

這個設計選擇的商業意涵非常深遠。它確保了品牌商家不會被「去中間化」，不會淪為 AI 平台的白牌供應商。這也解釋了為什麼 Shopify、Target、Walmart 這些重視品牌自主性的零售商會積極參與 UCP 的制定，因為這個協議在技術層面保障了他們的商業利益。

與此相對，OpenAI 和 Stripe 主導的 ACP 更接近平台中心化的模式。ACP 的設計優化的是在 ChatGPT 內完成交易的流暢度，商家在這個流程中的角色相對被動。這並不意味著 ACP 是「壞的」設計，而是反映了不同的商業目標。OpenAI 希望 ChatGPT 成為購物的主要入口，就像 Amazon 希望消費者在自己的平台上完成所有購物一樣。

Web3 的未竟之業

談到消費者資料所有權與去中心化電商架構，我突然想起 2022 至 2023 年間曾經掀起熱潮的 token-gated commerce。

那是 NFT 與 Web3 概念最狂熱的時期，我當時也密切關注這個領域的發展。支持者描繪了一幅美好願景，消費者透過區塊鏈錢包持有特定代幣或 NFT，就能獲得品牌專屬商店的存取權限。這些代幣不僅是會員資格的證明，更代表了消費者對自身資料的所有權。品牌可以直接與持有代幣的消費者互動，不需要透過 Facebook 或 Google 這類中介平台。消費者的購買歷史、偏好資料都儲存在區塊鏈上，由消費者自己掌控，可以選擇性地分享給不同品牌。

這個願景與 UCP 試圖解決的問題有驚人的相似之處。兩者都在挑戰平台對消費者關係的壟斷，都試圖建立更開放的電商基礎設施，都強調讓商家能夠直接觸及消費者。2022 年上半年，麥肯錫報告指出超過 1,200 億美元的投資湧入 Web3 相關技術。Shopify 推出了 token-gating 功能，讓商家可以為 NFT 持有者創建專屬商品頁面。Walmart 的創新育成部門 Store No8 甚至在 2023 年與 Outlier Ventures 合作推出了去中心化商務加速器計畫。

然而，token-gated commerce 從未跨越鴻溝進入主流市場。

問題出在實施路徑。Web3 要求消費者先完成一系列複雜的前置作業才能參與。首先要安裝加密錢包，然後購買加密貨幣，接著取得特定的 NFT 或代幣，最後才能享受專屬購物體驗。每一個步驟都會流失大量潛在用戶。對於習慣一鍵結帳的消費者來說，這種摩擦成本完全無法接受。

更根本的問題在於，Web3 試圖用全新的基礎設施取代現有系統，而不是與之相容。區塊鏈錢包無法直接連結銀行帳戶，NFT 的法律地位模糊不清，代幣價格的劇烈波動讓它難以成為穩定的商業基礎。我常用一個比喻來形容這種困境，這就像是要求所有人先學會開飛機，才能享受更快的交通方式。

UCP 選擇了完全不同的路徑。它不要求消費者改變任何行為。消費者繼續使用 Google Pay 或 Apple Pay，繼續透過 Gemini 或 ChatGPT 購物，完全不需要知道底層有一個叫做 UCP 的協議在運作。所有的整合複雜度都留在 B2B 端，由商家和支付處理商來處理。這正是 HTTP 成功的原因。普通用戶從不需要理解 TCP/IP 的運作原理，他們只需要點擊連結就能瀏覽網頁。

從 Web3 的經驗中可以提煉出一個關鍵洞見。成功的基礎設施協議往往是「隱形」的，它們在背後默默運作，讓使用者毫無感知地享受其帶來的好處。DNS 是隱形的，OAuth 是隱形的，信用卡網路的四方模式也是隱形的。消費者不需要知道這些技術如何運作，只需要知道「輸入網址就能找到網站」、「點擊 Google 登入就能授權」、「刷卡就能付款」。

UCP 的設計哲學顯然吸取了這個教訓。它沒有要求建立新的消費者行為，而是為現有行為提供更好的底層支援。這讓它比 token-gated commerce 有更高的採用機率。

當然，這並不意味著 Web3 的願景全然落空。區塊鏈在供應鏈追溯、數位資產確權等 B2B 場景中仍在持續發展。而 UCP 對「cryptographic proof of user consent」的要求，某種程度上也呼應了區塊鏈對可驗證性的追求。只是在消費者端，漸進式的改良永遠比革命性的顛覆更容易被接受。

加密證明與信任的技術基礎

UCP 要求每筆交易都附帶「cryptographic proof of user consent」（用戶同意的加密證明）。這個看似技術性的要求，其實是在為 AI 代理商務建立信任基礎。

當 AI 代理代替用戶進行購物決策，一個根本性的問題浮現。如何證明這筆交易確實經過用戶授權？傳統電商中，用戶親自點擊「購買」按鈕就是授權的證明。但在代理商務中，用戶可能只是說了一句「幫我買一雙跑鞋」，具體的商品選擇、價格確認、支付執行都由 AI 代理完成。

加密證明機制解決的是事後爭議的問題。當消費者聲稱「我沒有授權這筆交易」時，商家和支付處理商需要有技術手段來證明授權確實存在。這不僅降低了詐欺風險，也為監管機構提供了可審計的交易記錄。

從更宏觀的角度來看，這個設計選擇反映了一個產業正在從「假設用戶在場」轉向「假設代理在場」的典範轉移。OAuth 解決了「如何讓第三方應用代表用戶行動」的問題，UCP 的加密證明機制則是在解決「如何讓 AI 代理代表用戶交易」的問題。技術問題的本質是相同的，只是行動者從應用程式變成了 AI 代理。

標準戰爭的歷史教訓

UCP 與 ACP 的競爭，讓人想起過去幾十年的諸多標準戰爭。VHS 與 Betamax、Blu-ray 與 HD-DVD、USB 與 FireWire，這些案例提供了一些值得參考的模式。

首先，技術優越性往往不是決定勝負的關鍵。Betamax 在畫質上優於 VHS，但 VHS 更長的錄影時間和更開放的授權策略讓它贏得了市場。在 UCP 與 ACP 的競爭中，UCP 的技術設計更加完整和開放，但 ACP 的簡單易用（已有 Stripe 的商家只需一行程式碼）可能在早期採用階段更具吸引力。

其次，生態系統的廣度往往比深度更重要。USB 擊敗 FireWire 的關鍵不在於傳輸速度，而在於 USB 獲得了更廣泛的裝置支援。UCP 目前擁有超過 20 家合作夥伴，涵蓋零售商、支付處理商、信用卡組織，這種生態系統的廣度是 ACP 目前缺乏的。

最後，標準戰爭的結果往往不是「贏家通吃」，而是「各有所長」的共存。TCP/IP 與 OSI 模型的競爭最終以 TCP/IP 主導網際網路、OSI 概念模型被廣泛教學的方式共存。UCP 與 ACP 很可能也會走向類似的結局，兩者服務不同的 AI 平台，商家同時支援兩個協議以最大化消費者觸及。

從規格到實作的距離

談完歷史類比與設計哲學，一個務實的問題浮現。UCP 目前究竟走到哪裡了？

我花了一些時間研究 GitHub 上的官方 repository。坦白說，UCP 仍處於非常早期的階段。主分支僅有約十個 commits，這意味著協議規格剛剛公開，距離大規模商業部署還有一段路要走。不過，這個早期階段恰恰是觀察協議走向的最佳時機，因為設計決策尚未固化，生態系參與者仍有機會影響協議的演進方向。

技術實作層面，UCP 採用 transport agnostic 的設計，同時支援 REST API、MCP（Model Context Protocol）與 A2A（Agent-to-Agent）三種傳輸方式。這個選擇反映了務實的整合策略。已有 REST 基礎設施的商家可以快速接入，而原生支援 AI 代理通訊的新創企業則能直接採用 MCP 或 A2A。官方已釋出 Python 與 TypeScript SDK，並提供 Playground 環境供開發者測試。

生態系的廣度是 UCP 目前最明顯的優勢。共同開發者包括 Google、Shopify、Etsy、Wayfair、Target、Walmart 這些零售巨頭。支付領域的參與者同樣陣容堅強，Adyen、American Express、Mastercard、PayPal、Stripe、Visa、Worldpay 都在合作名單上。零售商端則有 Best Buy、Carrefour、Kroger、Lowe's、Macy's、Sephora、The Home Depot、Zalando 等橫跨北美與歐洲的主要業者。這種跨產業、跨地區的聯盟規模，在開放協議的早期階段相當罕見。

官方 roadmap 透露了協議的發展方向。短期內，UCP 將專注於購物場景的完善。中期目標是擴展至旅遊預訂與專業服務等新垂直領域。長期願景則包括標準化的會員忠誠計畫管理，以及更細緻的個人化信號傳遞機制。這個演進路徑與前述的 Capabilities 和 Extensions 架構相呼應，核心協議保持穩定，新功能透過擴展模組逐步加入。

如果你問我現階段該怎麼做，我的建議是「關注但不急於行動」。協議規格仍在快速演進，過早的深度整合可能需要在未來進行大幅調整。然而，這也是影響協議方向的最佳視窗。參與 GitHub 討論、提交使用情境回饋、甚至貢獻程式碼，都能讓企業在標準制定過程中發出自己的聲音。

協議決定權力

回顧這些技術細節，我越來越相信一件事。每一代技術基礎設施的建立，都會重新分配產業價值鏈上的權力。HTTP 讓內容創作者擺脫了傳統媒體的守門人，OAuth 讓應用開發者能夠存取用戶資料而不需要獲取密碼，信用卡四方模式讓商家獲得了支付選擇權。

UCP 的技術設計，無論是去中心化發現、支付分離、模組化能力、還是 Merchant of Record 保障，都指向同一個方向，就是確保商家在 AI 代理商務時代不會失去對顧客關係的控制。這與 ACP 將流量和交易集中到 ChatGPT 的設計形成鮮明對比。

我想對正在評估代理商務策略的企業說，技術細節的重要性往往被低估。協議的設計決策會在未來數年持續影響商業模式的可行性、議價能力的強弱、以及與平台關係的主動與被動。理解這些技術選擇背後的商業意涵，是在這個新時代保持競爭力的關鍵。

四十年前，很少有人預見 DNS 這個「只是讓電腦更容易被找到」的技術，會成為數位經濟的基礎設施。今天，UCP 的 /.well-known/ucp 端點看起來也只是一個技術細節。但我相信，正是這些看似細微的設計決策，將決定誰能在 AI 代理商務的時代掌握主動權。

---

本文基於 Google Developers Blog 技術文件、UCP 官方 GitHub repository 及公開資料撰寫。