AI 智能体的商务协议格局：UCP、ACP、AP2 与 MCP——协议栈如何协同

关键要点

• UCP 拥有 11 个共同开发方，包括 Google、Shopify、Amazon、Meta 和 Stripe——它正从购物扩展到住宿和餐饮领域，使其成为截至 2026 年 8 月覆盖面最广的商务协议联盟。
• ACP 由 OpenAI 和 Stripe 治理（Meta 现已加入），目前处于测试阶段，自 2025 年 9 月起已在 ChatGPT 中上线——它覆盖智能体驱动的结账，但不涉及 B2B 采购流程。
• AP2 为 60 多个组织的智能体主导支付提供保障，Coinbase x402 是其稳定币扩展——截至 2026 年，x402 已在 Coinbase Base 上处理了 1 亿笔智能体支付。
• MCP 是 UCP 与 ACP 底层共用的智能层——每一家采用 UCP 的 Shopify 门店都会暴露一个实时的 MCP 端点，而 ACP 的三层架构将 MCP 置于中间层。
• 这四个协议都没有覆盖 B2B 语义层——客户分层定价、批量 RFQ 报价、针对 ERP 的库存预留，以及跨渠道的订单归因，这些都需要在其之上叠加一个自定义 MCP 模块。

2025 至 2026 年间，两项开放标准在数月之内相继推出，从不同方向解决同一个问题：在没有人为每家门店手工搭建定制集成的情况下，AI 智能体如何发现商品、协商价格、完成结账并支付？通用商务协议（UCP）由 Google 和 Shopify 共同开发，联合了包括 Amazon、Meta、Microsoft、Salesforce 和 Stripe 在内的 11 个共同开发方。智能体商务协议（ACP）由 OpenAI 与 Stripe 维护，自 2025 年 9 月起已在 ChatGPT 中上线。第三个协议——智能体支付协议（AP2）——负责保障支付授权层，已有 60 多个组织参与。这三者都建立在模型上下文协议（MCP）之上，MCP 提供了智能体与门店数据之间的智能层连接。

本文梳理了这几个协议各自的定位、彼此的重叠之处，以及 B2B 商务的缺口所在——因为这四个协议都是为消费者的发现与结账场景设计的，而不是为中端 B2B 分销商在 NetSuite 或 BigCommerce 上实际需要的报价、分层定价和库存预留工作流而设计。

四层协议栈

商务协议的格局并非单一标准，而是由四个互补协议构成的一套栈，各自解决智能体交易中的不同层面：

层级	协议	治理方	作用	生产状态
发现与商务	UCP	Google、Shopify，共 11 个共同开发方	智能体发现商品、构建购物车、移交给商户完成结账、追踪订单	已上线（Shopify 2026 春季版）；正扩展至住宿和餐饮领域
结账交互	ACP	OpenAI、Stripe、Meta	智能体驱动的购买交互模型；三层架构（交互层 → 智能层 → 商务层）	测试阶段；自 2025 年 9 月起已在 ChatGPT 中上线
支付授权	AP2	Google、60 多个组织、FIDO 联盟	可验证凭证、支付授权令、智能体主导支付的加密审计轨迹	v0.2；正在 FIDO 联盟内推进标准化
智能与工具	MCP	Anthropic（最初提出）	智能体与工具的连接：读取商品数据、查询库存、调用门店 API	规范已于 2026-07-28 定稿；已注册约 2 万个服务器

MCP 本身并非商务协议——它是 UCP 与 ACP 都依赖的智能层。UCP 的规范文档明确指出"内置 MCP 支持"。ACP 的三层架构将 MCP 置于中间：上层是交互层（智能体与买家之间），中间的智能层（MCP）负责连接智能体与门店数据，下层的商务层负责履约。每一家实现了 UCP 的 Shopify 门店都会暴露一个实时的 MCP 端点，供智能体查询商品目录、管理购物车并获取订单状态。

UCP——从发现到结账的标准

UCP 是覆盖面最广的联盟。ucp.dev 网站列出了横跨三个行业的 11 个共同开发方：购物领域（Google、Shopify、Etsy、Wayfair、Target、Walmart、Amazon、Microsoft、Meta、Salesforce、Stripe）、住宿领域（Amadeus、Booking.com、Expedia、Hilton、Marriott、Trip.com）以及餐饮领域（DoorDash、Square、Toast、Uber Eats）。认可合作伙伴名单则包括 Visa、Mastercard、Coinbase、PayPal、Adyen、Klarna 和 Worldpay。

UCP 支持 REST 与 JSON-RPC 传输方式，并内置了对 AP2、A2A 和 MCP 的支持。Shopify 开发者文档证实，Shopify 的 MCP 工具在买家旅程的每一步都实现了 UCP：协商与身份验证（基于信任等级的档案）、商品发现（在数亿条商品列表中检索）、购物车与结账（构建购物车、转换为结账、移交商户完成支付），以及订单监控（订单 webhook，以及通过 get_order MCP 工具按需获取订单状态）。

通用购物车 API 让 AI 智能体能够通过 UCP，将来自任意商户（无论是否在 Shopify 上）的商品汇总到一个统一的购物车中。Shopify 的认证计划（Shopify + OpenAI + Google，目前处于封闭测试阶段，2026 年第三季度将扩大开放）实际上为智能体打造了一个新的发现层：结构清晰的数据决定着智能体能否找到并与某家门店完成交易。

ACP——结账交互模型

ACP 采取了不同的架构路径。它不是一个广泛的多行业联盟，而是由 OpenAI 和 Stripe 治理（Stripe 的文档现已将 Meta 列为共同创建方）作为创始维护方，并规划向更广泛的社区治理过渡。该规范目前处于 Apache 2.0 协议下的测试阶段。

ACP 定义了用于智能体驱动商务的可组合构建模块。Stripe 的 Agentic Commerce Suite 提供了参考实现：智能体发现商品、将其加入购物车，并使用 Stripe 的支付基础设施完成购买。BigCommerce 通过与 Stripe 的合作走上了 ACP 路线，而非自建第一方的门店数据 MCP 服务器——BigCommerce 连接器文章对此有深入分析。

ACP 的三层架构——交互层 → 智能层（MCP）→ 商务层——意味着 MCP 是其中的连接组织。智能体并不会绕过 MCP 去使用 ACP；它使用 MCP 与门店对话，同时使用 ACP 来组织购买交互。

AP2——支付授权层

AP2 位于 UCP 和 ACP 之下，充当支付信任协议。Google 于 2025 年 9 月宣布推出 AP2，并有 60 多个合作组织参与。目前它正在 FIDO 联盟内推进标准化。AP2 在 A2A（智能体间通信）的基础上扩展出结构化的支付授权令——意图授权令、购物车授权令和支付授权令——以此提供可验证、不可抵赖的证明，证明用户已授权智能体进行某笔特定购买。

Coinbase x402 是 AP2 的稳定币扩展，其名称源自 HTTP 状态码 402（"需要付款"）。x402 让智能体能够通过 HTTP 直接以稳定币为 API 调用、服务和微交易付款。Chainalysis 报告称，x402 在 Coinbase Base 上已处理超过 1 亿笔智能体支付，证明该稳定币通道正以生产规模运转。

围绕智能体商务，三个相互竞争的支付网络已经形成：Visa Trusted Agent、Mastercard Agent Pay（30 多个行业合作伙伴，通过 MDES 提供 Agentic Tokens）以及 Coinbase x402。Stripe 正在同时配置来自 Mastercard 和 Visa 的智能体网络令牌，将自身定位为传统卡组织通道与智能体支付层之间的桥梁。

下图展示了四层商务协议栈，以及需要自定义 MCP 模块填补的 B2B 语义层缺口：

协议栈的交汇之处——以及尚未交汇的地方

这四个协议正在朝着一套共享架构收敛：UCP 或 ACP 负责商务交互，AP2 负责支付授权，MCP 负责智能层，A2A 负责智能体间的委托协作。UCP 规范明确将 AP2、A2A 和 MCP 列为内置集成。AP2 文档也明确引用了 A2A 和 UCP。整套协议栈就是为了互操作而设计的。

但这种收敛是围绕消费者场景展开的。这些协议解决的是一个特定的问题：智能体发现一件商品、协商价格、完成结账并支付。这是消费者的旅程。而一家每周处理 200 份 RFQ 的中端 B2B 分销商，面对的并不是结账问题——而是分层定价问题、库存预留问题，以及 ERP 回写问题。

其缺口正是 B2B 语义层：

• 客户分层定价。 UCP 和 ACP 暴露的是门店公开发布的价格。而 B2B 分销商的价格是按客户、按合同、按批量层级划分的——存放在 NetSuite 或 BigCommerce 的客户分组中，而非公开目录里。没有任何商务协议能够协商分层定价。
• 批量 RFQ 报价。 消费者协议处理的是单件商品的购买。而 B2B 采购运行在 RFQ 之上：买家提出一份 500 件商品、附带交付窗口的请求，供应商回复报价，买家再进行协商。RFQ 引擎架构一文对这一工作流有深入分析。
• 针对 ERP 的库存预留。 消费者结账会在购买瞬间预留库存。而 B2B 报价需要的是一种可用性预留——对 NetSuite 或 Brightpearl 库存的限时预留，若报价未被接受则自动失效。没有任何 UCP 或 ACP 工具能提供这一能力。
• 跨渠道订单归因。 由智能体下达的 B2B 订单，需要归因到正确的客户账户、正确的销售代表，以及 ERP 中正确的合同。而消费者协议假定的是单一买家身份。

自定义 MCP 模块正是用来填补这一缺口的。MCP 模块代码标准定义了其结构模式：类型化的工具定义、智能体与 ERP 之间的语义层转换、速率限制治理，以及审计轨迹。该模块叠加在商务协议之上——它并不取代 UCP 或 ACP，而是将其延伸至消费者协议未曾设计覆盖的 B2B 工作流中。

相关阅读

• 用 MCP 将 AI 智能体连接到 BigCommerce：Stripe 合作未解决的问题——针对 BigCommerce 的连接器专项分析，探讨其 ACP 路线与 B2B 语义层缺口
• 当 AI 智能体代你销售：将 Shopify 接入 B2B 技术栈——Shopify 符合 UCP 标准的 MCP 服务器如何覆盖消费者半场，以及自定义模块在何处延伸至 B2B
• MCP + A2A：支撑每一个生产级智能体 AI 系统的两个协议——本文正是在这篇协议栈总览的基础上延伸到商务层

代表性案例

一家在线目录跑在 BigCommerce、ERP 跑在 NetSuite 上的中端工业分销商，每周通过邮件收到 150 份 RFQ。每份 RFQ 都需要一次客户分层价格查询、一次库存可用性预留，以及一份引用客户合同条款的报价。而消费者商务协议——用于商品发现的 UCP、用于结账的 ACP、用于支付的 AP2——都不涉及这些环节。自定义 MCP 模块填补了这一缺口：它暴露出类型化工具，用于分层定价查询、可用性预留创建和报价组装，供智能体在通过标准商务协议完成商品发现后调用。智能体端到端地处理整个 RFQ——发现、定价、预留、报价、人工审批——而 MCP 模块则负责治理 ERP 回写与审计轨迹。首个智能体可在 5 到 8 周内上线。

请求一个范围明确的构建。一周 Discovery。你获得系统清单、工作流图和固定范围——无论你是否与我们合作构建。