先读结论
这些协议处理的职责并不完全相同。本文用能力矩阵、证据边界、版本治理和试点验收，帮助商家判断先接什么、由谁实现，以及哪些能力仍需自建。
从职责到接入决策
不要把协议名直接当作采购答案
假设一家经营家居用品的商家已经有商品目录、订单系统和支付服务，希望让消费者通过外部购物代理购买。技术会议很快可能变成“选ACP还是UCP”的讨论，但真正的问题包括商品如何被发现、报价由谁计算、谁确认购买、支付如何授权以及退货由谁处理。协议名字不能替这些问题作答。本文提供的是原创选型方法，示例为假设，不构成任何供应商的接入保证。
建议先画出当前交易链路，再标注新增的代理入口。保留商家已有可信系统作为价格、库存、订单和支付状态的责任来源。代理可以协调调用，但不应因为采用某个协议就获得任意修改事实的权力。如果团队还无法回答哪个服务拥有最终订单状态，就应先修正内部职责，再讨论协议适配。否则，一个更标准的接口只会让原有混乱传播得更快。
用一小段事实建立共同词汇
截至本次核验，OpenAI的官方文档把ACP作为商家与代理商业体验之间的连接规范；Google的UCP介绍覆盖商业能力发现、结账和订单等环节，并说明与AP2兼容；Google对AP2的介绍侧重可验证的用户授权和支付证据。它们的关注层次存在交集，也存在差别，不能简单理解为三个功能完全相同的结账按钮。具体能力以所采用版本和实际实现为准。
编辑核验日期为2026年9月27日。Google还在2026年4月28日宣布将AP2交给FIDO Alliance并更新版本，因此文章不能把初始发布时的治理或能力描述永久固定。本文不据此推断哪个协议将胜出。对于商家，更实用的问题是现有渠道和服务方今天支持什么、明确承诺什么，以及哪部分能够通过测试证明，而不是根据发布声量替未来作确定判断。
按业务动作建立能力矩阵
建议矩阵的每一行都是商家真实需要完成的动作，例如发现商品变体、查询当前库存、生成含配送的报价、使用优惠、确认订单、提交支付、查询履约、取消订单和处理部分退款。每一列代表一个具体入口及其实际集成方案，而不是抽象协议名。填写状态时区分规范可表达、提供方已实现、商家已启用和测试已通过。四个状态不能用一个“支持”勾选框替代。
矩阵旁边还要记录责任服务、证据链接、版本、地区与例外。假设协议允许某种扩展，但目标入口没有启用，商家就不能把它列入首发体验。反过来，一个已有功能可能通过受控页面跳转完成，也不必为了追求所有步骤都在聊天里而仓促重写。矩阵的作用是帮助团队看到能力与缺口，而不是为预先偏好的供应商制造全绿评分。
分清开放规范与实际准入
公开规范意味着可以阅读并按其规则开发，不自动意味着某个消费平台接受所有商家、所有商品或所有国家。建议在项目计划中单列准入任务，核实目标入口的商家资格、产品要求、支付方式、支持地区以及申请流程。开发完成、测试通过和业务批准应分别记录。如果准入仍待确认，首页和销售材料就不应声称消费者已经能够通过该入口购买。
同样，供应商说兼容某协议可能只覆盖其中一部分。建议要求对方把声明对应到具体业务动作，提供当前文档或可测试环境，并明确哪些功能尚在规划。采购评估可接受分阶段交付，但必须把将来目标与现在能力分开。遇到模糊表述时，可以用一个完整订单案例逐步询问，而不是只要求对方回答“是否支持代理商业”这样过于宽泛的问题。
授权证据、身份认证和支付执行各有职责
建议评估三类问题：是谁在提出请求，用户允许了什么，以及哪一方实际执行资金动作。代理身份认证可以帮助商家识别调用方，但不自动证明这个调用方获得了消费者对当前商品和金额的同意。支付令牌能约束凭证使用，也不能单独证明商品已经送达。把这些证据混为一种“可信代理认证”，会使风险控制出现盲区。
能力矩阵应标出用户意图、购物车确认、支付限制和订单结果分别保存在哪里，以及谁验证它们。验证失败时要有明确动作：停止、重新确认或交给人工。不要让语言模型自行决定一个签名是否足够可信，也不要将缺少证据解释成用户默许。真正需要比较的是证据是否完整、限制是否执行和异常是否可恢复，而不是规范文本中安全相关词语出现了多少次。
决定直接接入还是通过服务方适配
直接维护协议端点可以让商家更细致控制状态和扩展，但也要求团队持续处理版本变化、签名验证、可靠性、监控和故障恢复。通过服务方适配可能减少部分集成工作，但需要确认责任边界、数据同步时效、错误可见性和迁移能力。本文建议以团队能长期承担的运维职责来判断，而不是只比较第一次演示需要写多少代码。
假设商家只有一个小型技术团队，已有目录和订单系统较稳定，最初需求又很有限，可以优先评估能提供清楚映射与可观测性的适配方案。若商家拥有复杂定价、分仓履约和严格的内控需求，则需要深入验证适配层是否保留这些约束，不能因为接口更少就认定实现更简单。无论选择哪条路径，商家的业务事实和审核记录都应能够导出并独立理解。
先确定一个可恢复的最小交易闭环
建议试点选择库存明确、配送简单、价格稳定且售后规则清晰的商品集合。最小闭环也必须包含支付失败、用户取消、订单查询和一种可处理的退款路径；只展示正常下单无法证明系统可以上线。试点可以限制地区、支付方式和商品范围，并在界面准确说明。限制越明确，团队越容易区分能力不足与偶发故障。
完整闭环需要让消费者在离开代理后仍找到订单，客服可以识别来源，财务可以关联收款，仓库不会因重复通知多发货。建议把这些要求写成跨团队验收表。某个协议适配器返回成功，只能证明那个步骤得到了预期响应，不能证明整笔生意已经正确完成。试点成功的证据应覆盖从发现到售后的链路，而不是一段流畅的演示视频。
版本治理应进入上线计划
协议和平台实现都可能迭代。建议记录商家当前采用的规范版本、扩展版本、支付处理方能力与测试日期，并保留可复现的契约测试。升级前查看变更涉及的是字段、语义、状态、鉴权还是错误处理。字段名没有变化也可能出现行为差异，因此不能只依靠接口类型检查判断兼容性。
如果使用适配服务，合同或操作约定应说明谁跟踪上游变化、多久通知商家、如何灰度和回退。商家仍需监控订单与资金结果，因为外部服务升级成功不意味着本地自定义流程完全兼容。建议将版本变化先应用于受限测试集合，比较关键动作与旧版本的结果，再逐步扩大。紧急回退也应保留已开始交易的恢复能力，不能简单关闭端点后让待处理订单失去入口。
把失败路径纳入协议适配测试
建议测试超时后恢复、重复创建订单、库存变化、报价过期、用户撤销授权、额外支付验证、部分退款以及通知乱序。每个场景应说明哪一层负责判断，哪一层保存事实，代理向用户说什么。若适配层无法表达一个重要失败原因，应确认是否存在安全的回退路径，不能把所有错误包装成“请稍后重试”。
尤其要验证代理重新规划之后是否仍引用原购买意图。购物代理擅长尝试另一条路线，但支付系统必须知道何时是同一操作的恢复，何时是新的授权交易。协议选择不能替代业务幂等和资金状态管理。建议在验收报告中同时给出正常路径与故障路径结果，避免仅凭少量成功示例为整个接入方案作结论。
衡量实施成本时加入持续工作
建议成本表包含目录准备、字段映射、支付接入、测试、监控、客服培训、对账和版本维护。一次接入报价低，可能意味着异常处理留给商家；一次接入工期长，也可能只是商家现有数据不完整。应把供应商费用与内部工作分别列出，再根据实际业务范围比较，不能引用没有来源的行业平均回报来替代自己的测算。
收益也应按可观察事实评估，例如新增可识别订单、成功完成交易的比例、客服重复联系和维护工时。来自代理入口的订单不必然都是增量，原有客户也可能换一个入口购买。可以设计合理的对照与分阶段观察，但在证据不足时应明确说是试点数据。协议标准化的潜在好处值得评估，却不应自动写成已经实现的收入增长。
保留可退出、可替换的集成边界
建议商家内部保留与协议无关的订单、报价、支付和售后模型，再在边界做清晰映射。这里不是主张抽象掉所有差异；特殊能力仍应显式表达，并注明只有哪些入口支持。过度抽象会把有用差异压成最小公分母，过度绑定又会让更换入口牵动整个后台。选择可以解释的边界，比追求一个万能对象更可靠。
退出计划应说明如何导出订单关联、保留用户授权证据、处理正在进行的退款，以及切换时如何避免双重接单。不要直到供应商服务变化时才发现历史订单只能在对方界面查询。一个可维护的方案能够让新入口接入，也能让旧入口停止新增交易而继续完成已有责任。这个能力应在采购和验收时验证，而不是作为未来再考虑的运维细节。
给决策者一页可复核的结论
建议最终选型结论列出当前优先入口、首发商品范围、所需协议能力、实现责任、已验证条件和未解决缺口。每项推荐都连接到能力矩阵中的证据，而不是使用“未来最有潜力”作为唯一理由。可以同时保留第二阶段方案，但不要让未来能力进入首发承诺。决策者应能明确看出批准的是什么范围，以及什么情况会触发暂停或重新评估。
合格的结论也包括不确定性：平台准入未完成、某种支付方式待确认、某项售后能力需人工接管。公开这些缺口能帮助团队安排具体工作。协议选型的结果是一条可执行、可验证、可恢复的路线，而不只是一个缩写。随着市场变化，栏目应更新证据和版本，但商家仍可长期沿用这套按职责拆解、以完整交易验收的方法。
检查证据质量与利益关系
供应商白皮书、官方规范和商家实际测试回答的是不同问题。白皮书能说明设计目标，规范能说明接口约定，测试才能说明某个具体环境中的行为。建议来源清单标明发布方、日期、版本和是否为自述案例。合作伙伴出现在发布稿里，不等于它已经在商家的目标地区提供完整能力；营销中的网络覆盖也不等于代理交易的实际覆盖。
对无法独立验证的性能、转化或欺诈数据，应保留其自述属性，记录样本和口径是否公开。商家可以用它们提出试点问题，但不宜直接搬进收益承诺。编辑更新文章时也应保留旧判断的时间边界，说明哪些变化来自新证据，避免让读者把过去的试点状态误当成今天的通用能力。
常见问题
- 采用UCP之后是否还需要关注AP2或支付服务？
- 需要根据实际职责评估。商业能力接口、授权证据和资金执行并不相同。应检查所选实现如何衔接这些部分，不能用一个协议名推定整个链路已完成。
- 支持开放协议是否意味着商家可以立即在所有AI平台卖货？
- 不意味着。规范、平台实现、商家准入、商品资格和地区开放是不同条件。应逐入口确认，并在完成真实测试后才宣称支持相应体验。
- 小团队必须自建全部协议端点吗？
- 不一定。可以评估服务方适配，但要确认数据、异常、版本和退出责任。减少初期代码不代表消除持续运营工作，选择应符合团队能长期维护的范围。
来源与延伸阅读
- Key concepts – Agentic Commerce · OpenAI
- Under the Hood: Universal Commerce Protocol (UCP) · Google
- Powering AI commerce with the new Agent Payments Protocol (AP2) · Google Cloud
- Google donates Agent Payments Protocol to FIDO Alliance · Google
本文为 AI 辅助的原创研究稿，案例为假设情景，事实背景以文末一手来源为准，不构成投资或法律建议。