Google 最新 AI 協議 UCP 是什麼,AI 代理購物的通用商務標準

AI 正在改寫線上購物的角色分工。過去 AI 多半停留在資訊整理與推薦階段,能把規格、評價、價差做成更快的決策輔助,但真正完成購買仍需要回到各家電商網站,一步一步結帳付款。這段流程的斷點,讓「代理式購物」難以真正落地,也讓商務整合長期卡在高成本與高碎片化的現實。

Google 推出的 UCP(Universal Commerce Protocol),正是在這個背景下出現。它試圖把探索、結帳、付款到訂單後續的關鍵能力標準化,讓 AI Agent 能用一致的方式與商家系統互通,進一步把購物從「只會推薦」推進到「可以完成交易」。理解 UCP,不只是看懂一個新協議,而是看懂未來成交入口如何被重新設計。

為什麼 UCP 協議會出現

電商流程對人類而言相當直覺。跳轉頁面、重新輸入資料、反覆確認訂單內容,甚至在不同平台之間來回切換,都是長期被接受的操作方式。然而當成交這件事交由 AI 代理執行時,問題就會變得高度工程化。商品資料、庫存與價格、折扣規則、付款授權分散在不同系統中,缺乏共同語意與一致介面,使得流程難以被機器順利串接。

更現實的挑戰來自整合成本。每一間商家都有自己的後台架構,每一個平台也各自定義結帳流程與狀態回傳方式。只要 AI 介面與通路數量增加,商家就必須面對大量客製化整合,維護成本快速累積,規模化幾乎不可能。

UCP 的出現,正是為了把這些複雜度收斂成可重複使用的標準。透過一次實作、跨場景通用的方式,讓成交流程不再被系統碎片化拖住,而能成為可被代理執行的完整商務路徑。

什麼是 UCP 協議?

UCP 可以視為「AI 代理購物的通用商務層」。它將購物行為拆解並抽象成一組標準化的語意與介面,讓不同商家、電商平台與支付服務,能以一致方式被 AI 系統理解與串接。

UCP 的核心並不在於提升對話能力,而是在於建立可執行的交易規格。當商務流程被明確定義並標準化後,代理的操作邏輯便能重複使用,整合也不再需要為每一個平台重新設計,商務系統得以真正朝向可擴展的方向發展。

UCP 的運作方式

能做什麼?

UCP 的起點不是結帳,而是先把「能做哪些事」說清楚。商家會用標準化的方式公開可支援的商務能力,包含可以執行的行為類型、對應的服務端點,以及必要的限制條件與必填欄位。AI 代理在理解這些能力範圍後,才會進入後續的購物流程。

這樣的設計重點在於降低不確定性。代理不需要解析網頁結構,也不必依賴推測式規則去猜流程,而是依照明確定義完成對齊,讓整個交易路徑更穩定、也更可預期。

怎麼跑流程?

在能力定義清楚之後,UCP 會把購物行為拆成一組可組合的流程步驟,例如商品探索、條件確認、結帳處理、訂單建立,以及訂單狀態查詢與售後相關流程。

購物不再被視為一段只能靠操作介面完成的網站體驗,而是一連串可以被執行、也能回傳狀態的動作。當這些流程被標準化,代理在不同商家之間也能維持一致的操作邏輯,這正是通用協議能夠擴展的關鍵。

交易怎麼完成?

當能力範圍與流程結構都準備好後,購買就能從以頁面為中心的操作方式,轉為由代理依照規格執行的完整交易流程。必要的確認完成後,其餘步驟會按照既定定義執行,包含訂單建立、狀態更新與後續追蹤。

透過這種方式,整個購物旅程可以在同一條標準化路徑上完成,不再因為系統切換或流程斷點而中斷。

UCP 流程示例

假設需求是「五萬內、適合剪片、記憶體至少 32GB、希望輕薄」。代理會先在 AI 介面中完成探索與比較,整理出符合條件的選項,並確認關鍵偏好後,向商家系統查詢實際庫存、預計到貨時間,以及最終結帳金額。這個金額會事先把運費與可套用的折扣一併計算,避免在進入結帳階段才出現條件落差。

條件確認無誤後,流程會進入結帳整合階段。主要路徑是原生結帳(Native checkout),由商家提供標準化的 REST API,讓系統以程式方式建立並管理結帳流程,例如建立 checkout session、補齊結帳所需資料,以及完成下單等操作。若商家的結帳流程較為複雜,或需要保留既有的結帳頁體驗,也可以採用嵌入式結帳(Embedded checkout),將商家的結帳頁以 iframe 方式呈現。

付款階段會透過安全機制完成授權,將加密後的付款資訊交由支付服務處理。授權完成後,訂單會正式建立並回傳訂單相關資訊。後續不論是查詢物流進度、調整收件資訊,或處理退換貨,都能沿用同一套狀態回傳方式,讓整段購物旅程持續在一致的流程中完成。

UCP 和 Gemini、AI Mode 的關係

UCP 並不是單純為開發者準備的技術規格,而是 Google 在重新設計購物入口時的重要一環。隨著搜尋結果與 Gemini 逐步具備理解需求、整合資訊,甚至引導完成交易的能力,購買行為不再一定要回到商家網站才能完成,而是有機會直接在 AI 介面中結束。

在這樣的架構下,UCP 扮演的是「讓成交發生得了」的底層角色。Gemini 與 AI Mode 負責理解需求、整理選項與引導決策,而 UCP 則確保當使用者準備下單時,系統有一套一致、可執行的方式把交易完成。兩者結合後,搜尋不再只是導流工具,而是能一路延伸到實際成交的入口。

成交路徑縮短,通常代表轉換阻力降低,但同時也改變了競爭重心。當下單可以在 AI 介面內完成,交易流程會更依賴資料是否一致、庫存與到貨是否可信,以及履約能力是否穩定。品牌信任、內容品質、售後服務與產品理解仍然關鍵,只是成交的最後一步,不再只綁定在單一網站介面,而是可以在不同的使用情境中完成。

支付與安全怎麼處理?

UCP 在付款設計上的核心目標,是讓結帳能在 AI 介面內完成,同時維持既有支付流程的安全性與可整合性。付款階段會透過安全機制,將加密後的付款資訊傳遞給商家的支付服務供應商(PSP)進行處理。商家不需要在網站上額外放置特定付款按鈕,但支付端必須具備接收並完成相應付款驗證的能力。

在這樣的架構下,結帳流程由 UCP 串接與協調,而實際的付款授權仍依照既有支付服務的規範執行。由於商家仍然是交易的主體,付款完成後的訂單成立、後續查詢、取消與售後處理,依舊由商家端系統與既有政策承接,並透過狀態回傳讓整個購買流程得以延續。

代理式購物能否順利落地,關鍵不在於付款體驗是否複雜,而在於流程是否安全、穩定且可控。只要每一個步驟都能被可靠地執行與回應,結帳體驗就能在縮短流程的同時,維持交易所需的完整性與信任基礎。

UCP 對誰影響最大?

電商商家

當成交入口逐步往 AI 介面前移,是否能順利完成交易,會越來越取決於商務基礎是否扎實。商品規格是否清楚、資料是否一致、庫存與到貨資訊是否可信,這些原本容易被忽略的細節,會直接影響代理是否願意把整筆交易跑完。

在代理式購物的情境下,流程不再有「人工補救」的空間。資料越乾淨、規則越明確、履約越穩定,越容易被納入順暢的成交路徑;反之,資訊混亂或不完整的商品,則更容易在流程中被排除。

平台與工具商

對平台與工具商而言,UCP 更像是一個可以被產品化的能力。平台型玩家通常會把協議封裝成可快速啟用的整合方案,讓商家不需要自行理解或實作過多底層規格。

當商品、訂單、支付與狀態回傳能以統一格式處理,導入成本自然降低,也更容易推動規模化。這類平台往往會成為商家接入代理式購物的重要橋樑。

開發與營運團隊

導入初期最重要的不是做出多華麗的推薦體驗,而是先把核心交易流程穩定下來。結帳是否可靠、訂單是否能正確建立、售後狀態是否能即時回傳,這些都是代理能否持續運作的基礎。

交易流程必須具備可預測性、可觀測性與可回復性。一旦流程中出現無法回應或狀態不明的環節,代理就很難持續執行,整段成交路徑也會因此中斷。

導入 UCP 前要準備什麼

Merchant Center

Merchant Center 帳戶需要維持正常狀態,商品必須通過審核並符合刊登條件,才能進入 UCP 結帳體驗的導入流程。

退貨政策必須先在 Merchant Center 設定完成,至少包含退貨費用、退貨期限窗口,以及完整政策連結。客服資訊也需要補齊,結帳相關頁面會引用這些資訊提供聯絡商家的入口。

商品資料欄位要求

UCP 不只串 API 就能跑,商品資料必須具備支撐結帳與合規呈現的欄位。官方做法通常會建議以 Supplemental Feed 補齊資料,降低對既有主 Feed 的影響。

其中關鍵欄位之一是 native_commerce,這是一個布林值,用來決定商品是否加入結帳體驗。未提供或為 false 的商品不會進入結帳流程。

若商品涉及法規或安全警示需求,需提供 consumer_notice 相關欄位,讓結帳頁能以明確方式呈現必要告知資訊。

商品 feed 的 id 也必須能對應到結帳介面所預期的商品識別。若兩者格式不同,需用 merchant_item_id 進行對應映射,避免結帳時無法正確匹配商品。

不支援的商品類型

UCP 的結帳體驗只支援特定交易型態,部分商品或履約方式不在支援範圍內。常見不支援類型包含訂閱或循環扣款、分期付款計畫、客製化商品、二手或翻新品、不可退商品、預購、需要額外合約或現場啟用的交易、特殊運送模式、需要年齡驗證的品項,以及數位商品與服務型交易。

這些商品必須在 feed 端就完成控管,避免被納入結帳流程。

Business Profile 發布

導入 UCP 需要在站點上發布 Business Profile,位置為 /.well-known/ucp。這份 profile 用來提供協議版本與能力協商資訊,讓整合方能理解服務端點與可用能力範圍。

Checkout 整合路徑

在結帳整合上,原生結帳(Native)是主要路徑,商家需實作標準 REST API,讓結帳 session 能被建立與管理,並完成下單流程。

嵌入式結帳(Embedded)屬於可選路徑,商家提供結帳 web URL,並以 iframe 方式呈現,適合結帳流程較複雜或需要保留既有結帳頁體驗的情境。

上線流程

導入 UCP 的上線流程目前需要先加入申請名單,並通過核准後才能在相關 AI 介面啟用對應體驗。

風險控管與合規

記錄商家責任

導入 UCP 後,商家仍然是交易的記錄商家(Merchant of Record),並持續對交易行為與客戶關係負責。結帳流程中會顯示商家設定的退貨政策,因此 Merchant Center 內的退貨資訊必須保持完整、正確且即時更新,才能確保交易過程符合既有規範。

交易風險訊號

在交易進行過程中,系統會提供必要的情境資料,協助商家進行風險評估。這些資料可用來判斷是否要繼續處理該筆交易,最終決策權仍由商家掌握。常見的訊號類型包含使用中的 session、裝置與瀏覽器資訊,以及寄送、帳單與付款驗證相關資料。

法規與商品告知

若商品涉及法規要求或安全警示,必須在商品資料中提供相應的告知內容,並於結帳流程中清楚呈現。相關合規資訊是否完整與正確,仍屬商家責任範圍,也是交易能否順利完成的重要前提。

商品資格控管

UCP 僅支援特定的交易型態與履約方式。導入時,商家需明確控管哪些商品符合結帳資格,並在商品 feed 端完成篩選,確保不支援的商品不會被納入結帳流程,避免產生流程錯誤或合規風險。

SEO 與廣告策略怎麼調整

內容要更像規格文件

在代理式購物的情境下,內容的角色不再只是吸引點擊或導流,而是用來建立可被系統理解與判斷的規則。產品比較頁、規格對照、運送時效、保固範圍與退換貨條件,這些原本被視為輔助資訊的內容,會變成影響成交的重要依據。代理需要的是清楚、可對照、可引用的資訊,而不只是說服性的文案。

商品資料品質成為基礎能力

商品資料是否結構化、屬性是否完整、規格是否一致,會直接影響代理能否正確理解商品並順利完成結帳流程。當資料品質不足,流程就容易在關鍵步驟中斷,因此資料治理的重要性會明顯提升,成為代理式成交的基礎能力之一。

轉換優化更重視流程可靠性

當成交路徑由代理承接,轉換不再只取決於頁面設計或操作動線,而是整體流程是否穩定。庫存準確率、支付失敗率、訂單狀態回傳延遲,以及售後處理時間,這些流程層面的表現,都會直接影響成交能否順利完成。流程越可靠,代理越能連續執行,轉換表現也越穩定。

結語

UCP 的重點不在於多了一個新名詞,而在於它把電商流程往「可被代理執行」推了一步。當結帳與付款能在 AI 介面內完成,競爭的關鍵就不再只是導流與曝光,而會更集中在資料品質、履約能力與流程可靠性。商品資訊是否一致、庫存與到貨是否可信、結帳狀態能否穩定回傳,會直接影響代理式購物能否順利跑完。

對商家與平台而言,最務實的準備不是追逐熱度,而是把商品資料、結帳流程與售後規則整理成更標準、更可整合的形狀。當購買入口逐步前移到 AI 介面,能否在新的成交路徑中被順利選中並完成交易,將成為下一階段更核心的成長能力。

常見問答

本區問答由 AI 依文章內容自動整理,僅供快速參考,正式內容仍以全文為準。

Google 提出的 UCP 協議到底是什麼?它解決什麼問題?

UCP(Universal Commerce Protocol)是 Google 推出的 AI 代理購物通用商務層協議。
它把購物行為拆解並抽象成一組標準化語意與介面,讓不同商家、電商平台與支付服務能以一致方式被 AI 系統理解與串接。
它要解決的是「代理式購物」最大的斷點——AI 雖能比價推薦,但實際結帳仍要回到各家網站。
UCP 把探索、結帳、付款到售後狀態通通標準化,讓 AI Agent 能直接完成完整交易,而不必為每個平台客製整合。

UCP 跟一般電商 API 串接有什麼差別?

傳統電商整合是「一對一客製」,每家商家後台都有自己的結帳流程與狀態回傳方式,AI 介面或通路一多,商家就要面對大量客製化整合,維護成本快速累積。
UCP 的做法是把成交流程收斂成「一次實作、跨場景通用」的標準。
商家先用標準格式公開可支援的商務能力,AI 代理依規格執行探索、結帳、付款與訂單追蹤。
整合邏輯能被重複使用,這是它跟既有 API 整合最關鍵的差異。

UCP 對電商商家會帶來哪些實際影響?

當成交入口逐步往 AI 介面前移,是否能完成交易越來越取決於商務基礎是否扎實。
商品規格是否清楚、資料是否一致、庫存與到貨資訊是否可信,會直接決定代理是否願意把整筆交易跑完。
在代理式購物情境下,流程不再有「人工補救」空間,資料越乾淨、規則越明確、履約越穩定,越容易被納入順暢成交路徑。
商家仍是 Merchant of Record,必須持續對交易與退貨政策、合規告知負責。

很多人以為 UCP 就是「讓 Gemini 變得會買東西」,這樣理解對嗎?

這個理解太表層。
UCP 並不是聊天能力,而是底層的交易執行規格。
Gemini 與 AI Mode 負責理解需求、整理選項與引導決策,UCP 則確保使用者準備下單時,系統有一套一致、可執行的方式把交易完成。
也就是說,AI 介面是「決定要買」,UCP 是「讓買得了」的基礎建設。
兩者結合後,搜尋不再只是導流工具,而能一路延伸到實際成交,這才是 UCP 真正的戰略價值。

想導入 UCP,目前有哪些限制或需要先準備的條件?

目前 UCP 仍需先加入申請名單並通過核准才能啟用。
你必須有正常運作的 Merchant Center,商品需通過審核、退貨政策與客服資訊要完整。
商品資料須補上 native_commerce、consumer_notice 等欄位,並在 /.well-known/ucp 發布 Business Profile。
要注意 UCP 結帳目前不支援訂閱、分期、客製化商品、二手品、預購、數位商品與服務型交易等品項,這些必須在 feed 端就排除,避免被納入結帳流程。