UCP 治理名單攤開來看：坐委員會的不只 Shopify，還有 Google、Stripe、Amazon、Meta

上一篇我寫「UCP 對外包裝得很中立，但我摸到的每一個技術端點都是 Shopify 自家網域」，這句話要修正一半。

不是換算匯率那種小修正，是我把官方文件真的讀完之後，發現治理這件事，比我原本想的嚴肅得多。

先講最重要的：UCP 治理委員會裡坐著誰

上一篇（我把 Shopify 的 UCP Playground 玩了一輪）寫到最後，我在 ucp.new 的子工具頁尾找到官方文件站 ucp.dev，這篇就是我把那份文件真的讀完之後的心得。

文件站有一頁「Announcements（公告）」，我原本只是想確認一下最新版本號，結果越看越不對勁。

2026 年 4 月 28 日的公告寫：Stripe 加入 UCP 的 Governing Council（治理委員會），跟既有的兩個永久成員並列，這兩個永久成員的名字是 Google 跟 Shopify。

4 月 24 日的公告更具體，Tech Council（技術委員會）擴編到 16 席，新加入 5 位具名成員：Amazon 的 Greg Smith、Meta 的 James Andersen、Microsoft 的 Patrick Jordan、Stripe 的 Prasad Wangikar、Salesforce 的 Scot DeDeo。

7 月 16 日，Food Technical Council（餐飲技術委員會）成立，創始成員是 Block（Square）、DoorDash、Google、Toast、Uber Eats。

8 月 11 日，Lodging Technical Council（住宿技術委員會）成立，創始成員是 Amadeus、Booking.com、Expedia、Google、Hilton、Marriott、Trip.com。

你知道為什麼這件事重要嗎？因為這代表 UCP 不是「Shopify 找了個中立品牌名字，自己在後面跳舞」，而是電商、雲端、支付、旅宿、外送幾個產業的重量級玩家，真的一起坐上同一張桌子。

我上一篇判斷錯的地方，老實修正

不是我說，上一篇下的判斷是根據「我實際測到的東西」，這件事本身沒錯：我用瀏覽器打的每一個 API，catalog.shopify.com、discover.shopifyapps.com，清一色是 Shopify 網域。

但這只證明了一件事：目前唯一一個做出公開 demo 的實作方是 Shopify，不代表整個協定是 Shopify 說了算。

這就像從只看一家連鎖加盟店的招牌，進化到去查了整個加盟總部的董事會名單，才發現董事會裡坐著好幾個你認識的大公司，只是剛好第一家開幕的分店掛的是某一家的招牌。

治理是治理，實作是實作，這兩件事我在上一篇混在一起講了，這篇拆開來講清楚。

我以前在雨傘工廠跑業務的時候，供應商合約看到一半常常就放棄了，想說反正條款都差不多，重點看價格跟交期就好。這次為了寫這篇，把 Core Concepts 這頁從頭讀到尾，才發現有些文件真的值得花時間啃，因為魔鬼藏在你以為不重要的那幾條裡。

協定架構長什麼樣：四種角色、三個構件

Core Concepts（核心概念）這頁有一張官方架構圖，我截圖放在下面，你可以直接看：一左一右是 Consumer Platforms（消費端平台）跟 Business Platforms（商家平台），中間堆了四層：Services（商業垂直領域）、Capabilities（能力）、Extensions（擴充）、Transports（傳輸層）。

先講角色。UCP 定義了四種參與者：

• Platform（平台/agent）：消費能力的一方，可能是 AI agent、app、採購系統，甚至另一家公司。例子：AI 購物助理、超級 App、搜尋引擎
• Business（商家）：曝露能力的一方，交易情境下通常要當 Merchant of Record（記錄商家），扛財務責任。例子：零售商、航空公司、連鎖飯店
• Credential Provider，CP（憑證提供者）：管理使用者敏感資料的信任方，例如 Google Wallet、Apple Pay
• Payment Service Provider，PSP（金流服務商）：處理實際扣款的金融基礎設施，例如 Stripe、Adyen、PayPal

再講三個核心構件。Capabilities（能力）是協定的「動詞」，每一個都用反向網域命名，例如 dev.ucp.shopping.checkout，帶日期版本號。Extensions（擴充）用來延伸某個 capability，用的是 JSON Schema 的 allOf 疊加寫法，如果延伸的對象沒進協商結果，這個擴充會被自動修剪掉，不會出現「有折扣擴充卻沒有結帳」這種矛盾狀態。Services（服務）把某個領域的操作打包，一個服務可以透過四種傳輸方式存取：

看到 MCP 了嗎？我上一篇整篇文章測到的 catalog.shopify.com/api/ucp/mcp，只是這四種傳輸方式裡的一種。REST、A2A、Embedded 這三條路，我完全沒碰過。

MCP（Model Context Protocol 我之前也拆過它自己的規格改版）在這裡的角色很單純，就是四選一的其中一種溝通媒介，UCP 才是定義「要溝通什麼」的那一層。

上一篇看到的「協商結果」，這篇看懂「協商演算法」

我上一篇用 Negotiation Explorer 測 allbirds.com，畫面跳出一個五步驟流程：Discover → Select version → Intersect → Resolve → Activate，我當時只把它當成一個好看的視覺化，沒去查背後的邏輯。

Core Concepts 這頁把演算法寫得很白話，三個步驟：

1. Intersect by name（依名稱取交集）：只有雙方都宣告的 capability 才會進入候選名單
2. Select version（選版本）：對每個匹配到的 capability，找雙方版本陣列裡的交集，選最新的那個；完全沒有交集就直接排除
3. Prune orphaned extensions（修剪孤兒擴充）：延伸的 parent capability 沒進交集，這個擴充就被修剪，反覆修剪到穩定為止

這解釋了我上一篇看到的另一個現象：allbirds.com 協商出來的能力清單裡，dev.shopify.catalog 被排除在外，標籤寫「business only」。因為 UCP 用反向網域命名把治理權直接嵌進識別碼裡：dev.ucp.* 歸 UCP 官方治理，dev.shopify.* 歸 Shopify 自己治理，任何廠商都能在自己的網域下定義新能力，不需要 UCP 官方核准。但協商永遠是「雙方都宣告才算數」，dev.shopify.catalog 只有商家單邊宣告，沒有平台端跟著宣告，自然進不了協商後的生效清單。

重點是什麼？ 這套命名規則讓「誰可以定義新功能」這件事天生就是去中心化的，不需要一個中央機構逐一審批。

再補一刀：checkout 能力存在，不等於 agent 能自己按下付款

寫到這裡我又去點開了 Specification 底下 Checkout Capability 那頁的原文，看到一句話，決定回來把上一篇的修正再修正一次。

官方寫的原文是：checkout 預設要由使用者透過一個可信介面手動完成，除非同時協商到 AP2 Mandates 這個擴充。

翻成白話：dev.ucp.shopping.checkout 這個能力，讓 agent 可以幫你建立、管理一個結帳流程（把商品放進去、算好總價、產生一個結帳物件），但預設情況下，最後按下「確認付款」這一步，還是要回到人類手上，在一個商家提供的可信介面完成。真正能讓 agent 自己完成整段付款、不用人類最後點一下的，是另外一個要額外協商的擴充：dev.ucp.common.payment.ap2_mandate（前面提過，這個就是跟 Google AP2 直接掛鉤的那個擴充，靠不可否認的授權書讓自主商務成立）。

所以我上一篇寫「allbirds.com 的能力清單裡白紙黑字掛著 checkout，代表協定做得到結帳」這句話沒有錯，但如果你順著這句話以為「agent 已經可以自己刷卡買東西了」，那就跳過頭了。能建立結帳流程，跟能自主完成付款，中間還隔著一個 AP2 Mandates 擴充要不要開。

這就像從只能問一家店「你們收不收信用卡」，進化到可以問「你們收不收信用卡」跟「你們讓不讓機器人自己刷卡」，這是兩個不同層次的問題，答案也常常不一樣。

付款怎麼設計：三角信任，憑證只能單向流動

UCP 把「接受付款工具」跟「處理付款」拆開，官方叫這個設計 Trust Triangle（信任三角）：Business 跟付款憑證提供者之間有既有的合約關係，Platform 透過憑證提供者的介面把資料代幣化但不擁有資金，最後 Platform 把結果（一組 token 或授權書）交給 Business 完成訂單。

這裡有一條寫得很硬的規則：憑證只能從 Platform 流向 Business，商家絕對不能在回應裡把憑證原封不動送回去。

想像一下，你開一家店，收銀機的邏輯設計成「顧客的信用卡卡號只能往你這邊流一次，你這邊絕對不能回傳給任何人」，這條規則就是在防止付款憑證在系統裡到處流竄、擴大外洩範圍。

付款生命週期分三步：Negotiation（商家宣告支援哪些付款方式）→ Acquisition（Platform 跟憑證提供者拿到 token）→ Completion（Platform 把 token 交給商家，商家自己去扣款）。

身份驗證：只有一種方式是真正「免許可」

UCP 支援四種身份驗證機制：HTTP Message Signatures（RFC 9421）、OAuth 2.0、API Keys、mTLS。

其中只有 HTTP Message Signatures 是真正免許可的：公鑰直接從對方公開的 profile 探索，不需要事先交換任何憑證。其他三種都需要雙方先建立好關係才能用。

以前你要跟一個新商家串接，第一件事是先申請 API 金鑰、簽合約、走一輪審核。現在如果雙方都用 HTTP Message Signatures，理論上你今天發現一個新商家的 profile，馬上就能驗證身份互動，中間不用任何人事先按核准。

版本策略：日期就是版本號

UCP 用 YYYY-MM-DD 當版本號。一次 release（例如 v2026-04-08）是整個核心協定打包發布的一個內部相容快照，profile 裡宣告要用哪個版本，必須精確匹配，除非商家在 supported_versions 裡明確列出還支援哪些舊版本。

第三方擴充跟付款處理器不受這個節奏約束，照自己的時程發版。

文件寫得夠不夠嚴謹，我也查了

還有一頁 Schema Authoring（規格撰寫指南），是給真的要寫 UCP schema 的工程師看的，深度已經超過一般讀者需要，但有一條設計哲學值得抄下來：官方明講「封閉的 enum 是一條單行道」，加新值對嚴格驗證器是破壞性變更，所以除非是永久固定的封閉集合，一律用「開放字串 + 文件註明目前已知值」，讀者端要能容忍未知值。

而且規格文件裡每一段 JSON 範例都會被機器驗證過，官方原話是「schema drift 會弄壞 CI，而不是悄悄誤導讀者」。這呼應了我上一篇在 GitHub 上看到的資訊：273 次 commit、78 個開放中的 pull request，這不是放在那邊生灰塵的文件，是真的有一群人在維護。

這件事對你來說，該做什麼？

如果你是電商經營者或品牌主：

► 別再把 UCP 當成「Shopify 自家的東西」看待。你上架的商品資料，未來可能同時被 Google、Amazon 等多方生態系的 agent 讀取，資料完整度的重要性只會往上升不會下降。

► 如果你的生意也碰旅宿或餐飲，去查一下 Lodging TC、Food TC 的公告，這兩個委員會的組成（Booking.com、Expedia、Marriott、Hilton、DoorDash、Uber Eats、Toast）代表這些領域的規格制定已經開始，早點了解規則，比等規格定案後被動跟上更划算。

如果你是做技術、做產品的人：

► 去讀 ucp.dev 的 Core Concepts 全文，裡面附的能力協商演算法、命名空間治理規則，都是可以直接套用到你自己設計開放協定時參考的範本。

► 想清楚你的整合要走 REST、MCP、A2A 還是 Embedded 這四種傳輸方式的哪一種，這個選擇會決定你未來能接進哪些平台。

收尾：規格是真的公開，治理是真的分權

我這幾天連續寫了兩篇 UCP，一篇測介面，一篇讀文件。兩篇合起來看，我對這件事的判斷是：這不是一家公司包裝出來的行銷話術，是一群原本互相競爭的公司，在「怎麼讓 AI agent 買東西」這件事上，願意坐下來訂同一套規則。

至於這套規則最後會不會真的變成產業標配，還是變成另一個雷聲大雨點小的聯盟公告，現在下結論還太早。

但這年頭就是查證、查證、再查證，光看一個 demo 站就下結論，跟連治理名單都翻過一次才下結論，是兩種不同重量的判斷。

協作聲明與免責

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

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