Fall '26 之后，一家 Shopify 店铺对 AI 代理暴露的面可以拆成六层。自上而下是代理的接触顺序，自下而上是你应该建设的顺序。
把这个倒置关系搞对，就得到了这个模型的大部分价值——因为我们见到的团队几乎都是从错的一端开始的。
核心要点
- 六层：渠道、技能、服务、协议、数据、结算。
- 每一层有自己的失败模式和自己的负责人。把它们当成一个项目来做，正是代理商务工作停滞的原因。
- 第五层「数据」是唯一一层几乎完全由你掌控的。
- 第四层与第六层由平台托管——这让它们很容易被默认为没问题，而实际上并不是。
- 自下而上建：先证明能被调用，再打磨调用返回的内容。
六层
层 | 关键资产 | 你能控制的 | 最常见的坑 |
|---|---|---|---|
1 · 渠道 | ChatGPT、Copilot、Gemini 与 AI Mode、Shop 应用 | 是否有资格，以及在哪些市场 | 以为有资格就有量，忽略各渠道自己的门槛 |
2 · 技能 | 官方 Shop skill、你的 | 不是文件本身——只有它引用的东西 | 手写 llms.txt，而在 Shopify 上它只是 agents.md 的镜像 |
3 · 服务 | Global Catalog、Storefront Catalog、购物车/结算/订单、Ask、WebMCP | 是否被收录，工具是否注册 | Headless 店面整层缺失而无人发现 |
4 · 协议 |
| 基本由平台托管——你的任务是确认它确实起来了 | 自定义域名下的能力与主站不一致 |
5 · 数据 | 标题、描述、媒体、选项、分类、价格、划线价、库存、事实 | 几乎全部 | 把预算花在代理看不见的 PDP 视觉上 |
6 · 结算 | Shop Pay、 | 支付方式、市场、代理条款 |
|
反直觉的优先级
直觉是从第五层开始。那是营销能掌控的层，工作熟悉，而且做起来有产出感：改标题、丰富描述、修分类。
但如果第四层或第六层是断的，更好的第五层工作只是提高了一个永远不会被调用的接口的质量。你没法靠优化绕过一个 404。
自下而上建：
- 先第六层。
payment_handlers填好了吗？permalink 指向自有域名吗？如果单成交不了，上面都不重要。 - 再第四层。
/.well-known/ucp返回 8 项以上能力吗？这一层通常没问题，而确认它只要一条命令。 - 然后第三层。
tools/list返回约十五个工具吗？首页注册了 WebMCP 标记吗？ - 接着第二层。
/agents.md与/llms.txt返回 200 吗？它们引用的政策页填完整了吗？ - 再做第五层。 现在商品数据工作才有回报，因为有地方可以回报了。
- 最后第一层。 在其余层稳住之后，做渠道资格与市场扩张。
十分钟自查用六条命令覆盖第一到第四步。
每一层真正的负责人
这是这个模型在组织上最有用的地方。这些不全是营销的活，假装它们是，正是工作停滞的原因。
层 | 负责人 | 第一个动作 |
|---|---|---|
1 · 渠道 | 增长 | 确认各渠道资格与你实际的开关状态 |
2 · 技能 | 法务与客服 | 补齐三个政策页；接受代理条款 |
3 · 服务 | 工程 | 验证 WebMCP 注册与工具清单 |
4 · 协议 | 工程 | 一条 curl，每季度一次，每次发版后一次 |
5 · 数据 | 商品与内容 | 标准分类、Color/Size/Target gender、可抽取文案 |
6 · 结算 | 支付与财务 | 支付方式、市场、 |
第五层很强而第六层断掉，是我们见得最多的形态，也是最浪费的——投入已经发生，回报是零。
各层在实践中怎么断
Headless 构建会同时断掉第二层与第三层。 两个代理文件 404，WebMCP 零注册，而第四层仍然返回 200——这让人以为协议没问题。完整对比在这里。
自定义域名会悄悄断掉第四层与第六层。 能力与 permalink 端点可能与主站不同，于是 permalink 指回 myshopify 域名，而没人注意到，因为店面对人类访客运行得完美。
营销会通过优化错的字段断掉第五层。 代理拿到的商品对象只有 14 个顶层字段，评论、视频与 3D 不在其中。
常见问题
必须六层全通才有价值吗？ 需要第四、五、六层。第三层在 Liquid 上基本自动。第二层取决于第六层的政策前提。第一层是其余层稳住之后增长发生的地方。
多久审一次？ 每季度一次，另加每次主题发版、迁站、支付与市场配置变更之后。协议版本的变动不跟着你的发版节奏走。
这个模型只适用于 Shopify 吗？ 层次结构可以推广到任何电商栈。Shopify 特有的是第三层与第四层有多少是白来的——在自建栈上那些都是工程预算，这也是整场发布在竞争层面最锋利的一点。