摘要：重構數字經濟的交互層
2026年1月，Google 在全美零售聯合會 (NRF) 大會上正式發佈的通用商業協議 (Universal Commerce Protocol, UCP)，標誌着全球數字貿易從“搜索與瀏覽”時代向“代理式商務 (Agentic Commerce)”時代的決定性轉折 。在過去的二十年裏，電子商務主要依賴於一種以人類為整合中樞的模式：用戶作為連接“發現引擎”（搜索引擎、社交媒體）與“履行引擎”（商家網站、結賬頁面）的中間件，手動跨越信息孤島，通過點擊、滾動和重複輸入支付信息來完成交易。UCP 的推出，旨在通過建立一套標準化的“通用語言”，消除這種摩擦，使人工智能 (AI) 代理能夠代表用戶自主發現產品、協商條款並執行購買 。
UCP 由 Google 與 Shopify 聯合開發，並獲得了 Walmart、Target、Wayfair 和 Etsy 等零售巨頭的強力支持。它不僅僅是一組新的 API，而是一個旨在解決“N x N 整合瓶頸”的開放標準——即每一個 AI 代理需要為每一個商家構建定製整合的指數級複雜性難題 。通過標準化商業信息的交換格式，UCP 意圖成為“商業領域的 HTTP”，為下一代 AI 驅動的數字經濟鋪設不可見的底層基礎設施 。
本報告將對 UCP 框架、其技術架構、配套的代理支付協議 (Agent Payments Protocol, AP2)、以及它對全球零售商、開發者和資本市場引發的深遠經濟變革進行詳盡的深度剖析。
第一部分：戰略必要性與市場背景
1.1 傳統搜索的危機與“行動引擎”的崛起
UCP 的推出，本質上是 Google 面對傳統搜索引擎及其廣告商業模式潛在生存危機的一次戰略反擊。隨着以 Gemini、ChatGPT 和 Perplexity 為代表的生成式 AI (Generative AI) 的興起，用戶獲取信息的方式正在發生根本性轉變：從尋找“十個藍色連結”的列表，轉向尋求直接的答案和任務的完成 。在這種新範式下，用戶期望的是結果的交付，而非導航的中轉。
然而，在 UCP 問世之前，大語言模型 (LLM) 與互聯網的交易層之間存在着根本性的斷裂。AI 可以根據參數記憶撰寫關於咖啡機的詩歌，或者對比兩款相機的技術規格，但它無法可靠地檢查並確認用戶家附近實體店的實時庫存，無法應用特定的忠誠度折扣，更無法在不產生幻覺或不跳轉頁面的情況下執行購買 。這種“執行鴻溝 (Execution Gap)”將 AI 限制在了被動顧問的角色，而非真正的主動代理。
Google 通過 UCP 實施的戰略機動，旨在跨越這一鴻溝，將其搜索界面從“推薦引擎”轉型為“交易引擎”。通過在 Google 搜索和 Gemini 的 AI 模式 (AI Mode) 中啟用“原生結賬 (Native Checkout)”，Google 試圖捕獲那些高意圖的商業時刻——這些時刻以往可能會流失到 Amazon 這樣的封閉生態系統或垂直領域的應用程序中 。這種轉變既是防禦性的（保護 Google 在商業搜索領域的主導地位），也是進攻性的（試圖將商業的接口層商品化，同時確立底層數據交換的新標準）。
1.2 “反亞馬遜聯盟”：零售商為何結盟
UCP 的首發合作伙伴陣容——Shopify, Walmart, Target, Etsy, Wayfair——揭示了一個清晰的戰略意圖：針對商業權力中心化（主要以 Amazon 為代表）的聯合防禦 。多年來，零售商面臨着兩難的囚徒困境：要麼依賴 Amazon 巨大的流量但犧牲數據所有權和利潤率，要麼維持獨立的品牌網站但在流量獲取和轉化摩擦中苦苦掙扎。
UCP 提供了一條“第三條道路”：聯邦式商業模式 (Federated Commerce Model)。通過採用 UCP，像 Shopify 和 Walmart 這樣的零售商可以將其產品目錄和結賬能力暴露給數以百萬計的 AI 代理（首先是 Google 的），同時不放棄“記錄商家 (Merchant of Record)”的地位 。至關重要的是，UCP 的設計理念確保了商家保留客戶關係、交易數據和業務邏輯。協議負責“協商”交易，但最終由商家“執行”交易。
對於 Shopify 而言，UCP 充當了一個巨大的分發乘數。它允許其平台上的數百萬商家瞬間變得“代理就緒 (Agent-Ready)”，有效地將每一個 Shopify 店鋪轉化為一個可以被 AI 買家訪問的無頭 (Headless) 節點 。這與 Shopify “無處不在的商業 (Commerce Everywhere)” 戰略高度契合，將其觸角從傳統的在線商店延伸到了社交媒體、遊戲，以及現在的 AI 代理中。
1.3 破解“N x N”整合瓶頸
要理解 UCP 的必要性，必須分析標準化之前代理式商務面臨的技術壁壘。在沒有統一協議的情況下，任何希望啟用購物功能的 AI 代理開發商，都需要為 Shopify、Magento、Salesforce Commerce Cloud、WooCommerce 以及成千上萬個定製的企業技術棧編寫特定的 API 連接器。每一個連接都意味着獨立的維護成本、獨特的身份驗證流程和差異化的錯誤處理機制。
這就造成了一個經典的“N x N”複雜性問題： 個 AI 代理乘以 個商家 。這種複雜性僅有利於那些擁有無限工程資源的巨頭，而將中小企業和新興的 AI 初創公司拒之門外。UCP 將這種複雜性坍縮為 模型。一個代理只需要“會説” UCP 語言；任何“會説” UCP 語言的商家就都變得可訪問。這種標準化類似於 SMTP 協議如何允許不同服務商之間互發電子郵件，或者 HTML 如何允許瀏覽器渲染來自任何伺服器的網頁 。
第二部分：UCP 技術架構深度剖析
UCP 技術架構
2.1 核心設計哲學：基於能力的協商 (Capability-Based Negotiation)
UCP 的核心不僅僅是數據傳輸，它是關於發現與協商的協議。與要求嚴格遵守靜態模式的剛性 API 不同，UCP 承認商業現實的混亂性——不同商家的折扣規則、運輸選項和稅收計算邏輯千差萬別 。該架構模仿了人類商務中的“握手”機制，代理和商家伺服器交換各自的“能力 (Capabilities)”以確定交易的參數。
系統採用分層架構以確保可擴展性和穩定性 ：
- 購物服務層 (Shopping Service Layer)： 定義交易的不可變原語——結賬會話 (Checkout Session)、行項目 (Line Items)、總計 (Totals)、消息 (Messages) 和狀態 (Status)。這確保了每一次 UCP 交互都共享相同的基本 DNA。
- 能力層 (Capabilities Layer)： 代表主要的功能區域（例如：結賬、訂單追蹤、目錄發現）。這些能力是獨立版本化的，允許商家在不破壞其目錄瀏覽能力的情況下升級其結賬能力。
- 擴展層 (Extensions Layer)： 這是最靈活的一層，允許領域特定的模式。例如，傢俱零售商可以使用“預約配送”擴展，而數字商品賣家則使用“即時下載”擴展。
2.2 發現機制：.well-known/ucp
任何 UCP 交互的入口點都是發現階段。模仿現有的 Web 標準，兼容 UCP 的商家會在一個標準化的端點發布 JSON 清單 (Manifest)：/.well-known/ucp 。
當一個 AI 代理（例如 Gemini 或第三方購物機器人）訪問商家的域名時，它首先查詢此端點。響應內容充當了服務的“菜單”，聲明如下信息：
- 支持的能力： “我支持 Checkout v1.0 和 Order Tracking v2.0。”
- 支持的支付處理程序： “我接受 Google Pay, Shop Pay, 和 Apple Pay。”
- 支持的擴展： “我支持‘忠誠度積分’擴展和‘店內取貨’擴展。”
- 身份驗證要求： “我需要 OAuth 2.0 進行用戶識別。”
這種機制將代理與商家的後端實現解耦。代理不需要知道商家運行的是 Shopify 還是定製的 Python 伺服器；它只需要能夠讀取 UCP 清單 。
2.3 動態協商邏輯
一旦代理讀取了清單，“協商”過程即刻開始。這是對代理能做什麼與商家需要什麼之間交集的實時計算 。
-
場景示例： 用戶要求代理“買這雙跑鞋，並使用我的退伍軍人折扣。”
-
協商過程： 代理檢查商家的 UCP 配置文件。
-
商家側： “我支持
dev.ucp.shopping.discount擴展。” -
代理側： “我也支持
dev.ucp.shopping.discount。我將傳輸折扣程式碼。” -
結果： 折扣程式碼輸入字段會在交易載荷中暴露出來。
反之，如果商家不支持折扣擴展，代理會先驗地知道不應向用戶提供該選項，從而防止了“功能幻覺”帶來的挫敗感。這種動態協商發生在每一次請求中，類似於 HTTP 內容協商，確保了交易的高保真度 。
2.4 傳輸與綁定 (Transports and Bindings)
UCP 是傳輸無關的 (Transport-Agnostic)，這意味着它不綁定於單一的數據傳輸方式。規範定義了多種傳輸協議的綁定，以確保最大的兼容性 ：
| 傳輸協議 | 適用場景 | 優勢 |
|---|---|---|
| HTTP/REST | 基於 Web 的標準交互 | 易於與現有的電子商務微服務整合，通用性最強。 |
| JSON-RPC | 有狀態、雙向通信 | 適用於需要快速交換多條消息的場景（例如：用戶添加商品時實時更新購物車）。 |
| Agent2Agent (A2A) | 代理間直接通信 | 允許“購物者代理”與“商家代理”在無人干預的情況下進行對話與協作。 |
| Model Context Protocol (MCP) | LLM 數據連接標準 | UCP 包含 MCP 綁定，實際上允許任何兼容 MCP 的 LLM（如 Claude 或 ChatGPT）立即“插入”UCP 商業軌道 。 |
2.5 結賬流程：原生 vs. 嵌入式
UCP 支持兩種主要的結賬模式，以適應不同程度的信任和複雜性需求 。
2.5.1 原生結賬 (Native Checkout - The "Headless" Path)
在此流程中，交易完全在 AI 界面（例如 Gemini 聊天窗口）內發生。商家的 API 提供數據，AI 負責渲染 UI 組件（產品卡片、運輸選擇器、“購買”按鈕）。
- 優勢： 無縫的用戶體驗；零上下文切換；由於摩擦減少，轉化率通常更高。
- 劣勢： 商家對視覺品牌的控制力較弱。
- 機制： 代理調用
checkout_session端點，創建會話 ID。它通過 API 調用更新行項目。當用戶確認時，代理通過 AP2 提交支付令牌至complete端點。
2.5.2 嵌入式結賬 (Embedded Checkout - The "Handoff" Path)
對於複雜的購買（例如：定製配置的筆記本電腦、需要處方的藥品），原生流程可能不足以應對。UCP 支持嵌入式能力。
- 機制： 商家在結賬會話載荷中提供一個
continue_url。 - 流程： 代理將用戶導航至商家託管的安全 Web 視圖或 iframe，以完成特定細節（如上傳處方或選擇布料樣本）。
- 交接 (Handoff)： 至關重要的是，UCP 保持了狀態。代理將會話上下文傳遞給 Web 視圖，因此用戶無需重新輸入信息。一旦特定任務完成，Web 視圖可以通過 JSON-RPC 消息將控制權交還給代理 。
2.6 身份與安全：OAuth 2.0 與賬户連結
商業交易需要知道誰在購買。UCP 利用行業標準的 OAuth 2.0 協議進行身份連結 。
- 流程： 當用戶想要購買時，代理檢查是否擁有該商家的令牌。如果沒有，它會提示用戶“連結賬户”。
- 授權： 用戶被短暫重定向到商家的登錄頁面（或使用保存的 Passkey），授予代理
ucp:scopes:checkout_session權限。 - 令牌： 代理接收刷新令牌，允許其在未來進行購買時無需每次都重新驗證用戶（受安全策略限制）。
- 訪客結賬： UCP 也支持標準化的訪客結賬流程，代理提供運輸/賬單信息而無需建立永久賬户連結 。
2.7 開發者實施指南：無 Shopify 場景下的手動整合
對於不使用 Shopify 的開發者或定製平台（如 Magento, WooCommerce），實施 UCP 需要以下技術步驟 ：
- 環境搭建： 使用 Python SDK (UCP 官方提供)。
mkdir sdk
git clone https://github.com/Universal-Commerce-Protocol/python-sdk.git sdk/python
uv sync # 使用 uv 進行依賴管理
- 業務伺服器配置： 開發者需要設置一個伺服器來託管業務 API，並指向產品數據庫。
uv run server.py --products_db_path=/tmp/ucp_test/products.db --port=8182
- 端點實現： 必須實現三個核心 REST 端點：
POST /checkout_sessions: 創建會話。PATCH /checkout_sessions/{id}: 更新購物車（添加商品、應用折扣）。POST /checkout_sessions/{id}:complete: 提交支付並完成訂單。
- 清單發佈： 在伺服器的
/.well-known/ucp路徑下託管 JSON 文件，聲明支持的能力和支付處理程序。
第三部分：信任層框架 —— 代理支付協議 (AP2)
如果説 UCP 處理的是商業的物流（買什麼），那麼 代理支付協議 (AP2) 處理的則是風險（怎麼付）。與 UCP 同步發佈的 AP2 解決了代理式商務最關鍵的障礙：信任。用戶如何信任 AI 花他們的錢？銀行如何信任一個由機器人發起的交易是經過人類授權的？
AP2 代理支付協議
3.1 確定性意圖 (Deterministic Intent) 的哲學
當前的大語言模型是概率性的——它們預測下一個字。然而，支付必須是確定性的。銀行不能處理一筆“大概可能是”50 美元的交易。AP2 通過引入 Mandates（授權指令） 來彌合這一差距：這是一種防篡改、經過加密簽名的數字合同，作為用戶意圖的可驗證證明 。
3.2 Mandate 結構與類型
AP2 定義了不同類型的 Mandate，以覆蓋不同的交互模型：
表 1：AP2 Mandate 類型解析
| Mandate 類型 | 用戶在場狀態 | 使用場景 | 安全機制 |
|---|---|---|---|
| 購物車指令 (Cart Mandate) | 人類在場 (Human-Present) | 用戶盯着屏幕，批准特定的商品和價格。 | 商家對購物車載荷簽名（保證價格/庫存）；用戶用私鑰對該載荷進行“反籤 (Countersign)”。 |
| 意圖指令 (Intent Mandate) | 人類不在場 (Human-Not-Present) | “價格下跌時幫我買。”（委託授權） | 用戶預先簽署一套邏輯規則（價格 < X, 商品 = Y）。代理持有此憑證，並在條件滿足時出示。 |
- 技術細節： 意圖指令實際上是一種受限的預授權。它不像傳統的信用卡預授權那樣鎖定資金，而是鎖定“購買條件”。如果代理試圖在價格高於 X 時執行購買，或者購買商品 Z 而非 Y，加密簽名驗證將失敗，支付網關會拒絕交易 。
3.3 可驗證憑證與支付處理程序
AP2 利用了 W3C 可驗證憑證 (Verifiable Credentials, VC) 標準。當一筆支付被提交時，它不僅僅是一個信用卡號；它是一個包含以下內容的捆綁包：
- 支付令牌 (Payment Token)： 代幣化的卡信息。
- 簽名指令 (Signed Mandate)： 用戶意圖的證明。
- 加密證明 (Cryptographic Proofs)： 驗證代理和商家的身份。
這種結構允許支付處理商（如 Stripe, Adyen, PayPal）區分“用戶點擊購買”和“代理執行預批准訂單”，從而實現複雜的風險建模和欺詐檢測 。主要金融機構（Visa, Mastercard, Amex）的參與表明，AP2 指令可能很快成為處理代理發起交易的強制性要求，從而將責任從消費者身上轉移開 。
第四部分：生態系統整合與比較分析
4.1 UCP vs. ONDC (印度)
印度的開放數字商務網絡 (ONDC) 經常被引用為 UCP 的前身或平行物。雖然兩者都共享“解綁”商業和打破平台壟斷的理念，但它們在技術堆棧中的層級不同 。
表 2：UCP 與 ONDC (Beckn Protocol) 的架構對比
| 特性 | ONDC (基於 Beckn 協議) | 通用商業協議 (UCP) |
|---|---|---|
| 主要目標 | 民主化電子商務接入；解綁物流、買家應用和賣家應用。 | 標準化代理式 (Agentic) 交互；解決 AI 的技術整合瓶頸。 |
| 架構基礎 | 去中心化網絡節點註冊表；Beckn 協議。 | 標準化 API 模式 & 發現機制；基於 HTTP/JSON。 |
| 核心關注點 | 基礎設施（物流配送、超本地化服務）。 | 交互（發現、協商、結賬）。 |
| 地理範圍 | 主要在印度（政府支持）。 | 全球（Google & Shopify 主導）。 |
| 互操作性 | 關注不同服務提供商（如物流與電商）的互聯。 | 關注 AI 代理與商家目錄的“對話”。 |
| 關係 | Beckn 是網絡的“鐵軌”。 | UCP 是代理的“語言”。UCP 可以作為抽象層運行在 ONDC 之上 。 |
值得注意的是，UCP 與 Beckn 的原則是兼容的。事實上，一些分析師將 UCP 描述為一種“通用抽象層”，理論上可以置於 ONDC 網絡之上，將 ONDC 特定的物流流程轉化為通用全球 AI 代理可以理解的語言 。
4.2 UCP vs. OpenAI 代理商務協議
有跡象表明，OpenAI 正在與 Stripe 合作開發自己的“代理商務協議” 。雖然細節較少，但競爭將非常激烈。
- UCP 的優勢： 採取“聯盟”策略——擁有 Shopify 和 Walmart 的營運能力，賦予了它即時的庫存深度。
- OpenAI 的路徑： 可能更依賴 Stripe 的支付軌道。
- 未來格局： UCP 的開源性質以及與 MCP（OpenAI 也受其影響）的兼容性表明，未來可能出現融合，或者類似於 Blu-ray 與 HD DVD 的“格式之戰”，商家最終可能被迫支持多個清單文件（如
.well-known/ucp和.well-known/openai-cp）。
4.3 融入“代理堆棧” (Integration with the Agent Stack)
UCP 並非孤立存在，它是 AI 時代“協議堆棧”的一部分 ：
- 通信層 (A2A - Agent2Agent)： 允許不同代理交談。一個“旅行代理”機器人（使用 A2A）可以與“預訂代理”機器人交談。
- 上下文層 (MCP - Model Context Protocol)： 允許 LLM 理解數據（讀取 PDF、查詢數據庫）。
- 商業層 (UCP)： 允許代理進行交易（協商價格、結賬）。
- 信任層 (AP2)： 確保資金安全流動。
這種模塊化設計意味着開發者無需重新造輪子。構建“個人造型師”代理的開發者無需構建支付網關；他們只需實施 UCP/AP2，讓底層軌道處理金融複雜性。
第五部分：營運 UCP —— 商家與開發者體驗
5.1 實施 UCP：從零到一的流程
對於商家而言，成為 UCP 兼容者的過程因平台而異 。
Shopify 商家： 整合基本上是原生的。Shopify 已更新其後端，為其數百萬商家自動生成 UCP 清單。管理面板中的一個開關（“啟用代理店面”）即可立即將目錄暴露給 Google 的 AI 表面 。這賦予了 Shopify 巨大的“先發優勢”，瞬間用數百萬個 SKU 填充了 UCP 生態系統。
審批與門檻： 目前，Google 對 UCP 的“原生結賬”功能實施了嚴格的准入控制。商家需要通過“候補名單 (Waitlist)”申請，且初期僅限於在美國境內履約並擁有美國銀行賬户的商家 。這表明在協議早期階段，Google 極度重視信任和品質控制，寧願犧牲速度也要防止不良商家利用 AI 渠道進行欺詐。
5.2 新的 SEO：代理優化 (Agent Optimization, AO)
UCP 引入了一門新學科：代理優化 (AO)，作為搜索引擎優化 (SEO) 的繼任者 。
- 舊世界 (SEO)： 優化關鍵詞、反向連結和頁面加載速度，以在藍色連結中排名靠前。
- 新世界 (AO)： 優化能力和數據的結構化程度。
- 準確性 (Accuracy)： 代理會嚴厲懲罰幻覺。如果商家的 UCP 源顯示“有貨”但結賬失敗，代理會在內部降低該商家的“可靠性評分”。
- 協商能力 (Negotiation Power)： 暴露細粒度能力的商家（例如：在 UCP 模式中結構化地聲明“接受 90 天退貨”）將比政策不透明的商家更受代理青睞。
- 風險信號 (Risk Signals)： Google 會將“風險信號”（設備數據、會話數據）回傳給商家，允許商家接受/拒絕交易。優化這些閾值對於轉化至關重要 。
5.3 風險與挑戰：商家的達摩克利斯之劍
儘管 UCP 承諾了覆蓋範圍，但也給商家帶來了重大風險 ：
- 商品化 (Commoditization)： 如果 AI 控制了界面，商家的品牌資產（字體、顏色、氛圍）將被剝離。商家變成了單純的產品管道。
- 利潤擠壓 (Margin Pressure)： AI 代理是無情的優化器。一個被編程為尋找最低價格的“購物代理”可以瞬間比較 50 個 UCP 兼容賣家並選擇最便宜的，這將比人類比價購物更快地侵蝕利潤率。
- 數據依賴： 雖然商家保留“記錄商家”的身份，但交互數據（用戶問了什麼，猶豫了多久）主要留在代理（Google）手中，而非商家。UCP 試圖通過共享部分信號來緩解這一問題，但主要上下文仍由 AI 掌握。
第六部分：未來展望與經濟影響 (2026-2030)
6.1 經濟轉移：從基於廣告到基於交易
UCP 的廣泛採用威脅到了價值 2000 億美元的搜索廣告市場 。如果用戶停止點擊搜索廣告，轉而通過代理直接購買，“每次點擊成本” (CPC) 模式將走向消亡。UCP 暗示了向“每次行動成本” (CPA) 或“每次交易成本”模式的轉型。Google 的“直接優惠 (Direct Offers)”功能——商家競價在 AI 結賬流程中直接放置折扣——正是這種新廣告模式的雛形 。
摩根士丹利 (Morgan Stanley) 預測，到 2030 年，代理式購物者可能佔據美國電子商務支出的 10-20%，代表着 3850 億美元 的市場轉移 。這不僅僅是新錢；這是從“瀏覽”渠道轉移到“代理”渠道的錢。
6.2 “個人參謀長”的崛起
有了 UCP 和 AP2，“個人 AI”的願景在技術上變得可行。我們很可能會看到專業化“生活代理”的出現：
-
食品儲藏室代理： 監控消費習慣，並通過 UCP 自動購買雜貨，在用戶無需打開應用程序的情況下，跨 Walmart 和 Target 協商批量折扣 。
-
旅行代理： 編排航班、酒店和餐廳預訂，持有“意圖指令”以便在航班取消時立即重新預訂。
6.3 對中小企業 (SME) 的影響
矛盾的是，UCP 可能會為中小企業創造公平的競爭環境。在瀏覽器時代，小商店無法與 Amazon 的 UI/UX 和物流速度競爭。在 UCP 時代，如果一家小店擁有獨特的商品並使用 Shopify（處理 UCP 技術），AI 代理發現它的難易程度與發現 Walmart 一樣 。 “發現”將基於產品的相關性，而非營銷預算或域名權重。然而，這完全取決於 AI 代理算法的中立性——這將是未來監管的主要戰場。
6.4 全球推廣與監管摩擦
儘管 UCP 在美國率先推出，但在全球範圍面臨複雜的道路。歐盟的《數字市場法案》(DMA) 將審查 Google 的“原生結賬”是否偏袒其自家的支付軌道 (Google Pay) 或 UCP 合作伙伴。目前的“候補名單”審批流程 已經暗示了一個有門檻的生態系統，這可能會招致反壟斷關注。此外，不同地區可能採用不同的協議（如印度的 ONDC），迫使全球代理必須會説多種商業“方言”。
結論
通用商業協議 (UCP) 不僅僅是一份技術規範；它是互聯網下一個時代的宣言。它承認 Web 的複雜性已經超出了人類的耐心，必須引入一層 AI 中介來處理繁瑣的發現和交易任務。
對於 Google 而言，UCP 是抵禦傳統搜索相關性下降的護城河。對於 Shopify 和零售商，這是在後 Web 世界中爭取分發權的賭注。對於開發者，這是一個新的原語——編寫程式碼來花錢的能力。
正如任何協議一樣，成功取決於採用率。憑藉全球最大搜索引擎、全球最大電商平台軟體 (Shopify) 和全球最大零售商 (Walmart) 的支持，UCP 在第一天就已達到了“逃逸速度”。“商業的 HTTP”已經到來；現在的問題不是代理是否會為我們購物，而是我們多快能信任它們來掌管我們的錢包。
