The Verge 記者在實測中，指示 Meta 的 Muse 將 The RealReal 上某品牌最新上架的 10 件商品加入購物袋。該平台加入購物袋後會保留商品 20 分鐘，其他買家暫時無法購買；記者再讓 Muse 在預留到期後重新加入，商品因此一再被占用，直到記者停止任務。這次實測尚未完成下單，影響已出現在付款前：代理只做「加入購物袋」，就改變其他人的購買機會。

報導刊出後，The RealReal 技術長向 The Verge 表示，公司已處理這個 Muse 使用情境，更新後的防護會提高代理登入、加入購物袋與結帳的難度，但仍可顯示商品並導向商品頁。報導沒有公開防護實作細節，也不能據此推定平台用了哪種辨識或封鎖技術。對使用代理找商品的消費者，以及開發購物代理或電商系統的人來說，問題因此不只是「代理能不能瀏覽」，還包括使用者授權到哪裡、網站接受哪些代理操作，以及何時會影響其他買家。

一、The RealReal 的預留機制如何變成占用問題

實測顯示，反覆重新加入購物袋可以讓 20 分鐘預留持續發生；代理操作即使沒有付款，也可能暫時排除其他買家。

在一般購物情境中，購物袋像是稍後決定的清單；對採限量或單件庫存的平台，它也可能觸發庫存狀態改變。The RealReal 的二手商品常是一件一款，預留期間商品無法被別人買走，因此持續續期的效果不同於單純讀取商品資訊。實測呈現的是一種可能的流程影響，並沒有統計這類操作在平台上發生的頻率，也不能證明整個電商市場已普遍出現代理搶購。

The RealReal 的更新說法也必須與實測分開看：公司表示將加強機器人防護，並未披露具體技術或完整規則。這個案例提供的可用訊息，是平台正在回應特定占用情境；至於新防護能阻擋哪些操作、是否會誤擋一般顧客，仍須看平台後續說明與實際使用結果。

二、瀏覽、登入、預留與付款是不同權限

不能直接這樣推論；商品瀏覽、帳戶登入、庫存預留和付款是不同操作，應分別取得授權並遵守網站參與規則。

先把操作拆開，才能避免「使用者叫代理找商品」被延伸成「代理可以替他完成所有交易」。瀏覽公開商品頁通常只涉及讀取資訊；登入會接觸帳戶資料與個人化內容；加入購物袋可能改變庫存或預留狀態；付款則會產生金錢與履約義務。每一段的影響對象和可逆程度不同，授權也不該只用一個「允許購物」開關概括。

使用者交代代理代查或代買，表示使用者對工具的指示；網站是否允許第三方代理登入、讀取資料或交易，則是另一個問題。Amazon 在 2026 年 9 月要求 Meta 將 Amazon 從 Muse 移除，並表示「未授權 Muse 存取顧客帳戶、抓取資料或處理交易」。這是平台對外部代理參與的立場，不等於所有網站都採相同規則。讀者使用代理前，應檢查服務條款、帳戶權限與交易流程；具體法律效果仍要依平台條款及適用法規判斷。

「operate openly and respect service provider decisions」是 Amazon 對第三方購物代理的要求。（Axios 引述 Amazon 發言） 四個由瀏覽公開商品頁到提交付款的操作方框依序排列，各階段旁有獨立授權確認標記

若想進一步釐清消費者指示與網站許可的差別，可參考代理購物如何分辨查詢、下單與付款授權。設計端則應讓使用者看見每一步將執行什麼，而不是以一次性同意包辦不同風險層級的操作。

三、機器人防護為何不只看請求量

請求頻率只是訊號之一；帳戶身分、操作目的、對庫存的影響與代理是否遵守網站規則，也會影響判斷。

網站若只看短時間請求量，可能攔下大量自動化讀取，卻漏掉低頻但會重複占用單件商品的操作。反過來說，把所有自動化都當成惡意，也可能擋住獲准的輔助工具或無障礙服務。較可行的設計是按操作風險分級：公開頁查詢、登入後讀取、加入購物袋、保留商品與付款，採不同門檻，並保留拒絕、暫停及人工接手的路徑。

Target 的案例顯示，代理存取也可能因頁面或時間而不同。The Verge 記者測試 Muse 搜尋商品時，有時遇到 Target 的機器人檢查，有時又能取得結果；Target 發言人則表示，網站可能讓代理存取部分內容、限制其他部分，以保護顧客資料和購物體驗。這說明「某次讀得到」不代表之後每種操作都被允許，也不代表其防護在所有情境下相同。

robots.txt 是網站向自動化爬蟲表達路徑存取偏好的協定。IETF 的 RFC 9309 明確說明，這些規則不是存取授權。因此，它不能授予登入、操作帳戶或下單的權利，也不能取代交易條款與明確授權。至於請求過多時，HTTP 的 429 狀態碼可用來表示限流，RFC 6585 也指出伺服器可以提供建議等待時間；但規格沒有規定伺服器必須如何辨識使用者或計算請求，故限流仍需與帳戶、操作狀態及商品預留規則一起設計。

「這些規則不是存取授權。」（IETF《RFC 9309：Robots Exclusion Protocol》）

四、網站可在代理識別、預留與付款處設界線

網站可要求代理表明身分、按操作類型授權、限制重複預留，並在付款等高影響動作前要求使用者確認。

第一，代理需要能被辨識，使用者授權則應記錄可執行的範圍、期限與撤銷方式。若代理是透過使用者帳戶操作，網站仍須區分「帳戶本人操作」與「受指示的第三方自動化」，並提供發生爭議時可查的紀錄。這些設計並不能只靠一個代理名稱或標頭保證，還要搭配網站實際採用的驗證流程。

第二，查詢、加購物袋和預留不宜共用同一組頻率限制。限流可降低短時間大量請求，預留機制還應考慮單一商品被同一帳戶反覆續期、不同帳戶協同占用，以及預留逾時後是否恢復販售。The RealReal 表示會更新機器人防護，但外界尚無其技術細節，因此這些是系統設計時可檢查的項目，不能寫成該平台已採用的措施。

四個並列的電商代理控管項目，分別呈現代理身分與授權、操作限流、預留期限與停止條件，以及付款前人工確認
交易安全要同時涵蓋身分與授權、操作限制、預留規則及付款確認。

第三，預留應有清楚到期時間與續期上限；若商品有限量或會排除他人購買，續期時可重新要求人確認。付款則屬於影響較大的動作，可再次呈現品項、價格、運費、退貨條件與付款對象，由使用者確認後提交。代理若收到拒絕、限流或驗證要求，應停止並回報原因，而非自行不斷重試。

五、台灣電商與工具開發者可用五步檢查交易界線

先逐步盤點代理能做的操作、網站允許的範圍、對庫存的影響、停止條件與付款確認，並以失敗情境驗收流程。

  1. 列出操作範圍：分開標示讀取商品、登入帳戶、加入購物袋、預留與付款；每一步都要有對應權限。
  2. 確認雙方規則：檢查網站服務條款、帳號權限與代理工具的授權紀錄，不能把使用者同意當成網站已允許第三方交易。
  3. 評估對他人的影響：找出哪些操作會鎖住庫存、改變價格或阻礙其他買家，為這些操作加上頻率、期限與續期限制。
  4. 設計停止及回報：遇到拒絕、限流、驗證或資料不一致時，停止操作並告知使用者；不要默默重試或改用其他途徑繼續。
  5. 付款前再次確認：呈現品項與交易條件，讓使用者確認後才送出；測試逾時、重複點擊與庫存變動時會如何處理。

這份檢查表適合用來找設計缺口，不代表每個電商都能採用同一組限制。商品是否可預留、代理身分如何驗證、需要何種使用者確認，都應依網站條款、庫存型態與交易風險調整。若需盤點更廣泛的網站存取角色與拒絕流程，可延伸閱讀AI 代理整合網站前的存取權限檢查。

對台灣的消費者，實際使用前要確認代理會不會登入、代為保留或付款，並查看平台是否允許這些操作；若服務條款或帳戶權限寫得不清楚，先停在商品搜尋或由本人完成交易。對產品團隊，先挑出會影響其他買家的步驟，再逐一驗證授權、限流、預留到期與付款確認，通常比只問「機器人防護有沒有開」更能找出真正的系統風險。

  • 使用者授權代理，與網站允許代理參與交易，是兩個不同判斷。
  • 瀏覽、登入、預留、付款應分開授權與控管，尤其要找出會排除其他買家的操作。
  • robots.txt 表達爬取規則，不是交易許可；限流也需要和帳戶、預留及停止流程配合。

常見問題

Q1：AI 代理可以代替使用者下單嗎？

要看代理取得的使用者授權、網站是否允許第三方代理操作，以及付款流程如何確認。能找到商品或登入帳戶，不代表自動取得下單許可。

Q2：網站開放商品頁給代理瀏覽，是否代表可以加入購物袋？

不一定。瀏覽是讀取商品資訊，加入購物袋可能觸發庫存預留，兩者對網站與其他買家的影響不同，應依平台規則分別判斷。

Q3：robots.txt 可以用來判斷代理能不能購物嗎？

不可以。RFC 9309 說明 robots.txt 是爬蟲存取規則，不是存取授權；帳戶登入與交易許可要另外確認。

Q4：電商只要加上限流，就能避免代理占用商品嗎？

限流能處理部分高頻請求，但未必看得出重複預留或低頻的資源占用。還要檢查代理身分、預留期限、續期上限與拒絕後的停止行為。