直接答案：Agentic Commerce Protocol（ACP）是一套连接商家、ChatGPT 用户和支付服务方的开放规范，用结构化商品数据支持商品发现，并在具备资格的场景中衔接购物车、结账、支付授权和订单状态。它不是“AI 自动替用户买东西”的万能插件，也不代表所有地区、商家和 ChatGPT 用户都能在对话内一键付款。商家仍负责价格、库存、税费、履约、退款、客服与合规；用户必须确认关键操作。
ACP 现在到底能做什么
ACP 当前官方文档把它定义为商家和 AI 代理之间的连接层。第一条落地路径是商品发现：商家提交结构化商品 feed，让系统理解商品标识、标题、描述、图片、价格、库存、规格和履约信息。第二条是结账协作：获准参与相应功能的商家可以实现结账会话接口，由 ChatGPT 收集用户明确确认的信息，商家再校验购物车、计算税费和运费、接受或拒绝订单，并调用自己的支付体系。OpenAI 当前文档已把原 Apps SDK 体系更新为 ChatGPT Plugins，仍将插件外部结账列为多数开发者推荐且一般可用的路线；这与商品 feed onboarding 和内嵌支付面板不是同一开放范围。
这里必须区分“协议具备的能力”和“某个用户当前看到的产品功能”。官方核心概念页明确写明：协议开发向所有人开放，但 ChatGPT 内即时结账当前只面向获准合作方；官方仓库同时把规范状态标为 beta，并采用日期版本。2026 年 9 月 9 日复核到的最新稳定快照仍为 2026-04-17，仓库最新提交仍停留在 7 月 18 日，且仅改动 unreleased 目录；该目录不是生产合同。因此，文章、产品方案和销售材料都不应笼统宣称“已经对所有商家开放一键下单”。正式接入前要重新检查地区、合作资格、稳定 schema、变更日志和协议版本。
如果读者只想理解智能体的基本能力，可先看站内的AI Agent 原理与架构；如果目标是选择零售场景，可结合AI 在零售行业的应用。ACP 解决的是“商品与交易系统怎样被智能体可靠调用”，不是替代商家的经营、风控或售后。
先分清三条商业接入路线
| 路线 | 当前用途 | 截至复核日的开放状态 | 主要责任 |
|---|---|---|---|
| 商品 feed | 让 ChatGPT 索引并理解商品目录 | OpenAI 文档写明 onboarding 当前面向获准合作方 | 商家维护商品、变体、价格、库存、图片和政策真值 |
| ChatGPT Plugin 外部结账 | 从插件跳到商家网站或应用完成购买 | 官方称为推荐且一般可用；当前商业审批限实体商品插件 | 商家域名处理价格、支付、税费、履约、退款和合规 |
| 商家已保存支付方式 | 在插件 UI 内展示商家已经保存的支付方式 | 不能在此流程中收集新的支付凭证 | 商家后台用既有支付方式处理订单 |
| ChatGPT 支付面板 | 在对话内展示金额并返回支付令牌 | 精选 marketplace 合作方 private beta，并非所有用户可用 | 商家构建权威 session，PSP 扣款，商家履约和售后 |
所以，最稳妥的实施顺序通常是：先把商品和网页真值整理好；获准后接入 feed；需要 ChatGPT Plugin 时优先采用外部结账；只有获得对应资格并完成支付、幂等与合规验收后，才接入内嵌支付。协议开源不等于某项 ChatGPT 产品功能自动开通。
一次商品发现和结账分别经过哪些系统
| 参与方 | 主要职责 | 不能外包给模型的责任 |
|---|---|---|
| 用户 | 描述需求、比较商品、确认收货与购买信息 | 对购买、金额和关键步骤作明确确认 |
| ChatGPT / AI 代理 | 理解需求、检索结构化商品、展示比较结果；在允许时发起或更新结账会话 | 不能自行改写商家价格、库存和订单真值 |
| 商家 | 维护商品 feed，验证购物车，计算税费与运费，接受或拒绝订单，履约和售后 | 商品准确性、消费者权益、退款、客服与监管合规 |
| 支付服务方 | 处理受约束的支付授权、网络令牌和扣款 | 支付安全、风控、结算、退款和拒付处理 |
商品发现的关键是真值同步。OpenAI 的接入指南建议先提供完整 feed，并用文件快照与 API 更新维持价格和库存的新鲜度；促销信息需要通过相应 API 提供。结账则不是“模型生成一个支付结果”，而是由商家端返回权威购物车状态。创建或更新会话时，商家应再次校验商品、数量、配送地址、优惠、税费和最终金额。
支付环节还多一层边界。Delegated Payment Spec 使用有金额上限和有效期的一次性授权，让支付信息交给商家信任的支付服务方处理。OpenAI 不是 merchant of record；商家仍使用自己的支付服务方并负责结算、退款和拒付。直接实现委托支付规范通常面向支付服务商或具备相应 PCI 能力的商家，普通商家不应照抄示例后直接处理卡数据。
| 交易对象 | 权威来源 | 失败时谁处理 | 最低审计字段 |
|---|---|---|---|
| 商品与变体 | 商家 PIM/商品系统 | 商家修正 feed 并撤回错误商品 | SKU、变体、feed 版本、更新时间 |
| 购物车金额 | 商家 checkout 响应 | 商家重新计算并返回消息，用户再次确认 | 币种、分项金额、税费、运费、折扣 |
| 支付授权 | 商家选择的 PSP | PSP 与商家处理拒付、3DS 和退款 | 令牌、授权状态、金额上限、有效期 |
| 订单状态 | 商家订单系统与 webhook | 商家履约、取消、退款和客服接管 | 订单号、状态事件、重试和永久链接 |
商家接入 ACP 的六步路线
- 先确定目标：只做商品发现，还是确实需要对话内结账。大多数商家应从 feed 开始，而不是先开发支付。
- 建立商品真值源：统一 SKU、变体、价格、库存、图片、配送与退货字段，明确哪个系统是最终权威。
- 生成和验证 feed：按稳定 schema 输出完整快照；对缺字段、无效链接、币种、库存冲突、图片质量和重复变体做自动校验。
- 控制更新延迟：记录快照时间、增量时间和失败重试；价格或库存变化不能只等下一次人工上传。
- 按资格增加结账：实现创建、更新和完成结账会话，确保每次响应都返回完整且权威的购物车状态，并正确处理拒绝、缺货、地址无效和价格变化。
- 通过生产验收：保存请求与响应日志，覆盖税费、配送、优惠、幂等、超时、支付失败、重复 webhook、退款和客服接管。
官方入门页目前说明商品 feed 接入面向获准合作方，不能把“协议开源”误写成“任何店铺提交文件后立即进入 ChatGPT 推荐”。开放规范、商家接入资格、特定产品功能和地区可用性是四件不同的事。对外发布前应把复核日期写入项目文档。
商品 feed 怎样写，才能减少错误推荐
Feed 不是把网页正文复制成 CSV。每个商品和变体应有稳定标识，标题避免堆砌促销词，描述要包含能影响选择的真实属性，图片与具体变体一致，价格带币种，库存和配送状态可及时更新。产品页、feed 和结账接口如果对同一 SKU 给出三套价格，AI 再聪明也无法替商家判断哪一个是真的。
- 变体建模：颜色、尺寸、容量等必须能关联到父商品，又保留自己的库存、图片和价格。
- 时效字段：记录数据生成时间、更新时间和失效策略；对下架商品及时撤回。
- 媒体质量：使用清晰、可访问且有权使用的商品图片，不用与商品不符的概念图。
- 归因与链接：保持商家、品牌、商品页和最终结账目的地一致，避免中间跳转掩盖真实销售方。
- 监控差异：定期抽样比较 feed、站点、库存系统和结账响应，发现价格或库存漂移立即告警。
这与传统 SEO 并不冲突。网页仍需让用户和搜索引擎看懂，结构化 feed 则给商品发现系统提供更稳定的机器可读真值。站内的AI 搜索工具与智能检索可以帮助理解答案式发现，而API 报错排查指南适合补充接口监控方法。
Feed 新鲜度应当变成可测的服务指标
OpenAI 当前入门文档一般建议每天通过文件上传提供一次完整 feed，并在当天通过 API 发送更新；如果目录较小，也可以全部通过 API 提交，促销数据则只能通过 API。这里的“一天一次”是集成建议，不代表价格和库存可以延迟一天。商家应依据业务风险为不同字段设定更短的内部目标，并在超时后停止展示或回退到商品页。
| 检查项 | 应保存什么 | 失败处理 | 验收问题 |
|---|---|---|---|
| 完整快照 | 生成时间、分片、记录数、文件哈希 | 保留上次有效版本并告警 | 是否能确认没有漏 SKU 或重复分片 |
| API 增量 | 事件时间、接收结果、重试次数、最终状态 | 幂等重试，超过窗口转人工 | 价格和库存变化多久可被发现 |
| 字段验证 | 必填缺失、枚举错误、链接与图片状态 | 隔离坏记录，不能拖垮整个目录 | 拒收原因是否可回溯到源系统 |
| 跨系统抽样 | feed、商品页、库存与 checkout 差异 | 停止高风险商品并修正真值源 | 用户最终金额是否与发现阶段一致 |
| 撤回与下架 | 撤回时间、原因和传播完成时间 | 高优先级处理并检查缓存 | 下架商品是否仍可能被推荐 |
最容易出事故的五个地方
- 把展示价当成交价：税费、运费、优惠资格或库存变化后，商家必须返回新的完整购物车并让用户确认。
- 幂等失效：网络重试不能生成两个订单或重复扣款；创建、更新、完成和 webhook 都要测试重复请求。
- 过度共享数据：只传完成当前步骤必需的用户数据，明确保存期限、访问控制和删除流程。差分隐私的概念可参考差分隐私指南，但它不能替代交易系统的最小权限与合规设计。
- 模型替商家作最终判断：税费、限制商品、配送资格、风控与退款必须由确定性系统和人工流程兜底。
- 上线后无人接管：订单失败、金额争议、商品不符和退款需要可找到的客服与审计记录。
生产验收至少保存：协议版本、feed 哈希与生成时间、SKU/变体数量、拒收记录、接口延迟与错误率、请求 ID、幂等键、订单状态变化、支付失败类型、webhook 重试、人工接管时间和退款结果。只证明“测试环境能下一个单”远远不够。
结账接口最小故障矩阵
| 故障场景 | 期望系统行为 | 用户可见信息 | 不能发生 |
|---|---|---|---|
| 价格或税费变化 | 返回完整新购物车并要求重新确认 | 清楚展示变化项和最终总额 | 静默按旧金额或新金额扣款 |
| 库存不足 | 标记对应 line item，阻止完成或提供可选处理 | 指出缺货商品和下一步 | 模型自行替换未获确认的商品 |
| 请求超时重试 | 使用相同幂等键安全返回同一结果 | 显示处理中或可重试状态 | 创建重复订单或重复扣款 |
| 支付拒绝/需要验证 | 按 PSP 结果返回明确错误或验证流程 | 不暴露敏感风控细节 | 把失败订单标为已付款 |
| webhook 重复或乱序 | 验签、去重并按订单状态机处理 | 订单页显示权威最新状态 | 已退款订单被旧事件恢复为已发货 |
| 用户取消 | 停止后续写操作并释放临时状态 | 确认未下单或说明已发生步骤 | 取消后继续调用完成接口 |
版本、命名和维护边界
ACP 仓库使用日期版本保存规范快照，并同时维护尚未发布的变更。生产系统应锁定明确版本，升级前阅读 changelog、对 OpenAPI/JSON Schema 做兼容测试，不能长期跟随未发布目录。ACP 这个缩写还可能指 Agent Client Protocol，后者用于编辑器和编码代理通信，与电商协议无关；技术文档首次出现时应写全称和维护组织。
截至 2026 年 9 月 9 日，最稳妥的表述是：ACP 为商品发现和可选交易协作提供开放规范；商家保有商品、订单、支付、履约和客户关系的控制权；商品 feed onboarding、ChatGPT Plugin 外部结账和支付面板分别有不同开放范围。需要搭建更广义的工具调用体系，可继续阅读AI Agent 工具调用与治理。
把结账做成可重放的状态机，而不是一次接口调用
结账链路会跨越 ChatGPT、商家接口、支付服务方和订单系统，任何一段都可能出现超时、重试、重复事件或乱序事件。ACP 结账规范要求请求携带 Idempotency-Key 与 Request-Id，商家端还需要稳定的 checkout session ID、支付授权标识和 order ID。它们的作用不是“方便查日志”这么简单，而是把同一个用户意图在多个系统中的记录关联起来，阻止一次重试变成第二个订单或第二笔扣款。
幂等不能只在创建订单接口上实现。创建、更新、完成、取消和 webhook 都要定义重放结果：同一幂等键与同一请求内容再次到达时，应返回先前结果或当前权威状态；同一键却携带不同金额、商品或用户时，应拒绝并告警。系统还要区分“请求没有到达”“请求已处理但响应丢失”和“支付已授权但订单落库失败”，否则自动重试仍会在边界故障中制造重复交易。
| 关联标识 | 权威生成方 | 必须关联的记录 | 验收测试 |
|---|---|---|---|
| Idempotency-Key | 调用方为一次写入意图生成 | 请求体摘要、首次结果、重放次数、有效窗口 | 相同请求重放不新增订单；同键异参明确拒绝 |
| Request-Id | 每次请求唯一 | 网关、商家服务、错误与响应日志 | 能从用户报错定位到一次具体调用 |
| Checkout session ID | 商家结账服务 | 商品、地址、配送、税费、总额和会话状态 | 每次更新返回完整权威购物车，不拼接陈旧字段 |
| 支付授权/令牌 | PSP 或适格支付流程 | 币种、金额上限、有效期、授权与退款状态 | 过期、超额、重复使用和拒绝均不能生成已付款订单 |
| Order ID | 商家订单系统 | 履约、取消、退款、拒付、客服和永久订单链接 | 重复/乱序 webhook 不会让订单状态倒退 |
对账不能只在财务月底做。生产系统至少应持续检查三组不变量：订单总额是否等于已授权或已扣款金额；已付款订单是否都能在商家订单系统找到；退款、取消和拒付是否同步到用户可见的最新状态。出现“支付成功但无订单”“订单已发货但支付失败”“退款完成但 ChatGPT 仍显示已付款”等差异时，应暂停自动动作、保留原始事件并转交人工，而不是让模型猜测正确状态。
数据最小化、客服与退出也要在上线前设计
交易系统天然会接触地址、联系方式、订单和支付状态，但“结账需要数据”不等于可以收集完整对话或长期保留所有字段。当前 ChatGPT Plugin 指南要求工具只请求完成任务所需的最少信息，不应索取完整聊天记录、宽泛上下文或不必要的精确位置；受 PCI DSS 约束的支付卡数据也不应由普通插件工具收集。商家应把商品发现、结账、支付、履约和客服所需字段拆开授权，并在隐私政策中说明目的、接收方、保留期限和用户控制方式。
| 阶段 | 通常需要的数据 | 不应默认收集 | 退出/删除动作 |
|---|---|---|---|
| 商品发现 | 用户明确表达的需求、粗粒度地区或可配送条件 | 完整聊天记录、精确地址、支付资料 | 允许用户返回普通搜索，不创建订单或营销档案 |
| 购物车与配送 | 商品、数量、收货所需地址和配送选项 | 与履约无关的身份、联系人网络或设备数据 | 取消后释放临时会话；说明是否仍保留购物车 |
| 支付 | PSP 返回的受限令牌、授权状态和必要账务标识 | 普通插件直接收集卡号、CVC 或账户秘密 | 授权过期或取消后禁止再次使用；按支付规则处理记录 |
| 履约与售后 | 订单、物流、退款、客服沟通与法定凭证 | 把聊天内容无限期并入客户画像 | 提供订单永久链接、退款路径和人工客服入口 |
| 分析与优化 | 必要且去标识化的错误、转化与延迟指标 | 为“以后可能有用”保存逐字对话和敏感字段 | 设定保留期限、访问审计和删除/匿名化流程 |
上线验收必须包含“用户反悔”和“系统退役”。用户在最终确认前取消时，系统应停止所有后续写操作并清楚说明是否已经产生订单或授权；商家退出 ACP、撤销 Plugin 或更换 PSP 时，要撤销密钥和 webhook、停止 feed 更新、处理未完成会话、保留法定订单记录并为用户提供售后入口。关于智能体身份、最小权限、审计与退役责任，可继续使用站内企业 AI 智能体治理指南建立责任清单。
OpenAI 当前 ChatGPT Plugin 指南还明确：插件的商业活动目前限实体商品，标准做法是跳转到商家自有域名完成外部结账；Instant Checkout 仍为面向部分 marketplace 合作方的 beta。另一份官方结账文档把外部结账称为推荐且一般可用的路线，但这并不取消插件审批、实体商品范围、商家接入资格和地区限制。工程与市场材料应同时保留这些边界。
上线前检查清单
- 商品标识、变体、价格、币种、库存、图片和退货信息有唯一真值源。
- 完整 feed、增量更新、失败重试和撤回流程均有日志与告警。
- 明确当前接入资格、地区、产品功能和锁定的 ACP 版本。
- 购物车金额变化、缺货、无效地址、优惠失败会触发重新确认。
- 所有写操作具备幂等键，webhook 可安全重放并验证来源。
- 支付信息只交给适格支付方，权限、保存期限和人工接管已审计。
- 履约、退款、拒付和客服责任在用户购买前清楚可见。
- 生产验收保留端到端请求响应、订单状态和失败样例，不只保留成功截图。
上线回执还应固定“测试了什么”和“没有测试什么”。建议保存接入资格确认、ACP 稳定版本、schema 哈希、feed 样本与拒收报告、测试商家和 PSP 环境、测试币种与地区、请求签名验证、幂等重放结果、金额变化重新确认、缺货与无效地址、支付拒绝和 3DS、webhook 重复/乱序、取消、退款、人工接管以及未覆盖风险。每个用例记录前置条件、输入、期望状态、实际状态、证据位置、缺陷编号和批准人；不要只用一张“下单成功”截图代替端到端证据。
发布后需要运行合成交易和真实订单抽样，但测试订单必须与生产财务分开标记，不能污染销量、库存或用户画像。监控至少覆盖 feed 延迟、坏记录比例、商品页与结账价差、会话错误率、幂等冲突、支付后无订单、订单后无支付、webhook 积压、退款超时和客服接管时长。任何会影响用户金额、商品可得性或订单状态的告警，都要有停止自动交易、回退外部结账或撤下商品的明确负责人和时限。
一手资料与复核范围
- OpenAI：ChatGPT 商品发现更新
- OpenAI Developers：Agentic Commerce 文档入口
- 商品 feed 入门、接入资格与更新路线
- 商品文案、变体和归因最佳实践
- 商品 feed 文件上传规范
- 商品 feed API 规范
- Agentic Checkout Spec
- 稳定快照中的 Delegated Payment OpenAPI
- ChatGPT Plugins 外部结账与支付面板开放边界
- ChatGPT Plugin 商业范围、外部结账与 Instant Checkout 指南
- OpenAI 商家接入申请入口
- ACP 协议站点
- ACP 官方开源仓库、版本与变更记录
资料复核日期：2026 年 9 月 9 日。ACP 仍处于 beta，仓库最新稳定快照仍为 2026-04-17；OpenAI 开发者文档已把原 Apps SDK 入口重定向到 Plugins，但商品 feed 和结账功能的资格边界未放宽。ChatGPT 商品功能和合作资格会变化，实施前应重新核对官方页面、稳定 schema、版本变更和所在地区要求。本文不构成支付、PCI、消费者保护、税务或隐私法律意见。
编辑复核与纠错记录：兰塞 AI 编辑流程于 2026 年 9 月 9 日再次核对 OpenAI Developers 与 ACP 官方仓库。商品 feed onboarding 仍面向获准合作方，Plugin 外部结账仍是推荐且一般可用的路线但商业审批仍限实体商品，ChatGPT 支付面板仍是部分 marketplace 合作方 beta；本次把已重定向的 Apps SDK 旧术语和链接更新为 Plugins，并确认稳定协议版本仍为 2026-04-17。跨系统幂等、订单状态机、持续对账、数据最小化、退出流程和原创对账图保持有效。本站的来源、更新与纠错原则见关于本站与编辑规范。
2026 年 9 月 9 日更正：编辑部重新核对 ACP 2026-04-17 稳定 OpenAPI 文件及当前官方入口，核心结论未改变；同时依据发布任务与提交记录校准了首次公开时间的时区字段，并把正文中的资料复核日期更新为本次实际核验日期。
