从商品页面到知识图谱：让你的店铺被 AI 发现
一个被要求在300美元以内找到最好的无线降噪耳机的AI代理，面临着一个根本性挑战。它不像人类那样看待网页。
可读性难题
一个被要求在300美元以内找到最好的无线降噪耳机的AI代理，面临着一个根本性挑战。它不像人类那样看待网页。人类看到的是一个布局精美的商品页面：主图、醒目的价格、五颗金色星星。代理接收到的是一串HTML流：
<div class="pdp-main" data-product-id="wh1000xm5">
<div class="gallery-wrapper">
<div class="swiper-container">
<div class="swiper-slide active">
<img src="/images/products/wh1000xm5-hero.jpg"
class="gallery__img pdp-gallery__main-img" />
</div>
</div>
</div>
<div class="pdp-info">
<span class="brand-label">Sony</span>
<h1 class="pdp-title">WH-1000XM5 无线耳机</h1>
<div class="price-block">
<span class="pdp-price__current">$349.99</span>
<span class="pdp-price__was">$399.99</span>
</div>
</div>
</div>
类名是任意的。pdp-price__current对一个没有专门针对这个站点命名规范训练过的 AI 毫无意义。另一个店铺可能用product__price--sale、offer-price，或者就是price。代理必须逆向工程出站点的设计系统，才能提取基本的商品信息。
这就是可读性难题。HTML是为人类视觉渲染设计的，不是为 AI 理解设计的。当AI代理成为产品信息的主要消费者时，这种架构上的错配制造了一个日益严重的商务障碍。
结构化数据长什么样
解决方案是嵌入页面<head>部分的JSON-LD。JSON-LD（链接数据的JavaScript对象表示）使用Schema.org词汇表以一种任何 AI 系统都可以解析的方式描述实体，无需理解视觉布局。
同一个产品用JSON-LD表示：
{
"@context": "https://schema.org",
"@type": "Product",
"name": "WH-1000XM5 无线耳机",
"brand": {
"@type": "Brand",
"name": "Sony"
},
"image": "https://store.example.com/images/products/wh1000xm5-hero.jpg",
"sku": "WH1000XM5-BLK",
"gtin13": "4548736132610",
"offers": {
"@type": "Offer",
"price": 349.99,
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": 4.7,
"reviewCount": 2847
}
}
每个字段都没有歧义。价格是一个带货币代码的数字。库存状态是Schema.org定义的枚举值。品牌是一个有类型的实体，不是一个CSS类名。AI代理消费这种数据时，解析歧义为零。
Schema.org商务词汇表
Schema.org为商务提供了丰富的类型集。对AI代理可发现性最关键的几种：
Product 是核心实体。它描述一个商品，包含名称、描述、图片、SKU、GTIN/UPC、品牌、颜色、材质、重量等字段。
Offer 代表一个具体的商业报价——价格、货币、库存状态、商品条件（全新、二手、翻新）、配送信息以及卖家。一个Product可以有来自不同卖家的多个Offer。
Brand 提供对制造商或品牌的有类型引用，支持跨商户的品牌查询。
Review 和 AggregateRating 让代理无需抓取评论组件就能获取社会证明数据。一个带有ratingValue和reviewCount的AggregateRating，让代理能够将口碑纳入推荐考量。
BreadcrumbList 描述类目层级结构，帮助代理理解一个产品在店铺分类体系中的位置。"电子产品 > 音频 > 耳机 > 头戴式"的面包屑路径提供了改善搜索相关性的类目上下文。
FAQPage 捕获关于产品的常见问题和答案。AI代理在对话式购物中越来越多地使用FAQ数据来回答用户的追问。
相比Microdata（嵌入HTML属性中）和RDFa等旧方案，JSON-LD是首选格式。原因很实际：JSON-LD位于文档head中的<script>标签里，与可视化DOM完全分离。这意味着结构化数据可以在不触碰页面HTML模板的情况下添加、更新或修正——对使用锁定CMS模板或第三方主题的店铺来说，这是很大的优势。
从HTML到知识图谱
ORBEXA的核心转化管线将非结构化的商户店铺页面转换为可查询的知识图谱。这个过程分五个步骤。
第一步：抓取并识别产品实体。 系统从商户店铺获取产品页面，识别哪些页面包含产品数据，区别于资讯内容、合集页面或博客文章。实体识别使用URL模式（例如Shopify店铺的/products/路径）、HTML meta标签以及现有的Schema.org标记。
第二步：提取属性。 从每个识别出的产品页面中，提取层抽取关键属性：商品名称、价格（现价和原价）、货币、库存状态、图片、变体选项（尺码、颜色、材质）、描述、SKU和分类信息。对于有结构化API的平台如Shopify，提取通过API完成。对于自建站，则依赖DOM分析和基于ML的提取。
第三步：规范化至Schema.org词汇。 提取的属性被映射到Schema.org的类型和属性。Shopify的variant.price值"34999"（分）变成一个Schema.org Offer，"price": 349.99，"priceCurrency": "USD"。库存字符串如"in_stock"、"available"或"true"统一映射到"https://schema.org/InStock"。品牌名称根据标准品牌字典进行规范化。
第四步：生成JSON-LD结构化数据。 规范化的数据被序列化为有效的JSON-LD文档。每个产品获得完整的结构化数据块，包含Product实体、其Offer、Brand引用、AggregateRating（当有评论时）以及BreadcrumbList用于类目上下文。这些JSON-LD块经过Schema.org规范和Google结构化数据要求的双重验证。
第五步：创建AI优化的查询端点。 结构化数据通过协议特定的端点提供服务。MCP资源将产品作为有类型的资源暴露，Claude和其他LLM可以通过MCP协议发现。UCP端点遵循Google和Shopify的Universal Commerce Protocol规范提供RESTful产品数据。ACP方法为OpenAI代理集成提供JSON-RPC访问。每个端点将同一底层知识图谱数据格式化为其目标协议。
最终结果是一个知识图谱，其中每个产品是一个节点，拥有有类型的、经过验证的属性和关系（与品牌、类目、评论和关联产品的关系）。AI代理通过协议端点查询这个图谱，而非抓取HTML。
知识图谱条目示例
为了更直观地说明，以下是一个产品经过ORBEXA管线处理后在知识图谱中的样子。商户的原始页面是一个使用标准Liquid模板的Shopify产品页面。
{
"id": "prod_8f2a4b1c",
"source": "shopify",
"merchantId": "merchant_abc123",
"schema": {
"@context": "https://schema.org",
"@type": "Product",
"name": "陶瓷手冲咖啡滤杯",
"brand": { "@type": "Brand", "name": "Hario" },
"image": [
"https://cdn.shopify.com/s/files/1/ceramic-dripper-1.jpg",
"https://cdn.shopify.com/s/files/1/ceramic-dripper-2.jpg"
],
"description": "手工制作的陶瓷滤杯，螺旋凸肋设计优化萃取效果。兼容标准2号滤纸。",
"sku": "HARIO-V60-02-WHT",
"gtin13": "4977642723115",
"offers": {
"@type": "Offer",
"price": 29.95,
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": 4.8,
"reviewCount": 342
}
},
"quality": {
"completeness": 95,
"accuracy": 98,
"freshness": 100,
"consistency": 97,
"composite": 97.3
},
"metadata": {
"lastCrawled": "2026-02-18T08:30:00Z",
"extractionMethod": "shopify_api",
"variantCount": 3,
"categoryPath": "厨房 > 咖啡与茶 > 手冲"
}
}
这个条目包含了AI代理需要的一切：Schema.org格式的结构化产品数据、用于信任度校准的质量评分、以及关于数据来源的元数据。代理可以使用复合质量评分来衡量这个产品相对于替代品的可靠性。extractionMethod字段告诉代理数据是来自可靠的API还是来自不太确定的DOM解析。
平台级的转变
向结构化、协议可访问的商务数据迈进，不仅仅是ORBEXA的方向，而是行业整体的平台级转变。
2025年夏天，Shopify在其生态系统的每一个店铺上默认激活了MCP端点。这意味着数百万商户——其中很多人从未听说过MCP——突然拥有了AI可访问的协议端点来提供他们的产品数据。此举表明Shopify将代理就绪性视为基础平台能力，而非开发者自选项。
Google和Shopify联合开发的Universal Commerce Protocol（UCP），于2025年1月公布，定义了结构化产品数据在商户系统与AI代理之间流转的标准。UCP规定了发现机制（通过.well-known/ucp.json）、目录端点、搜索接口和结算流程。它提供规范；ORBEXA等平台负责实现。
这些并非孤立事件。它们反映了行业正在围绕一个共识收敛：AI代理需要结构化的、标准化的数据才能在商务领域有效运作——而行业正在就具体的协议达成标准化。
多租户架构
ORBEXA通过共享基础设施为数千商户提供服务。每个商户的数据在应用层隔离——一个商户的API密钥只能访问自己的产品数据——但底层基础设施是共享的，以提高效率。
多租户架构使一些在单租户部署中不切实际的功能成为可能。例如，跨商户的品牌规范化受益于看到数千个店铺如何引用同一品牌。类目分类映射则随着来自多样化商户的训练数据增多而不断改进。
自定义域名支持允许商户从自己的域名提供协议端点。商户配置一条CNAME记录将域名指向ORBEXA的边缘节点，SSL证书会自动签发。从AI代理的视角看，它直接与商户的域名交互，而非ORBEXA的基础设施。这在提供结构化协议访问的同时保留了品牌身份。
实时与批处理的权衡
并非所有产品数据都需要同等的时效性保证。ORBEXA采用分层处理模型。
实时处理 覆盖价格变更、库存更新和供应状态变化。这些是过时后最容易导致代理出错的数据点。当一个产品售罄时，知识图谱必须在分钟级而非小时级反映这一变化。基于Webhook的集成（Shopify、WooCommerce）实现了近乎即时的传播。
批处理 处理时效性要求较低的操作：全目录重新抓取、丰富处理（GTIN解析、品牌规范化）、质量评分重算和模式漂移检测。这些按计划间隔运行——活跃商户通常每隔数小时一次。
实时和批处理的边界按商户可配置。一个限时特卖零售商可能需要所有数据点的实时处理。一个定价稳定的书店可以完全依赖批处理运行而不会有明显的准确性损失。
实际影响
拥有结构化数据并通过标准化协议端点提供服务的店铺，会出现在日益驱动商务的那些界面中：ChatGPT的购物体验、Google搜索的AI模式、Microsoft Copilot的产品推荐、Perplexity的带购买功能的搜索结果。
从HTML产品页面到知识图谱条目的转化不是一个表面变化。它决定了一个店铺在下一代商务界面中是可见的还是隐形的。随着AI代理从小众工具发展为主流购物界面，投资于结构化、协议可访问数据的店铺将在代理驱动的交易中获得不成比例的份额。
知识图谱就是新的店面。协议端点就是新的大门。