ACP、UCP 与 AP2 对比：2026 年 10 月的智能体商务协议，以及您的网店需要哪一个

如今有三项开放协议规定了 AI 智能体如何在网店购物。Agentic Commerce Protocol（ACP）来自 OpenAI 和 Stripe。Universal Commerce Protocol（UCP）来自 Google 和 Shopify。Agent Payments Protocol（AP2）由 Google 发起，4 月交给了 FIDO 联盟（FIDO Alliance），它则根本不是结账协议：它定义的是用户已授权一笔付款的签名证明，设计上嵌在 UCP 内部使用。三者都采用 Apache 2.0 许可证。

截至 2026 年 10 月 22 日，三者的状态大不相同。ACP 标注为测试版，最新版本是 2026-04-17，自 7 月 17 日以来没有任何新的提交。它的主要使用方 ChatGPT 在 3 月放弃了独立的结账功能，如今主要用 ACP 接收商品数据。UCP 在 8 月发布了破坏性版本 2026-08-25，而 Google 自己的产品仍在运行 2026-04-08，其结账功能处于抢先体验阶段，仅限美国。AP2 的版本是 v0.2，没有任何 Google 产品的文档提到在使用它。

本文写给正在决定实现哪项协议的网店和电商平台的 CTO 与技术负责人。如果您想了解各 AI 平台在业务层面对网店有什么要求，请先阅读我们的智能体商务（agentic commerce）概览。

一览对比

ACP：Agentic Commerce Protocol

治理与版本

规范仓库写明，ACP 由 OpenAI 和 Stripe 维护，并把它标注为测试版。仓库的治理文件把这两家定为创始维护者（Founding Maintainers）：由它们任命指导委员会的席位（最多七个），并保留一项“作为最后手段”使用的否决权。2026 年 4 月 24 日，Meta 作为第三位首席维护者加入，同时成为委员会成员。Stripe 的文档称 ACP“由 Stripe、OpenAI 和 Meta 创建”，但仓库的声明文件只列出了 OpenAI 和 Stripe。交给中立基金会管理，目前只是一条已经表明的未来路径。

共有五个带日期的版本：2025-09-29（结账和委托支付）、2025-12-12（根据 URBN 和 Etsy 适配器的经验做出的破坏性变更）、2026-01-16（由商家选择的 3DS 服务商）、2026-01-30（能力协商、扩展，以及一个破坏性的支付处理程序框架）和 2026-04-17（购物车、数据源、订单、委托认证、发现和 MCP），后者弃用了 2026-01-30。此后六个月没有再发布任何版本。unreleased/ 文件夹中存放着日期最晚到 7 月 17 日的较小改动，例如数据源更新 ID，以及结账商品上的可选商品 URL。

商家在 2026-04-17 中需要实现什么

结账 API 由商家托管，由智能体调用：

• POST /checkout_sessions 创建会话，POST /checkout_sessions/{checkout_session_id} 更新会话（用的是 POST，不是 PUT），对同一路径发送 GET 读取会话，.../complete 和 .../cancel 结束会话。
• 请求携带 bearer API 密钥和必填的 API-Version 请求头。自 2026-04-17 起，每个 POST 都必须带 Idempotency-Key，并定义了相应的错误：400 idempotency_key_required、409 idempotency_in_flight 和 422 idempotency_conflict。
• 创建请求携带一个 capabilities 对象。智能体声明自己支持什么，卖家返回双方的交集，这样不兼容的问题在付款之前就会暴露出来。
• 商家把订单事件 POST 到 OpenAI 托管的接收端 /agentic_checkout/webhooks/order_events，使用 HMAC-SHA256 签名，签名放在 Merchant-Signature 请求头中。状态从 created 一直到 delivered 或 canceled，adjustments[] 记录退款、退货、争议和拒付。

2026-04-17 版本还新增了一个静态的公开文件 /.well-known/acp.json，其 transports 字段说明网店支持 rest、mcp 还是两者都支持。它新增了基于 Streamable HTTP 的 MCP 绑定，包含五个工具（create_checkout_session、get_checkout_session、update_checkout_session、complete_checkout_session、cancel_checkout_session），认证在服务器配置中完成，而不是每次请求单独认证。它还新增了由智能体托管、商家向其推送数据的 Feed API（数据源 API，POST /feeds、PATCH /feeds/{id}/products），不含支付数据的单一卖家购物车（POST /carts、PUT /carts/{id}），以及委托式 3DS2 认证（POST /delegate_authentication）。订阅则没有：扩展 RFC 把 subscription 列为“定期计费支持（未来）”。

ACP 中的支付如何运作

ACP 最初的方案是委托支付。支付服务商或银行卡信息保管库实现 POST /agentic_commerce/delegate_payment，把一张银行卡（唯一的凭证类型）转换成一个令牌，商户的支付服务商只能在限定范围内使用它：reason（只能是 one_time）、max_amount、currency、checkout_session_id、merchant_id 和 expires_at。用 RFC 的话说：“支付、结算与合规仍然走商户自己的通道。”Worldpay 在文档中给出了这一调用的自有版本，PayPal 则通过 Braintree 中的委托令牌支持 ACP。

自 2026-01-30 起，可接受的支付方式以处理程序的形式在 capabilities.payment.handlers 下声明。变更日志中的支付数据示例：

{ "handler_id": "card_tokenized", "instrument": { "type": "card", "credential": { "type": "spt", "token": "spt_123" } } }

spt 是 Stripe 的 Shared Payment Token（共享支付令牌），在“美国、加拿大和部分欧洲国家”提供。使用 Stripe 的卖家在预览版 API 版本上通过 payment_method_data[shared_payment_granted_token] 对其扣款；使用其他支付处理商的卖家可以把它一次性解析为网络凭证。风险由谁承担，请参阅我们的智能体支付文章。

OpenAI 3 月的调整改变了什么

2026 年 3 月 24 日，OpenAI 写道，“Instant Checkout 的最初版本没有提供我们希望实现的那种灵活性”，它允许商家使用自己的结账流程，并表示正在“扩展 ACP，使其成为整个商品发现过程中连接商家和用户的纽带。”Target、Sephora、Nordstrom、Lowe's、Best Buy、The Home Depot 和 Wayfair 已经为商品发现集成了 ACP，Shopify 的商品目录则经由 Shopify Catalog 接入。这对开发者意味着：

• 真正上线的是数据源。OpenAI 的商家页面写道，购买“在商家自有的网站或应用中完成”，购物功能已面向美国用户上线。数据源接入面向从候补名单中获批的合作伙伴开放：每天通过 SFTP 提交一次包含九个必填字段的全量文件，白天通过 API 更新，促销信息只能通过 API 提交。标准上传“目前以美国为目标”。
• 结账是另一道门槛。数据源规范写道，结账“需要单独启用的集成”。对于 ChatGPT 应用，正式上线的途径是在开发者自己的域名上进行外部结账。对话内的支付面板是一个“仅限部分电商平台”的非公开测试版，它通过 complete_checkout 工具调用把支付令牌交给应用的 MCP 服务器。
• OpenAI 的页面落后于规范。它的结账参考文档仍显示 API-Version 为 2025-09-12，provider 枚举值为 stripe、adyen 和 braintree。请按仓库中的规范开发，并向 OpenAI 确认它接受哪个版本。

仍把 Instant Checkout 描述为已上线的支付服务商页面已经过时。

UCP：Universal Commerce Protocol

治理与版本

Google 于 2026 年 1 月 11 日推出 UCP，它是与 Shopify、Etsy、Wayfair、Target 和 Walmart 共同开发的。治理规则规定，Google 和 Shopify 在治理理事会（Governing Council）中各有一个永久投票权（Stripe 于 2026 年 4 月 28 日加入该理事会），并写明“在 2028 年 12 月之前，Google 代为行使所有空缺席位的投票权”。4 月 24 日，Shopping Tech Council（购物技术委员会）扩大到 16 个席位，新增了 Amazon、Meta、Microsoft、Salesforce 和 Stripe，因此 Meta 和 Stripe 如今同时在 ACP 的委员会和 UCP 的理事会中占有席位。

仓库共有四个版本。2026-04-08 新增了购物车和商品目录能力、请求与响应签名，以及 Get Order。2026-08-25 是破坏性版本：signing_keys[] 改为 keys[] 中的 JWK Set，支付扩展从 dev.ucp.shopping.* 移到了 dev.ucp.common.payment.*，共享 schema 换了位置，$id URL 也随之改变，PAN 和网络令牌成为两种独立的凭证类型。它还新增了与厂商无关的 3DS2、拆分支付、付款条件，以及与 Web Bot Auth 的互操作性。

陷阱就在这里。Google 的配置文件指南只涵盖 2026-04-08 和 2026-01-23，Google 自己位于 ucp.goog 的智能体配置文件声明的是 "version": "2026-04-08"，Salesforce B2C Commerce 26.9 提供的也是这两个版本。而 Shopify 的 Checkout MCP 链接的是 2026-08-25。按最新版本开发，您开发出来的就是一个 Google 没有文档说明的版本。规范给出的办法是一个 supported_versions 对象，它把每个旧版本映射到各自的配置文件 URI。

发现、传输与认证

每个商家都在 /.well-known/ucp 发布一个配置文件，包含 ucp.version、ucp.services 和 ucp.payment_handlers，Google 要求它公开且无需认证。智能体所在的平台也发布一个配置文件，每个请求都在 UCP-Agent 请求头中携带其 URI，并通过至少使用 TLS 1.3 的 HTTPS 传输。认证方式由商家选择：不认证、X-API-Key、OAuth 2.0、双向 TLS 或 RFC 9421 HTTP 消息签名。Google 发送的是 bearer 令牌，其常见问题也提供 mTLS。Idempotency-Key 只是“SHOULD”（建议）级别的要求；接受它的服务器要将其保留至少 24 小时，同一个键配上不同的请求体再次使用时，返回 409。

REST 是核心传输方式，此外还有 MCP、A2A 扩展，以及通过 continue_url 进入的嵌入模式。订单部分是一个 GET /orders/{id}，外加一个从商家发往平台、按 RFC 9421 签名的 webhook。购物车路径与 ACP 相同。结账操作看起来相似，却不能互换：

一套结账核心可以同时服务两者，一张路由表却不行。

UCP 中的支付如何运作

UCP 本身不转移资金。支付处理程序是由凭证提供方编写的规范，例如 Google Pay 的 com.google.pay 或 Shop Pay 的 dev.shopify.shop_pay。商家列出自己接受的处理程序，平台运行其中一个，在 complete 时商家收到一个不透明令牌，再通过自己的支付服务商扣款。

在 Google 的产品上，唯一的处理程序是 Google Pay，使用的认证方式只有 PAN_ONLY，而且您的支付服务商“必须能够处理我们的令牌”。Stripe 为银行卡和 Apple Pay 发布了 com.stripe.payments：“智能体在 Complete Checkout 请求中发送共享支付令牌（SPT），由卖家对其扣款。”Google Pay 仍使用它自己的处理程序。PayPal 通过 Braintree 或其 Orders v2 API 支持 Google Pay 处理程序。

Google 调用您之前有哪些要求

Google 的原生结账指南要求提供 REST 结账 API，而支付环节由 Google 自己掌握：购物者“只通过 Google 界面”输入敏感信息。其服务水平要求是每个端点的可用性至少达到 95%，p50 和 p95 延迟分别为：创建 1 秒和 4 秒，更新 1 秒和 5 秒，完成 6 秒和 10 秒。下单之后，您需要用接入时发放的合作伙伴 ID 和密钥，把状态更新推送到 Google 的 webhook。在 Merchant Center 中，每件商品都要把 native_commerce(checkout_eligibility) 设为 true（它“默认为 FALSE”），退货政策和客服联系方式是必填项，订阅、分期付款、个性化定制商品、二手和翻新商品、预售以及有年龄限制的商品都被排除在外。

更轻量的选项是自 2026-04-08 起提供的购物车转移（cart transfer）：您只需实现购物车创建，Google 把购物车交给您的网站，不需要支付处理程序，也不需要订单 webhook。

真正的限制在于准入。结账功能通过抢先体验计划的意向表“面向特定商家提供”，您要在表上承诺 30 天内开始实施，并接受如果没有进展，访问权限“可能会被撤销”。UCP Checkout 条款“仅适用于美国”。Merchant Center 中的集成中心将于“明年年初”在澳大利亚和加拿大推出；对于其他任何国家，Google 都没有给出结账功能的日期。

Google 之外的 UCP

自 2026 年 4 月 21 日起，Microsoft Merchant Center 在美国接受支持 UCP 的商品数据源。Copilot Checkout 需要符合 UCP 的数据源，接受以美元向美国买家销售的英语商家，每个商家只能使用一家支付服务商，其网店设置中标注着“仅以试点形式向部分客户开放”。Shopify 通过 MCP 提供 UCP，地址为 https://{shop}/api/ucp/mcp，并移除了旧的商品目录和购物车工具。一项住宿预订能力已于 2026 年 9 月 24 日以草案形式合并，但尚未进入任何版本。

AP2：Agent Payments Protocol

AP2 并不是第三种结账方式。它的规范写道，它“作为商务协议中的一项安全功能运行”，并且“专门设计为与 Universal Commerce Protocol（UCP）兼容”。0.1.0 版于 2025 年 9 月 16 日发布，v0.2 于 2026 年 4 月 28 日发布，同一天 Google 把 AP2 捐赠给了 FIDO 联盟。FIDO 的公告提到了一个智能体认证工作组，以及一个由 Mastercard 和 Visa 的成员担任主席的支付工作组，并表示这些贡献“将得到审查并进一步开发”。FIDO 尚未发布任何 AP2 规范。GitHub 仓库现在只接受示例和 SDK 方面的改动，最后一次提交是在 4 月 29 日。

0.2 版定义了 Checkout Mandate（结账授权书，规定购买什么）和 Payment Mandate（支付授权书，规定付款，并带有 payment.amount_range、payment.budget 和 payment.allowed_payees 等约束）。两者都是 SD-JWT，各有封闭和开放两种形式（例如 mandate.payment.1 和 mandate.payment.open.1）。在 Human Present（用户在场）模式下，用户批准的是封闭授权书。在 Human Not Present（用户不在场）模式下，用户批准设定约束条件的开放授权书，其中的 cnf 声明携带智能体的公钥，智能体再在这些限制之内组装封闭授权书。讲解 Intent Mandate 和 Cart Mandate 的教程描述的是 v0.1；这些术语在 v0.2 中已经不存在了。

在 UCP 中，AP2 是扩展 dev.ucp.common.payment.ap2_mandate（2026-08-25 之前为 dev.ucp.shopping.ap2_mandate）。一旦协商启用，商家就要对自己的结账响应签名，平台在 complete 时出示 checkout_mandate 和 payment_mandate，会话随即处于“Security Locked”（安全锁定）状态：任何一方都不得退回普通结账。

目前还没有谁要求使用它。Google 的常见问题称 AP2“对于未来涉及自主 AI 智能体交易的场景尤其有用”。Google 自己的智能体配置文件只列出 Google Pay 这一个支付处理程序，没有声明任何 AP2 能力，其 2026-08-25 配置文件中也没有 AP2 条目。没有任何 Google 产品的文档提到使用 AP2，所以在某个平台协商启用它之前，商家没有什么需要开发的。

周边协议

MCP

ACP 和 UCP 都可以运行在 MCP 之上。MCP 的当前规范 2026-07-28 移除了会话和 Mcp-Session-Id 请求头，去掉了 initialize 握手，要求实现 server/discover，并规定流中断时客户端要用新的 ID 重新发出请求。ACP 的绑定仍然链接 2025-11-25 版的传输规范。结账会话 ID 恰好就是新规范所期望的那种由服务器生成的句柄，而在流中途丢失的 complete 会作为一个全新的请求再次到达：在两个协议中都应把幂等键当作必需项。

WebMCP

WebMCP 是一项拟议中的 Web 标准，用于把网页自身的功能开放给浏览器中的智能体。Shopify 同时以 Checkout MCP 和 Checkout WebMCP 两种形式提供 UCP 结账，两者使用同一个结账对象，Shopify 推荐使用 Checkout MCP。WebMCP 的现状请参阅我们的 WebMCP 指南。

x402 与 MPP

x402 和由 Tempo 与 Stripe 设计的 Machine Payments Protocol 按 HTTP 请求向智能体收取 API、数据或内容的费用。它们不是网店结账协议。请参阅我们的 x402 文章。

Visa Trusted Agent Protocol 与 Mastercard Agent Pay

它们与 ACP 和 UCP 并存，而不是取代它们。Visa 的 Trusted Agent Protocol 为智能体提供“一种标准化的加密方法”，用来向商户证明自己的身份和所获的授权；Mastercard Agent Pay 则是一个面向智能体商务的令牌化计划。Mastercard 的商户指南把 UCP 和 ACP 列为最高的就绪级别，指出“早期采用者目前正在集成”，并建议商户从两个较简单的级别开始。这两个计划的介绍见我们的智能体支付文章。

Personal Agent Protocol

Sierra 表示，它于 2026 年 10 月 6 日与 Meta 共同宣布了 Personal Agent Protocol（“Poppy”），并于 10 月 9 日发布了草案。企业在 /.well-known/poppy.json 发布一个文件；该协议使用 OAuth、JWT、HTTPS、OpenAPI 和 MCP，让个人智能体表明自己的身份，并为任何类型的任务获得顾客的许可，Sierra 称它与 UCP 互为补充。协议网站显示的版本是 0.2，并写着“这是一份草案”。我们在 Meta 自己的新闻中心没有找到关于它的文章。

您需要哪一个？

使用 Shopify

无需开发。Shopify 的智能体店面（agentic storefronts）“对符合条件的网店默认启用”。ChatGPT 通过 Shopify Catalog 接收您的商品目录，并把购物者送到您的网店。对于设在美国并向美国销售的网店，Google 的直接结账默认开启，Copilot 也自动为 Shopify 商家完成了加入。您要决定的是商品数据，以及是否保留直接结账，同时要知道，在 Google 的直接结账中，自定义像素不会触发。

使用 Salesforce、commercetools 或其他平台

Salesforce B2C Commerce 26.9 提供 UCP 2026-01-23 和 2026-04-08：带 supported_versions 映射的 /.well-known/ucp，以及需要 SLAS 令牌才能访问的结账会话端点。Salesforce 把 Google 上的 UCP 结账列为 2026 年 10 月正式上线。一个会话是购物篮的无头（headless）视图，Salesforce 的审计指南警告说，SFRA 和 SiteGenesis 控制器以及“您目前使用的其他 SCAPI 资源不会在此流程中运行”，因此挂在它们上面的逻辑必须复制或桥接到 UCP 结账会话的钩子上。数据源必须以 en-US 为目标，而且 Salesforce“不能让您跳过 Google 的候补名单”。对于 ChatGPT，Salesforce 是 OpenAI 列出的 ACP 数据源提交途径之一。

如果使用 commercetools 或其他平台，请向供应商询问：它提供哪些 UCP 版本和能力，您的哪些钩子会在智能体结账中运行，以及它是否向 OpenAI 发送数据源。

使用自有软件

1. 先做数据源。Google Merchant Center，以及在 OpenAI 接纳您之后，它的商品数据源。ACP 如今在 ChatGPT 中的商业用途恰恰就是这个。
2. 如果您在美国销售且被 Google 接纳，就为 Google 开发 UCP。按 2026-04-08 开发：带 com.google.pay 的配置文件、满足 Google 延迟目标的结账操作、能处理 Google Pay 令牌的支付服务商、订单 webhook 以及数据源属性。或者先只做购物车转移。
3. 只在有理由时才开发 ACP 结账，例如某个 ChatGPT 应用被纳入支付面板测试版。按仓库中的 2026-04-17 开发。
4. AP2：暂时无需任何开发。
5. 一套结账核心。两个协议都需要一个能通过 API 创建、更新、完成和取消，并且可以安全重试的会话。在您的订单、税务和支付逻辑之上把它做一次，上面再加轻薄的 ACP 和 UCP 适配器，在智能体需要的地方加上 MCP。

目前，两个协议都没有为订阅制业务提供原生的智能体结账。

只在美国以外销售

目前三者都无法为您提供智能体结账。ChatGPT 购物和 OpenAI 的标准数据源上传仅限美国；Google 的 UCP Checkout 条款仅适用于美国；Copilot Checkout 服务的是以美元付款的美国买家。Google 宣布的下一步，是“明年年初”在澳大利亚和加拿大推出 Merchant Center 集成中心，英国和欧盟都没有日期。

请保持 Merchant Center 数据源完整；如果您本来就要重建结账流程，就按上文所述做一个由 API 驱动的核心，这样等您的市场开放时，适配器只是一项小工作。从海外向美国销售？请查看每个计划要求商家设在哪里；例如，Shopify 的 Google 直接结账就要求网店位于美国。

从哪里获得帮助

我们为不使用 Shopify 的网店开发协议层：在您现有的订单、税务和支付逻辑之上搭建 /.well-known/ucp 配置文件和结账会话端点，向 Google 发送订单 webhook，为 Google Merchant Center 和 OpenAI 提供商品数据源，以及把同一套结账开放给智能体的 MCP 服务器。这类工作从我们的 AI 智能体开发与 MCP 集成服务开始。

请写信到 office@c9group.dev，告诉我们您使用的平台、支付服务商和销售所在的国家，我们会告诉您适用哪个协议，以及实施它需要哪些工作。Google 和 OpenAI 的计划条款是合同：我们是工程师，不是律师，请在签署之前让顾问审阅。