一、背景与引入
1.1 从经典 SEO 到“可被模型理解的商务”
过去二十年，独立站优化的核心是让搜索引擎爬虫高效发现、抓取并索引页面，例如 robots.txt、sitemap.xml、结构化数据等。
进入生成式 AI 与代理自动化时代，流量与转化的入口正在分化。
用户既在 Google / Bing 搜索，也在 ChatGPT、Perplexity、Copilot 等环境中提问并获得答案；同时，自主购物代理、比价助手、语音助手下单等“代理商务”（agentic commerce）场景也在快速演进。
在这一背景下，业界逐步出现面向大模型的纯文本“站点摘要”约定，例如广泛讨论的 llms.txt 思路：
用机器友好、低噪声的文档说明“你是谁、核心事实是什么、权威入口在哪里”，以降低模型幻觉与重复爬取成本。
与之并行的是程序化交易协议，例如 Universal Commerce Protocol（UCP）与 MCP（Model Context Protocol）等，它们把“发现能力 → 工具列表 → 购物车 / 结账流程”暴露给代理运行时。
矛盾在于：
如果把所有这类信息仅散落在首页 HTML、博客或 PDF 中，模型与代理很难稳定定位“官方、最新、低歧义”的版本。
于是，需要一层显式的、可发现的元数据基础设施。
1.2 Shopify 的平台级动作：Agentic Discovery 子站点地图
Shopify 在近期为商户店面提供的机制中，包括在主站点地图体系下增加 sitemap_agentic_discovery.xml。
示例商户：
https://www.getcasely.com/sitemap_agentic_discovery.xml
该子站点地图会固定枚举三类 URL，并给出 weekly 更新频率提示：
/llms.txt
/llms-full.txt
/agents.md
下文将围绕同一框架说明：
- 为什么需要单独的子站点地图。
llms.txt、llms-full.txt、agents.md分别代表什么。- 这些文件对 GEO 和 agentic commerce 有什么商业价值。
- Shopify 在 AI 时代建站与商务基础设施上的平台友好度意味着什么。
二、sitemap_agentic_discovery.xml：为何是“子站点地图”？
2.1 职责分离：Separation of Concerns
主 sitemap.xml 通常承载大量商品、集合、博客等 URL，主要服务于经典爬虫与抓取频次管理。
而将 llms.txt、llms-full.txt、agents.md 单独放入 sitemap_agentic_discovery.xml，传递的是另一层信号：
这些 URL 不是传统意义上的“页面流量入口”，而是面向模型与代理机的“元数据与协议层”。
它们与海量商品 URL 解耦，有利于降低索引噪声，并由平台以统一模板维护。
2.2 机器可发现的入口清单
对 LLM 爬虫、合规 bot，以及未来进一步标准化的“代理发现”流程而言，XML 站点地图是一种低成本、低歧义的枚举格式。
它不需要解析复杂 HTML，就可以列出商店为 AI / 代理准备的 canonical 文档集合。
其中，<changefreq>weekly</changefreq> 在传统 SEO 中多为提示性质；在代理调度场景中，同样可以作为新鲜度假设的参考，便于抓取计划。
2.3 产品叙事：GEO 与代理商务的双重对齐
agentic_discovery 这个命名，明确对齐两条主线：
GEO / AEO
让商店在生成式答案环境中更容易被引用、摘要、对齐事实，减少错误品牌信息与过时联系方式。
Agentic commerce
让自主代理能够合法、安全、可审计地发现协议端点，例如 /.well-known/ucp、MCP 接口，而不是仅依赖脆弱的 HTML 抓取路径。
子站点地图在这里扮演公开的“AI 侧书签索引”：
把平台希望商户具备的“模型与代理可读资产”，一次性暴露给生态系统。
三、llms.txt：面向模型的极简站点摘要
llms.txt 可以理解为 Lean Grounding Pack，也就是面向模型的极简站点摘要。
3.1 内容结构
以示例商户逻辑为准，典型结构通常包括：
- 品牌一句话定位。
- 站点归属，例如 Shopify。
- 最少可用的浏览路径，例如全店集合、搜索模板 URL。
- 货币与联系方式。
For Agents & Developers小节。- 指向
agents.md、.well-known/ucp、/api/ucp/mcp与主sitemap.xml。
3.2 专业价值
llms.txt 的价值在于，它为 AI 模型提供了一份轻量、稳定、低噪声的商店说明。
它不是给真人浏览的营销页面，而是给模型快速 grounding 的站点名片。
它能帮助 AI 更快理解：
- 这个网站是谁。
- 这个品牌卖什么。
- 主要入口在哪里。
- 联系方式与货币信息是什么。
- 面向代理或开发者的下一步入口在哪里。
小结：
llms.txt ≈ 面向 LLM 的商店名片 + 合规导航指针，偏检索、摘要与轻量 grounding。
四、llms-full.txt：扩展上下文包
llms-full.txt 可以理解为 Rich Grounding + Dev Surface，也就是比 llms.txt 更完整的扩展上下文包。
4.1 相对 llms.txt 的加厚点
在相同骨架上，llms-full.txt 通常会增加更多机器可读端点，例如：
/products/{handle}.json
/collections/{handle}/products.json
同时，Store Information 部分可能会补全店名、官网等信息。
For Agents & Developers 部分也可能补充 Storefront API 文档入口，并与 sitemap.xml 并列展示。
4.2 专业价值
llms-full.txt 的价值在于，它为 AI 和开发者提供了更厚的事实层与端点索引。
相较 llms.txt，它不只是告诉模型“我是谁”，还进一步告诉模型和代理：
- 有哪些机器可读的数据入口。
- 商品与集合信息可以从哪里读取。
- 开发者应该从哪些 API / 文档入口继续集成。
- 哪些页面或端点更适合进行结构化抓取。
小结：
llms-full.txt ≈ 加厚 grounding + 开发者友好的端点索引，但它仍不是支付与结账流程的规范全文。
五、agents.md：面向自主代理的操作手册与合规边界
agents.md 可以理解为 Executable Agent Policy，也就是面向自主代理的可执行操作手册与合规边界。
5.1 文体与内容重心
这个文档从营销摘要转向协议说明。
它通常基于 Universal Commerce Protocol（UCP）描述典型链路：
Discover → Search → Cart → Checkout → Fulfill → Complete
并标明关键能力与边界，例如：
Discovery：GET /.well-known/ucp
MCP：POST /api/ucp/mcp，通过 MCP tools/list 发现工具与 schema
版本：如 2026-04-08 等稳定版本标识
硬规则：结账须买方明确同意、429 退避、传递国家 / 货币等买方上下文
只读浏览：集合页、.json、站内搜索等无需认证的路径
5.2 专业价值
agents.md 的价值在于，它告诉 AI Agent：
- 可以怎样发现商店能力。
- 可以调用哪些协议入口。
- 哪些路径是只读的。
- 哪些行为需要买方明确授权。
- 结账、限流、上下文传递等边界是什么。
- 如何在 UCP / MCP 语境中合规完成商务流程。
它不是普通帮助文档，而是代理商务时代的操作策略层。
小结：
agents.md ≈ 程序化交易的语义与安全策略，连接 UCP / MCP 与 Shopify 作为承载平台的叙事。
六、三者与子站点地图的组合效应
从栈式理解来看，sitemap_agentic_discovery.xml、llms.txt、llms-full.txt、agents.md 共同构成了一套面向 AI 模型与自主代理的发现基础设施。
1. sitemap_agentic_discovery.xml
将三类 AI / 代理专用资产登记为可发现、可调度更新的公共资源，并与海量商品 URL 解耦。
2. llms.txt
提供最小、稳定、低噪声的模型侧摘要与指针，服务于 GEO / 检索友好。
3. llms-full.txt
提供加厚事实与端点清单，支撑更深入的结构化抓取与集成，但不取代正式 API 文档。
4. agents.md
说明代理如何被允许做事、必须遵守什么，衔接 UCP / MCP 与结账边界。
整体上，这套机制正在落实一个重要方向：
商店不仅要被搜索引擎索引，还要被模型与代理可靠地发现、理解与合规调用。
这属于基础设施层，而不是单次营销活动。
七、总结：Shopify 在 GEO 与 Agentic Commerce 上的友好度与建站优先级建议
7.1 GEO：生成式引擎优化维度
Shopify 通过默认暴露 llms.txt、llms-full.txt，并用专用子站点地图将其纳入可发现集合，实质上为商户提供了平台级、模板化的“模型友好事实层”。
这些内容包括：
- 品牌与联系方式。
- 浏览入口。
- 货币信息。
- 协议指针。
- 面向代理和开发者的入口。
这些信息可以被 AI 重复引用，有利于在生成式答案场景中降低错误信息与过时结构。
相较自建站或依赖插件拼凑的实现路径，Shopify 的一致性、覆盖面与演进节奏更容易跟平台版本对齐。
7.2 Agentic commerce：代理商务维度
通过 agents.md 与 UCP / MCP discovery 的标准陈述，Shopify 将以下链路纳入同一话语体系：
代理发现 → 工具枚举 → 购物车 / 结账语义
同时，它也对支付同意、限流、上下文等给出可操作边界。
这对信任、合规与可复制集成至关重要，也是平台型商务基础设施与“一次性脚本抓取”的本质差异。
7.3 建站与选型建议
从研究视角看，如果团队的核心诉求包括：
- 生成式环境中的品牌可控性与可被引用性。
- 未来接入代理购物与程序化商务协议。
- 减少自研 discovery 与文档分叉成本。
- 降低 AI 模型误读品牌与商品信息的概率。
- 提升站点对 AI Agent 的可发现性与可理解性。
那么，在同等产品与运营条件下，将 Shopify 作为优先考虑的建站与商务栈之一具有较强合理性。
它并非唯一选项，但在 GEO 基础设施与 agentic commerce 协议对齐上，当前公开路径清晰、可观测性强。
例如，可以通过各店的 /sitemap_agentic_discovery.xml 与相关文件直接核验。
参考示例
可线上核验的 Agentic discovery 子站点地图示例：