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

> 做 SEO 时向搜索引擎提交 sitemap，做 GEO 时向 AI 提交什么？答案是商品 feed。但 2026 年的商品 feed 已经有三个互不相同的协议——OpenAI 与 Stripe 的 ACP、Google Merchant、Shopify 的 UCP/MCP。本文把三者的技术规范、字段要求与运营约束摊开对照，并说明它到底能解决什么问题、不能解决什么问题。

## 从 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 店铺（商家零操作），确认以下端点全部自动存在且可用：

| 端点 | 状态 | 内容 |
|---|---|---|
| `/agents.md` | HTTP 200 | 给 AI agent 的说明书：如何交互、推荐安装 Shop skill |
| `/.well-known/ucp` | HTTP 200 | 完整商户档案：支持版本、能力清单、支付方式 |
| `/api/ucp/mcp` | HTTP 200 | MCP 端点，`tools/list` 返回 **13 个工具** |
| `sitemap_agentic_discovery.xml` | HTTP 200 | 专给 agent 的 sitemap 扩展 |

那 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`），单个商品要填的字段分成十组：

### 基础与标识

| 字段 | 要求 | 约束 |
|---|---|---|
| `id` | **必填** | ≤100 字符，建议用 SKU，更新时必须保持不变 |
| `title` | **必填** | ≤150 字符，**避免全大写**，须与落地页标题一致 |
| `description` | **必填** | ≤5000 字符，**纯文本**，不得含店铺链接 / 促销信息 / 竞品信息 |
| `link` | **必填** | 必须 **HTTP 200** 可达（不允许死链） |
| `brand` | **必填**（影视书除外） | ≤70 字符 |
| `gtin` | 建议 | ≤50 字符，去掉短横与空格 |
| `mpn` | **无 GTIN 时必填** | ≤70 字符，只能填厂商分配的 MPN |

### 媒体

| 字段 | 要求 | 约束 |
|---|---|---|
| `image_link` | **必填** | JPEG/PNG，公网可访问，**建议 ≥800×800**，**禁水印/文字叠加/促销图形** |
| `additional_image_link` | 可选 | 最多 10 张，逗号分隔（URL 内的逗号需编码为 `%2C`） |
| `video_link` | 可选 | 建议 15–60 秒 |
| `model_3d_link` | 可选 | GLB/GLTF，<20 MB |

### 变体与自定义选项

```
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` 下的所有商品必须使用同一组变体属性**。官方举例——一条裙子有两个颜色两个尺码，那么每个变体都必须同时提供颜色和尺码。

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

| 字段 | 要求 | 说明 |
|---|---|---|
| `availability` | **必填** | `in_stock` / `out_of_stock` / `preorder` / `backorder` |
| `availability_date` | preorder 时必填 | ISO 8601 |
| `inventory_quantity` | `inventory_not_tracked=false` 时必填 | 非负整数 |
| `price` | **必填** | 金额 + ISO 4217 货币 |
| `sale_price` | 可选 | 折扣价 |
| `sale_price_effective_date` | **有 sale_price 时必填** | 起止日期用 `/` 分隔 |

### 履约（物流与退货）

`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 与排序系统识别高质量、可信的商品**。

| 字段 | 约束 |
|---|---|
| `popularity_score` | 0–5 分，用一致口径（如近 90 天） |
| `return_rate` | 0–100 数值，**不带 % 号** |
| `product_review_count` | 非负整数 |
| `product_review_rating` | 1–5，`review_count > 0` 时必填 |

富内容三个字段值得单独说，因为它们是**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 官方给出了分类型的更新频率：

| Feed 类型 | 频率 | 用途 |
|---|---|---|
| 商品数据 | **每天一次** | 标题、描述、图片、类目 |
| 库存 | **每 15 分钟** | 防 agent 展示已缺货商品 |
| 价格 | **每 15 分钟** | 保持结账价与报价一致 |
| 促销 | 按需 | 折扣码、优惠、免运费 |

原因很直接（官方原文）：**价格不一致会导致结账失败**——"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 模式会永久删除未包含的商品。**

两种处理模式：

| 模式 | 行为 | 适用 |
|---|---|---|
| `upsert`（默认） | 未包含的商品**保持不变** | 所有增量更新 |
| `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 通道自动就有，那商家还需要做什么？

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

| 层 | 谁做了 | 商家要做什么 |
|---|---|---|
| **通道**（商品能被 agent 找到、下单） | **Shopify 已做完**（UCP/MCP 自动启用） | 不需要做 |
| **数据质量**（商品数据对不对、全不全） | 部分 | **需要做**——差字段会让 agent 读不到或读错 |
| **可见性**（AI 是否真的推荐了你、竞品是否更常被推荐） | **没人做** | 需要独立测量 |

第三层是关键。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** | 把商品**基础字段**补齐：`id` 一致、`title` 规范、`description` 纯文本无链接、`link` 可达（HTTP 200）、`image_link` ≥800×800 无水印 | 官方硬性要求，缺一项即无法进入 |
| **P0** | **库存与价格同步做到 15 分钟级**（或调用 Incremental 接口） | 官方明确：不同步直接导致结账失败 |
| **P0** | **下架商品显式 `delete=true`** | 官方明确：upsert 模式下漏传不会删除 |
| **P1** | 补 `shipping` / `free_shipping_threshold` / `shipping_exclusions` | 配送信息是买家决策要素，且是 agent 计算总价所需 |
| **P1** | 补 `gtin` / `mpn`（有则填） | 影响商品匹配与去重 |
| **P1** | 补性能信号：`popularity_score` / `product_review_rating` / `return_rate` | 官方说明这些字段**直接喂给排序系统** |
| **P2** | 补富内容：`product_highlight`（4–6 条）/ `question_and_answer` / `product_reviews` | 这些是 AI 对话里真正会引用的素材 |
| **P2** | 站点结构化数据（schema.org Product） | 可反哺 Merchant Center 自动更新（官方说明） |
| **P2** | 评估 `disable_checkout` 是否适合你的品类 | 高客单/定制类可保留站内结账 |

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

## 八、这件事与 GEO 的关系

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

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

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

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

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

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

## 参考来源

| 来源 | 内容 | 链接 |
|---|---|---|
| Agentic Commerce Protocol 官方站 | 协议说明、FAQ、结账流程 | https://www.agenticcommerce.dev/ |
| ACP GitHub 仓库 | 规范与变更（Apache 2.0） | https://github.com/agentic-commerce-protocol/agentic-commerce-protocol |
| Stripe Agentic Commerce 文档 | catalog feed 逐字段规范、同步频率、处理模式 | https://docs.stripe.com/agentic-commerce/concepts/catalog-feed |
| Google Merchant Center 帮助 | 商品数据规范、Universal Commerce Protocol | https://support.google.com/merchants/answer/7052112 |
| Shopify 开发者文档 | UCP/MCP 端点与工具 | https://shopify.dev/docs/agents |

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