研究2026-10-017 分鐘讀完

UCP:巨頭們的 Agent 電商協議,沒有合規這一層

Google 牽頭、十家巨頭治理的 UCP 已把 Agent 購物接口定完。我們把兩個版本的規範全文檢索了一遍:制裁、反洗錢、KYC、合規、篩查——零次出現。有防騙層,沒合規層;縫隙剛好落在 Agent 時代最新的風險上。

分享：X LinkedIn Facebook Telegram WhatsApp 微博 🖼 海報（英文）

Google 牽頭的 Universal Commerce Protocol(通用商務協議,下稱 UCP)正在把「AI 替你下單」變成基礎設施。我們把它公開規範的兩個版本從頭到尾檢索了一遍,找這些詞:sanctions(制裁)、AML(反洗錢)、KYC、OFAC、compliance(合規)、screening(篩查)、blocked(封禁名單)。結果:零次出現。這篇文章講三件事:UCP 是什麼、它的安全層實際覆蓋了什麼、以及「錢付給誰」這個監管問題為什麼落在了所有人的縫隙裡。

UCP 是什麼,誰在推

2026 年 1 月 11 日,Google CEO Sundar Pichai 在美國零售聯合會(NRF)年會上發佈 UCP:一個讓 AI Agent 能在任何接入商戶完成「發現商品 → 加購物車 → 結算」的開放標準。共同開發方包括 Shopify、Etsy、Wayfair、Target、Walmart;Visa、Mastercard、Stripe、美國運通等二十餘家機構在發佈時背書。2026 年 4 月,主導協議方向的技術委員會擴充到十家——Amazon、Meta、Microsoft、Salesforce、Stripe 加入。2026 年 3 月起,購物車、商品目錄與商戶接入簡化陸續補齊,整條購物鏈路已經完整。

換句話說:零售、支付、平臺三側的頭部玩家,已經在同一張桌子上把 Agent 購物的接口定完了。這不是概念驗證,ucp.dev 上有規範、參考實現和沙盒。

規範裡的「安全」管什麼

UCP 規範裡確實有安全設計,核心是一層叫 Signals(信號)的機制:平臺在目錄、購物車、結算請求裡向商戶傳遞交易環境數據。截至 2026-08-25 版規範,已定義的信號字段是兩個:dev.ucp.buyer_ip(買家 IP)與 dev.ucp.user_agent(客戶端 UA)。規範特別強調,信號值「MUST NOT be buyer-asserted claims」——必須來自平臺的直接觀測或可獨立核驗的第三方證明,不能是買家自己說的。商戶拿這些信號做授權決策、限流與防濫用;欺詐防控的更多環節,規範把它放在支付憑證方(payment credential provider)一側。

注意這層設計在防什麼:防「買家騙商戶」——盜卡、機器人下單、濫用。這是電商二十年來反欺詐的標準戰場,UCP 把它的接口標準化了。

規範裡沒有的那層

我們在 2026 年 10 月 1 日對 ucp.dev 公開規範做了全文檢索,覆蓋 2026-08-25(最新)與 2026-04-08 兩個版本的 overview 與 reference 文檔。以下詞彙的出現次數全部為零:sanctions、AML、anti-money-laundering、KYC、OFAC、compliance、screening、blocked。任何人都可以在 ucp.dev 上重複這個檢索,一分鐘內復現我們的結論。

也就是說:這套協議定義了錢怎麼流動,但對「錢流向誰、那個收款方是否出現在任何政府名單上、資金有沒有監管風險」,規範本身一個字都沒有。

這是分層,不是疏忽

公平地說,這個空白符合傳統電商的分工假設:合規篩查歷來住在持牌機構裡——收單行、髮卡行、支付服務商(PSP)在自己的義務範圍內做制裁篩查與反洗錢,協議只管接口互通。UCP 沿用了這個假設,就像 HTTP 不管你用它傳什麼內容一樣。協議作者們沒有做錯什麼。

但 Agent 場景恰好在三個地方把這條縫隙放大了:

第一,收款方的構成變了。傳統電商的收款方是有收單行兜底的註冊商戶;而 Agent 經濟裡,任何能提供結算端點的實體都可能成為收款方——尤其當結算走穩定幣等鏈上通道時,收款方可以只是一個昨天剛生成的地址,背後沒有任何持牌機構替你篩過它。

第二,Agent 沒有人類的直覺防線。人會覺得「這個網站不對勁」;Agent 只會核對接口返回格式對不對。端點被仿冒時,它遞給 Agent 的收款地址是攻擊者剛生成的、乾淨得任何名單都查不到——這類風險必須在端點與收款方兩層分別攔,而這兩層恰好都不在 UCP 的 Signals 清單裡。

第三,監管方向正在往收款方識別走。FATF 的轉賬規則(Travel Rule)框架下,接收端機構同樣承擔識別義務;多個司法轄區對穩定幣結算的審查都在加碼。協議棧裡沒有預留這層接口,意味著每個參與方將來都要自己打補丁。

缺的這層長什麼樣

中立地描述,這層能力大致是:結算前對收款方(地址、端點、實體)做一次判定,返回機器可執行的三態(通過 / 人工複核 / 拒絕),附上可獨立核驗的證據(命中哪份名單、哪個版本、何時入庫),並生成一枚可以綁進結算記錄的憑證,供事後審計複核。它可以由 PSP 做、由專門的信任服務方做,也可以作為協議擴展進入 Signals 這樣的機制——UCP 的信號清單是可擴展的,這正是這層未來可能的入口。

利益相關聲明:OceanAlt 做的就是這一層(結算前合規篩查),所以這篇分析帶立場。我們能給出的對沖是方法透明:上文的每個結論都標註了檢索對象、版本與日期,不需要你信任我們——去 ucp.dev 自己搜一遍,比讀完這段話還快。