# Google UCP 代理人商務技術架構、生態系整合與 OpenAI ACP 戰略差異之深度分析報告

- 連結：https://cloudsea35.com/google-ucp-agent-architecture/
- 發佈時間：2026-01-14T11:29:03+08:00
- 作者：David

![Google UCP 代理人商務技術架構、生態系整合與 OpenAI ACP 戰略差異之深度分析報告](
https://i0.wp.com/cloudsea35.com/wp-content/uploads/2026/01/image.webp?resize=1024%
2C559&ssl=1 "Google UCP 代理人商務技術架構、生態系整合與 OpenAI ACP 戰略差異之深度
分析報告 1")

# 執行摘要

內容目錄

[Toggle](https://cloudsea35.com/google-ucp-agent-architecture/#)

 * [執行摘要](https://cloudsea35.com/google-ucp-agent-architecture/#%e5%9f%b7%e8%a1%8c%e6%91%98%e8%a6%81)
    - [1. 代理式商務的崛起與基礎設施挑戰](https://cloudsea35.com/google-ucp-agent-architecture/#1_%e4%bb%a3%e7%90%86%e5%bc%8f%e5%95%86%e5%8b%99%e7%9a%84%e5%b4%9b%e8%b5%b7%e8%88%87%e5%9f%ba%e7%a4%8e%e8%a8%ad%e6%96%bd%e6%8c%91%e6%88%b0)
    - [⚡ Google UCP 影響分析：從「流量經濟」轉向「代理經濟」](https://cloudsea35.com/google-ucp-agent-architecture/#%e2%9a%a1_google_ucp_%e5%bd%b1%e9%9f%bf%e5%88%86%e6%9e%90%ef%bc%9a%e5%be%9e%e3%80%8c%e6%b5%81%e9%87%8f%e7%b6%93%e6%bf%9f%e3%80%8d%e8%bd%89%e5%90%91%e3%80%8c%e4%bb%a3%e7%90%86%e7%b6%93%e6%bf%9f%e3%80%8d)
    - [2. Google UCP 技術架構深度解析](https://cloudsea35.com/google-ucp-agent-architecture/#2_google_ucp_%e6%8a%80%e8%a1%93%e6%9e%b6%e6%a7%8b%e6%b7%b1%e5%ba%a6%e8%a7%a3%e6%9e%90)
    - [3. 安全與信任架構：Agent Payments Protocol (AP2)](https://cloudsea35.com/google-ucp-agent-architecture/#3_%e5%ae%89%e5%85%a8%e8%88%87%e4%bf%a1%e4%bb%bb%e6%9e%b6%e6%a7%8b%ef%bc%9aagent_payments_protocol_ap2)
    - [4. 代理人間的溝通語言：Agent2Agent (A2A) 協定](https://cloudsea35.com/google-ucp-agent-architecture/#4_%e4%bb%a3%e7%90%86%e4%ba%ba%e9%96%93%e7%9a%84%e6%ba%9d%e9%80%9a%e8%aa%9e%e8%a8%80%ef%bc%9aagent2agent_a2a_%e5%8d%94%e5%ae%9a)
    - [5. 生態系與合作夥伴整合策略](https://cloudsea35.com/google-ucp-agent-architecture/#5_%e7%94%9f%e6%85%8b%e7%b3%bb%e8%88%87%e5%90%88%e4%bd%9c%e5%a4%a5%e4%bc%b4%e6%95%b4%e5%90%88%e7%ad%96%e7%95%a5)
    - [6. Google UCP 與 OpenAI ACP 之戰略與技術差異分析](https://cloudsea35.com/google-ucp-agent-architecture/#6_google_ucp_%e8%88%87_openai_acp_%e4%b9%8b%e6%88%b0%e7%95%a5%e8%88%87%e6%8a%80%e8%a1%93%e5%b7%ae%e7%95%b0%e5%88%86%e6%9e%90)
    - [7. 新變現模式：直接優惠 (Direct Offers) 與商業代理 (Business Agent)](https://cloudsea35.com/google-ucp-agent-architecture/#7_%e6%96%b0%e8%ae%8a%e7%8f%be%e6%a8%a1%e5%bc%8f%ef%bc%9a%e7%9b%b4%e6%8e%a5%e5%84%aa%e6%83%a0_direct_offers_%e8%88%87%e5%95%86%e6%a5%ad%e4%bb%a3%e7%90%86_business_agent)
    - [8. 戰略影響與未來展望](https://cloudsea35.com/google-ucp-agent-architecture/#8_%e6%88%b0%e7%95%a5%e5%bd%b1%e9%9f%bf%e8%88%87%e6%9c%aa%e4%be%86%e5%b1%95%e6%9c%9b)
    - [9. 結論與建議](https://cloudsea35.com/google-ucp-agent-architecture/#9_%e7%b5%90%e8%ab%96%e8%88%87%e5%bb%ba%e8%ad%b0)

隨著大型語言模型 (LLM) 從單純的資訊檢索工具演進為具備推理、規劃與執行能力的「代理
式 AI」(Agentic AI)，全球電子商務正經歷一場足以媲美從桌機轉向行動裝置的典範轉移。
在此背景下，Google 於 2026 年 1 月正式推出了通用商務通訊協定 (Universal Commerce
Protocol, UCP)，這是一項旨在解決代理人商務 (Agentic Commerce) 碎片化問題的開源標準
^(1)。與此同時，OpenAI 亦透過其 Agentic Commerce Protocol (ACP) 積極佈局，形成了
兩大科技巨頭在商務基礎設施層面的激烈競爭。

本報告旨在針對 Google UCP 進行詳盡的技術解構與戰略分析。研究顯示，UCP 並非單純的
產品功能更新，而是一套完整的基礎設施堆疊，其核心由負責商務邏輯的 UCP、負責安全支付
授權的 Agent Payments Protocol (AP2)，以及負責代理人間通訊的 Agent2Agent (A2A) 協定
所組成 ^(2)。透過與 Shopify、Walmart 及 Ant International 等產業巨頭的深度整合，
Google 試圖建立一個「去中心化」但標準化的商務網路，以「登記商家 (Merchant of Record,
MoR)」模式作為對抗封閉平台壟斷的戰略支點 ^(4)。

本報告將深入探討 UCP 的技術細節，包括其基於 JSON 的能力發現機制、加密授權憑證 (Verifiable
Credentials) 的運作原理，以及「直接優惠 (Direct Offers)」如何將廣告計價模式從點擊
成本 (CPC) 轉向行動成本 (CPA) ^(6)。同時，透過與 OpenAI ACP 的系統性比較，揭示兩者
在生態系治理、數據主權及長期商業模式上的根本差異，為相關企業與技術決策者提供具深度
的策略洞察。

---

## 1. 代理式商務的崛起與基礎設施挑戰

### 1.1 從圖形介面到意圖驅動的商務轉型

傳統電子商務的基礎設施是建立在人類視覺互動的假設之上——用戶透過瀏覽器訪問網站，解讀
圖形使用者介面 (GUI)，並手動執行點擊操作。然而，代理式 AI 的興起打破了這一假設。
AI 代理人 (AI Agents) 不具備視覺感知需求，而是依賴結構化數據與 API 來理解世界。當
用戶向 AI 發出「幫我買一頂適合四人使用、防風且預算在 200 美元以內的帳篷」這類高層
次意圖指令時，AI 需要能夠跨越多個商家進行搜尋、比較、談判並執行交易 ^(8)。

現有的商務環境面臨著嚴峻的「N x N 整合瓶頸」。假設市場上有 $N$ 個商家和 $N$ 個不同
的 AI 代理平台 (如 Gemini, ChatGPT, Claude, Perplexity)，若缺乏統一標準，每個商家
都必須為每個平台開發專屬的連接器。這不僅導致了巨大的技術債，更造成了數據孤島，使得
AI 經常因為無法獲取即時庫存或價格資訊而產生「幻覺」(Hallucination)，進而破壞用戶
信任 ^(10)。

### 1.2 UCP 的核心定位：商務領域的 USB 標準

Google 推出的 UCP 旨在解決上述結構性問題。正如 USB 標準統一了電腦周邊設備的連接，
UCP 試圖為代理式商務提供一個標準化的抽象層。它不取代現有的電商平台 (如 Shopify 或
Magento)，而是疊加在其之上，將商家的商品、庫存、物流與支付能力轉化為 AI 可讀、可
操作的標準化介面。這使得任何支援 UCP 的 AI 代理都能夠與任何支援 UCP 的商家進行無縫
交易，而無需進行一對一的客製化整合 ^(4)。

這種轉變標誌著商務互動從「瀏覽 (Browsing)」向「執行 (Executing)」的演進。UCP 的設計
哲學強調互操作性 (Interoperability) 與商家主權 (Merchant Sovereignty)，確保商家在
享受 AI 流量紅利的同時，不至於淪為單純的供貨商，而是保留了對客戶關係與交易數據的
控制權 ^(4)。

---

## ⚡ Google UCP 影響分析：從「流量經濟」轉向「代理經濟」

### 1. 核心觀點：重構電商的「入口」與「介面」

過去二十年，電商的核心邏輯是 **SEO (搜尋引擎優化)** 與 **UI/UX (使用者體驗)**。商家
花大錢買關鍵字把人引流到網站，再用漂亮的介面與文案說服人下單。

**UCP 的出現宣告了「代理人商務 (Agentic Commerce)」時代的正式來臨。**

 * **衝擊點：** 消費者不再逛網站 (UI 不重要了)，而是由 AI 代理人直接完成「比價、
   篩選、下單」。
 * **新戰場：** 商家不再需要爭奪人類的眼球，而是要爭奪 **AI 的演算法推薦權**。
 * **關鍵字變革：** 傳統 SEO 逐漸失效，取而代之的是 **AIO (Agent Integration Optimization，
   代理人整合優化)**。

### 2. 對電商產業鏈的具體衝擊

我整理了一份多維度比對表，幫助您快速掃描各方影響：

  |  **影響維度** |  **傳統電商模式 (Current)** |  **UCP 代理人商務模式 (New)** |  **衝擊程度** |  
   |  **流量入口** |  搜尋引擎、社群廣告、App |  AI 助理 (Gemini, ChatGPT)、智慧音箱 |  ⭐⭐⭐⭐⭐ (極高) |  
 |  **購物體驗** |  瀏覽頁面 → 購物車 → 結帳 |  對話指令 → 確認方案 → 自動扣款 |  ⭐⭐⭐⭐⭐ (極高) |  
 |  **廣告模式** |  展示型廣告 (Display Ads)、關鍵字 |  **Direct Offers (直接報價)**：系統判斷意圖後直接推播折扣 |  ⭐⭐⭐⭐ (高) |  
 |  **技術門檻** |  架設網站 (Web/App) |  **API First**：必須提供標準化數據接口供 AI 抓取 |  ⭐⭐⭐⭐ (高) |  
 |  **品牌忠誠** |  依賴品牌官網會員經營 |  依賴 AI 代理人的「錢包綁定」與「習慣設定」 |  ⭐⭐⭐ (中高) |

---

### 3. 深入解析：三大關鍵變局

#### A. 「隱形貨架」的戰爭 (The Invisible Shelf War)

在 UCP 架構下，消費者可能根本不會看到傳統的「商品列表頁」。

 * **現狀：** 使用者搜尋「跑鞋」，Google 給出 10 個連結，使用者一一點開。
 * **UCP 未來：** 使用者說「幫我買一雙適合跑馬拉松的鞋，預算 3000 元」，AI 代理人
   直接透過 UCP 協議，在背景與 Nike、Adidas、Asics 的系統溝通，最後只呈現 **「最佳
   推薦」** 並附上 **「Direct Offer (專屬折扣)」**。
 * **風險：** 如果你的商品資訊無法被 UCP 標準化讀取，或者你的品牌不在 AI 的「信任
   清單」中，你將直接從市場上「消失」。

#### B. 零售商的「雙面刃」 (The Retailer’s Dilemma)

Google 拉攏了 Shopify, Walmart, Target 等巨頭，這是一個典型的「合縱連橫」。

 * **優勢：** 中小型商家透過 Shopify 支援 UCP，瞬間獲得了與 AI 對接的能力，大幅降低
   掉單率（因為結帳流程被 Google/AI 託管了，不再需要跳轉）。
 * **劣勢：** 零售商失去了對「顧客旅程」的控制權。當交易發生在 AI 對話框裡，商家
   難以進行「加價購 (Upsell)」或傳遞品牌氛圍。品牌可能淪為單純的「供貨商」。

#### C. 與 OpenAI ACP 的協定之戰 (Protocol Wars)

您提到的 OpenAI ACP (Agentic Commerce Protocol) 與 Google UCP 是目前最大的兩股勢力。

 * **OpenAI ACP：** 專注於「對話即交易」，強項在於 ChatGPT 的龐大用戶與 Stripe 的
   支付底層。它更像是一個「超級外掛」。
 * **Google UCP：** 試圖吃下「全生命週期」。不只是買，還包含售後、物流追蹤、甚至
   跨代理人協作（搜尋Agent交棒給支付Agent）。Google 的優勢在於它擁有 Android、Google
   Pay 和最完整的商家圖譜 (Shopping Graph)。
 * **產業預測：** 短期內兩者並存，商家必須「兩邊押寶」。但長期來看，誰能定義「標準」，
   誰就是下一個世代的 VISA。

---

## 2. Google UCP 技術架構深度解析

UCP 的技術架構採用了模組化設計，允許商家根據自身需求選擇性地實作特定功能。其架構
可分為三個主要層次：發現層 (Discovery Layer)、傳輸層 (Transport Layer) 與能力層 (
Capability Layer)。

### 2.1 發現機制與能力清單 (The Capability Manifest)

UCP 的運作始於「發現」。為了讓 AI 代理知道某個網站支援哪些商務功能，商家需在標準化
的路徑 (通常為 `/.well-known/ucp`) 託管一份 JSON 格式的 **能力清單 (Capability Manifest)**
^(11)。這份清單如同商家的「數位名片」，向 AI 宣告其技術規格。

**表 1：UCP 能力清單結構範例與解析**

  |  **欄位 (Key)** |  **說明 (Description)** |  **技術意涵 (Technical Implication)** |  
   |  `version` |  協議版本 (如 `2026-01-11`) |  確保代理人與商家使用相同的語法標準，避免版本衝突。 |  
 |  `capabilities` |  支援的功能列表 |  例如 `dev.ucp.shopping.checkout` (結帳)、`dev.ucp.common.identity_linking` (帳號連結)。 |  
 |  `transport` |  支援的通訊協定 |  指定透過 REST API、MCP 或 A2A 進行互動。 |  
 |  `extensions` |  擴充功能 |  如 `com.merchant.loyalty` (忠誠度計畫) 或 `com.google.offers` (優惠券)。 |  
 |  `endpoints` |  API 端點位置 |  代理人發送請求的具體 URL。 |

當 Google Gemini 或其他 AI 代理訪問商家網站時，會首先讀取此檔案。如果發現有效的 
UCP 清單，AI 就會切換到「代理模式」，直接透過 API 與商家後端互動，而非嘗試解析 HTML
網頁 ^(11)。這種設計極大地降低了爬蟲解析錯誤的風險，並確保了數據的即時性。

### 2.2 核心能力模組 (Core Capabilities)

UCP 初始版本定義了三個最關鍵的商務能力，構成了完整交易閉環的基礎：

#### 2.2.1 結帳能力 (Checkout Capability)

`dev.ucp.shopping.checkout` 是 UCP 最複雜也最重要的模組。它不僅僅是傳遞訂單，而是
管理一個有狀態的 (Stateful) 購物會話 (Session)。

 * **動態購物車邏輯：** AI 可以呼叫 API 新增或移除商品 (Line Items)，商家的後端會
   即時重新計算總價。
 * **複雜稅務與運費計算：** 當 AI 提供用戶的配送地址時，UCP 結帳模組會回傳精確的
   稅額和可用的物流選項 (如「標準配送」、「隔日達」) 及其對應費用。這解決了傳統 
   AI 購物中常見的「最終價格不符」問題。
 * **庫存鎖定：** 在會話期間，商家可以暫時保留庫存，避免超賣。
 * **擴展性：** 支援折扣碼 (Discounts) 與禮品卡 (Gift Cards) 的應用邏輯 ^(4)。

#### 2.2.2 身份連結能力 (Identity Linking Capability)

為了實現個性化服務 (如會員折扣) 與訂單追蹤，AI 需要能夠「代表」用戶登入商家系統。
UCP 採用標準的 **OAuth 2.0** 協定來實作 `dev.ucp.common.identity_linking` ^(4)。

 * **範圍 (Scope)：** 專門定義了 `ucp:scopes:checkout_session` 權限。
 * **流程：** AI 請求連結帳號 -> 用戶在商家授權頁面確認 -> 商家發放存取權杖 (Access
   Token) 給 AI。
 * **安全性：** AI 永遠不會接觸到用戶的帳號密碼，僅持有受限的權杖，且該權杖可隨時
   被撤銷。這使得 AI 能夠查詢歷史訂單或累積會員點數，增強了用戶黏著度。

#### 2.2.3 訂單管理能力 (Order Management Capability)

購後體驗是代理式商務信任建立的關鍵。此模組允許 AI 訂閱訂單狀態的變更 (Webhooks) 
^(4)。

 * **即時追蹤：** 當商品出貨、延遲或送達時，商家系統會主動推播通知給 AI。
 * **語意化查詢：** 用戶可以問 AI：「我的包裹到哪了？」，AI 不需去翻找 Email，而是
   直接查詢 UCP 狀態並回答：「包裹已於今早 9 點抵達台北轉運中心。」

### 2.3 整合路徑：原生 (Native) 與 嵌入式 (Embedded)

Google 理解並非所有商家都願意將結帳體驗完全交給 AI 渲染，因此 UCP 提供了兩種整合
路徑，以平衡標準化與品牌控制權 ^(4)。

**表 2：UCP 原生與嵌入式整合模式之比較分析**

  |  **特性** |  **原生結帳 (Native Checkout)** |  **嵌入式結帳 (Embedded Checkout)** |  
   |  **使用者介面 (UI)** |  由 AI 平台 (如 Google) 原生渲染，風格統一。 |  由商家透過 iframe 或 Webview 提供，保留品牌視覺。 |  
 |  **互動模式** |  AI 全權代理，用戶僅需確認。 |  AI 引導至嵌入視窗，用戶在商家介面操作。 |  
 |  **適用場景** |  標準化商品、高頻低單價交易、追求極致速度。 |  複雜配置商品 (如訂製家具)、奢侈品、需特殊法規驗證 (如處方藥)。 |  
 |  **開發複雜度** |  需實作完整的 REST API 邏輯。 |  需實作嵌入式通訊協定與前端訊息傳遞 (postMessage)。 |  
 |  **優勢** |  轉化率最高，消除跳轉摩擦。 |  商家對品牌體驗有完全控制權，支援非標準流程。 |

**原生整合**是 UCP 的理想型態，能最大化發揮代理式商務「一句話完成購物」的潛力；而**
嵌入式整合**則是對現實商業環境的妥協，確保了大型企業與特殊品類商家的參與意願 ^(16)。

---

## 3. 安全與信任架構：Agent Payments Protocol (AP2)

UCP 負責處理「買什麼」(商品資訊)，而 **Agent Payments Protocol (AP2)** 則負責處理「
如何付」(資金授權)。在代理人商務中，最大的風險在於「代理人幻覺」與「未經授權的交易」。
AP2 透過引入加密的 **授權指令 (Mandates)** 機制，從根本上解決了這一信任難題 ^(18)。

### 3.1 授權指令系統 (The Mandate System)

AP2 不依賴傳統的 Session Cookie 或單純的 API Key，而是使用基於密碼學簽章的數位合約，
稱為 Mandates。這些指令構成了不可否認 (Non-repudiable) 的證據鏈。

#### 3.1.1 意圖指令 (Intent Mandate) – 人不在場 (Human-Not-Present)

此指令適用於委託型任務，例如「如果比特幣跌破 5 萬美元就買入」或「每個月底自動訂購
洗衣精」。

 * **機制：** 用戶預先簽署一份包含限制條件 (最高金額、商家類別、有效期限) 的意圖
   指令。
 * **執行：** AI 代理持有此指令，當市場條件觸發時，可自動執行交易，無需再次喚醒用戶。
   商家端會驗證該指令的簽章與條件是否符合，確保 AI 沒有逾越授權 ^(20)。

#### 3.1.2 購物車指令 (Cart Mandate) – 人在場 (Human-Present)

適用於即時互動場景。當 AI 推薦商品並將購物車呈現給用戶時，用戶的「確認」動作實際上
是簽署了一份購物車指令。

 * **內容鎖定：** 該指令包含購物車內所有商品、單價、總價與商家的雜湊值 (Hash)。
 * **防篡改：** 這保證了「所見即所得」。如果商家在用戶確認後偷偷修改價格或商品，
   雜湊值將不匹配，交易會被支付處理器拒絕。這消除了 AI 介面顯示價格與實際扣款金額
   不符的風險 ^(19)。

#### 3.1.3 支付指令 (Payment Mandate)

這是最終發送給支付服務提供商 (PSP) 的憑證。它封裝了上述的意圖或購物車指令，將「支付
工具」(如信用卡 Token) 與「支付處理者」(如 Stripe) 分離。這意味著 AI 代理本身永遠
接觸不到用戶的原始信用卡號，大幅降低了資料外洩風險 ^(22)。

### 3.2 角色分離與隱私保護

AP2 的架構嚴格區分了三種角色：

 1. **購物代理 (Shopping Agent)：** 負責尋找商品、協商價格 (如 Google Gemini)。
 2. **憑證提供者 (Credential Provider)：** 負責保管用戶私鑰與支付工具 (如 Google Wallet)。
 3. **商家端點 (Merchant Endpoint)：** 負責接收訂單與指令。

這種設計確保了「最小權限原則」。購物代理只知道用戶想買鞋子，但不知道用戶的信用卡
號；商家知道要收多少錢，但無法在未經授權下發起額外扣款。所有的交易授權都依賴於用戶
在憑證提供者端的生物辨識 (如 FaceID) 或密碼驗證 ^(18)。

---

## 4. 代理人間的溝通語言：Agent2Agent (A2A) 協定

除了 UCP 與 AP2，Google 還推出了 **Agent2Agent (A2A)** 協定，作為不同 AI 代理之間
溝通的傳輸層。如果 UCP 是「商務語言」，那麼 A2A 就是「電話線路」^(25)。

### 4.1 解決代理人孤島問題

目前的 AI 代理大多是孤立的。A2A 允許不同來源、不同功能的代理進行協作。例如，一個「
旅遊規劃代理」可以透過 A2A 呼叫一個「航空公司代理」來訂票，再呼叫一個「保險代理」
來買保險。

### 4.2 A2A 核心組件

 * **代理名片 (Agent Card)：** 類似於網站的 `robots.txt` 或 API 文件，代理透過交換
   名片來宣告自己的能力 (Capabilities)、輸入輸出格式與身份驗證要求 ^(26)。
 * **任務生命週期 (Task Lifecycle)：** A2A 定義了任務的狀態機 (提交、執行中、需要
   輸入、完成、失敗)。這對於長時運行 (Long-running) 的商務交易至關重要，例如「持續
   監控價格直到達標」。
 * **多模態支援：** A2A 不僅支援文字，還支援傳輸結構化數據 (JSON)、檔案甚至即時串
   流，這對於處理複雜的商務單據或客戶服務場景非常有用 ^(27)。

在 UCP 的架構中，A2A 可以作為一種傳輸綁定 (Transport Binding)。這意味著 UCP 的商務
訊息 (如結帳請求) 可以被封裝在 A2A 的信封中傳送，實現了跨代理的商務互操作性 ^(3)。

---

## 5. 生態系與合作夥伴整合策略

Google 深知在商務領域無法單打獨鬥，特別是在面對 Amazon 這種垂直整合巨頭時。因此，
UCP 的推廣策略是建立一個廣泛的聯盟，涵蓋平台、零售商與支付業者。

### 5.1 零售平台巨頭：Shopify 與 Walmart

 * **Shopify：** 作為全球最大的獨立站建站平台，Shopify 的支援是 UCP 能否普及的關鍵。
   Shopify 與 Google 的合作屬於「平台級整合」。這意味著數百萬 Shopify 商家無需自行
   開發 UCP 介面，Shopify 平台會自動為其生成 UCP 清單與 API 端點。這瞬間為 Google
   的 AI 購物生態系注入了海量的長尾商品庫存 ^(1)。
 * **Walmart：** 作為反 Amazon 聯盟的核心成員，Walmart 的加入具有戰略意義。透過支援
   UCP，Walmart 的商品可以直接在 Google Gemini 中被購買，減少了用戶跳轉流失。這讓
   Walmart 能夠在搜尋與發現階段就攔截用戶意圖，對抗 Amazon 的流量黑洞 ^(31)。

### 5.2 支付與金融科技：Ant International 與 Adyen

UCP 的開放性體現在其對跨境支付與多樣化支付方式的支援。

 * **Ant International (螞蟻國際)：** 雙方的合作將 Alipay+ 的龐大支付網絡引入 UCP
   生態。這對於跨境商務尤為重要。當美國用戶想購買亞洲商品時，AI 代理可以透過 UCP
   處理商務邏輯，並利用 Ant 的技術處理跨境結算與匯率轉換，所有過程都受到 AP2 指令
   的保護。這擴展了 UCP 在非信用卡主導市場 (如東南亞) 的適用性 ^(33)。
 * **Adyen 與 Stripe：** 這些支付處理器扮演「支付處理者 (Payment Handler)」的角色。
   對於使用 Adyen 的商家，Adyen 提供了相容於 AP2 的介面，使得商家後端能解析並驗證
   來自 AI 的加密支付指令。這種整合讓 PSP (支付服務商) 能夠開闢新的「機器對機器 (
   M2M)」支付業務流，而無需自行開發前端 AI ^(4)。

### 5.3 登記商家 (Merchant of Record, MoR) 的戰略堅持

Google 在推廣 UCP 時，極力強調**「商家仍是登記商家 (MoR)」**這一點 ^(4)。

 * **對比 Amazon/Marketplace 模式：** 在 Marketplace 模式中，平台往往介入交易，甚至
   控制客戶數據。
 * **UCP 模式：** Google 僅作為連接管道，交易的法律主體、稅務責任、售後服務均由商家
   負責。這消除了品牌商 (如 Nike, LVMH) 對於「被平台綁架」的恐懼，是 Google 爭取
   大型品牌支持的核心論述 ^(38)。

---

## 6. Google UCP 與 OpenAI ACP 之戰略與技術差異分析

目前市場上主要存在兩大代理商務標準：Google 的 UCP 與 OpenAI 的 Agentic Commerce 
Protocol (ACP) (與 Stripe 合作開發)。這兩者的競爭將決定未來 AI 商務的格局。

**表 3：Google UCP 與 OpenAI ACP 之詳細比較分析**

  |  **比較維度** |  **Google UCP (Universal Commerce Protocol)** |  **OpenAI ACP (Agentic Commerce Protocol)** |  
   |  **核心哲學** |  **去中心化基礎設施：** 旨在成為「商務界的 HTTP」，強調生態系共榮與開放標準。 |  **平台中心化：** 旨在強化 ChatGPT 作為「超級應用 (Super App)」的地位，打造封閉或半封閉的商務花園。 |  
 |  **發現機制** |  **能力清單 (Manifests)：** 透過 `/.well-known/ucp` 動態發現，任何代理均可讀取。 |  **註冊制/工具定義：** 依賴 OpenAI 的 Function Calling 與平台註冊，偏向將商家視為「插件」。 |  
 |  **支付安全** |  **AP2 授權指令：** 使用加密簽章的 Mandates，支援多種支付處理器，強調意圖驗證。 |  **委託權杖 (Delegated Tokens)：** 主要依賴 Stripe 的 Link 技術與一次性虛擬卡，與特定金融夥伴綁定較深。 |  
 |  **商家控制權** |  **極高 (MoR)：** 明確定義商家為 MoR，支援嵌入式結帳以保留品牌體驗。 |  **中等：** 雖然商家是 MoR，但 UI 體驗高度統一於 ChatGPT 介面，品牌差異化較難體現。 |  
 |  **生態系策略** |  **廣泛結盟：** 聯合 Shopify, Walmart, Adyen 等建立統一戰線。 |  **垂直整合：** 與 Stripe 深度綁定，透過「Agentic Commerce Suite」快速吸納中小型商家。 |  
 |  **變現模式** |  **直接優惠 (Direct Offers)：** 引入 CPA 廣告模式，將商務與廣告系統深度整合。 |  **訂閱/抽成：** 目前偏向增強模型效用以驅動訂閱，未來可能走向交易抽成。 |

### 6.1 技術路徑的根本分歧

UCP 走的是 Web 標準路線，試圖定義一套通用的語法，讓商務行為像網頁瀏覽一樣普及。它
支援 REST, A2A, MCP 等多種傳輸方式，展現了極強的兼容性 5。

相反，OpenAI ACP 更像是 App Store 路線，它優化了特定平台 (ChatGPT) 內的用戶體驗，
利用其強大的 LLM 推理能力來簡化整合，但相對封閉。OpenAI 與 Stripe 的合作 (Agentic
Commerce Suite) 雖然降低了商家的進入門檻，但也加深了對單一技術堆疊的依賴 37。

### 6.2 流量入口與防禦性策略

Google 推動 UCP 的潛在動機是防禦性的。如果 OpenAI 成功建立了自己的商務閉環，用戶
將不再透過 Google 搜尋商品，這將直接威脅 Google 的核心廣告營收。透過 UCP，Google
試圖將商務行為「標準化」，確保無論用戶使用哪個 AI 代理，Google 的索引與廣告系統仍能
發揮作用 ^(41)。

---

## 7. 新變現模式：直接優惠 (Direct Offers) 與商業代理 (Business Agent)

UCP 不僅是基礎設施，更是 Google 新一代廣告產品的載體。

### 7.1 直接優惠 (Direct Offers)：從 CPC 到 CPA 的演進

這是一種全新的廣告單元。傳統的 Google Ads 是基於關鍵字競價 (CPC)。而 Direct Offers
則是基於**意圖與行動 (CPA)**。

 * **運作機制：** 商家不需預先設定關鍵字，而是設定「折扣規則」與「利潤門檻」。Google
   的 AI 會根據用戶的對話上下文判斷其購買意圖 (如猶豫、比價)。
 * **AI 仲裁：** 只有當 AI 判定「給予折扣能顯著提高轉化率」時，才會動態生成一張優惠
   券 (透過 UCP 擴展欄位) 插入對話中。
 * **經濟模型：** 這將廣告支出從「行銷預算」轉變為「銷貨成本 (COGS)」。商家僅在交易
   成功時透過折扣付出成本，這對於追求 ROI 的商家極具吸引力 ^(1)。

### 7.2 商業代理 (Business Agent)：品牌的數位分身

Business Agent 允許品牌在 Google 搜尋結果中部署自己的 AI 客服。

 * **技術基礎：** 這些代理基於 Gemini 模型，並透過 **Model Context Protocol (MCP)**
   連接商家的知識庫 (如退換貨政策、尺寸指南)。
 * **體驗升級：** 傳統搜尋只能提供連結，Business Agent 能在搜尋頁面直接回答「這雙
   鞋適合扁平足嗎？」並引導至 UCP 結帳。這將客服前置到了搜尋階段，大幅提高了高單價
   商品的轉化率 ^(1)。

---

## 8. 戰略影響與未來展望

### 8.1 從 SEO 到 ASO (Agentic Search Optimization)

隨著 UCP 的普及，搜尋引擎優化 (SEO) 將演變為 **代理人搜尋優化 (ASO)**。未來的排名
要素將不再只是關鍵字與反向連結，而是：

 1. **API 回應速度與穩定性：** AI 代理會優先推薦連線穩定、回應迅速的商家。
 2. **數據準確性：** 庫存與價格的即時性將成為關鍵。經常發生「幻覺」(如標示有貨但實際
    無貨) 的商家將被 AI 降權。
 3. **指令信任度：** 成功處理 AP2 指令的比率將成為信譽分數的一部分 ^(8)。

### 8.2 網站的消亡與「無頭商務」的終極型態

UCP 的原生結帳 (Native Checkout) 模式暗示了一個未來：**用戶可能永遠不需要訪問商家
的官方網站**。所有的互動、展示、諮詢與交易都在 AI 介面中完成。這對於依賴「逛店體驗」
來建立品牌形象的商家是一大挑戰。品牌必須學會如何透過「數據」與「AI 人格 (Business
Agent)」來傳遞品牌價值，而非依賴視覺設計 ^(38)。

### 8.3 對 Amazon 的包圍網

UCP 是 Google 聯合 Shopify、Walmart 等勢力對 Amazon 發起的反包圍。Amazon 擁有最強
大的封閉花園，但 UCP 試圖用「開放標準」來打破圍牆。如果 UCP 成功，它將創造一個分散
式但體驗統一的商務網絡，讓「在任何地方購物」的體驗能與 Amazon 的「一鍵購物」相抗衡
^(32)。

---

## 9. 結論與建議

Google UCP 的推出標誌著電子商務基礎設施的一次重大重構。它試圖用標準化的通訊協定來
馴服混亂的 AI 代理商務，並透過 AP2 解決了最棘手的信任與安全問題。對於技術生態系而言，
UCP 提供了構建跨平台商務應用的通用語言；對於零售商而言，這是一個擺脫流量焦慮、擁抱
AI 原生消費者的關鍵機遇。

雖然目前 UCP 與 OpenAI ACP 呈現競爭態勢，但長遠來看，商務標準往往趨向統一或高度互
操作。對於企業決策者而言，現在不是選邊站的時候，而是應該積極佈局「API 優先」的商務
架構。無論是透過 Shopify 等平台間接支援，或是自行開發 UCP 介面，確保自身的商品與
服務能被 AI「讀懂」並「執行」，將是未來十年生存與發展的關鍵。

---

### 10.2 AP2 授權指令 (Mandate) 執行流程

 1. **初始化 (Initiation)：** AI 代理根據用戶口頭指令，向商家 API 請求建立購物車，商家
    回傳購物車雜湊值。
 2. **簽署請求 (Signing Request)：** AI 將購物車摘要發送給用戶的憑證提供者 (如 Google
    Wallet)。
 3. **生物驗證 (Biometric Auth)：** 用戶在手機上透過 FaceID 確認金額與商家名稱。
 4. **指令生成 (Generation)：** 錢包生成帶有私鑰簽章的 `PaymentMandate`，其中包含 `
    CartMandate` 的雜湊。
 5. **執行交易 (Execution)：** AI 將此簽章指令發送給商家的 UCP 結帳端點。
 6. **驗證與結算 (Verification)：** 商家的支付處理器 (如 Adyen) 驗證簽章有效性，確認
    無篡改後，執行扣款。
 7. **完成 (Completion)：** 商家回傳訂單確認資訊，AI 通知用戶交易完成 ^(19)。

此流程確保了即便 AI 軟體被駭或出錯，也無法在用戶不知情的情況下修改交易金額或對象。

## 相關閱讀

 * [未來的行銷，不是學更多工具，而是建立一套會自己運轉的內容系統](https://cloudsea35.com/content-marketing-system/)
 * [【為什麼你一定要學如何使用openclaw?】](https://cloudsea35.com/why-learn-openclaw/)
 * [2026年世界經濟論壇（WEF）達沃斯年會：地緣政治重構、中等強國崛起與全球經濟的新現實](https://cloudsea35.com/wef-davos-2026-geopolitics/)

### 請按讚：

喜歡 正在載入...

### _相關_