架構

智慧代理商務架構：一個 MCP 能力層，四個 AI 通路

作者：IdeaBosque最後更新：2026年10月3日

Key takeaways

四個 AI 存取通路（自家入口網站、OpenAI ACP、Meta Muse 與外部 A2A 代理）可以共用一個 MCP 能力層，而不必為同一套商務邏輯做四次各自獨立的重複實作。
決策規則只有一句：僅當外部協定與 MCP 不同時，才加入協定轉接器。 OpenAI 的 Agentic Commerce Protocol 需要 ACP→MCP 轉接器；已經支援 MCP 的連接器則不需要。
Magento / Adobe Commerce 仍是具權威性的系統記錄來源：ACP、MCP 與 A2A 都不會複製它的定價、庫存、稅務或訂單邏輯，而是呼叫它。
寫入類工具在工具邊界依影響程度加以管控：catalog.search_products 這類讀取操作可自由通行，而 order.submit 與 payment.authorize 這類敏感寫入則需要人工核准與冪等性保障。

把商品目錄接入 ChatGPT、Meta Muse 以及合作企業的代理，天真的設計會把定價、庫存與結帳邏輯**重複實作四次，每個平台一次。**每個 AI 入口使用的協定都不同：OpenAI 推出了 Agentic Commerce Protocol（ACP，與 Stripe 共同開發），代理透過 Model Context Protocol（MCP）呼叫工具，並透過 A2A 彼此委派任務。慣性思維是為每個平台各建一套整合堆疊，而這種慣性正是代價高昂的錯誤。

本文提出一種與供應商無關的智慧代理商務架構：**南向是一個企業級 MCP 能力層，北向是多個 AI 存取通路。**文中以 Magento / Adobe Commerce 作為商務系統記錄來源的實例，但此模式適用於任何 ERP、OMS 或商品目錄。核心結論是一條決策規則：僅當外部平台的協定必須轉換為 MCP 時才加入轉接器。它能準確告訴你整合程式碼應該放在哪裡，更有價值的是，哪裡不該放。

陷阱：四個平台，四次重複實作

每個 AI 商務入口需要的底層操作都相同：搜尋商品目錄、查詢庫存、取得價格、建立購物車、提交訂單。天真的架構會讓每個入口帶著各自的邏輯直接接入商務平台：

自家網站 → 客製的 Magento 呼叫
OpenAI / ChatGPT → 另一套 Magento 呼叫
Meta Muse → 又一套 Magento 呼叫
合作夥伴代理 → 再一套

這時，一次定價規則變更、一個新的稅務轄區或一次庫存保留修正，都要在四個地方修改並測試。業務邏輯被複製了，而副本會逐漸偏離。這與讓點對點整合在任何規模下都代價高昂的連接器蔓延是同一個問題，只不過對象從 SaaS 端點換成了 AI 通路。

解決辦法是把四套南向實作合併為一套。所有通路都存取同一個企業能力層，它透過 MCP 對外提供，由標準化商務服務支撐，最終以 Magento 作為商品、定價、庫存、購物車、稅務與訂單的唯一事實來源。Magento 繼續掌管商務邏輯，AI 通路只是呼叫它。

決策規則：僅在協定不符時才加轉接器

對架構而言，各通路只有一處關鍵差異：**它們使用什麼協定。**僅此一點就決定了某個通路是需要轉換轉接器，還是可以直接接入 MCP。這三種協定並不相互競爭，它們回答的是不同的問題：

技術	它是什麼	它回答什麼問題
HTTP / REST / JSON	傳輸方式、API 風格與資料格式	位元組如何傳輸
ACP	AI 商務互通性（OpenAI + Stripe）	AI 商務平台與商家如何完成交易
MCP	代理/應用程式與工具之間的互通性	代理或應用程式可以呼叫哪些工具
A2A	代理之間的互通性	一個代理如何把工作委派給另一個代理

ACP 與 MCP 解決的是不同的問題，因此確實需要一個 ACP 轉接器：它把 ACP 的商務語意（結帳工作階段、訂單狀態、資料饋送格式）轉換為 MCP 工具呼叫。A2A 同樣有別：外部代理透過 A2A 委派任務，由閘道路由到你的 Agent Core，再由 Agent Core 呼叫 MCP。但如果某個平台的連接器模型本身就使用 MCP，則完全不需要轉接器，它可以直接存取能力層。

這正是違反直覺之處。直覺是「新的 AI 平台就要新的轉接器」，而這條規則恰恰相反：**僅當平台協定不是 MCP 時，才建置轉接器。**於是四個通路最終歸結為四條存取路徑，而不是四套整合：

自家入口網站 → Agent Core → MCP
OpenAI / ChatGPT → ACP → ACP 轉接器 → MCP
Meta Muse → Muse 連接器 → MCP （無需轉接器，連接器本身使用 MCP）
外部代理 → A2A → A2A 閘道 → Agent Core → MCP

一切都匯聚到 MCP。這種匯聚就是整個設計：

整體架構一覽：

MCP Commerce Server 是可重複使用的邊界

能力層是一個 MCP 伺服器，對外提供一組小而穩定的商務工具：catalog.search_products、pricing.get_price、inventory.check、cart.create、cart.add_item、order.submit、order.get_status。所有通路使用同一組工具。自家入口網站的 Agent Core、ACP 轉接器、Muse 連接器，以及透過 A2A 到達的外部代理，都呼叫同一個 catalog.search_products，沒有誰各自實作一遍商品搜尋。

關鍵在於，MCP 是能力介面，而不是業務資料模型。工具背後是標準化商務服務（一個與協定無關的 Product、Variant、Price、Inventory、Cart、Order 模型），以及把該標準化模型對應到 Adobe Commerce API 的 Magento 轉接器。當 OpenAI 的商品資料饋送格式或 ACP 的結帳結構變動時，只有 ACP 轉接器需要修改；當 Magento 的 API 變動時，只有 Magento 轉接器需要修改。中間的工具保持穩定。這與受治理的 MCP 模組遵循同樣的結構紀律：具型別的工具、穩定的契約，以及被隔離在邊緣的供應商特有行為。

工具依影響程度分類，治理就體現在這種分類上。讀取操作（catalog.search、pricing.get、inventory.check）風險較低，可自由通行。寫入操作（cart.add_item）會改變狀態，但可以復原。敏感寫入（order.submit、payment.authorize、refund.create）涉及資金流動或產生義務，需要人工核准、用於防止重複下單的冪等金鑰，以及稽核日誌，並在工具邊界強制執行，無論由哪個通路發起呼叫。連接器自身的治理層（身分驗證、使用者權限、人工核准關卡）位於 MCP 伺服器之前，而不是取代它。

為什麼 Meta Muse 不需要轉接器，而 ACP 需要

兩個外部 AI 平台的對比，最能說明這條決策規則。OpenAI 的 ACP 與 MCP 是不同的協定，所以 ACP 路徑帶有一個轉接器，把 ACP 的商務語意轉換為 MCP 工具呼叫。相較之下，如果連接器模型將整合以 MCP 端點的形式提交，就可以直接使用能力層：治理邊界是連接器的審查與權限模型，但無須再建置或維護第二個轉換層。若「因為 Muse 是另一個平台」而再加一個，只會產生沒有實際作用的整合債務。

同樣的檢驗適用於未來的每一個 AI 入口。只需問一個問題：*這個平台能直接使用 MCP 嗎？*如果能，它就接入現有伺服器並重複使用所有工具；如果不能，就恰好增加一個協定轉接器，別無其他。這樣，四個通路（以及第五個、第六個）的成本都能維持在低位。

超越商務：同一個能力層成為企業代理平台

商務只是 MCP 的一個領域。同一個 Agent Core 可以呼叫 Commerce MCP 伺服器、CRM MCP 伺服器與 ERP MCP 伺服器，在一個計畫中跨 Commerce 與 CRM 完成諸如*「找出與該客戶過往購買相容、500 美元以內、有庫存的商品，並準備一份推薦」*這樣的請求。對於外部委派，A2A（在第一年就超過了 150 個組織）允許合作企業的採購代理委派你的銷售代理，由後者呼叫你的 MCP 層，而無須讓合作方直接存取內部系統。商務架構與更廣泛的 MCP + A2A 企業技術堆疊，是不同範圍下的同一種架構。

一個典型的實施案例

一家使用 Adobe Commerce 的中型商家希望在沒有平台團隊的情況下，能在 ChatGPT 與 Meta Muse 中銷售商品。我們先建置了標準化商務服務與 Magento 轉接器，對外提供六個 MCP 商務工具，並讓自家入口網站的 Agent Core 建立在這些工具之上。接著是 OpenAI：一個 ACP 轉接器加上商品資料饋送轉換器，底層完全重複使用同一組工具。Meta Muse 是所有通路中成本最低的：我們為現有的 MCP Commerce Server 撰寫了文件（端點、身分驗證、工具、讀寫分類、敏感寫入核准），並提交連接器審查，沒有撰寫任何專有轉接器。一個能力層；每增加一個通路，只是多一條存取路徑，而不是一次重建。