> ## Content Index
> Fetch the complete content index at: https://growthhackers.tw/llms.txt
> Use this file to discover other available public pages before exploring further.

# 我玩了一輪 Shopify 的 UCP Playground：同一雙鞋、同一個商品 ID，換個國家查，賣家跟價格整個變了
- URL: https://growthhackers.tw/blog/ucp-new-shopify-commerce-protocol-playground/
- Published: 2026-08-26T06:55:36.000Z
- Updated: 2026-08-26T06:55:36.000Z
- Description: 同一個商品 ID，換個國家查，賣家跟價格整個換掉。我把 Shopify 剛推出的 UCP Playground 玩了一輪，把這背後的 MCP 協定拆給你看。
- Author: Lewis wang
- Tags: Universal Commerce Protocol, agentic commerce, Shopify, AI Agent, 電商趨勢

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

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

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

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

UCP，全名 Universal Commerce Protocol（通用商業協議），是 Shopify 推出的一套讓 AI agent（人工智慧代理）查詢商品目錄、下單購物的開放協定。我今年 5 月就寫過一篇 [Shopify UCP-CLI 解碼文](https://growthhackers.tw/blog/shopify-ucp-cli-agent-commerce/)，講的是 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++ 自己寫商品搜尋引擎」](https://growthhackers.tw/blog/shopify-catalog-product-search-engine/)是同一條線的後續發展：底層先把商品搜尋做成一套夠快、夠準的引擎，接下來就是把這套引擎包一層協定，讓 AI agent 能直接呼叫。

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

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

![實際截圖：UCP 的除錯面板攤開了每一次工具呼叫 get_product、search_catalog，連 MCP endpoint、狀態碼、耗時都秀給你看](https://growthhackers.tw/content/images/2026/08/inline-mcp-debug-v1-2.png)

實際截圖：UCP 的除錯面板攤開了每一次工具呼叫 get\_product、search\_catalog，連 MCP endpoint、狀態碼、耗時都秀給你看

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

搜尋列上有三個切換頁籤：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」的視覺化設計，把「加了一句話描述顧客之後，結果差在哪」講得比任何一份技術文件都清楚。如果你是做電商後台、做搜尋排序邏輯的產品經理，這個畫面值得你截圖存起來當範例。

![實際截圖：加了買家意圖前後的搜尋結果 Diff 對比，跟文中數字一致：1 added / 1 removed / 6 moved](https://growthhackers.tw/content/images/2026/08/inline-intent-diff-v1-2.png)

實際截圖：加了買家意圖前後的搜尋結果 Diff 對比，跟文中數字一致：1 added / 1 removed / 6 moved

## 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 挑中，不是看你「有沒有上架」，是看你在「那個買家所在的市場」裡，是不是排得進去的那一個選項。

![實際截圖：同一個商品 ID，Taiwan 情境查到 Lovell Sports，United States 情境查到 ShopSimon，US$24.00](https://growthhackers.tw/content/images/2026/08/inline-region-routing-v1-1.png)

實際截圖：同一個商品 ID，Taiwan 情境查到 Lovell Sports，United States 情境查到 ShopSimon，US$24.00

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

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

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

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

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

![實際截圖：UCP 的購物車是聯邦制，2 items、2 shops，結帳仍要分別走進每個商家自己的櫃檯](https://growthhackers.tw/content/images/2026/08/inline-federated-checkout-v1-2.png)

實際截圖：UCP 的購物車是聯邦制，2 items、2 shops，結帳仍要分別走進每個商家自己的櫃檯

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

寫到這裡我以為測得差不多了，結果左側欄有一個一直沒點開的「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 值得你花兩分鐘，拿自己的網域測一次，看看你的商店目前公開了哪些能力、又漏掉了哪些。

![實際截圖：Negotiation Explorer 實測真實品牌 allbirds.com，協商出 4 active、5 excluded，其中 checkout 也在 active 清單裡](https://growthhackers.tw/content/images/2026/08/inline-negotiation-explorer-v1.png)

實際截圖：Negotiation Explorer 實測真實品牌 allbirds.com，協商出 4 active、5 excluded，其中 checkout 也在 active 清單裡

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

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

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

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（訂房、多種房價方案、付款排程）。如果這條路走得通，過陣子你訂餐廳、訂飯店，背後可能也是同一套協定在跑。

![實際截圖：ucp.dev 官方文件站的 UCP and AP2 頁面，以及 GitHub 上獨立組織 Universal-Commerce-Protocol/ucp 的 repo 頁面](https://growthhackers.tw/content/images/2026/08/inline-ucp-dev-governance-v1.png)

實際截圖：ucp.dev 官方文件站的 UCP and AP2 頁面，以及 GitHub 上獨立組織 Universal-Commerce-Protocol/ucp 的 repo 頁面

## 老實講幾個粗糙的地方

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

► 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](https://ucp.dev/?ref=growthhackers.tw) 讀 Specification 分頁，比在 playground 裡連猜帶測快得多。

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

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

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

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

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

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

---

**協作聲明與免責**

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

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