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 商業權威交接把頁面工具連線到即時與交易來源。