用 MCP 將 AI 代理連接到 BigCommerce：Stripe 合作未解決的問題

問題：三條路徑，沒有一條解決 B2B 報價

BigCommerce 選擇了與 Shopify 和 HubSpot 不同的路徑。Shopify 建構了第一方 Storefront MCP 和 Customer Accounts MCP 伺服器，並與 Google 共同開發了 Universal Commerce Protocol。HubSpot 發布了第一方 Remote MCP Server（2026 年 4 月 13 日正式發布），包含 12 個覆蓋標準 CRM 物件的工具。BigCommerce 兩者都沒做。相反，2025 年 12 月 18 日，BigCommerce 與 Stripe 合作，加入 Stripe 的 Agentic Commerce Suite，該套件基於 Agentic Commerce Protocol (ACP) 建構——一個由 Stripe、OpenAI 和 Meta 共同建立的開放標準，採用 Apache 2.0 授權。

結果是連接 AI 代理到 BigCommerce 店鋪的三條不同路徑，每條路徑的覆蓋範圍不同：

BigCommerce 代理整合的三條路徑連接不同的技術堆疊層級：

路徑 1——BigCommerce 文件 MCP 伺服器。 BigCommerce 在 https://docs.bigcommerce.com/_mcp/server 暴露了一個 MCP 端點，讓 AI 代理搜尋 BigCommerce 開發者文件。它透過從文件中提取資訊來回答諸如"BigCommerce checkout API 如何運作"之類的問題。它是一個用於文件的 MCP 伺服器，而非用於店鋪資料。連接到它的代理可以學習 BigCommerce API 如何運作，但無法讀取任何店鋪的產品、客戶、訂單或庫存。這是一個開發者賦能工具，不是店鋪整合路徑。

路徑 2——Stripe 的 Agentic Commerce Suite，基於 ACP。 合作公告這樣表述："BigCommerce 商家將能夠解鎖 AI 驅動的發現和結帳流程，同時繼續使用現有的目錄、訂單系統和操作流程。"商家將產品目錄連接到 Stripe，選擇透過哪些 AI 代理銷售，Stripe 處理發現、結帳、支付和詐欺偵測。Stripe 的 Agentic Commerce Suite 文章量化了替代成本：沒有它，企業面臨"每支援一個新 AI 代理最多 6 個月的整合工作"。ACP 路徑用一個可配置的整合替代了這些。

ACP 架構是可組合的：agentic checkout（購物車管理、履約選項、支付處理）、cart 和 feed（產品目錄瀏覽）、透過 Shared Payment Tokens 的委託支付（SPTs——限定於賣家、受時間和金額約束、透過其生命週期可觀測）、透過 OAuth 2.0 的委託認證，以及用於生命週期追蹤的訂單和 webhooks。Stripe Radar提供針對非人類流量模式調校的詐欺偵測。商家保留 merchant-of-record 狀態和對客戶關係的控制。

這條路徑解決了消費者代理商務問題：購物者向 AI 代理請求產品，代理透過 Stripe 的目錄 feed 發現它，透過 Stripe Checkout Sessions API 結帳，並透過 SPTs 支付。它不解決 B2B 問題。

路徑 3——第三方供應商的託管 MCP 伺服器。 StackOne 提供一個 BigCommerce MCP 伺服器，開箱即用 120 個操作。Truto 透過其 /tools 端點暴露 BigCommerce REST API 能力。開源專案 isaacgounton/bigcommerce-api-mcp 封裝了完整的 BigCommerce REST API 表面。這些伺服器給代理提供對產品、客戶、訂單和庫存的型別化工具存取——即 REST API 支援的 CRUD 操作。

問題不在於這些託管伺服器做錯了什麼。問題在於三條路徑都沒有編碼的東西：B2B 語意層——決定哪個價格適用於哪個客戶、哪些庫存可預留、哪些訂單對應到哪些 ERP 記錄的業務含義。

ACP 路徑對 B2B 未覆蓋的內容

ACP 產品 feed 到 Stripe 每個產品攜帶一個價格——公開目錄價格。BigCommerce 實際的 B2B 定價結構存在於 Customer Groups 和 Price Lists 中。Price Lists 允許透過 Price List Assignment API 將變體級價格覆蓋分配給特定 Sales Channels 上的特定 Customer Groups。一個執行四個定價層級——企業合約、中市場批量、批發和公開零售——的經銷商有四個 Price List Assignments，將四個 Price Lists 對應到四個 Customer Groups，跨一個或多個管道。

當代表企業買家採購協調員的 AI 代理透過 ACP 路徑發送請求時，代理看到公開目錄價格。客戶有合約權利獲得企業層級價格——可能低 20-40%。ACP feed 不攜帶層級結構。代理報出錯誤價格。經銷商要麼吸收利潤，要麼取消並失去銷售。

BigCommerce 合作公告承認了這一點：商家"透過 BigCommerce 庫存和定價邏輯來告知代理購物。"這個措辭意味著商家在 BigCommerce 中配置定價邏輯，而 Stripe 應當遵守它——但 ACP feed 架構將目錄扁平化為單一價格表面。B2B 層級智慧不在 feed 中。

第二個缺口是庫存。BigCommerce 的 Catalog Products API 報告庫存水平但不預留。一個針對 240 活庫存報價 200 件的代理可能在採購訂單到達時已經錯了，因為其他三份報價在此期間消耗了同樣的庫存。RFQ 引擎架構——帶 TTL 的原子性可用性預留、取消策略快照、FX 匯率鎖定——存在於 ERP 和報價層，不在電商店鋪中，也不在 ACP 路徑中。

第三個缺口是 ERP 回寫。ACP 路徑透過 webhooks 將已接受訂單交回商家。商家的訂單系統——BigCommerce Orders API——接收它。但 BigCommerce 中的訂單物件不編碼 GL 科目、子公司、稅務 nexus 或 NetSuite/Brightpearl 需要正確過帳訂單的自訂欄位。NetSuite MCP 模組分析深入涵蓋了這一點：電商訂單和 ERP 訂單記錄之間的語意缺口是哪些 GL 科目、哪個子公司、哪個稅務 nexus 以及哪些自訂欄位構成有效過帳。ACP 路徑不橋接該缺口。

託管 MCP 伺服器未編碼的內容

託管 MCP 伺服器（StackOne、Truto、Apideck）解決不同的問題：它們給代理型別化的 BigCommerce REST API 存取。StackOne 的 120 個操作 覆蓋產品、客戶、訂單、庫存和店鋪管理。Truto 將 REST API 封裝在統一的 /tools 端點後面。這些是真實產品，不是演示——它們讓 BigCommerce API 對 AI 代理可讀，無需自訂整合程式碼。

但型別化 API 存取不等於型別化業務含義。一個暴露 get_products(filters) 的託管 MCP 伺服器給代理查詢產品的能力。它不告訴代理對於這家店，客戶群組 4（"Enterprise Contract"）在"B2B Portal"管道上有權獲得 Price List 7，且來自該群組買家的請求應透過 GET /v3/pricelists/7/records?variant_id={id} 解析，而非透過預設目錄價格。託管伺服器封裝 API 表面。它不編碼決定哪個 API 呼叫意味什麼的業務規則。

這是跨連接器系列出現的相同結構模式。HubSpot 分析記錄了 HubSpot 第一方伺服器的六個能力缺口——無自訂物件、無可審查寫入計畫、每連接一個入口、無系統級設計、僅活 API 查詢，以及敏感資料約束。Shopify 分析記錄了第一方 Storefront MCP 未覆蓋的 B2B 路徑——客戶層級定價、批量 RFQ 報價、針對 NetSuite 的庫存預留和跨管道訂單歸因。每種情況下，供應商連接器解決了連接問題。自訂 MCP 模組解決了語意層問題。

對於 BigCommerce，供應商根本沒有建構連接層 MCP 伺服器——它將消費者代理商務委託給 Stripe，將店鋪資料 MCP 表面留給了第三方供應商。語意層缺口是相同的。不同之處在於連接層本身更加碎片化。

認證：對 headless 友好的約束

BigCommerce 的 API 認證使用 X-Auth-Token——一個從店鋪管理後台（Store Setup → API Settings）生成的店鋪範圍 bearer token，或透過 OAuth 應用安裝流程在商家安裝應用時簽發。與 HubSpot 的 OAuth 2.1 with PKCE（需要基於瀏覽器的同意和一次性 refresh token）不同，BigCommerce API token 除非被撤銷否則不過期，且不需要基於瀏覽器的刷新。這比 HubSpot 第一方 MCP 伺服器更適合 headless：一個在凌晨 2 點執行以同步隔夜訂單變更的背景代理可以用靜態 X-Auth-Token 認證，無需任何人工介入。

約束是速率限制，不是認證：

API 透過 headers 回傳速率限制狀態：X-Rate-Limit-Requests-Quota、X-Rate-Limit-Requests-Left、X-Rate-Limit-Time-Reset-Ms。列表端點每頁回傳 250 條。一個對 Standard 店鋪同時發起 30 個並行工具呼叫的代理會一次性耗盡 150 請求視窗並在其餘呼叫上收到 429。一個不執行每工具限流的託管 MCP 伺服器將該失敗作為非結構化錯誤傳給代理。

自訂 MCP 模組內部執行每工具速率限制——每個工具宣告自己的限制，骨幹節點將請求限制在 30 秒視窗內，代理收到一個帶 Retry-After（從 X-Rate-Limit-Time-Reset-Ms 推導）的結構化 429，而非崩潰。模組還批次處理列表查詢——模組使用過濾查詢僅拉取代理實際需要的記錄，而非分頁遍歷 200 個每頁 250 條的請求，保持在速率視窗內。

自訂 MCP 模組提供什麼

模組模式遵循 MCP Module Code Standard：每個工具有型別化輸入 schema、型別化輸出 schema、速率限制、稽核日誌和錯誤合約。代理透過名稱和結構化參數呼叫工具，而非對原始端點的自由格式 API 呼叫。

對於 BigCommerce，自訂模組填補 ACP 路徑和託管 MCP 伺服器留開的缺口：

客戶群組價格解析。 模組暴露 get_tier_price(customer_id, product_id, channel_id, quantity)——一個型別化工具，解析買家的 Customer Group，找到該群組在當前管道的 Price List Assignment，並回傳所請求數量的變體級價格。代理不需要知道客戶群組 4 對應到 Price List 7。模組編碼該對應。代理呼叫 get_tier_price 並收到正確的合約價格，而非公開目錄價格。

庫存可用性預留。 模組封裝 BigCommerce 庫存水平檢查並新增預留層——如果店鋪支援則針對 BigCommerce 庫存，否則針對上游 ERP（NetSuite、Brightpearl），那裡存放著權威庫存計數。代理呼叫 acquire_availability_hold(product_id, quantity, duration_minutes) 並收到一個帶 TTL 的預留 token，與 RFQ 引擎架構一致。報價由預留庫存支援，而非可能消失的活庫存計數。

帶語意對應的 ERP 回寫。 模組接受 BigCommerce 訂單並將其轉換為 ERP 期望的格式——GL 科目、子公司、稅務 nexus、自訂欄位。代理呼叫 create_erp_order(bigcommerce_order_id)，模組處理轉換、API 表面選擇（SuiteTalk REST、RESTlets、SuiteQL 用於 NetSuite；Brightpearl API 用於 Brightpearl）、認證和稽核日誌。代理不建構 OAuth 簽名或選擇 API 表面。

可審查的寫入計畫。 模組為多步驟變更起草結構化計畫——"從昨天已接受的報價建立 15 個訂單，每個以正確的 GL 科目過帳到 NetSuite，在 BigCommerce 建立履約任務"——並在執行前路由到人工審核。ACP 路徑和託管 MCP 伺服器立即執行。模組新增審核門以防止錯誤批次扭曲 ERP。

限流批次查詢。 模組內部執行 BigCommerce 速率限制——每工具限流、批次列表查詢，以及一個將目錄和訂單資料同步到本地儲存的管理資料層，用於跨物件分析而無需每次問題都走 API 往返。代理問"顯示過去 30 天內 Enterprise 客戶群組中沒有對應 NetSuite 過帳的所有訂單"，模組從本地層回傳答案，而非 30 分鐘的分頁 API 呼叫。

為什麼這可以泛化

BigCommerce 模式——一個供應商透過合作而非自建來處理消費者代理路徑，一個封裝 REST API 但不編碼業務含義的託管 MCP 層，以及一個所有可用表面都不覆蓋的 B2B 語意層——是跨電商和 ERP 領域出現的相同結構，只是缺口分布不同：

• Shopify 建構了最完整的第一方代理表面（Storefront MCP、Customer Accounts MCP、UCP），但 B2B 路徑——客戶層級定價、批量 RFQ 報價、針對 NetSuite 的庫存預留——不在第一方表面中。Shopify 連接器分析涵蓋此內容。
• HubSpot 建構了包含 12 個覆蓋標準 CRM 物件工具的第一方 MCP 伺服器，但自訂物件、可審查寫入計畫、headless 認證和多入口操作是缺口。HubSpot 連接器分析涵蓋此內容。
• NetSuite 有第一方 AI Connector Service 但在自己 FAQ 中警告"AI 可能產生幻覺。始終根據來源資料驗證結果。"語意缺口是哪些 GL 科目構成收入。NetSuite MCP 模組分析涵蓋此內容。

Anthropic 2026 State of AI Agents Report（500+ 技術領導者，Novo Nordisk、Doctolib、L'Oréal、Shopify 的真實實施）將與現有系統的整合為代理採用的第一大障礙——46% 的組織引用它，高於資料存取（42%）、安全（40%）和模型智慧。47% 使用混合 build-and-buy 方法：不完全預建構，不全部自建，而是一個他們用自訂程式碼擴充的平台。ACP 路徑是 BigCommerce 的「買」的一半。託管 MCP 伺服器是店鋪資料存取的「買」的一半。自訂模組是「建」的一半——使代理對 B2B 操作有用而非僅消費者結帳的語意層。

BigCommerce 與 Stripe 的合作是一個合理的產品決策——Stripe 處理支付基礎設施和詐欺偵測比大多數電商平台自建做得更好。但合作覆蓋了消費者路徑。B2B 路徑——買家是有協商定價的採購協調員、庫存必須被預留而非僅報告、訂單必須以正確的 GL 科目和子公司對應到達 ERP——需要與本系列中所有其他連接器相同的自訂模組層。MCP Module Code Standard 定義了結構。BigCommerce 連接器是合作路徑案例的參考實作——即供應商外包消費者代理層並將 B2B 語意層留給整合團隊的案例。

一個在店鋪前端執行 BigCommerce、用 NetSuite 或 Brightpearl 做 ERP、有四個客戶群組定價層級的 B2B 經銷商，獲得一個透過 Price List Assignment API 解析買家合約價格的代理，針對 ERP 庫存計數取得原子性可用性預留，在報價時對商業條款進行快照，並以正確的 GL 科目和子公司對應將已接受訂單回寫到 ERP——每個工具呼叫都限流、記錄日誌並路由給人工審核異常。該建構是四步法的 Phase 2-3，通常在 5-8 週內上線。

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