我玩了一輪 Shopify 的 UCP Playground：同一雙鞋、同一個商品 ID，換個國家查，賣家跟價格整個變了

同一個商品 ID，我在「台灣」情境下查到的是 Lovell Sports，開價 $621 起，切到「美國」情境，同一個 ID 變成 ShopSimon，只賣 US$24。

不是換算匯率，是整家店都換了。

這是我這幾天把 Shopify 剛推出的互動測試場 ucp.new 從頭玩到尾之後，覺得最值得寫下來的一件事。如果你對「UCP」「agentic commerce（代理式商務）」這些名詞已經有點麻木，覺得又是一堆廠商發的公關術語，這篇文章我想帶你實際打開、實際點、實際看它背後打了什麼 API，用眼見為憑的方式，告訴你這件事到底離你的生意有多近。

你可能聽過 UCP，但你有實際玩過嗎？

UCP，全名 Universal Commerce Protocol（通用商業協議），是 Shopify 推出的一套讓 AI agent（人工智慧代理）查詢商品目錄、下單購物的開放協定。我今年 5 月就寫過一篇 Shopify UCP-CLI 解碼文，講的是 Shopify 釋出的命令列工具（CLI）版本。

問題是，CLI 這種東西對大部分做行銷、做電商的人來說，門檻高到你根本不會想去碰。

你知道為什麼嗎？因為你打開終端機（terminal）的那一刻，就已經先被嚇跑了。

ucp.new 不一樣，它是一個網頁版的互動 playground（遊樂場，這裡指可以直接動手玩的測試介面），左邊是聊天式的搜尋輸入框，右邊是結果卡片，長得像是一個電商比價網站。但它骨子裡，每一次你按下 Enter，背後都是真槍實彈打一次 UCP 協定的 API。

我花了一個晚上，把它能點的按鈕全部點過一輪。這篇文章就是我實際測完之後的紀錄。

先講重點：這個玩具，骨子裡是什麼？

切入重點，我先把最技術的部分講完，你就懂後面所有現象是怎麼來的。

我隨便搜尋「running shoes」，點開一張商品卡，發現除了正常的商品頁面，還藏了一個「JSON」分頁，直接秀出這筆商品最原始的資料結構。裡面有一行：

"id": "gid://shopify/p/24psqxAtEU062iBkZSC9wF"

gid://shopify/... 這個格式，就是 Shopify 內部商品識別碼的寫法。這代表 UCP 底層直接就是 Shopify 自家的商品目錄服務，不是另外重新做一套資料庫。

再往下點「Inspect」，會跳出一個 Debug（除錯）面板，把這次查詢的細節攤開給你看：

• Tool：get_product
• MCP endpoint：https://catalog.shopify.com/api/ucp/mcp
• Via worker：POST /lookup
• 還有 Status、耗時（1023 毫秒）、Response size（3 KB），甚至直接附上一行可以複製貼上的 curl 指令，讓你原地重現這次呼叫

MCP，是 Model Context Protocol（模型情境協定）的縮寫，最初是 Anthropic 推出的一套標準，讓 AI 模型可以透過統一的方式呼叫外部工具。這裡看到的畫面，證實了 UCP 的實作方式：Shopify 把自己的商品目錄，包成 get_product、search_catalog 這幾支 MCP 工具，讓任何支援 MCP 的 AI agent 都能直接呼叫。

這件事跟我之前寫過的「Shopify 為什麼用 C++ 自己寫商品搜尋引擎」是同一條線的後續發展：底層先把商品搜尋做成一套夠快、夠準的引擎，接下來就是把這套引擎包一層協定，讓 AI agent 能直接呼叫。

這就像從只有店員知道倉庫在哪一格，進化到每個貨架都貼了條碼，掃描機隨便拿起來都能讀。

我自己這幾年在做網路行銷，看過太多廠商講「我們有開放 API」，結果打開文件才發現參數對不上、範例是壞的。ucp.new 這個 Debug 面板，是我第一次在一個「面向行銷人」的產品裡，看到把技術細節攤這麼開的做法，連耗時毫秒數都給你看。

三種搜尋模式，我都實際打了一輪

搜尋列上有三個切換頁籤：Text、Similar、Lookup，我一個一個測。

Text（文字搜尋）：就是打關鍵字，例如「running shoes」，回傳「8 of 349 products」，代表這個關鍵字底層真的匹配到 349 筆商品，不是隨便湊出來的假資料。結果裡混著 Born Primitive、NOBULL、Lovell Sports、Pro:Direct Sport、Tracksmith 這些真實品牌與通路。

有一個小地方我要老實講：同一份結果裡，幣別符號完全沒有統一，有的顯示 $4,777.00，有的是 US$152.83，有的是 £58.33。這其實反過來證明了一件事，這批資料是直接彙整自各國真實商店的原始資料，不是廠商為了 demo 特地整理過的乾淨假資料。

Similar（相似商品）：這個模式不讓你打關鍵字，而是要你貼一組 gid://shopify/p/... 的商品 ID，意思是「幫我找長得像這個的東西」。我拿剛剛那雙 adidas Women Galaxy 7 Running Shoes 的 ID 去測，回傳的 8 筆結果，全部都是「Galaxy 7」這一款在不同國家、不同通路的上架版本：英國 Start Fitness、巴基斯坦 Brands.PK（用巴基斯坦盧比計價）、加拿大 Winnipeg Outfitters……語意比對抓得相當精準，不是隨便湊幾雙運動鞋充數。

Lookup（精準查詢）：一樣要貼商品 ID 或 lookupUrl，但這次回傳的不是一份清單，是「單一」一筆商品，對應到我前面講的 get_product 工具最原始的用法。

三種模式背後，其實就是同一套 MCP 工具集的三種呼叫方式：模糊找（search_catalog）、找相似（也是 search_catalog，只是換了輸入）、精準抓（get_product）。

Intent（買家意圖）加上 Diff 對比，是我覺得最驚豔的一個設計

搜尋列右邊還有一個「Intent」按鈕，點開會多一個輸入框，placeholder 寫著「Buyer intent, e.g. 'Customer runs marathons'」。

這就是 agentic commerce 最核心的概念：AI agent 幫你買東西的時候，不是只丟一個關鍵字，而是把「這個顧客是誰、想要什麼」也一起傳給後端。

我實測的做法是：關鍵字一樣打「running shoes」，Intent 欄位填「Customer runs marathons and wants a lightweight breathable shoe」（顧客跑馬拉松，想要一雙輕量透氣的鞋）。

結果出來之後，介面多了一個「Diff（差異對比）」分頁，直接列出跟純關鍵字搜尋比起來差在哪：1 個新增、1 個移除、6 個排名有變動、1 個沒動，每一筆都標出從第幾名移到第幾名，例如 Men's Allday 365 從第 3 名升到第 2 名。

老實說，我原本以為加了意圖之後結果會整個大洗牌，實際看到的變化幅度是溫和的微調，原本排第一的 Born Primitive 重訓鞋（其實一點都不像馬拉松鞋）依然穩坐第一。這代表 Intent 對排序有影響，但不是唯一決定因素。

重點是什麼？ 這個「Diff」的視覺化設計，把「加了一句話描述顧客之後，結果差在哪」講得比任何一份技術文件都清楚。如果你是做電商後台、做搜尋排序邏輯的產品經理，這個畫面值得你截圖存起來當範例。

Filters 面板：連篩選條件都能直接改 JSON

點開 Filters，會看到一個很正常的篩選面板：價格區間（有快速選取的 chip，像是 <25、<50、100-250）、庫存狀態、顏色色票、運送地區。

但它多了一個「JSON」分頁，讓你直接手動編輯篩選條件的原始物件，狀態列會即時顯示「Valid · applied（有效並已套用）」。這代表整個篩選功能背後就是一組結構化的 filter payload（篩選參數物件），視覺化面板只是幫你組出這個物件的其中一種方式。

我注意到裡面有一個欄位叫 includeSecondhand（是否納入二手商品），代表這個目錄很可能不只收全新品，二手/轉售商品也在同一套搜尋範圍裡。

真正的重頭戲：切換國家，換的不是匯率，是整家店

這一段，是我今天想寫這篇文章最主要的動機。

我點開右上角的地區設定，跳出一個「Search context（搜尋情境）」面板，裡面有三個獨立欄位：Country（國家）、Currency（幣別）、Language（語言）。這三個欄位，跟我前面在 Debug 面板看到的 request 參數 addressCountry、currency、language 完全對得上。也就是說，你在畫面上調的每一個選項，都是原封不動傳進 MCP 工具的參數，不是介面上的裝飾。

我做了一個很簡單的實驗：用同一組商品 ID，先在「Taiwan」情境下查一次，再切成「United States」情境查第二次。

• Taiwan 情境：Lovell Sports，約 $621
• United States 情境：ShopSimon，US$24.00

同一個商品 ID，賣家換了，價格也不只是匯率轉換的差距，是完全不同的一筆上架資訊。

想像一下，你以前經營一個跨國電商網站，通常做法是同一個商品頁面，後台放一個匯率換算表，顧客選哪個國家，畫面上的數字就照匯率跳一次，賣家還是你自己。

現在 UCP 做的事情不一樣。它比較像是你走進一間百貨公司，問專櫃小姐「這款包在哪裡買」，她告訴你的答案，會因為你說自己是台北人還是紐約客而完全不同，因為背後真正在賣這款包的，可能是兩家完全不同的代理商。

我以前在百貨公司專櫃打滾過幾年，同一個品牌、同一款商品，南部館跟北部館的代理進貨管道不一樣、活動檔期不一樣，價格跟現場能不能買到，本來就常常對不上。UCP 這個「地區決定賣家」的設計，讓我一看就有既視感，只是它把這件事從人腦裡的默契，變成一行明確寫在 API 參數裡的規則。

以前你上架一個商品，全世界看到的都是同一個頁面、同一個價格。 現在同一個商品 ID，AI agent 幫你在不同國家找到的，可能是完全不同的賣家、完全不同的價格。

如果你是做跨境電商的，這件事你要放在心上：你的商品能不能被 AI agent 挑中，不是看你「有沒有上架」，是看你在「那個買家所在的市場」裡，是不是排得進去的那一個選項。

購物車是「聯邦制」，不是「大同盟」

加入購物車之後，我發現購物車面板是依商家分組的，例如「Born Primitive · 1 item」自成一組，底下是「Checkout at Born Primitive」的按鈕。

換句話說，UCP 統一的是「幫你探索商品、幫你組出一份購物清單」這個階段，結帳這一步，還是要分別跳回各家原始商店去付款。

這一點跟 Google 想解決的問題不一樣。我之前寫過 Google Universal Cart，它想做的是跨站的單一結帳，把 Nike、Sephora、Target 這些不同商家的商品放進同一個購物車一次付清。UCP 現階段還沒走到那一步，它先解決的是「找得到、找得準」，結帳這塊，還是各憑本事。

這就像從只能一家一家逛街，進化到有一個總管幫你把想買的東西列成清單，但真的要付錢，還是得走進每一家店的收銀台。

側邊欄藏了兩個開發者工具，其中一個我直接拿真實品牌測了一次

寫到這裡我以為測得差不多了，結果左側欄有一個一直沒點開的「Browse all tools」，點進去才發現裡面還有兩個子工具，這兩個工具，直接把我前面一段「結帳還是各憑本事」的判斷推翻了一半。

Permalink Generator（連結產生器）：讓你把商家端點、商品 ID、數量、折扣碼、國家、語言這些欄位，打包組成一條「UCP 購物意圖連結」，而且會即時算這條連結塞進 QR code、簡訊、Email 三種通路，各自的位元組上限用掉多少。頁面講得很清楚：「Local format validation for the UCP draft. The merchant endpoint is not contacted.」，這個工具不會真的打商家 API，純粹是本地格式驗證。

Negotiation Explorer（協商探索器）：這個更狠，直接讓你輸入任何一個商家網域，去查它有沒有公開自己的 UCP 能力清單。我沒有隨便打個假網址，直接測了 allbirds.com，一個大家應該都聽過的鞋類品牌。

結果馬上跳出來：「Negotiated 4 capabilities on protocol v2026-04-08」。

背後的機制，是去抓 https://allbirds.com/.well-known/ucp 這個路徑，跟 security.txt、robots.txt 走的是同一套「.well-known」業界慣例。畫面上還畫了一條五步驟的協商流程：Discover → Select version → Intersect → Resolve → Activate。

4 個生效的能力，全部是中立命名空間 dev.ucp.*：

• dev.ucp.shopping.cart
• dev.ucp.shopping.catalog.lookup
• dev.ucp.shopping.catalog.search
• dev.ucp.shopping.checkout

你看到最後一個了嗎？

我前面才寫「UCP 現階段先解決找得到、找得準，結帳這塊還是各憑本事」，但 allbirds.com 公開的能力清單裡，白紙黑字掛著 checkout。同時被排除掉的兩個能力，命名空間換成了 dev.shopify.*（dev.shopify.catalog、dev.shopify.catalog.global），標籤寫著「business only」「platform only」，意思是只有單邊（只有商家或只有平台）宣告支援，沒有湊成雙邊交集，協商後就進不了生效清單。

不是我說，這段要老實修正一下我自己前面的判斷：UCP 這套協定規格本身，是有定義結帳能力的，只是 ucp.new 這個 playground 的示範介面，選擇用「導回商家自己網站結帳」這種簡化呈現，不代表協定做不到，也不代表每個商家都真的把 checkout 這個能力打開。

這就像從只能站在店門口猜這家店收不收信用卡，進化到可以先問一句「你們支援哪些付款方式」，對方直接遞一張清單給你，不用走進去試了才知道。

如果你是電商經營者，這個 Negotiation Explorer 值得你花兩分鐘，拿自己的網域測一次，看看你的商店目前公開了哪些能力、又漏掉了哪些。

官方文件我後來還是找到了，藏在一個很深的角落

上一版我寫「這個 playground 沒有內嵌官方文件連結」，這句話要收回。

文件真的藏得很深：首頁不會直接連過去，要先點「Browse all tools」進子工具頁，再點進 Permalink Generator，頁尾才有一條「Read the permalink specification」，連過去是完全獨立的網域 ucp.dev。

ucp.dev 是官方文件站，大標寫著「The common language for platforms, agents, and businesses」，導覽列有 Core Concepts、Specification、UCP and AP2、Roadmap、Schema Authoring 這些分頁。

「UCP and AP2」這一頁直接寫：「UCP is fully compatible with Agent Payments Protocol (AP2)」。AP2 是 Google 推的 Agent Payments Protocol（代理支付協定），用「可驗證數位憑證」當信任層，讓商家收到的是一份簽名過、事後不能被竄改金額的結帳承諾。換句話說，UCP 跟 AP2 是互補關係，不是互相打對台的兩套協定。

GitHub repo 也查得到：Universal-Commerce-Protocol/ucp，注意這個組織名稱，不是掛在 Shopify 官方帳號底下。Apache-2.0 授權、273 次 commit、3.3k 星、448 個 fork、78 個開放中的 pull request，最新一次 release 是我測試的前一天。這是一個真的有人在維護的開源專案，不是放在那邊生灰塵的規格文件。文件站頁尾寫的也是「Copyright 2026 UCP Authors」，同樣看不到 Shopify 字樣。

如果你問我，這裡有一個很有意思的落差：對外的品牌包裝做得很中立，看起來像一個多方共治的開放標準；但我這幾天實際摸到的每一個技術端點，catalog.shopify.com、discover.shopifyapps.com，清一色都掛在 Shopify 自家網域上。以前你看一個協定，要嘛是某家公司自己關起門來做的私有規格，要嘛是掛在中立基金會底下、大家都能插一腳的開放標準。現在你看到的是：規格包裝成後者，長出血肉的實作卻是前者。

Roadmap 頁面還透露一件事：UCP 準備往電商以外的產業擴張，第一波是 Food（餐廳菜單探索、含小費與外送備註的結帳）跟 Lodging（訂房、多種房價方案、付款排程）。如果這條路走得通，過陣子你訂餐廳、訂飯店，背後可能也是同一套協定在跑。

老實講幾個粗糙的地方

不是我說，一個東西好不好用，要連缺點一起講才可信。

► Intent 標籤在切換搜尋模式時狀態不一致：從 Text 切到 Similar，Intent 標籤還黏著沒清掉；切到 Lookup，反而整個消失。這是介面狀態管理沒有做乾淨的小瑕疵。

► 官方文件連結藏得太深。首頁完全沒有導覽列可以連過去，要一路點「Browse all tools」→「Permalink generator」→ 頁尾小字，才找得到通往 ucp.dev 的路。對一個想快速搞懂協定規格的開發者來說，這個路徑太隱蔽了。

► 我第一次打開網站，購物車裡就已經有 1 件商品，左側也已經有一個舊 session 的搜尋紀錄。後來測第二輪才確認：這是瀏覽器本機狀態（localStorage）留下的痕跡，不是所有訪客共用同一份 demo 資料，重新清一次瀏覽器資料應該就會回到全新狀態。

這件事對你來說，該做什麼？

如果你是電商經營者或品牌主：

► 檢查你在 Shopify 後台的商品資料完整度。UCP 拿去餵給 agent 的欄位，包括描述、賣點、圖片，資料越完整，越有機會被 AI 挑中。

► 別再假設「上架一次，全世界看到都一樣」。如果你有跨國經銷或多個授權通路，現在要開始思考「不同市場的買家，透過 agent 查到的會是哪一個通路」。

► 去 ucp.new 自己玩一輪，親手看一次你的品類搜尋出來長什麼樣子，比看任何一篇分析文章都直接。

► 如果你自己的商店就是開在 Shopify 上，去 Negotiation Explorer（ucp.new/tools/profile-comparison）貼你自己的網域測一次，看看你已經公開了哪些 UCP 能力、又漏了哪些。

如果你是做技術、做產品的人：

► 把 Debug 面板裡那行 curl 指令複製下來，自己在終端機跑一次，比看規格書更快搞懂這個協定的請求格式長什麼樣。

► 留意 search_catalog 回傳裡的 nextCursor、hasNextPage、totalCount，這是標準的游標分頁（cursor pagination）設計，串接的時候不用自己猜格式。

► 想看協定規格全貌，直接去 ucp.dev 讀 Specification 分頁，比在 playground 裡連猜帶測快得多。

收尾：這件事已經摸得到了，不再只是概念

我 5 月寫 UCP-CLI 那篇文章的時候，這套協定還停留在命令列工具、開發者才碰得到的階段。這次 ucp.new 把它包成一個誰都能點開玩的網頁，某種程度上代表 Shopify 想讓更多非工程背景的人，親眼看到 agent 查商品的過程長什麼樣。

也許就是想讓更多品牌主看懂，也許就是想讓更多開發者願意接，也許就是想搶在其他平台前面把這套語彙定下來吧？

也可能是想把「這是一套中立的開放標準」這件事，講給更多人聽。畢竟從 GitHub 組織名稱到文件站頁尾，看得出來這個包裝是刻意做過的，只是實際能摸到的技術，目前還是長在 Shopify 自己的地盤上。

不管動機是什麼，「同一個商品 ID，換個國家查，賣家整個換掉」這件事，已經是我親手測出來的真實行為。

這年頭就是實測、實測、再實測，任何工具，你自己點過一輪，才知道它離你的生意有多近。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。