商品 feed：AI 电商时代的第三种"提交协议"

从 sitemap 到 feed：提交对象的迁移

做 SEO 的人对一个动作很熟悉：把 sitemap 提交给搜索引擎，告诉它「我的网站有哪些页面」。

到了 AI 时代，这个动作发生了两次分化。第一次是页面层——内容能不能被 AI 读到（robots.txt 放不放行、结构化数据完不完整），这一层我们在此前的文章里讨论过。

第二次分化正在发生，而且更彻底：当 AI 从"回答"走向"下单"，被提交的对象不再是页面，而是商品。页面是给人看的，商品数据是给机器读的。这两者的规范完全不同——页面要可读、要有信息架构；商品 feed 要字段级精确，因为一个字段错了，后果不是"排名下降"，而是结账失败。

这篇文章讲清楚 2026 年商品 feed 的三个主流协议，以及它们共同暴露出的一个现实：提交通道已经标准化了，但提交本身不等于被推荐。

一、三个协议，三种位置

先看清它们各自站在哪里。这三个协议不是竞争关系，而是不同利益方各自推动的管道。

① ACP：OpenAI + Stripe 定义的结账协议

Agentic Commerce Protocol（agenticcommerce.dev），由 Stripe 与 OpenAI 联合开发，Apache 2.0 开源。

官方定位是"buyers、AI agents 与 businesses 之间程序化商业流程的开放标准"。它的核心不是商品数据上传，而是结账会话：

POST /checkout_sessions              # 创建购物车
POST /checkout_sessions/{id}         # 更新
GET  /checkout_sessions/{id}         # 读取状态
POST /checkout_sessions/{id}/complete  # 完成支付
POST /checkout_sessions/{id}/cancel

设计要点（官方原文）：

• 每次响应都返回权威购物车状态（line items、totals、messages、fulfillment options），让 agent 不必猜测就能渲染界面；
• 支付通过 payment_data 传递 payment token，商家用自己的 PSP 处理，不暴露底层支付凭据；
• 商户保持 merchant of record（自己管卖什么、怎么展示、怎么履约）。

第二个 PSP 与 MCP：任何兼容 PSP 都能用，Stripe 是第一个（通过它的 Shared Payment Token）。协议同时支持 REST 与 MCP，商家不必改后端架构。

② Google Merchant Center：既有基础设施上的新增接入

Google 侧最实际的变化是：Merchant Center 的帮助文档里出现了"Universal Commerce Protocol"这个条目——也就是说 Google 把 AI 购物接到了既有的 Merchant Center 体系上。

这对商家的含义是：如果你已经在跑 Google Shopping，你的商品数据基础已经有了，需要的是按新规范补齐字段，而不是从零搭一套。

③ Shopify UCP/MCP：平台侧自动铺好的通道

Shopify 的做法与前两者不同：它不要求商家做任何配置。

我们实测了一个真实的 Shopify 店铺（商家零操作），确认以下端点全部自动存在且可用：

那 13 个工具覆盖了完整链路：search_catalog、lookup_catalog、get_product、create_cart、update_cart、cancel_cart、get_cart、create_checkout、update_checkout、cancel_checkout、get_checkout、complete_checkout、get_order。

这是一个重要的分界线：在 Shopify 生态里，"商品能被 AI agent 找到并下单"这件事平台已经免费做完了。商家不需要写代码，也不需要接协议。

那还需要做什么？往下看。

二、字段级规范：feed 与 sitemap 的根本差别

sitemap 的规范简单到可以手写：一个 URL 列表，加可选的 lastmod。商品 feed 完全不是这个量级。

以 Stripe 的 catalog feed 为例（docs.stripe.com/agentic-commerce/concepts/catalog-feed），单个商品要填的字段分成十组：

基础与标识

媒体

变体与自定义选项

item_group_id          变体组 ID（有变体时必填，≤70 字符）
item_group_title       ≤150 字符
color / size           建议（服装），size ≤20 字符
size_system            ISO 3166 国家码（如 US）
gender                 male / female / unisex
custom_variant_option_name_{1-3} / _value_{1-3}   最多三组自定义选项

⚠️ 一个容易忽略的约束：同一 item_group_id 下的所有商品必须使用同一组变体属性。官方举例——一条裙子有两个颜色两个尺码，那么每个变体都必须同时提供颜色和尺码。

库存与价格（这里决定成败）

履约（物流与退货）

shipping 字段格式是五段冒号分隔：

国家:配送区域:服务名:时效范围:价格
US:ALL:Standard Shipping:3-5:0.00 USD
US:ALL:Expedited Shipping:1-2:12.99 USD

配送区域支持 region（ISO 3166-2 分区码）与 postal_code（仅美国，支持单码 94012 / 范围 73114-74547 / 通配 94* / 多通配 94*-95*）。

配套还有四个字段：shipping_cost_basis（per_order / per_item）、shipping_tax_behavior、free_shipping_threshold（订单满额免运费规则）、shipping_exclusions（不可配送区域）。

性能信号与富内容（这部分直接喂给排序）

这一组是"可选但建议"，官方明确说明用途：帮助 AI agent 与排序系统识别高质量、可信的商品。

富内容三个字段值得单独说，因为它们是AI 在对话里真正会引用给买家的素材：

• product_reviews：JSON 数组，每条含 title(≤150) / content(≤1000) / rating(1–5)，每商品最多 30 条；
• question_and_answer：JSON 数组，q / a 各 ≤1000 字符，最多 30 条；
• product_highlight：字符串数组，每条 ≤150 字符，官方建议 4–6 条，最多 30 条，用短句而非长描述。

⚠️ 官方对 Q&A 有明确排除：不得含价格、促销、配送日期、店铺政策、关键词堆砌或无关营销文案。

合规、关联与投递控制

product_warning     type:message（legal_disclaimer / safety_warning / prop_65），≤1000 字符
age_restriction     最低购买年龄
related_products    upsell / cross_sell / substitute / accessory，最多 10 条，不可自引用
custom_label_{0-4}  内部标签，≤100 字符，不面向终端
delete              标记永久删除（true 时只读 id 与 delete 两列）
disable_checkout    true = 仍可被 AI 发现，但结账跳回你的网站

disable_checkout 这个字段值得注意：它让"只想被推荐、不想被代下单"成为协议级选项——高客单或定制类商家可以用它保留结账环节在自己站上。

三、运营约束：feed 是活的

如果只记一件事，记这个：feed 不是一次性上传，而是持续同步。

Stripe 官方给出了分类型的更新频率：

原因很直接（官方原文）：价格不一致会导致结账失败——"Price mismatches, where the price shown to a shopper doesn't match the price we charge, cause checkouts to fail."

同理，库存不更新会让 agent 持续报告商品不可用，即使已经补货。

增量的两个陷阱

陷阱一：upsert 模式下"漏传"不等于删除。

官方原文："In upsert mode, omitting a product from your feed leaves it unchanged in the Stripe catalog. To explicitly remove it, set delete=true. Otherwise, the product remains visible to shoppers and agents."

也就是说，下架商品必须显式标记 delete=true，否则它会一直对 agent 可见——而 agent 会继续推荐一个你根本发不出货的商品。

陷阱二：replace 模式会永久删除未包含的商品。

两种处理模式：

官方警告：replace 模式只支持商品 feed，且应仅用于有意的全量刷新。

任务是无序的

还有一条容易被忽略的官方说明：feed 上传是独立的异步任务，不保证按提交顺序处理——"If you upload multiple files in quick succession, a later upload can finish before an earlier one."

这意味着同一商品的并发更新需要自己保证顺序，不能依赖平台按序处理。

四、Shopify：一切都自动，除了"看得见"

回到 Shopify。既然 UCP/MCP 通道自动就有，那商家还需要做什么？

我们用真实店铺实测后发现的分层是这样的：

第三层是关键。Shopify 提供通道，但不提供任何"AI 是否真的在引用你"的诊断数据。你无法从后台知道：

• 问 AI"XX 品类买什么好"时，你的商品在不在答案里；
• 在哪些引擎里出现、在哪些里缺席；
• 竞品被推荐的频率是不是比你高；
• 你的商品描述在 AI 眼里有没有被读歪。

这不是 Shopify 的疏漏，而是它的产品边界——它给通道，但不做跨渠道的可见性仲裁。

五、Google Merchant 与传统 SEO 的衔接

Google 这条线的优势在于：它建立在既有体系上。

Merchant Center 的商品数据规范里，id、title、description、link、image_link、availability、price 是必填，gtin 的官方口径是 "It Depends（有则强烈建议）"——与 Stripe 的规范高度重合但不完全相同。

一个值得注意的官方表述是：Merchant Center 的数据可以自动更新，前提是"在你的网站里设置好结构化数据"：

"For an easier time formatting your product data, your product data attributes can be updated automatically. To enable this, you need to toggle on the feature as well as set up your websites with structured data."

也就是说，Google 把 feed 与站点结构化数据打通了——你在页面里写对 schema.org 标记，Merchant Center 可以据此自动更新商品数据。

这对已有 SEO 投入的商家是个杠杆：站点结构化数据不是只服务于搜索排名，它还直接成为 AI 电商的数据源。

六、不能据此推出什么（请务必读完）

以上都是机制说明，不是效果承诺。请避免以下推论：

• ✗ "接了 feed 就会被 AI 推荐" —— 官方原文明确否定。ACP FAQ 的问题是"是否实现了协议就自动被列为可选商品"，官方答案是不（No）：

  "No, each AI platform will manage their own process for how businesses can participate. If your business wants to participate in ChatGPT, you'll need to apply."

  也就是说，协议是通道，准入是审批——想进 ChatGPT 需要单独申请。

• ✗ "通道建好了，可见性自然会有" —— agent 的发现机制仍在建设中。ACP 官方 FAQ 明确写道：发现机制"working to create discovery mechanisms"，尚未完成。这意味着"协议就绪"与"被找到"之间还有一段未铺完的路。

• ✗ "这三个协议是竞争关系，选一个就行" —— 它们的定位不同：ACP 定义结账流程，Shopify UCP 是平台内自动化的通道，Google Merchant 是既有广告/购物体系的延伸。同时存在于多个系里是常态，不是重复投入。

• ✗ "字段填满就万事大吉" —— 字段决定的是"能不能被正确读取"，不是"会不会被选中"。是否被推荐取决于各平台未公开的排序逻辑。

• ✗ "我们的数据证明接了 feed 效果更好" —— 本平台不掌握这类因果关系。任何声称"接了某协议就能提升 X%"的说法，在没有对照实验的情况下都不成立。

七、给商家的优先级清单

按"投入产出比"排序，而不是按"技术先进性"排序：

⚠️ 一个务实的提醒：P0 的三项是"不做就出局"，不是"做了就有优势"。它们的作用是让你不掉队，而不是让你领先。

八、这件事与 GEO 的关系

最后回到本文开头的问题：这跟 GEO 是什么关系？

我的判断是——它是 GEO 在电商场景里的下半场：

• 上半场是内容层：让 AI 愿意引用你的内容（可发现性、结构化、事实一致性）；
• 下半场是交易层：让 AI 能准确读取并下单你的商品（字段规范、实时同步、履约信息）。

两者有一个共同点，也是这几年最反直觉的一条规律：它们的胜负手都不在"写得多好"，而在"结构性事实对不对、够不够新"。

内容层拼的是"AI 读到的事实是不是准确、是不是最新"；交易层拼的是"商品字段是不是完整、价格库存是不是实时"。写得漂亮但字段错的商品页，和一个字段全对但没有独立价值的介绍页，都不会赢。

而两者还有一个共同的边界：**结构化的完备性可以被测量，被选中与否不可以被承诺。**这是做这个行业必须守住的一条线。

参考来源

本文引用的所有技术约束均来自上述官方来源，并标注了原文表述。文中"我司实测"部分为本平台对真实店铺的验证结果，不含推测。本平台与上述任何协议方（OpenAI、Stripe、Google、Shopify）无股权、雇佣或合作关系；引用不代表其认可本平台或其产品。