智能体商务（Agentic Commerce）Feed 就绪指南：UCP、ACP 和 AI Mode 的实际要求

在过去十八个月里，电商领域悄然发生了一场结构性的变化，而关于这场变化的大多数文章，要么过度兴奋，要么含糊其辞。

下面是具体的版本。当购物者让 AI 助手帮忙寻找商品时，助手并不会访问您的首页。它看不到您的产品摄影、品牌故事，也看不到文案人员反复推敲的商品描述。它读取的是结构化商品数据（Feed、结构化数据块、API 响应），并据此决定推荐您还是其他商家。

您的 Feed 一直是广告的输入。现在，它也成了推荐本身的输入。

目前有三个系统决定了这一切如何运作：Google 的通用商务协议（Universal Commerce Protocol，UCP）、OpenAI 与 Stripe 的智能体商务协议（Agentic Commerce Protocol，ACP），以及 Perplexity 的商家计划。很多文章把它们写得好像是换了不同标志的同一样东西。事实并非如此。它们使用的数据不同、格式不同、要求不同，上线的国家/地区也不同。

本指南将介绍每个系统在字段层面的实际要求、哪些内容真正重叠、哪些不重叠，以及（由于本博客的大多数读者主要并不在美国销售）在智能体结账尚未进入您所在市场时，哪些工作值得去做。

---

坦率地看整体格局

在继续之前，有两点观察。

第一：发现和结账是两个独立的问题。能够被 AI 智能体找到，是一个数据质量问题，如今在世界任何地方都适用。能够在 AI 界面内完成交易，则是一个协议集成问题，目前仅限于少数几个市场。把两者混为一谈，是关于这一话题的报道中最常见的错误，它让美国以外的商家得出结论，认为这些都与自己无关。事实恰恰相反：发现层适用于所有人，而且目前几乎所有可获得的价值都在这一层。

第二：各协议正在基础设施层面趋同，而不是在数据层面趋同。UCP 明确与 A2A、AP2 和 MCP 协同工作。ACP 也基于相同的总体思路。但它们的商品架构仍然确实不同，为其中一个构建的 Feed 不能直接用于另一个。这是一个 Feed 管理问题，而不是战略问题，而且有一个直接的解决方案：维护一个经过丰富的内部唯一可信数据源，并从中为每个目标渠道生成导出文件。

---

第 1 层：发现基线（如今在任何地方都适用）

在进行任何特定于协议的工作之前，所有这些系统都有一组共同的要求。如果您从本文中只做一件事，那就做好这一层。它不需要任何集成工作，而它恰恰决定了您能否被推荐。

商品标识符

GTIN 是整个 AI 购物生态系统的连接键。所有这些系统都使用标准化标识符，将您的商品与其他地方的同一商品进行匹配：比较价格、汇总评价，以及确认您的商品信息与某个评测网站的商品信息描述的是同一件商品。

缺少 GTIN 不会产生错误提示，而是会悄无声息：您的商品根本不会出现在智能体所进行的比较中。据报道，Perplexity 对标识符完整性的要求尤其比 Google 更严格。

请按在售 SKU 的百分比来审核 GTIN 覆盖率。如果低于 90%，这个数字就是您的首要项目。

属性完整性

传统的购物广告只需要相当少的一组必填属性。而智能体会对您提供的所有信息进行推理。每个已填写的字段，都是智能体推荐您的潜在理由：材质、尺寸、兼容性、保养说明、电源要求、保修条款。

需要转变的思维是：属性不再是一个筛选值，而是一个论据。material: full-grain leather 不是一个筛选维度，而是当购物者询问两个包中哪一个更耐用时，智能体会使用的那句话。

所有界面之间的一致性

这是最常被忽略、也最可能对您造成伤害的要求。

如果人类购物者在您的商品页面上看到 ₺2,499，而在比价结果中看到 ₺2,399，他们会耸耸肩继续浏览。而智能体会将这种不一致视为关于您数据可靠性的信号；对智能体的运营方来说，因价格变动而导致结账失败，是比干脆不推荐您糟糕得多的结果。

请审核以下各处之间的一致性：您的商品页面、Merchant Center Feed、页面上的结构化数据，以及您运营的所有电商平台商品信息。价格、库存状态、配送条款和退货政策都必须一致。尤其是退货和配送政策，越来越多地被智能体读取并转述给购物者。

时效性

<!-- İç link: /feed-update-frequency -->

每晚刷新一次 Feed 已经不够了。Google 的 Shopping Graph 每小时刷新数十亿条商品信息，并且更偏好实时数据；OpenAI 的 Feed 接收机制可接受最快每 15 分钟一次的刷新。

原因并非表面上的。当智能体能够完成交易时，过时的库存数据导致的就不再是一个略感失望的购物者，而是一笔失败的交易。导致交易失败的系统会被降低权重。

实际目标：对于周转快的库存，价格和库存状态在 15 分钟内同步；其他所有商品至少每小时同步一次。对大多数商家而言，这意味着从按计划抓取文件转向基于 API 或推送的更新。

抓取访问

检查您的 robots.txt 中针对 AI 爬虫的设置。在 2024 年和 2025 年关于“是否应允许 AI 使用我们的内容进行训练”的争论中，许多商家条件反射般地屏蔽了这些爬虫，并且此后再也没有重新审视这一决定。屏蔽为购物索引提供数据的爬虫，与屏蔽用于训练的爬虫是两个不同的决定，而前者常常是被一个从未将其视为商务决策的团队无意中做出的。

---

第 2 层：Google 的对话式属性

这是整个话题中最具体、讨论最少、也最能立即付诸行动的部分，值得反复阅读。

在推出 UCP 的同时，Google 在 Merchant Center 商品数据规范中新增了一组对话式属性。它们是选填的，用于补充您现有的商品数据，其明确目的是帮助 AI 系统和对话式智能体理解您商品的具体细节。Google 表示，添加这些属性不会影响现有商品的审批状态。

最后这一点很重要：下行风险为零。您只是在添加描述性数据，并没有改变 Google 在审批时验证的任何内容。

以下是这组属性：

Google 自己给出的完整示例针对一款手机的某个变体，在同一个商品上，除标准属性外，还组合使用了 item_group_title、variant_option、question_and_answer、product_highlight、product_detail、related_product、popularity_rank 和 document_link。

为什么是这六个属性，它们真正的用途是什么

看看每个属性能为智能体做些什么：

• question_and_answer 是智能体的台词。购物者问“这个可以用洗碗机清洗吗？”，智能体要么有您的答案，要么没有。如果没有，它要么说不知道（这会失去这笔销售），要么推荐填写了该字段的竞争对手。
• document_link 为智能体提供了一份可以推理的文档。组装说明可以回答“这个组装起来有多难？”，规格表可以回答您无法预料的兼容性问题。
• related_product 让交叉销售在您的网站从购物旅程中消失后依然存在。尤其是 required_part，它可以防止智能体商务中最糟糕的结果：购物者买到了一件无法单独使用的商品。
• item_group_title 和 variant_option 解决了变体 Feed 自诞生以来就一直存在的难题：智能体看到八行数据，却不明白它们是同一件商品的八个尺码。这是变体结构化问题在新场景下的体现。
• popularity_rank 是您告诉智能体哪些商品真正畅销的方式。没有其他人能为它提供这一信号。

如何大规模填写这些属性

坦率地说，障碍在于：没有人的 PIM 中现成就有一个 question_and_answer 列。

但大多数商家都有原始素材：客服工单主题、页面上的商品常见问题、评价内容、退货原因。最有价值的问答对，通常就藏在客服团队最常回答的问题以及商品被退货的原因中。一条写着“不适配我的机器”的退货记录，就是一个您应该在 Feed 中回答的兼容性问题。

Google 建议通过补充数据源添加这些属性，而不是改造主 Feed。从运营角度来看，这是正确的选择，因为负责商品数据的团队和负责客服内容的团队很少是同一个团队。

在商品目录规模上，这就变成了一个规则问题：从父商品名称派生 item_group_title，根据您已存储的颜色和尺码属性构建 variant_option，以百分位数形式根据自己的销售数据计算 popularity_rank，并按 SKU 模式从现有的使用手册库中映射 document_link。在 Feedance 中，这些都是每次刷新时应用的 Feed 规则，尤其是 popularity_rank，可以根据销售数据自动重新计算，而无需手动维护。

先从按收入排名前 200 的 SKU 开始，每个 SKU 准备三组问答。这只需一周的工作量，却能覆盖您在智能体中可见的大部分展示。

---

第 3 层：OpenAI 的 ACP，一种真正不同的结构

如果您认为 ChatGPT Feed 只是换了列名的 Google Feed，那么您构建出来的东西就会是错的。ACP 商品 Feed 架构在结构上是不同的，而这些差异很能说明智能体系统想要什么。

商品包含变体。Google 的 Feed 是扁平的：每个变体都是单独的一行，通过 item_group_id 关联在一起。ACP 则正好相反：商品对象是规范记录，其中包含一个变体对象数组。每个变体都有自己的 ID、标题、价格、库存状态、媒体和选项。

对智能体来说，这是一个更好的模型，值得理解其原因。扁平的 Feed 要求智能体根据共享的分组键重建“这是一款有九个尺码的鞋”这一事实。而嵌套的 Feed 则直接把这个事实交给它。变体繁多的商品目录（尤其是时尚类）的商家，在这里能获得实实在在的准确性提升。

价格是以最小货币单位表示的整数。{ "amount": 7999, "currency": "USD" } 表示 79.99 USD，而不是十进制字符串。任何对价格进行浮点运算的数据流程，都需要在它悄无声息地产生错误结果之前进行检查。

描述是对象，而不是字符串。description 对象接受 plain、html 和 markdown，您可以提供其中任意组合。

卖家政策链接是一等字段。seller 对象包含 links，其类型可以是 privacy_policy、terms_of_service、refund_policy、shipping_policy 或 faq。请再读一遍这个列表：智能体希望将您的退货政策作为结构化字段获取。在购物者永远看不到您网站的世界里，您的政策必须随商品一起传递。

商品状况是一个数组。["new"]，并且可以适用多个值，这为二手转售和翻新库存预留了空间。

一个最简结构如下：

{
  "id": "SKU12345",
  "title": "Trail Running Shoe",
  "description": { "plain": "Waterproof trail shoe with cushioned sole." },
  "url": "https://example.com/products/SKU12345",
  "media": [
    { "type": "image", "url": "https://example.com/images/SKU12345.jpg",
      "alt_text": "Black trail running shoe", "width": 1200, "height": 1200 }
  ],
  "variants": [
    {
      "id": "SKU12345-BLK-10",
      "title": "Black / 10",
      "barcodes": [{ "type": "gtin", "value": "1234567890123" }],
      "price": { "amount": 7999, "currency": "USD" },
      "list_price": { "amount": 9999, "currency": "USD" },
      "availability": { "available": true, "status": "in_stock" },
      "variant_options": [
        { "name": "color", "value": "Black" },
        { "name": "size", "value": "10" }
      ],
      "categories": [
        { "value": "Apparel & Accessories > Shoes", "taxonomy": "merchant" }
      ],
      "condition": ["new"],
      "seller": {
        "name": "Example Store",
        "links": [
          { "type": "refund_policy", "title": "Returns policy",
            "url": "https://example.com/returns" }
        ]
      }
    }
  ]
}

Feed 文件附带一个标头，其中包含 feed_id、account_id、target_merchant 和 target_country。请注意，国家/地区是在 Feed 级别设置的，这意味着多市场商家需要为每个市场提交一个 Feed。

OpenAI 推荐的交付模式是每天通过文件上传提交一次完整 Feed，日内更新则通过 API 推送。小型商品目录可以全部通过 API 完成。

有一点值得清醒认识：OpenAI 的对话内结账在第一年的发展比发布时所暗示的更为曲折，该公司已公开承认，最初的 Instant Checkout 实现不如预期灵活，并将重点转向商品发现，再将用户引导至商家网站完成支付。如果您需要确定优先级，请将 ACP 发现视为近期机会，而将 ACP 结账视为一项更长期的押注。

---

第 4 层：Perplexity

Perplexity 的商家计划是三者中文档最少的，也正因如此，相关报道中的错误最多。那些发布详细 Perplexity 字段规范的指南，都是从 Google 的规范推断而来的，官方并未发布字段规范。

已知的信息如下：

• 该计划免费，采用申请制；2025 年和 2026 年期间，入驻范围一直在扩大。
• Feed 以 CSV 或 XML 格式，通过 API、SFTP 或专用 S3 存储桶，按 Google Shopping 格式交付。
• 商品数据完整性是一项排名输入：数据越完整，系统在生成比较和优缺点总结时可用的信息就越多。
• 与 Google 相比，标识符完整性、评价数据和页面上的 Schema.org 标记似乎被赋予了更高的权重。
• 被引用并不严格要求提供 Feed：一个可被抓取且具有干净 Product 结构化数据的商品目录也可以被展示，但 Feed 能提高成为推荐商品的几率。
• 交易功能仅限美国。在美国以外，您可以被引用和链接，但无法通过它完成销售。

实际的解读是：对于 Perplexity，要做的工作是商品页面上的 Schema.org 规范化加上评价数据，而不是新的 Feed 集成。如果您的商品详情页已经输出包含 GTIN、价格、库存状态和 aggregateRating 的有效 Product 和 Offer 标记，那么大部分工作您已经完成了。

---

第 5 层：结账，以及真实的地域情况

这是相关报道最容易夸大其词的地方，所以让我们准确说明哪些功能真正已经上线。

UCP 结账。面向部分商家开放，截至撰写本文时，符合条件的商品范围为美国、加拿大和澳大利亚。它在 AI Mode 和 Gemini 中以“购买”按钮的形式出现在符合条件的商品信息上。您仍然是登记在册的卖家。顾客使用已保存在 Google Wallet 中的凭据，通过 Google Pay 付款。参与需要满足技术要求、提交意向表并完成实施，而且关键的是，只有带有 native_commerce(checkout_eligibility) 商品属性的商品信息才会显示“购买”按钮。

最后这个细节就是 Feed 层面的要点。UCP 结账中的其他一切都是后端集成工作；而资格信号本身就存在于您的商品数据中。

Google 于 2026 年 3 月宣布通过 Merchant Center 简化 UCP 入驻流程，同时推出购物车、商品目录和身份关联功能，并表示将在 2026 年内向全球扩展。

ACP 结账。需要实现三个流程：商品 Feed、结账 API，以及通过 Stripe 等支付服务提供商（PSP）进行的委托支付，面向经批准的合作伙伴开放。

Perplexity Buy with Pro。仅限美国。

如果您在美国以外销售

我们的大多数客户在土耳其、海湾地区和欧洲销售。对于这种情况，坦率的结论是：

智能体结账目前还无法为您所用。但智能体发现现在就已完全可用。

在伊斯坦布尔，一位让 Gemini 或 ChatGPT 比较商品的购物者，此刻得到的答案就是基于结构化商品数据生成的。这个答案是否包含您的商品，完全取决于上面的第 1 层和第 2 层：标识符覆盖率、属性完整性、对话式属性、时效性和一致性。这些都不需要协议集成、美国实体或抢先体验申请。

因此，对于非美国商家，推进顺序很清晰：

1. 全面做好第 1 层。它只有好处，而且还能提升您现有的 Shopping 和 Performance Max 效果。
2. 现在就做第 2 层。对话式属性已包含在标准 Merchant Center 规范中，没有审批风险，而且您所在市场几乎没有人填写过它们。
3. 关注第 5 层。当结账功能进入您的市场时，做好了第 1 层和第 2 层的商家将在几周内完成集成；而没有做好的商家，则只能从一个不完整的商品目录起步。

尽早行动的优势，并不在于您本季度就能在 ChatGPT 中完成交易，而在于商品目录数据质量需要数月才能修复，等到窗口打开时，是无法临时花钱速成的。

---

⚠️ 一个不可忽视的截止日期

与上述所有内容无关，但更加紧迫的是：Google 的 Content API for Shopping 将于 2026 年 8 月 18 日停用。在此日期之后，对旧版 v2.1 端点的调用将停止工作。

这只影响程序化集成，手动上传、计划抓取和 Google 表格 Feed 不受影响。使用官方平台集成（Shopify 的 Google & YouTube 渠道、WooCommerce 的 Google Listings & Ads）的商家将由平台处理。自定义集成和部分第三方工具需要手动迁移到 Merchant API v1。

今天就需要检查两件事：在 Merchant Center 中，前往设置 → 数据源，查看“来源”列。如果显示为“Content API”，您就有一项待办事项。另外请注意，Feed 标签不会自动迁移；如果您的 Google Ads 广告系列结构依赖 Feed 标签，草率的迁移可能会导致广告系列停止投放。

如果您的 Feed 通过 Feedance 提交到 Merchant Center，这项迁移将由我们负责处理，您的导出配置无需更改。

---

逐个字段看“智能体就绪”意味着什么

将各层内容整合为一个运营视图：

横向阅读这张表很有用：请注意，右侧的行为有多少是由选填字段驱动的，而大多数商品目录都把这些字段留空了。

---

就绪检查清单

基本要求：优先完成，它们适用于所有界面

• [ ] GTIN 覆盖率超过在售 SKU 的 90%
• [ ] 价格和库存状态在 15 分钟到 1 小时内同步，而不是隔夜同步
• [ ] 网站、Feed 和电商平台之间的价格、库存状态、配送和退货信息保持一致
• [ ] 所有图片至少为 500×500（自 2027 年 1 月 31 日起，Google 也将要求这一点）
• [ ] 每个商品详情页都有有效的 Product 和 Offer Schema.org 标记，有评价时还包含 aggregateRating
• [ ] 没有在 robots.txt 中意外屏蔽 AI 爬虫
• [ ] google_product_category 已正确映射，而不是交由推断
• [ ] 已确认完成 Content API 迁移

竞争优势：您所在市场的大多数商家还没有做这些

• [ ] 为按收入排名前 200 的 SKU 填写 question_and_answer，每个至少 3 组
• [ ] 为每个变体系列填写 item_group_title 和 variant_option
• [ ] 根据自己的销售数据计算 popularity_rank
• [ ] 从现有的使用手册和规格表库中映射 document_link
• [ ] 为配件和必需部件填写 related_product
• [ ] 为主推商品添加 video_link
• [ ] 收入排名前 10% 的商品属性完整性超过 95%

前沿探索：面向符合条件市场的商家

• [ ] 生成并交付 ACP Feed，每日完整提交并通过 API 进行日内更新
• [ ] 已提交 Perplexity 商家计划申请
• [ ] 已提交 UCP 意向表，并在符合条件的商品信息上标记 native_commerce 资格
• [ ] 在分析工具中单独标记来自智能体的流量和订单

最后一项值得强调。由智能体带来的订单，其归因方式与搜索或付费社交不同；如果您不在集成时就进行标记，将无法证明这些工作取得了成效。请在需要之前就把衡量体系搭建好。

---

值得投入吗？

这里给出一个平衡的回答，因为这个话题吸引的确定性往往超过了证据所能支持的程度。

持怀疑态度的理由。结账功能的普及速度比发布公告所暗示的要慢。OpenAI 在首次尝试 Instant Checkout 之后公开调整了方向。大多数交易功能都有地域限制。关于增量收入的公开数据很少，而那些听起来令人印象深刻的增长倍数，通常都是从很小的基数开始计算的。

仍然值得行动的理由。无论智能体商务能否达到预期，第 1 层和第 2 层中几乎所有内容都能提升您现有的付费广告效果。完整的属性、准确的标识符和新鲜的库存数据，如今就能让 Performance Max 表现更好。对话式属性没有审批风险。而商品目录数据质量是一个需要数月的项目，没有捷径可走；等到机会显而易见时才开始的商家，将从落后的位置起步。

我们建议的思路是：不要专门为智能体商务而构建，而要构建一个完整且正确的商品目录。智能体就绪就是 2026 年一个完整且正确的商品目录应有的样子。协议工作只是叠加在上面的薄薄一层，一旦底层数据正确，这部分工作可以很快完成。

如果您想在投入之前先了解基线，我们的免费商品 Feed 审核工具可以从数据完整性、数据质量和技术健康度三个方面为任何 Feed 评分，这可以合理地反映您已经具备了多少上述条件。

---

参考来源

• Google Merchant Center 帮助：关于通用商务协议（UCP）：https://support.google.com/merchants/answer/16837055
• Google Merchant Center 帮助：如何使用对话式属性：https://support.google.com/merchants/answer/17085370
• Google Merchant Center 帮助：商品数据规范：https://support.google.com/merchants/answer/7052112
• Google Developers Blog：Under the Hood: Universal Commerce Protocol：https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/
• Google for Developers：从 Content API for Shopping 迁移到 Merchant API：https://developers.google.com/merchant/api/guides/compatibility/overview
• OpenAI Developers：商品 Feed 规范（Agentic Commerce）：https://developers.openai.com/commerce/specs/spec
• OpenAI Developers：Agentic Commerce 关键概念：https://developers.openai.com/commerce/guides/key-concepts
• Agentic Commerce Protocol：https://www.agenticcommerce.dev/
• Universal Commerce Protocol：https://ucp.dev