MCP、ACP、UCP、A2A：驱动 AI 商务的四大协议深度解析

四个协议正在定义AI代理与商务的交互方式。每个协议由不同的科技巨头联盟创建，解决不同的问题。它们共同构成了AI代理商务的基础设施层，但也带来了一个现实挑战：碎片化。

本文对四大协议进行系统性的技术和战略分析：它做什么、谁构建的、怎么工作、采纳现状如何，以及它们之间的关系。

MCP：连接标准

Model Context Protocol（MCP） 是Anthropic于2024年11月发布的开放标准，目的很直接：为AI助手提供一种通用方式来连接外部数据源和工具。

在MCP出现之前，每个AI集成都是定制化的。开发者要让AI助手访问数据库或调用API，就得构建专用连接器。MCP将这一连接层标准化，使任何兼容MCP的AI系统能够与任何兼容MCP的服务进行交互。

采纳速度极快。OpenAI于2025年3月采纳MCP，Google、微软和Shopify跟进。2025年夏天，Shopify在其平台所有店铺上激活默认MCP端点（路径为/api/mcp），使数百万商户即刻对MCP兼容的AI代理可见。2025年11月的一周年规范更新（版本2025-11-25）基于实际部署反馈进行了优化。

PayPal的AI负责人公开表示，MCP是他意识到代理电商即将到来的那个时刻。这句话精准捕捉了MCP的意义：它没有发明AI到服务的连接，但它以一种催化整个生态的方式将其标准化。

技术特征： MCP定义了客户端-服务器架构，AI应用（客户端）通过标准化接口连接数据源和工具（服务器），支持多种传输机制，并提供描述可用工具、参数和输出的Schema。

在商务场景中， MCP使AI代理能够查询产品目录、检查库存、读取物流政策，并以结构化的、可预测的格式访问商户数据。它是其他协议依托或互补的基础层。

当前状态： AI到服务连接的事实标准，在所有主要AI平台中拥有最广泛的采纳度。

ACP：支付层

Agentic Commerce Protocol（ACP） 由OpenAI和Stripe于2025年9月联合发布，采用Apache 2.0许可证，专为AI代理与企业之间的程序化商务设计。

ACP解决一个根本性问题：AI代理如何在不暴露用户支付凭证的前提下替用户付款？传统结账流程假设有一个人类在场输入卡号、进行银行验证、确认购买。AI代理需要一种不同的机制。

核心创新是共享支付令牌（Shared Payment Tokens, SPTs）。SPT是代币化的支付工具，AI代理可以用它代替用户发起交易。SPT限定于特定卖家，有时间和金额上限，永远不暴露底层支付凭证。消费者在定义的约束范围内授权SPT，代理在这些边界内操作。

OpenAI和Stripe担任协议的创始维护者，代码公开在GitHub（github.com/agentic-commerce-protocol）。早期采纳者包括URBN（Anthropologie、Free People和Urban Outfitters的母公司）、Etsy、Ashley Furniture、Coach、Kate Spade和Revolve。

在生产环境中，ACP驱动ChatGPT内的Instant Checkout功能。Etsy卖家是首批上线的商户，Shopify商户正在集成管线中。

在商务场景中， ACP是代理商务的支付轨道。MCP将代理连接到数据，ACP将代理连接到结账环节。

当前状态： 在ChatGPT Instant Checkout中上线，主要零售品牌采纳中。支付专注的定位使其与其他协议互补而非竞争。

UCP：购物旅程标准

Universal Commerce Protocol（UCP） 于2025年1月29日发布，由Google和Shopify联合开发。它覆盖完整的购物旅程：商品发现、购买，以及售后交互（包括退货、物流追踪和客户服务）。

UCP的区分特征是端到端的范围。MCP提供通用的AI到服务连接，ACP处理支付，而UCP专门为完整的商务体验而设计。它定义了AI代理如何发现商品、向消费者展示选项、促进购买决策、处理订单追踪和管理退货。

背书名单庞大：超过20家合作伙伴，包括Etsy、Wayfair、Target、Walmart、Adyen、American Express、Best Buy、Flipkart、Macy's、Mastercard、Stripe、The Home Depot、Visa和Zalando。联盟横跨市场平台、零售商、支付网络和卡组织。

技术特征： UCP支持多种传输机制，包括REST API、MCP、Agent Payments Protocol（AP2）和A2A。协议为产品数据、优惠、库存、订单管理、物流追踪、退货和客服交互定义了Schema。

消费者入口 包括Google搜索中的AI Mode和Gemini应用，Google的AI代理通过UCP与商户目录交互。协议网站为ucp.dev。

当前状态： 主要零售商和支付网络的强力支持，已在Google消费者AI产品中部署。

A2A：代理协作层

Agent2Agent Protocol（A2A） 由Google于2025年4月发布，解决的是与前三个协议截然不同的问题：不同系统的AI代理之间如何通信和协作？

前三个协议定义代理与服务的交互（数据源、支付系统、商户）。A2A定义代理与代理的交互。在商务场景中，这使得买方代理与卖方代理谈判、物流代理与履约代理协调、客服代理与退货处理代理协作成为可能。

A2A起步即有超过50家合作伙伴，包括Atlassian、Box、Cohere、Intuit、Langchain、MongoDB、PayPal、Salesforce、SAP和ServiceNow。2025年6月交由Linux基金会托管。到2025年7月，0.3版本引入gRPC支持，联盟增长至超过150家组织。

技术特征： A2A基于HTTP、Server-Sent Events（SSE）和JSON-RPC构建。核心功能包括Agent Cards（JSON格式的代理能力描述）、任务生命周期管理、代理间上下文共享，以及UX协商（多个代理参与单一工作流时如何协调用户体验）。

在商务场景中， A2A实现多代理工作流。个人购物代理可以通过MCP发现商品，通过A2A与商户代理协商，通过ACP完成支付，通过UCP追踪配送。

当前状态： 超过150家组织支持，Linux基金会治理。在实际商务部署方面仍在成熟中。

协议对比

碎片化的现实

对于构建AI代理的开发者来说，协议多样性是可管理的。但对于试图在所有AI平台上可被发现和可交易的商户来说，这是切实的运营负担。

现实情况是：ChatGPT用户通过Instant Checkout购物会触发ACP。Google AI Mode用户浏览商品使用UCP。开发者构建基于Claude的购物助手通过MCP连接。企业部署多代理采购工作流使用A2A协调。

想要全面覆盖所有入口的商户需要支持四个协议。每个协议都需要理解规范、实现端点、随规范演进维护合规性，并针对多个AI平台进行测试。大型企业有专门的工程团队可以承担，独立商户和小型DTC品牌则力不从心。

这种碎片化不是设计缺陷。每个协议解决的是真实且不同的问题。挑战不在于四个协议的存在，而在于商户必须全部支持。

协议如何协同工作

四个协议不是同一功能的竞争标准，而是栈中的不同层级。

第一层：连接（MCP）。 AI代理需要访问商户的产品数据、库存和政策。MCP提供标准化连接。

第二层：商务旅程（UCP）。 代理需要引导消费者完成发现、比较和购买。UCP定义完整购物生命周期的Schema和交互。

第三层：支付（ACP）。 代理需要代替消费者完成购买。ACP提供代币化支付机制。

第四层：协作（A2A）。 多个代理需要在复杂工作流中协调。A2A提供通信框架。

在完全实现的代理商务场景中，四个协议同时运作。消费者的代理通过MCP连接商户，通过UCP导航购物旅程，通过ACP处理支付，通过A2A与商户代理协调。每个协议处理其领域，共同实现完整的自主购物体验。

多协议基础设施挑战

分层模型在理论上优雅。但实际中，商户面对的是实现、测试和维护四个独立协议集成的成本。规范更新、新版本发布、合规要求变化——Anthropic发布新MCP规范版本时商户的MCP端点可能需要更新，Stripe更新SPT格式时ACP集成可能需要调整，UCP和A2A各有各的演进节奏。

这从根本上说是一个基础设施问题。商户不应该需要成为协议专家，就像他们不需要成为支付网关专家一样——当年Stripe将信用卡处理抽象化时解决的就是同类问题。

ORBEXA通过提供实现所有四个协议的单一集成点来解决这个问题。商户将产品数据、政策和信任信号连接到ORBEXA一次，平台将这些信息通过MCP端点、ACP兼容的结账流程、UCP合规的商务接口和A2A就绪的代理服务暴露出去。协议规范更新时，由ORBEXA处理合规变更，而非商户。

展望

中期来看，协议趋同是大概率事件。当前的四协议格局反映的是新技术层的早期阶段，类似于1990年代末多种竞争的Web标准并存的局面。Linux基金会（A2A）和开源社区（ACP）等治理机构将推动互操作性。

但短期内，商户需要在一个多协议世界中运营。代理已经在购物，协议已经上线。通过MCP、ACP、UCP和A2A可被访问的商户将捕获同比增长4700%的AI驱动商务流量。不可被访问的商户，将只能旁观。