martech_jy
把「AI 能用的商務能力」規格化：上下文、工具編排、事件路由、UI 協作，一次講清楚
本文大綱
TL;DR
- Shopify 在 Storefront 場景導入「模型上下文協議」（Model Context Protocol, MCP），把產品搜尋、購物車、商店政策等「與購物相關的能力」定義成標準化工具與資源，AI 助理可即插即用。
- 核心設計四大面：上下文傳遞與隔離、工具自描述與流程編排、Agent 主導的事件路由、可嵌入的 MCP UI 元件。關鍵是「讓 AI 保持對流程與狀態的掌控」。
- 對 AI Agent 團隊的啟示：把外部系統「轉譯」成一致協議、把使用者操作「提升」為可路由的意圖事件、以最小集的標準工具支撐 80% 業務，再漸進擴充。
1｜為何要在電商 Storefront 用 MCP
- 問題本質：AI 助理必須「理解商店的真實資料與規則」並「能執行操作」。若每個商店、每個模組都自定 API，AI 團隊將被整合成本壓垮。
- 解法要點：用一套標準協議把「資料與能力」規格化。AI 模型看到一致的工具描述與回覆格式，就能穩定地串連步驟。
- 對電商的額外價值：商品維度多、流程長（搜尋→比對→加購物車→結帳→售後），MCP 能把這些步驟拆成可組合的工具，並讓上下文在多輪對話中持續有效。
2｜核心概念速讀：MCP 的主機、客戶端、伺服器
- 主機（Host）：承載 AI 對話與推理的應用端；它管理連到各種 MCP 伺服器的生命週期與配置。
- 客戶端（Client）：主機內部針對某個 MCP 伺服器的連線器；負責工具列舉、工具呼叫、資源讀取與事件處理。
- 伺服器（Server）：提供具體能力的服務端。以 Storefront MCP 為例，包含產品搜尋、政策查詢、購物車操作等。
延伸模組化思路（Shopify 實務）：
- Storefront MCP：面向購物流程（搜尋、政策、購物車）。
- Customer Accounts MCP：面向帳戶與訂單（查單、退貨、地址）。
- Dev MCP（開發者文件）：面向工程開發情境（查 API 規格、範例、Schema）。
3｜Shopify Storefront MCP：可以直接拿來用的能力邊界
常見工具（名稱依實作可能略有差異，但語義一致）：
- search_shop_catalog：以關鍵字、屬性、價格範圍搜尋產品。
- get_product_details：取得產品與變體的細節（規格、可售性、媒體）。
- search_shop_policies_and_faqs：查詢商店政策與常見問答。
- get_cart：取得目前購物車內容。
- update_cart：新增、刪除、更新購物車項目，或創建購物車。
- generate_checkout_link（或等效能力）：根據購物車生成可分享的結帳鏈接。
資料回覆特性：
- 結構化 JSON，欄位穩定、語義清晰（名稱、價格、貨幣、圖片、可售狀態、變體等）。
- 工具描述自帶 Schema（參數、必要欄位、約束、回傳格式），便於模型理解與程式驗證。
4｜上下文傳遞與隔離：讓多輪對話「記得住，但不混線」
要點一：對話級持久上下文
- 應用層保存對話歷史（先前的商品、需求、限制），供模型持續推理。
- MCP「資源」概念可承載可重用的片段（例如上一輪的搜尋結果集、店鋪政策摘要）。
要點二：工具級情境參數
- 像 search_shop_catalog、search_shop_policies_and_faqs 支援 context 參數，能把「當前話題」傳到伺服器，提高回傳結果的針對性。
要點三：清晰的優先級與邊界
- 系統層規則優先於會話層；會話之間水平隔離，避免資料穿透；上下文具生命週期（什麼時候生效、何時失效）要明訂。
常見錯誤與規避：
- 把「上一輪選的產品」當作「任何情境都適用」的預設：應明確標記來源與有效範圍。
- 對多使用者或多任務共用同一份上下文：應使用會話分隔與作用域標記。
5｜工具與流程編排：從「有清單」到「能可靠地連續調用」
兩層能力：
A. 發現與描述
- tools/list：列舉可用工具；每個工具自帶用途、參數、回傳格式。
- 易於 Few-shot 提示：把「什麼時候用哪個工具」「參數如何組裝」寫成規則與範例。
B. 多步驟任務
- 典型路徑：搜尋 → 擷取候選 → 詳情/庫存 → 選擇變體 → 加入購物車 → 結帳。
- 容錯與回退：任何一步失敗（搜尋無結果、變體缺貨）要有替代策略（重試、放寬條件、引導使用者補資訊）。
工程化關鍵：
- 參數正規化：顏色、尺寸、地區等需做映射（「寶藍」→ Blue）。
- 資料校驗：提交工具前先在應用層校驗必填欄位，避免把垃圾請求送進 MCP。
- 態勢監控：把每次工具呼叫、耗時、失敗原因打點，支援回放與調優。
6｜Agent 協作與 MCP UI：事件（意圖）先行、狀態由 Agent 掌控
核心原則：即使出現「可互動的嵌入式 UI」，也不要讓 UI 元件繞過 Agent 直接修改狀態。
做法：把使用者操作抽象成「意圖事件」（Intent），由 Agent 接收後決定要調用哪個工具、以什麼參數執行，再把最新狀態回填到 UI。
常見意圖：
- add_to_cart（加入購物車）
- view_details（查看詳情）
- checkout（準備結帳）
- notify（通知類事件，如購物車已更新）
MCP UI 的載入方式與安全：
- 載入型式可為行內內容、遠端資源、或透過沙盒隔離（例如 iframe）。
- 樣式由宿主提供（例如提供 CSS 變化），確保品牌一致性。
- 安全沙箱與事件白名單：避免任意腳本越權與資料外洩。
7｜安全與治理：權限、資料可見範圍、抗提示攻擊
- 權限最小化：不同工具與資源對應不同權限；僅開放任務所需的最小集。
- 來源標記與審計：每次工具調用皆記錄來源、參數、回傳摘要與判斷依據，支援事後稽核。
- 抗提示攻擊（Prompt Injection）：系統層指令不可被會話層覆寫；對外部資源（例如政策文本、FAQ）做來源驗證與內容清洗。
- 敏感欄位遮罩：地址、電話、付款資訊等，預設遮罩與按需顯示；導出報表時做去識別化。
8｜架構亮點總表（精華對照表）
| 架構亮點 | 在 Storefront MCP 的體現 | 實作重點（工程視角） |
|---|---|---|
| 標準化與模組化 | 用一致協議暴露「搜尋、政策、購物車、結帳」等能力；可平行新增 Customer Accounts、Dev 文檔等模組 | 把每個外部系統翻譯成「少量且穩定的工具」，先撐 80% 場景，再逐步擴充 |
| 上下文傳遞與隔離 | 對話級持久上下文＋工具級 context 參數；會話隔離與優先級 | 把上下文做作用域標記；對工具回傳結果做快取與引用（有版本標籤） |
| 工具與流程編排 | tools/list 自描述；連續多步調用（搜尋→變體→購物車→結帳） | 參數正規化、前置校驗、錯誤分支與回退；埋點與回放 |
| Agent 中心與 UI 協作 | UI 只拋意圖；所有狀態變更由 Agent 決策與執行 | 建立「事件白名單」；把 UI 操作映射到工具調用策略 |
| 即時性與擴展 | 支援通知與串流（長任務進度、庫存變化） | 以事件匯流排思路管理變更；針對慢查詢做增量回傳 |
9｜對 AI Agent 團隊的實作建議（含常見坑位與對策）
A. 建議做法
- 以協議為中心設計：先定義「工具字典」與「資源清單」，再反推前端與提示詞。
- 少即是多：先把 6～8 個最重要的工具做到「可觀測、可回放、可追責」。
- 意圖事件先行：所有 UI 操作、表單提交、快捷按鈕，統一轉成意圖事件給 Agent 路由。
- 資料治理內建：欄位遮罩、來源校驗、版本標籤、審計日誌，一開始就上。
- 觀測與回放：每一步工具呼叫、耗時、結果摘要都打點；建立「任務回放器」做問題定位。
B. 常見坑位與對策
- 坑位：模型「看懂工具描述」≠「會正確串工具」。
對策：在系統提示詞中加入任務計畫（先找產品→再查庫存→…），並提供幾個正反範例。 - 坑位：多語詞彙與變體映射錯亂（顏色、尺碼、地區）。
對策：建立正規化詞典；把映射當作「前置步驟」工具或應用層函式。 - 坑位：UI 直接呼叫後端導致上下文不同步。
對策：嚴禁 UI 直連；一律意圖事件交由 Agent 轉為工具調用。 - 坑位：測不出真實可靠度。
對策：建立任務級測試（用「目標—步驟—驗證點—可替代路徑」四件組）；離線回放＋線上抽樣。
結語
- 對話式電商真正的挑戰，不在模型「會說話」，而在「能保證正確完成一件事」。
- MCP 在 Storefront 的實踐展示了「協議先行、意圖路由、Agent 掌控、資料治理內建」的完整閉環。
- 拿這套方法論去做客服、訂單、物流、售後甚至後台流程自動化，思路是一致的：先定義能力邊界與上下文規則，再讓 AI 去「組裝」能力，而不是讓 UI 或後端「繞過」AI。
附錄｜專有名詞 白話文字典
- 模型上下文協議（MCP）：一種讓 AI 能看見、理解並調用外部系統能力的「通用介面協議」。
- 工具：可被 AI 調用的原子能力（例如「搜尋商品」「加入購物車」）。
- 資源：提供給 AI 參考的資料片段（例如「這一頁的商店政策摘要」）。
- 意圖事件（Intent）：把使用者在 UI 的操作提升為「動作意圖」，交由 Agent 轉譯成工具調用。
- 主機／客戶端／伺服器：承載 AI 的應用端／主機內連線器／提供能力的服務端。
JiunYi Yang
Yang Abao