當市場向代理敞開大門：Amazon Seller Central 的 AI 外掛與賣方側營運層

要點

• Amazon 已於 2026 年 9 月 23 日將 Seller Central 的賣方側 API 介面開放給外部 AI 代理——這是一個美國測試版的 Selling Partner 外掛，適用於 Amazon Quick 和 Anthropic 的 Claude，涵蓋庫存、價格、商品清單與銷售分析。
• 90% 的 Amazon 銷售夥伴已在使用第三方 AI 工具，且賣家接受 Seller Assistant 建議的比例超過 90%——Amazon 正跟隨其賣家，走進一個早已存在的代理中介工作流程。
• Amazon 選擇了外掛路徑，而非開放協定——UCP、ACP、AP2 與 x402 仍是買方側標準，由 Amazon 決定哪些助理可以連接，而且在公告幾天前，它才把 Meta 的 Muse 購物代理擋在其商店之外。
• 權限模型就是評估介面：限定的資料類型、逐動作的人工核准，以及完整的稽核軌跡——賣家選擇外掛可以觸及哪些資料，並在每個動作執行前予以核准。
• 這個外掛是把 Amazon 的資料連接到助理——而不是把賣家自己的系統堆疊連接進來——一家運行 NetSuite、BigCommerce 或 ShipStation 的 B2B 賣家，仍然需要自己的代理模組層來處理分級定價、多通路庫存與訂單回寫。

今年追蹤的每一項代理商務標準——UCP、ACP、AP2、x402、Checkout MCP——描述的都是買方側：代理如何發現商品、議定價格、完成結帳並付款。（我們已在AI 代理的商務協定版圖一文中梳理過這套堆疊。）2026 年 9 月 23 日，Amazon 在其 Accelerate 賣家大會上開放了交易的另一側。一個全新的 Selling Partner 外掛把最大市場的賣方側營運——庫存、價格、商品清單與銷售分析——放進了 Amazon Quick 和 Anthropic 的 Claude 之中，目前為美國測試版。這股吸引力是可以量測的：90% 的 Amazon 銷售夥伴已在使用第三方 AI 工具打理部分業務，而這些賣家支付給 Amazon 的費用，在 2026 年第二季帶來了 468 億美元——超過 AWS 的營收，正如 GeekWire 在報導中指出的那樣。

本文梳理這個外掛實際開放了什麼、Amazon 為何選擇代理外掛路徑而非開放協定、權限模型把關了什麼，以及它沒有解決什麼——因為 B2B 賣家的營運並不止於市場邊界。代理在 Amazon 上調整的價格，必須能與 NetSuite 裡的分級價格對帳。它剛剛更改的庫存水位，必須與 BigCommerce 和倉庫一致。市場產生的訂單，仍然必須送進 ERP。這個外掛是市場對代理營運給出的答案。而這個整合中屬於賣家的那一側，仍有待建置。

Amazon 實際發布了什麼

9 月 23 日推出了三樣東西，值得把它們分開來看，因為它們各自需要不同的評估方式。

Seller Assistant 升級版。 Seller Central 內的 AI 助理，現在具備對每位賣家定價模式、庫存週期與成長目標的持久記憶，並運行在搭載 Claude 模型的 Amazon Bedrock 上。Amazon 表示，它已推廣至超過 90% 的銷售夥伴，活躍用戶達數十萬人，且賣家接受其建議的比例超過 90%。最後這個數字比記憶功能更重要：Seller Central 內一個獲得多數接受的推薦引擎，正是這個外掛所延伸的行為基準線。

Seller Assistant 工作流程。 全天候監控狀態並在獲得許可下行動的自動化機制——「如果我排名前 10 的任何商品評等跌破 4 顆星，提醒我並草擬回應計畫」，或者「監控我的主力品類，留意競爭空檔；一旦發現，就調整我的定價並更新商品清單」。賣家以日常語言設定護欄，並選擇工作流程是只呈現建議，還是實際採取行動。每個動作都記錄在完整的稽核軌跡中。

Selling Partner 外掛。 全新的介面。這個外掛把賣家的商品清單內容、即時效能指標、庫存水位與銷售分析，連接到一個外部代理——上線時為 Amazon Quick，測試版為 Claude——而外部代理可以像 Seller Assistant 在 Seller Central 內那樣，對帳戶採取行動。Amazon 表示，接入 Claude 大約只需 60 秒、免寫程式，並與賣家既有的會計及供應商資料連接並行。

Amazon 自己副總裁的說法，就是策略面的頭條：「我們的願景是，他們永遠不必再登入 Seller Central，」全球銷售夥伴體驗副總裁 Mary Beth Westmoreland 在 GeekWire 的訪談中表示。「我們會直接把它帶到他們工作的地方。」

為何走外掛路徑，而非協定路徑

買方側協定在設計上就是開放的：UCP 有公開規格和共同開發夥伴，ACP 放在 GitHub 上，任何商家都能公開端點。賣方側的開放卻是另一種形態。Amazon 為它挑選的助理發布外掛——先是自家的 Quick，接著是 Anthropic 的 Claude，一家 Amazon 已投資數十億美元、其模型早已驅動 Seller Assistant 的公司——並表示會有更多整合跟進，且建置方式「模組化程度足以讓我們持續發布外掛」。公告中沒有任何內容描述一個其他平台可以實作的規格。

這個背景讓對比更加尖銳。在 Accelerate 召開前幾天，Amazon 把 Meta 的 Muse——一個消費者購物代理——擋在其商店之外，Amazon 表明的立場是：外部代理必須表明身分，並遵守其所使用網站的規則（GeekWire）。在賣方側，Amazon 同時扮演主機、規則制定者與外掛發布者。賣方側的代理介面，存在於 Amazon 說它存在的地方。

對賣家而言，這不是卻步的理由，而是以評估能力時同樣的嚴謹標準去評估條款的理由——因為這個介面可以由擁有市場的對手方加以擴充、重新定價或限縮。賣家費用早已是 FTC 對 Amazon 反壟斷訴訟的標的，該案定於 2027 年 3 月開庭（GeekWire）；賣家工具的經濟學並不是一個中性的背景。

下圖把這個外掛放進買方側協定堆疊的對照中，並呈現它所設下的權限關卡。

權限模型把關什麼

Amazon 自己的安全描述精確到足以評估：外掛互動受到「存取範圍的明確邊界、動作的人工核准，以及完整的稽核軌跡」保護。實務上，那就是四道關卡。

資料範圍。 賣家選擇外掛可以觸及哪些類型的資料——商品清單、庫存、銷售分析、效能指標。範圍按資料類型劃分，由賣家自行選擇。

意圖可見性。 在 Quick 裡，圍繞這個外掛建構的代理——定價代理、刊登代理、補貨代理——會在動手之前，先顯示它們打算做什麼。

人工核准。 動作在執行之前，需要賣家的核准，與 Seller Assistant 工作流程已經採用的模式一致：僅提供建議，或經核准後執行。

稽核軌跡。 每個動作都會留下記錄。Amazon 也聲明，它看不到賣家助理裡的其他業務資料——也就是賣家保存在 Claude 中的會計與供應商連接。這是 Amazon 對自身執行情況的說法，並非一個可獨立驗證的特性；請據此看待。

這與自訂 MCP 模組所執行的是同一套控制模式：限定的工具、型別化的參數、寫入前的人工關卡，以及經得起稽核的日誌。差別在於這對賣家的可見性不利。用自己的模組，範圍是你的團隊讀得懂的程式碼。用第一方外掛，範圍由市場定義，賣家只能信任供應商的執行。兩者都沒有錯——但它們是不同的信任決策，而後者值得安全團隊以審查任何第三方整合的同一標準加以檢視。

缺口：外掛連接的是 Amazon 的資料，而非賣家的系統堆疊

60 秒的連接，把 Amazon 綁到助理上。對 B2B 賣家實際營運賴以運行的那些系統，它什麼都沒有做。

定價。 這個外掛可以在賣家護欄內調整 Amazon 價格，但它無法在調整之前查核 NetSuite 裡的客戶分級價目表、CPQ 中的合約條款，或利潤下限。對於 Amazon 通路必須與直營 B2B 定價對帳的賣家來說，治理這項變動的定價邏輯，位於外掛觸及範圍之外。

庫存。 它看得到 Amazon 的庫存水位。多通路庫存——同一個 SKU 同時在 BigCommerce、在 Brightpearl 的倉庫、被分配到一筆 ShipStation 出貨——是外掛不會碰的另一個同步問題。

訂單與回寫。 市場訂單仍然需要驗證、稅務與運送邏輯，以及 ERP 建檔。那就是訂單管理層——一家 380 人的經銷商每週處理 1,800 張訂單，靠著跨 NetSuite、BigCommerce 與 ShipStation 的型別化 Schema 驗證，把 12% 的輸入錯誤率降到 2% 以下，靠的正是這一層。

自選助理的模式是一體兩面。 Amazon 的說詞是，賣家已經「與既有的會計及供應商資料連接並行」運行 Claude。一旦 Amazon 的資料進入同一個助理，賣家就會要它把 Amazon 定價與 ERP 成本對帳、把市場庫存與倉庫庫存對帳。這種跨系統推理，恰恰是這個外掛沒有提供的整合——而賣家自己的代理層，正是讓它安全的關鍵：每個系統都有受治理的模組、對代理可讀寫範圍的明確把關，以及落在企業本來就在稽核的系統裡的稽核軌跡。

啟用測試版前應評估的事項

四個問題，依序如下：

1. 這個外掛能寫入什麼，而不只是讀取？ 定價變更、商品清單編輯與庫存調整，屬於不同的風險類別。Amazon 的工作流程區分了僅提供建議與經核准後執行——在開啟之前，先把每個工作流程對應到正確的類別。
2. 核准落在哪裡？ 逐動作、逐工作流程，還是逐工作階段。定價代理上的逐動作核准，與涵蓋整個工作階段的授權，是兩種不同的營運模式。
3. 稽核軌跡擷取什麼，又能送到哪裡？ 如果你的稽核人員讀的是 NetSuite 或合規資料倉儲，軌跡就必須能送達稽核人員本來就在讀的系統。
4. 賣家這一側需要什麼？ 你的哪些系統必須看到代理做了什麼——ERP、店面、倉庫——而這些資料如何傳送？這就是屬於你的整合。

賣方側營運層如今是一個代理介面。Amazon 已經用一個外掛和一個權限模型下了這步棋；中型 B2B 賣家實際擁有的部分，是這個外掛沒有連接的一切。

相關閱讀

• AI 代理的商務協定版圖：UCP、ACP、AP2 與 MCP——協定堆疊如何組合——這個外掛所補足的買方側協定堆疊：發現、結帳、付款授權，以及 B2B 語意層缺口
• 更多 RFQ，更少真實機會：面向代理生成需求的賣方資格審核層——需求側的對應面：當代理生成流入的需求時，供應商的報價團隊如何加以資格審核
• 訂單管理：代理如何每週驗證 1,800 張 B2B 訂單並將錯誤率從 12% 降至 2% 以下——市場之外的賣方側整合層樣貌：驗證、履約路由與 ERP 回寫

代表性案例

一家中型 B2B 賣家在 Amazon 之外同時運行自己的 BigCommerce 店面與 NetSuite，而其營運團隊無法把某一個通路的代理做了什麼，與其他系統所相信的對帳起來。建置從一份系統清單（Selling Partner 外掛涵蓋哪些介面，NetSuite 與 BigCommerce 公開了什麼）、一張工作流程圖（定價調整、庫存同步、訂單接收），以及一個固定範圍開始：合適之處採用第一方外掛，為 NetSuite 和 BigCommerce 建置自訂 MCP 模組，並搭配一套編排政策——限定寫入範圍、對超過門檻的價格變更要求逐動作核准，並讓每個代理動作落入 ERP 與合規工作流程都讀得到的稽核日誌。第一個整合流程——一次會查核 NetSuite 分級價目表、並把決策軌跡回寫的 Amazon 價格變更——在 5 到 8 週內上線。

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