當 AI 代理代你銷售：將 Shopify 連接到 B2B 技術堆疊

問題：代理能購買，但你的 B2B 技術堆疊無法報價

一個透過 ChatGPT 或 Google 的 Gemini 購物的消費者現在可以發現產品、加入購物車並結帳，無需開啟瀏覽器分頁。Shopify 的 agentic commerce 文章 報告稱，2026 年第一季，AI 驅動的 Shopify 商店流量年增 8 倍，AI 驅動搜尋帶來的訂單增長近 13 倍。新買家透過 AI 通路下單的速率幾乎是其他通路的兩倍。Shopify 的企業資料 進一步指出：AI 引薦的購物者轉換率高出近 50%，平均訂單價值比自然搜尋流量高 14%。

對於消費品牌來說，這是順風。對於在前端執行 Shopify 或 BigCommerce、在後端執行 NetSuite 或 Brightpearl 的中端市場 B2B 經銷商來說，這是一個不同的問題。AI 代理另一端的買家不是消費者——而是一家公司的採購協調員，該公司已談判了 Shopify 目錄中不存在的定價層級、信用條款和批量折扣。AI 代理看到的是公開價格。客戶在合約上享有不同價格的權利。當代理以公開價格結帳時，經銷商要麼吞掉利潤，要麼取消訂單並失去銷售。

第二個問題是庫存。B2B 報價不是衝動消費——它需要經過審批，有時長達數天。Shopify 的即時庫存是準確的，但不可預留。一個針對 240 的即時計數報價 200 單位的代理，可能在採購訂單到達時就已經錯了，因為在此期間另外三份報價消耗了相同的庫存。處理這個問題的 RFQ 引擎模式——帶 TTL 的原子性可用性預留、取消策略快照、FX 匯率鎖定——存在於 ERP 和報價層中，而非電商店面。

第三個問題是歸因。Polar Analytics 的 2026 Shopify AI 評測 直接點名：「每個工具給自己的作業打分，因此歸因收入加起來超過了商店實際賺到的。」當 ChatGPT、Google AI Mode、Copilot 和商家自己的店面都聲稱同一訂單時，收入數據就不再可信。對於需要向董事會報告通路組合的財務團隊來說，不可歸因的收入是一個報告問題，而非行銷虛榮問題。

第一方表面覆蓋什麼，不覆蓋什麼

Shopify 在第一方 AI 代理方面所做的工作比任何其他電商平台都多。Storefront MCP server 透過 Model Context Protocol 暴露產品發現、購物車管理、商店資訊和訂單管理。Customer Accounts MCP server 處理訂單追蹤和退貨。Universal Commerce Protocol (UCP) 與 Google 共同開發，並得到 Amazon、American Express、Etsy、Mastercard、Meta、Microsoft、Salesforce、Stripe、Target、Walmart 和 Visa 的支援，定義了 AI 代理如何跨任何平台和任何支付處理方與商家交易。Google 在 Google I/O 2026（2026 年 5 月 19 日）推出了 Universal Cart，建立在超過 600 億商品列表的 Shopping Graph 之上，配有 Agent Payments Protocol (AP2)，讓代理在使用者指定的支出和品牌護欄內支付。

第一方表面解決了消費路徑：購物者向 AI 代理要一個產品，代理在 Shopify Catalog 中找到它，加入購物車，並透過 Shopify Checkout 結帳。商家仍為記錄商家。合格產品無需自訂整合——Shopify Catalog 自動將結構化資料聯合到 AI 平台。

第一方表面沒有解決的是 B2B 路徑。Storefront MCP server 暴露公開目錄資料。它不暴露客戶分層定價、談判的合約費率、批量數量層級或帳戶特定的信用條款。它不預留庫存——它報告可用性。它不將已接受的訂單以正確的 GL 編碼、子公司和稅務 nexus 寫回 NetSuite。它不生成採購團隊可附加到採購訂單的報價文件。它不產生映射哪個 AI 通路發起了訂單以及哪些工具呼叫執行了結帳的稽核軌跡。

這與 NetSuite MCP 模組分析 中出現的相同結構模式：供應商的第一方連接器解決了連接問題。它沒有解決語意層問題——資料所說的與業務所意指的之間的差距。對於 NetSuite，語意差距是哪些 GL 科目構成收入。對於 Shopify B2B，語意差距是在哪些條款下哪個價格適用於哪個客戶的哪個數量。

代理編排的 B2B 解決方案

生產模式是一個位於 AI 代理和完整 B2B 技術堆疊之間的自訂 MCP 模組——前端 Shopify，後端 NetSuite 或 Brightpearl，中間是供應商目錄圖，RFQ 引擎處理報價和預留。第一方 Storefront MCP 處理產品發現和購物車機制。自訂模組處理店面不知道的商業邏輯。

考慮一個向三個客戶分段銷售工業元件的經銷商：具有談判合約定價的 enterprise 帳戶、具有批量層級的 mid-market 帳戶，以及以公開目錄價格購買的交易型買家。一個代表 enterprise 買家採購協調員的 AI 代理發送了 500 個某元件的請求。代理看到的不是公開價格——它看到的是一個起點。自訂模組攔截請求並做四件第一方表面做不到的事：

第一，解析客戶身分和分段。代理攜帶帳戶識別碼（而非信用卡），模組查找該帳戶和產品的談判價格層級。代理報的價格是合約價格，而非目錄價格。RFQ 引擎架構 透過從供應商項目批次載入並按數量閾值過濾的基於分段的定價層級來處理此問題。

第二，獲取可用性預留。模組針對 NetSuite 庫存計數呼叫 RFQ 引擎的 acquire_availability_hold 操作，原子性地扣減可用產能並返回帶 TTL 的預留權杖。報價現在由真實預留庫存支援——而非可能在買家批准前消失的即時計數。如果買家在窗口內接受，預留確認無需第二次扣減。如果 TTL 過期，產能恢復，下一份報價可以使用。

第三，快照商業條款。取消策略、FX 匯率（如果買家貨幣與供應商不同）以及任何限時促銷在報價時凍結。如果供應商在談判中途收緊取消條款，報價攜帶的是發出時生效的條款。否則會隨之而來的爭議不會發生。

第四，透過正確的 API 表面將已接受訂單寫回 NetSuite——SuiteTalk REST 用於訂單記錄，RESTlet 用於自訂驗證，SuiteQL 用於任何需要連接的讀取——同時遵守並發限制，內部計算 OAuth 簽章，並為每次工具呼叫記錄稽核日誌條目。代理從不構造 OAuth 簽章或選擇 API 表面。它呼叫 create_order，模組處理其餘。

人類保持在迴圈中的位置：模組將低信心定價解析、低於利潤護欄的訂單以及任何來自新帳戶的請求在報價發出前路由給人工審核。guardrail_price_per_uom 欄位標記任何折扣使價格低於批次成本的報價。代理提議，人類批准例外，稽核日誌顯示誰批准了什麼以及何時。

結果

可衡量的改進是具體的。報價時間從數天降至數分鐘，因為代理在一次過程中解析產品、價格和可用性，而非跨 Shopify、定價試算表和 NetSuite 進行三次手動查找。可用性預留消除了過度承諾問題——報價要麼由預留庫存支援，要麼不予發出。基於分段的定價消除了當合約客戶因代理不知道合約存在而被以公開價格報價時發生的利潤侵蝕。稽核日誌產生一份通路歸因記錄，將訂單與發起的 AI 平台、執行它的工具呼叫以及修改它的人工審批關聯起來——Polar Analytics 所識別的「每個工具給自己的作業打分」的歸因問題在模組層解決，而非透過信任任何單一平台的自我報告功勞。

Shopify 報告的來自 AI 通路 13 倍的年增訂單不是 B2B 經銷商可以坐視不理的浪潮。捕獲它的經銷商是那些其代理層知道消費結帳與 B2B 報價之間區別的——並擁有使後者成為可能的模組模式。

---

一個在店面執行 Shopify、用 NetSuite 做 ERP 並有三個供應商目錄的經銷商獲得一個代理，它接收來自 AI 購物通路的請求，解析客戶的談判價格層級，針對 NetSuite 庫存獲取原子性可用性預留，快照取消和 FX 條款，並透過正確的 API 表面將已接受訂單寫回 NetSuite——每次工具呼叫都被記錄，每個例外都被路由給人工審核。該建構是四步方法的第 2-3 階段，通常在 5-8 週內上線。

請求一個範圍明確的建構。 一週 Discovery。你獲得系統清單、工作流圖和固定範圍——無論你是否與我們合作建構。