搜尋觀點
當 AI 可以落單，香港網店還要交代甚麼？UCP 與 Agentic Commerce 的交易資料清單
顧客對 AI 說：「幫我找一部可在香港使用、星期五前送到、預算不超過三千元的產品。」下一步如果不只是列出連結，而是由 AI 比較型號、確認庫存、套用優惠、選擇送貨，再請顧客核准付款，網站需要交出的就不再是一段產品文案，而是一連串可以即時執行的商業承諾。
這正是 agentic commerce 與 Universal Commerce Protocol（UCP）值得電商團隊關注的地方。Google 將 UCP 定義為代理、商户與付款服務之間的共同語言，覆蓋商品發現、購買以至售後支援。不過，Google 的 UCP checkout 現時只適用於美國、加拿大和澳洲的合資格產品及指定商户，並採分階段開放。香港商户今天不應把它包裝成已可立即接入的銷售渠道；更實際的工作，是先整理將來任何代理式購物都必須依賴的交易資料。
Universal Cart 出現後，儲存商品與成立訂單仍是兩回事
Google 在 2026 年 10 月 15 日公佈 Universal Cart 在美國推出，讓使用者集中保存不同商户商品、留意價格或庫存變化，並在支援情況下透過 Google Pay 購買，或轉到商户購物車完成交易。這不是香港全面開放的公告，也不表示把商品加入清單便已成立訂單。
把兩份官方文件放在一起看，日期與對象尤其重要：這份推出公告談的是美國使用者的 Universal Cart；Merchant Center 的 UCP checkout 說明另列美國、加拿大、澳洲的合資格產品及指定商户。購物工具的推出地區，不能取代結帳整合的商户資格。香港團隊應按自己銷售的市場、參與資格與實際整合重新核對，不把「採用 UCP」寫成一個立即可售的保證。
清單保留的是意向，不是當時價格的無限期承諾
假設顧客星期一把一個型號儲存，星期五再繼續買。期間促銷已結束，某顏色也缺貨。這是假設資料驗收情境，不是我們測過的 Universal Cart 訂單。商户需要核對的是重新進入時的商品 ID、變體、幣別、可用庫存、優惠資格與最終應付額，而不是讓舊畫面決定今天一定可履行甚麼。
| 交接時刻 | 要核對的事實 | 應保留的紀錄 |
|---|---|---|
| 儲存後再次查看 | 同一變體、價格與庫存是否改變 | 商品 ID、資料來源及查核時間 |
| 使用優惠 | 會員、最低消費、疊加與期限是否適用 | 所採用規則及失效原因 |
| 進入結帳 | 商品、數量、送貨條件及最終總額 | 顧客看到並確認的內容 |
| 收到訂單 | 是否有商户訂單編號，付款狀態是否明確 | 訂單與付款參照的對應 |
| 售後查詢 | 哪間商户處理物流、取消及退款 | 聯絡路徑、處理狀態與責任人 |
這張表是建議的商户驗收方法，不代表 Google 會向每間商户提供表中所有紀錄。實際可取得的欄位與儲存方式，要按所用平台及整合核對；不要把卡資料或不必要的個人資料複製進試算表。
多商户一起保存，不等於一間商户統一履約
官方推出說明保留了商户的訂單確認與客戶支援角色。對網店，必須讓顧客知道誰出售哪件商品、確認由誰發出、送貨與退款找誰處理；不要因為清單在同一個介面，就自行承諾合併送貨、統一退貨或相同售後條款。
若請求超時，畫面未顯示成功，也不能直接重送一次真實訂單。可在測試環境設計「先查狀態，再按支援的去重規則重試」的驗收；付款狀態不明時轉人工核對，而非猜測成功或失敗。顧客需要重新確認變體、總額或不利條件時，不能由代理替他跳過。這些是商户安全設計建議，不是聲稱已完成 Google 結帳整合。
以下原有的三本資料帳與五個反例，仍適用於這種交接。重點從未是先開一個新 endpoint，而是把商品真相、交易承諾和顧客授權接到同一套可核對的訂單流程。
一句購物要求，背後其實要查六次資料
傳統搜尋把顧客帶到產品頁，後面的比較和判斷大多由人完成。代理式商務則嘗試在對話內串起多個動作，所以一個看似簡單的要求會依次觸發六個不同問題：
- 身份是否對得上：品牌、商品、型號和變體是否有穩定識別碼，而不是三個系統各用一個名稱。
- 產品是否真的適合：規格、尺寸、相容性、使用地區和限制能否回答顧客的實際條件。
- 此刻是否可買：價格、貨幣、庫存和優惠是否仍有效，會員價或折扣有甚麼資格限制。
- 承諾能否履行：送貨地區、截單時間、運費、到貨時段、自取和缺貨替代方案是否可計算。
- 誰核准交易：顧客在甚麼畫面確認商品、總額、地址與付款，商户如何保存同意和訂單紀錄。
- 買完如何處理：訂單狀態、改單、取消、退貨、退款、保養與客服由哪個系統接手。
這六步任何一處只有宣傳語而沒有可執行規則，代理就可能在最接近成交時停下來，或者把一項根本履行不了的承諾帶給顧客。問題不在於 AI 是否夠聰明，而在於商户資料是否足以支持一宗真實交易。
UCP 解決的是系統怎樣對話，不是替網店整理錯誤資料
UCP 使用可被平台發現的能力模型。商户可以聲明自己支援哪些功能，例如 checkout、履約選項或身份連結；平台或代理先發現能力，再在協議容許的範圍內呼叫。官方技術文件亦說明，UCP 可透過 API、Agent2Agent（A2A）或 Model Context Protocol（MCP）整合，付款則可配合 Agent Payments Protocol（AP2）。
這種標準化可以減少每個 AI 平台都要另建一套商户接口的問題，但它沒有替商户決定商品規格，也不會自動修正 ERP、網站和 Merchant Center 之間的錯價。Google 明確指出，採用 UCP checkout 後，商户仍是 Merchant of Record，繼續承擔交易、財務與履約責任。換句話說，協議能搬運和協調資料，卻不會替品牌證明資料是真的。
這也解釋了為何 UCP 不等於 SEO 排名因素。產品頁仍需可抓取，頁面可見內容、Product structured data 與 Merchant Center feed 仍要一致；UCP 處理的是代理與商務後端的互操作，不是為自然搜尋提供一條捷徑。若商品基礎尚未整理，可先由 AI 購物廣告與商品資料檢查 回看產品頁、feed 和 Schema 的共同欄位。
香港網店要先建立三本帳，而不是先開發一個 UCP endpoint
第一本：商品真相帳
這本帳回答「它究竟是甚麼」。每個 SKU 或變體至少要有穩定 ID、品牌、型號、GTIN／MPN（適用時）、規格、圖片、相容性、分類和明確限制。產品頁、後台、feed 與 structured data 的主要數值需要對得上。
特別要留意把銷售形容詞改成可判斷條件。「適合專業人士」無法用來篩選；「支援哪一種插頭、作業系統、尺寸或保養地區」才是代理能拿來比對的事實。對香港跨境店，語言、電壓、插頭、保養適用地與進口版本差異通常比多加幾個關鍵字更重要。
第二本：交易承諾帳
這本帳回答「現在用甚麼條件買」。價格與庫存只是起點，還包括折扣有效期、會員資格、最低消費、配送地區、偏遠附加費、截單時間、門市自取、預計到貨、退貨窗口、退貨費和退款方式。
Google Merchant Center 對 structured data 的要求已提供一個實用底線：網站向顧客顯示的數值應與提交資料一致，退貨可以用 MerchantReturnPolicy 表達，送貨亦有對應欄位。這些標記不是為了把頁面塞滿 Schema，而是迫使團隊把原本只寫在客服話術裡的承諾變成一致規則。可使用 Schema 結構資料檢測工具 先檢查公開頁面是否真的輸出相關資料。
第三本：授權與責任帳
這本帳回答「誰準許甚麼動作發生」。一宗由代理協助的交易仍要保存顧客確認的商品、數量、總額、收貨資料和付款授權；商户亦要知道錯價、重複下單、付款失敗、缺貨和退款分別由誰處理。
對內還要界定哪些動作可全自動、哪些必須 human-in-the-loop。例如商品比較可以自動，套用一般公開優惠可以自動，但替顧客更換型號、接受預訂延誤、使用積分或確認不可退貨商品，可能仍要顧客再次核准。真正的安全邊界不是「有沒有 AI」，而是高風險動作是否有明確同意、重試規則和回滾紀錄。
用五個反例測試資料，比開一場「AI 商務」會議更有用
| 測試要求 | 系統應該查到甚麼 | 不合格的反應 |
|---|---|---|
| 「明晚前送到大嶼山」 | 配送區域、截單時間、偏遠附加費與可承諾到貨日 | 只回覆「全港送貨」，到結帳才說不適用 |
| 「可配合我已有的型號嗎？」 | 兼容清單、版本限制、所需配件與替代品 | 靠相似名稱猜測，沒有可核對規格 |
| 「會員價和優惠碼可以一起用嗎？」 | 優惠資格、疊加規則、有效日期與最終總額 | 產品頁、購物車和客服提供三個答案 |
| 「拆封後不合適可否退？」 | 產品狀態、退貨期限、退貨方法、費用與退款方式 | 只顯示「受條款約束」，沒有可執行條件 |
| 「幫我直接買兩件」 | 庫存鎖定、最終金額、地址、付款授權與訂單確認 | 沒有再次確認便更換規格或建立不可回復的訂單 |
把這五條問題分別丟給網站搜尋、客服、產品頁和後台，比對答案是否一致，就能快速找出交易資料斷點。若四個入口對同一條運送或退貨問題有四種說法，暫時不應先做代理式結帳整合。
Shopify、WooCommerce 或自建站，準備次序其實相同
不同平台的擴充方式會變，但商户資料責任不會變。SaaS 電商通常較容易保持 checkout 與庫存流程一致，自建站則可控制更多商業規則；兩者都要先確認資料來源和 owner。
| 層級 | 應指定的主要來源 | 發布前驗收 |
|---|---|---|
| 商品與變體 | 電商後台或 PIM | 產品頁、feed、Schema、搜尋結果的 ID 與規格一致 |
| 價格與庫存 | 訂單／庫存系統 | 快取、促銷切換和缺貨狀態不會輸出過期承諾 |
| 運送與退貨 | 履約政策及物流設定 | 香港地區、附加費、時效、退貨條件能被逐條計算 |
| 付款與身份 | checkout、wallet、PSP | 顧客同意、付款 token、失敗重試和重複訂單有紀錄 |
| 售後 | 訂單系統、CRM 或客服平台 | 查單、取消、退款與保養不會在交易完成後失去上下文 |
平台選擇隻影響實作成本，不會把這張責任表取消。若網店目前連分類、canonical、商品 Schema 和 Merchant Center 都未對齊，應先處理 香港電商 SEO 的基本結構，再評估更深的商務協議整合。
未來 30 日，香港商户可以完成的不是「上 UCP」，而是通過交易資料驗收
- 第 1 週，選一條真實交易路徑：只選一個主力分類和五個 SKU，由顧客問題開始，列出每一步需要的欄位與資料 owner。
- 第 2 週，對齊公開與後台資料：核對產品頁、Merchant Center、structured data、庫存、價格、運送與退貨，記錄所有不一致及更新延遲。
- 第 3 週，做例外與授權測試：測試缺貨、錯價、優惠衝突、偏遠送貨、付款失敗、取消和退款，確認每個高風險動作是否需要人工或顧客再次核准。
- 第 4 週，才評估技術整合：根據目標市場、平台支援、Google 的地區資格和商業價值，決定是繼續改善 Merchant Center，還是準備 API／UCP 能力；沒有官方資格時，不為一個未開放入口製造虛假時程。
完成這輪後，即使香港尚未開放 UCP checkout，網店也會得到可立即使用的成果：更可信的產品頁、更少 feed 錯誤、更清楚的送退承諾，以及較容易由客服、搜尋和 AI 系統一致理解的商品資料。
結論：代理式商務把交易入口搬走，卻把商户責任放得更大
UCP 的價值，在於讓代理、商户和付款服務用共同方式交換能力與交易資料。它可能令顧客在 AI Mode、Gemini 或其他介面內完成更多步驟，但沒有把商户從交易中移走。Google 的文件反而一再保留 Merchant of Record、商業邏輯和履約責任。
對香港網店而言，現階段最穩妥的策略不是搶先宣稱已進入 agentic commerce，而是確保商品、優惠、運送、退貨、付款授權和售後都有可核對來源。這些資料同時支援產品 SEO、Merchant Center、客服和未來代理式購物。若你想先盤點哪一層資料最容易令搜尋或交易中斷，可由 YUSIHK SEO 工具中心 抽查公開訊號，或透過 聯絡 YUSIHK 整理網店的商品與交易資料責任。
Gemini 能連接工作應用程式，仍要逐項核對讀寫權限與帳戶資格。可用 Gemini 接入入口與採用條件核對表界定測試範圍；連接本身不等於已能完成訂單。
交易與技術文件
- Google：Google Marketing Live 2026 公告合集
- Google：New tech and tools for retailers to succeed in an agentic shopping era
- Google Merchant Center：About UCP and UCP-powered checkout
- Google Developers Blog：Under the Hood — UCP
- UCP 官方文件：Core concepts
- Google Merchant Center：Supported structured data attributes and values