代理購物的三道閘門：查詢、下單與付款，授權帳要分開記

2026年10月19日，APPI News 刊出一篇關於 AI 代理購物授權的分析，把一個常被混為一談的問題重新攤開：代理能替你付款，與代理整段購物流程都獲得授權，是兩回事。支撐這篇文章的市場線索有兩條，一條來自支付端，一條來自商家端，兩條的證據等級並不相同。

支付端是 Stripe 的說法。據 The Decoder 報導，Stripe 表示其 Link 服務的代理交易筆數在九月成長38倍、交易金額成長20倍。報導同時交代了這組數字的限制：Stripe 未公布實際筆數與金額，倍數是從較小起點計算；分析時約有70個代理使用該服務，受訪主管其後估計約200個。這是單一支付服務的成長描述，無法據此推估代理購物的整體市場規模，也無法回答代理佔電商交易多少比重。

商家端則是一則尚未證實的用戶經驗。TechNews 報導有 X 用戶反映，Grok Bot 在 Amazon 下單時出現未授權 AI 代理的警告；截至報導刊出時，Amazon 未公開確認曾封鎖 Grok Bot。單一用戶的遭遇不能推定 Amazon 對所有 AI 代理採取一致政策，更不能推定為行業慣例。

三個操作，三種權限後果

把代理購物拆開，至少有三段操作，各涉及不同的資料與後果。商品查詢讓代理讀取商品名稱、價格、庫存與配送資訊；建立訂單則選定商品、數量、地址與配送方式；送出付款才動用帳戶或支付憑證。使用者同意代理找商品，並未同意它下單；同意它下單，也未必同意特定金額的支出。

責任同樣分屬不同角色。消費者設定代理可做的事；代理服務接收指令並代表使用者操作；商家決定網站如何接受自動化存取與訂單；支付平臺處理付款授權與交易。四個角色彼此連接，但不會自動代替對方給出同意。

Stripe 在其《Agentic Commerce: A Getting Started Guide》文件中寫道：「買家會審核並核準每筆支出請求。」這句話劃出了支付端的邊界：它能確認買家同意某筆支出，無法代替商家核對庫存、履約條件或網站存取規則。換句話說，支付端核準的對象是支出，不是整筆交易的所有欄位。

商家端才是更硬的控制點

支付服務願意處理代理付款，與商家允許代理進站或下單，是兩本帳。Grok Bot 的案例之所以值得注意，正在於卡關位置發生在商家端：付款憑證無論多完整，都解決不了網站對自動化存取的規則。這也與其他平臺近期的治理方向一致，例如蘋果收緊 macOS 完全磁碟存取權限的調整，同樣是把閘門往前移到作業系統層，先擋代理的存取口（見本站先前整理的macOS 27 權限收緊分析）。

對商家而言，允許代理下單牽涉的不只是技術介面。自動化存取改變了流量結構與爭議處理成本：訂單若在核準後改了品項、數量、配送地點或總額，原核準是否仍適用，就需要重新判斷。把這些欄位納入支出請求，消費者才知道自己核準的是哪一筆具體交易，而非一個抽象的付款動作。

消費者的檢查清單

APPI News 給出的檢查順序可以濃縮為六個問題：代理是誰、使用者如何連結帳戶、它要向哪家商店買什麼、總額多少、同意效期多長、訂單改動時是否重新詢問。若服務只顯示付款成功，卻不呈現代理做過哪些操作，消費者便無從判斷授權是否符合原意。

這套權限帳的計算方式，與我們先前拆解過的CERT-In AI 代理憑證公告是同一套邏輯：代理越過授權邊界的成本，最終記在憑證與環境隔離那一欄。

收束判斷

目前可確認的事實有限：Stripe 單一服務的代理交易在九月高速成長，但基數與絕對值未揭露；Grok Bot 遭擋是未經 Amazon 確認的用戶反映。能確認的是結構，代理購物的授權必須按查詢、下單與付款分段檢查，支付端的核準無法覆蓋商家端的存取規則。在商家端政策明朗、交易量數據揭露之前，任何關於代理購物市場規模的說法，都應視為行銷敘事而非統計事實。