> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # UCP 治理名單攤開來看：坐委員會的不只 Shopify，還有 Google、Stripe、Amazon、Meta - URL: https://growthhackers.tw/blog/ucp-dev-protocol-governance-decode/ - Published: 2026-08-29T01:00:00.000Z - Updated: 2026-08-29T01:00:00.000Z - Description: 上一篇我說 UCP 品牌包裝中立、實作長在 Shopify 地盤上。把官方治理公告讀完才發現，坐委員會的不只 Shopify，還有 Google、Stripe、Amazon、Meta、Microsoft、Salesforce。 - Author: Lewis wang - Tags: Universal Commerce Protocol, agentic commerce, Shopify, AI agent, 電商趨勢 上一篇我寫「UCP 對外包裝得很中立，但我摸到的每一個技術端點都是 Shopify 自家網域」，這句話要修正一半。 不是換算匯率那種小修正，是我把官方文件真的讀完之後，發現治理這件事，比我原本想的嚴肅得多。 ## 先講最重要的：UCP 治理委員會裡坐著誰 上一篇（[我把 Shopify 的 UCP Playground 玩了一輪](https://growthhackers.tw/blog/ucp-new-shopify-commerce-protocol-playground/)）寫到最後，我在 ucp.new 的子工具頁尾找到官方文件站 [ucp.dev](https://ucp.dev/?ref=growthhackers.tw)，這篇就是我把那份文件真的讀完之後的心得。 文件站有一頁「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 找了個中立品牌名字，自己在後面跳舞」，而是電商、雲端、支付、旅宿、外送幾個產業的重量級玩家，真的一起坐上同一張桌子。 ![實際截圖：UCP 官方公告，Google、Shopify、Stripe 是治理委員會常任成員，Amazon、Meta、Microsoft、Salesforce 是技術委員會新成員](https://growthhackers.tw/content/images/2026/08/inline-governance-councils-v1-1.png) 實際截圖：UCP 官方公告，Google、Shopify、Stripe 是治理委員會常任成員，Amazon、Meta、Microsoft、Salesforce 是技術委員會新成員 ## 我上一篇判斷錯的地方，老實修正 不是我說，上一篇下的判斷是根據「我實際測到的東西」，這件事本身沒錯：我用瀏覽器打的每一個 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（服務）**把某個領域的操作打包，一個服務可以透過四種傳輸方式存取： | 傳輸方式 | 格式 | 適合場景 | | -------- | ------------- | ---------------------------------- | | REST | OpenAPI 3.1.0 | 標準的伺服器對伺服器整合 | | MCP | OpenRPC | AI agent 透過 Model Context Protocol | | A2A | Agent Card | Agent 對 Agent 協定整合 | | Embedded | OpenRPC | 嵌入式整合 | 看到 MCP 了嗎？我上一篇整篇文章測到的 `catalog.shopify.com/api/ucp/mcp`，只是這四種傳輸方式裡的一種。REST、A2A、Embedded 這三條路，我完全沒碰過。 MCP（[Model Context Protocol 我之前也拆過它自己的規格改版](https://growthhackers.tw/blog/mcp-stateless-core-spec/)）在這裡的角色很單純，就是四選一的其中一種溝通媒介，UCP 才是定義「要溝通什麼」的那一層。 ![官方架構圖：Services、Capabilities、Extensions、Transports 四層結構，MCP 只是四種傳輸方式之一](https://growthhackers.tw/content/images/2026/08/inline-architecture-diagram-v1-1.png) 官方架構圖：Services、Capabilities、Extensions、Transports 四層結構，MCP 只是四種傳輸方式之一 ## 上一篇看到的「協商結果」，這篇看懂「協商演算法」 我上一篇用 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](https://ucp.dev/documentation/core-concepts/?ref=growthhackers.tw) 全文，裡面附的能力協商演算法、命名空間治理規則，都是可以直接套用到你自己設計開放協定時參考的範本。 ► 想清楚你的整合要走 REST、MCP、A2A 還是 Embedded 這四種傳輸方式的哪一種，這個選擇會決定你未來能接進哪些平台。 ## 收尾：規格是真的公開，治理是真的分權 我這幾天連續寫了兩篇 UCP，一篇測介面，一篇讀文件。兩篇合起來看，我對這件事的判斷是：這不是一家公司包裝出來的行銷話術，是一群原本互相競爭的公司，在「怎麼讓 AI agent 買東西」這件事上，願意坐下來訂同一套規則。 至於這套規則最後會不會真的變成產業標配，還是變成另一個雷聲大雨點小的聯盟公告，現在下結論還太早。 但這年頭就是查證、查證、再查證，光看一個 demo 站就下結論，跟連治理名單都翻過一次才下結論，是兩種不同重量的判斷。 --- **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。