研究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 自己搜一遍,比读完这段话还快。