SKU.md v0.10 × WebMCP：访问前理解商品，打开页面后可靠行动

用户请 agent 推荐一台适合婴儿房的静音空气净化器：房间面积已经给出，希望滤芯可更换，也在意噪声数据的测试条件。此时，agent 首先需要的不是一个“购买”按钮，而是可靠的商品理解：究竟是哪一个 Product 和 Variant，噪声指标在什么模式下测得，适用面积是否有边界，滤芯是否与既有设备兼容，哪些说法有商家审核过的证据。随后，用户打开商品页，任务才转为页面内行动：选择已确认的规格、查看当前可见的对比信息，或把该 Variant 加入购物车。前者是持久的商品知识，后者是当前页面中的受控交互。

SKU.md v0.10 与 WebMCP 恰好在这里衔接，但不应被混为同一层。SKU.md 是商家发布的商品知识与证据层；WebMCP 是由已经打开的网页向 agent 暴露操作的浏览器页面 API。可靠的 agent 先用前者形成可引用、可审计的意图，再用后者完成一个范围明确、用户可见的页面操作，最后回到实时商业系统确认会变化的事实。

一次购买，在标签页打开之前就开始了

最初的问题通常不是“该点哪个按钮”。用户可能想问：这款产品能否和已经拥有的设备兼容？某种材质说法有没有指定的测试依据？儿童安全警示是否适用于当前配置？这些问题应当在页面尚未打开时就能回答，且回答必须保留来源、适用范围与审核时间。商品说明里残留的旧价格或旧库存文字，不能因为旁边的产品解释仍然准确，就被悄悄提升为今天的报价。

这正是 SKU.md v0.10 的工作。它可以把稳定的 Product、Variant、SKU 与 GTIN 标识，关联到经商家审核的事实、主张、披露、兼容性说明、原始证据与核验时间。agent 在规划访问、按用户需求比较商品、准备带引用的解释，或核对自己是否锁定了精确型号时，可以使用这些内容。它不是可执行会话，不是实时库存响应，也不是购买指令。

WebMCP 则从后一步开始。Chrome 的 WebMCP 总览 明确限制了使用条件：必须存在浏览器页面上下文，页面必须已经打开。本地或远程浏览器会话都可以提供这个上下文。页面上下文正是 WebMCP 的运行边界。它既不是后台 API，也不能离线调用或承担访问前发现。WebMCP 不提供后端 MCP 传输、静态工具清单或跨站发现，只让活动页面暴露在此刻、此 UI 状态下有意义的操作。

这一点能避免一种看似方便却不安全的捷径。agent 不能读取 SKU.md 的能力提示后，自行编造工具调用并操作用户尚未打开的网站；商家也不应把今天的工具名称与输出 Schema 固化到长期商品文档中。用户可能在读取文档后更换地区、登录账户、选择 Variant、清空购物车或失去权限。只有运行中的页面才知道现在有哪些工具、哪些操作仍然有效。

WebMCP 暴露什么，又不暴露什么

WebMCP Community Group 草案 定义了由网页应用提供给 agent 的 JavaScript 工具。Imperative API 通过 document.modelContext.registerTool() 注册工具：页面提供名称、描述、输入 Schema、执行回调与可选注解。它适用于需要应用逻辑、状态检查、导航或结构化结果的操作。

Declarative API 则为普通 HTML 表单增加语义。toolname 用来命名操作，tooldescription 用来说明操作目的。agent 调用后，浏览器会聚焦仍然可见的表单并填入字段，用户可以看到即将发生什么；移除任一属性，工具就会注销。它适合提交一个范围明确的支持请求或餐厅预约请求，而不是假装自动化浏览器可以绕过审查，完成每一种商业承诺。

Chrome DevTools for agents 与它的关系仅限调试。其配置文档描述了一个让 agent 连接 Chrome、检查和测试的 MCP server。它是独立 MCP 调试桥，不是商家的 WebMCP 工具端点，也不是替代商品发现的协议。团队可以用它检查已注册工具、手动调用开发中的工具、查看结构化输出；这不意味着页面工具变成后台或离线商业 API。

官方演示让这条线更直观。Smart Home 演示 实际注册了 rearrangeDOMComponents 工具，只改变模拟控制台中哪些组件可见，并不控制真实设备。French Bistro 演示 展示了声明式、可见的预约请求表单，其中包含日期、时间、人数、座位偏好和特殊要求；在浏览器没有原生支持时，演示页面会使用 polyfill。它们说明复杂的页面操作能够映射为结构化意图；不应外推为通用发现、跨站执行、可靠履约、支付授权或完整交易。演示不等于真实交易。

让每一层只回答自己有权回答的问题

下表不是技术堆栈的高低排序，而是权威归属的划分。把方便的一层当成所有问题的答案，最终会让静态资料冒充实时事实，或让页面操作冒充交易授权。

表面	权威职责	agent 应做什么
SKU.md	知识证据：审核过的事实、主张、披露、兼容性、来源与稳定标识。	解释并引用；锁定精确的 Product、Variant、SKU 与 GTIN。
WebMCP 与可见 UI	当前页面的工具及用户可见的交互状态。	打开页面后发现已注册工具，再执行范围明确的页面操作。
实时 Catalog 与商家后端	当前价格、库存、资格、配送选项、税费输入与账户相关规则。	重新查询，不能信任静态快照。
Checkout	最终价格、配送、税费、支付授权、同意与购买确认。	展示最终状态，并保留确认边界。

SKU.md 中一条带来源的记录可以说明厂商建议零售价或曾经核验过的价格，但它不会变成当前价格。库存、促销、预计送达与税费也是如此：它们可以是有用背景，却只有在实时 Catalog、商家后端或 Checkout 当前返回时，才是可用于交易的商业事实。

v0.10 实际声明了什么

SKU.md v0.10 已经为“访问后可能出现页面能力”留下了窄而清晰的表达方式。capabilities[] 中可以使用 protocol: webmcp，标明 page_runtime，用 scopes 与 page_url_patterns 收窄范围，并要求 requires_user_presence: true。这只是访问提示：它告诉消费者，用户打开匹配 URL 后，商家可能在页面运行时暴露相关能力。

它刻意不是动态界面的副本。工具名称、输入与输出 Schema、工具描述和是否注册，都属于活动页面运行时，不应复制到 SKU.md。v0.10 JSON Schema 定义了机器可读的文档边界；v0.10 英文规范仍是唯一规范性文本。运行时细节留在 SKU.md 之外，避免过期文档伪装成当前工具契约。因此，消费者只能把 page_url_patterns 当作导航提示，不能把它当作调用未公开操作的权限，更不能假定列出的每一页现在都注册了工具。

这种分工既是原则，也是工程现实。商品页可以在尚未选择 Variant 时只注册一个只读对比工具；当选择合法后，再注册配置工具；当购物车状态变化后，立即注销不再适用的操作。当前工具集还会随登录、地区、库存、无障碍需求与同意状态而变化。静态文档无法安全地承担这些变化。

还应区分“知识中的证据链”与“页面中的执行链”。前者让用户和审核者能够回看：某个结论引用了什么资料、适用于哪一个型号、是否省略了限制，以及复核发生在何时。后者让用户在同一个可见界面中观察输入、预期效果与错误提示。二者相接并不意味着把页面返回值写回静态资料，也不意味着把资料中的自然语言当作可执行指令。agent 应把商品文档、工具描述、页面输出和用户输入都视为不同来源：对事实做来源判断，对操作做权限与状态判断，对任何高影响结果都重新确认。

这也有助于处理失败路径。若页面没有注册预期工具，agent 可以继续使用正常 UI，或说明当前页面不提供该能力；不能把“可能有 page_runtime”解释成故障后仍可强行调用。若工具返回提示、错误或来自用户填写内容的文本，应展示其含义并避免把它当成新的系统指令。若实时服务显示 Variant 已售罄、配送区域不可用或价格已变化，应以实时结果为准，向用户解释差异并回到可选择的下一步。可审计的流程不仅记录成功时的便利，也保留拒绝、撤销和重新确认的理由。

agent 的完整路径

一条可靠的路径可以这样走：

1. 阅读 SKU.md 的证据、披露与适用范围。
2. 解析精确的 Product、Variant、SKU 与 GTIN；身份不清楚时先询问，不能猜测。
3. 在用户在场的前提下，打开匹配安全页面 URL 模式的商家页面。
4. 发现活动页面实际注册的工具。
5. 根据用户请求和工具描述，选择一个适当的页面操作，并在可见 UI 中执行。
6. 回到实时 Catalog 或商家后端，读取当前商业状态。
7. 由 Checkout 确认最终总额、税费、配送、支付授权，并获取最终用户确认。

这并不是一个单一的“购买”工具。工具可以选择已识别 Variant、解释当前可见的比较项、开始预约请求，或打开购物车视图。最终购买需要新鲜报价，也需要在承诺发生时仍有意义的确认边界。不建议将 toolautosubmit 用于最终购买。Declarative API 可以支持自动提交表单，但这种浏览器能力不是商家省略服务端校验或用户最终决定的理由。

商家应如何把边界落实到产品中

第一，发布经人工审核的资料和证据。稳定标识尤其重要：再好的解释也不能安全地套用到相近型号或任意颜色、尺寸 Variant。每一项材质或性能主张都应保留来源与限制，而不是让 agent 从营销文案中推断。事实本身改变时，应复审并更新文档；实时状态则继续交给拥有它的系统。

第二，页面工具应当单一职责。“选择这个已识别的 Variant”或“显示兼容性解释”都容易理解；“查找、配置、折扣、支付并下单”则把太多承诺藏进一次调用。只有当用户可见状态允许时才注册工具，状态变化时应注销。工具元数据也是不可信输入：简明准确的描述和 Schema 能减少歧义，却不能消除提示注入或实现缺陷。

最后，readOnlyHint 与 untrustedContentHint 只是提示，不是安全保证。只读标签不能证明实现没有写入；不可信内容标记也不会自动净化输出。仍需保留服务端验证、授权、幂等处理、反欺诈控制、审计日志和高风险确认。页面应诚实说明效果，后端必须独立执行业务规则。

评估互补关系，而不是制造排名叙事

有价值的比较是在同一组、范围受控的购物场景中，比较 WebMCP-only 与 WebMCP+SKU.md。可测指标包括：agent 是否匹配到用户指定的商品与 Variant，是否引用正确证据，是否披露限制与依据，是否选择恰当的当前页面工具，是否拒绝过期报价，以及是否保留确认边界。它们都能通过固定样本、受控页面和人工复核检查。

不应把这种评估包装成排名、转化率或生态采用声明。WebMCP 可以让已打开界面更容易被可靠操作；SKU.md 可以让访问前的商品理解更持久、可审计。两者都不保证完成购买，组合后也不会替代实时 Catalog、商家后端或 Checkout。更窄也更强的承诺是：访问前知道用户指向哪一件商品，页面打开后再对用户看得见的当前状态可靠行动。

部署时应重新查看 Chrome 的 WebMCP Origin Trial，因为试用范围与浏览器行为可能改变。

延伸阅读

用AI 商业权威交接把页面工具连接到实时与交易来源。