很多人想到 AI 代理替使用者購物、訂位或預約，第一個念頭是讓它模仿真人點擊網頁。但在操作之前，還有更前面的問題：網站如何辨認來訪者是誰，使用者允許代理做到哪裡，以及網站是否接受這種存取。這些條件沒有對上，代理能操作瀏覽器也不代表交易可以完成。

一、AI代理遭網站阻擋，問題出在操作能力還是授權？

能操作頁面只代表代理具備操作能力，不代表網站已授權它存取，也不表示使用者已同意這筆具體交易。 網站政策、代理身分和使用者委派是不同層次，必須分開判斷。

瀏覽器點擊、網站工具與正式介接的差別

瀏覽器自動化是代理透過瀏覽器辨讀頁面、填表、點擊按鈕，技術上接近替人操作現有介面。網站介面若更新、登入逾時或出現驗證步驟，原本的操作流程就可能中斷。代理可以依畫面嘗試恢復，但無法因此取得網站原本沒有提供的權限。

正式 API（應用程式介面）則是網站明確提供給其他系統呼叫的功能，可能設有開發者註冊、金鑰、權限範圍、流量限制和合約條款。它能讓雙方清楚約定哪些資料可讀寫、操作如何驗證；代價是網站必須開放並維護這個介面，代理服務也要完成整合。API 可用不等於所有操作都已獲准，仍須依各服務設定和授權流程執行。

WebMCP 是另一種讓網站向瀏覽器代理提供結構化工具的提案方向，目的在明確描述網站功能，減少代理只靠猜測按鈕用途而出錯。Chrome for Developers 將它列為 early preview 與 origin trial（來源試驗）階段的技術。網站端提供工具，不代表自動授權代理，也不能取代登入、交易確認或服務條款。

報導呈現的阻擋原因並不只有一種

TechCrunch 記錄了幾種不同狀況：Amazon 開始阻擋 Meta 的 Muse；Walmart 表示，合作代理遇到的 CAPTCHA（人機驗證）問題並非刻意封鎖；Delta 表示尚未與第三方代理合作代客搜尋或訂票；United 則提醒使用者，其條款限制未經許可的自動化用途。

TechCrunch 也報導 Yelp 不允許非人類流量，除非代理透過付費資料授權計畫取得平台內容與資料。這是 Yelp 對資料存取的個案，不能延伸成一般網站都會以付費資料授權作為代理操作條件。

這些個案不能代表所有網站政策，也不能只憑一次失敗判定遭到封鎖。產品團隊應確認驗證服務是否故障、網站有無代理合作管道、條款是否限制自動化，並保留拒絕狀態供後續釐清。

TechCrunch 轉述 Delta 全球傳播總經理 Heena Chavda 說，Delta 正評估以新科技提升顧客互動；安全與顧客體驗也是開放代理時的考量。航空服務因此須先界定代理權限及出錯後的接手責任。

二、網站為什麼要辨識並限制AI代理？

網站需要判斷自動化請求會讀取或改變什麼、能否代表真實使用者，以及是否符合服務政策。 CAPTCHA 失敗可能是反機器人措施與代理操作不相容，也可能是網站基於政策限制，不能一概當成技術故障。

自動化請求帶來帳號、交易與服務風險

從產品設計角度看，短時間大量請求可能增加服務負載，也可能被用來爬取內容、試探帳號或大量提交表單；各網站公開的封鎖理由與實際考量仍須個別查證。購物和訂位則可能帶來交易風險，例如錯買商品、重複下單、誤訂時段，或在不清楚退改條件時送出付款。

網站可依流量型態、帳號狀態及服務條款採取不同控制。產品團隊須預期介面可能要求驗證、限制頻率或拒絕操作，並說明使用者接下來能怎麼處理。

代理的自動操作也可能和網站既有的防濫用設計衝突。人機驗證要確認某次行為符合網站預期，卻未必能判斷這個代理是否獲得使用者授權；代理能否辨讀或完成驗證，也不能作為網站同意它操作的證明。若網站的驗證步驟同時擋到真人，問題還涉及流程設計與錯誤回報，不能只用「代理不夠聰明」來解釋。

身分訊號不等於使用者同意

「這是哪一個代理服務？」、「它代表哪位使用者？」、「這位使用者允許它做什麼？」是三個問題。代理服務的應用程式識別碼或簽章，能提供服務端身分訊號；使用者登入可以證明一個帳號完成驗證；但兩者都無法單獨回答，這次請求是否包含購買、修改、取消等具體操作的同意。

登入狀態也不是永久授權。若把帳號密碼、Cookie 或工作階段交給代理，它可能取得超出任務所需的能力，網站也未必看得出哪些操作由代理執行。驗證確認主體、授權界定可做的事、網站政策決定是否接受這種方式，三者都須成立。

三、使用者授權要交代哪些權限與條件？

授權應說明代理身分、代表的使用者、指定任務、資料範圍、限制條件和有效期間，並標出哪些操作要再次確認。 一次登入或籠統地按下「允許」，不足以代表使用者同意代理未來所有行動。

將同意轉成可執行範圍

以代訂餐廳為例，使用者可授權代理查詢某日期、指定人數和地點的空位；若要送出訂位，就應再呈現餐廳、時段、人數，以及取消規則或訂金條件。若任務是購物，則可在確認前呈現商品、數量、價格、運費與付款方式。這些限制最好由系統驗證，而不是只寫在對話指示裡，避免模型漏看、誤解或自行補上條件。

授權也需限制時間和範圍。例如，允許代理在本次任務中讀取配送地址，不等於允許它長期保存或用於其他購物；允許查看航班，也不代表可修改既有訂單。OAuth 2.0（開放授權協定）的範圍參數可描述應用程式能存取哪些資源，但實際範圍由服務提供者定義。網站顯示同意畫面，也不會替產品團隊決定資料保存方式或後續用途。

依影響程度設計確認節點

會扣款、取消、變更個資或造成不可逆結果的操作，應設置確認點，列明動作、對象、金額或條件。若資訊不足，或價格、時間在送出前變動，應重新請使用者確認。

使用者也應能在任務進行中暫停或取消代理，並在設定中撤銷授權。OAuth 相關標準提供撤銷權杖的機制，讓用戶端通知授權伺服器某個權杖不再需要；實際撤銷範圍與生效時間仍受服務端設計影響。產品介面應交代撤銷後哪些存取會停止、已完成的訂單是否仍有效，以及是否需要聯絡網站處理。

授權卡片列出可操作網站、任務、資料範圍、金額上限、有效期限、再次確認條件與撤銷控制。
授權要逐項界定網站、任務與限制，登入或籠統按下允許不足以代表所有操作都獲同意。

「WebMCP 的用途與需求會因網站而異，沒有單一答案。」Chrome for Developers 的指引提醒網站依使用者目標、所需資料和限制條件設計工具。這項原則也適用於授權介面：先定義任務邊界，再決定要開放的能力。

「存取權杖的權限應限制在特定應用程式或使用情境所需的最低程度。」IETF RFC 9700 第 2.3 節以此作為 OAuth 安全最佳實務，提醒產品依任務限制權杖可用資源與操作。

四、產品團隊有哪些網站介接方式？各自的責任邊界是什麼？

先採用網站正式提供且符合條款的介面，再依任務評估 OAuth 委派、結構化瀏覽器工具或人工操作。 API、OAuth 和 WebMCP 解決的問題不同，任何一種都不會單獨替代理取得網站同意。

比較介接方式的支援、權限與限制

OAuth 是授權協定，可依網站設定，在使用者同意後提供特定資源的存取權杖。RFC 8693「OAuth 2.0 權杖交換」定義系統間交換權杖的流程，並以 subject token 與 actor token 表達代表使用者行動的情境；它沒有規定所有委派權限都必須採特定範圍或期限。產品仍應依任務限制權限範圍和有效期間。若網站提供官方 API 與 OAuth 流程，須依其文件申請並妥善保管權杖。

RFC 9700《OAuth 2.0 安全最佳實務》建議將存取權杖限制在應用程式或使用情境所需的最低權限，並限定可存取的資源與操作。產品團隊可據此檢查權杖是否只允許本次任務所需的資料讀取或變更。

WebMCP 等結構化瀏覽器工具，適合網站主動把特定任務功能提供給代理，例如查詢空位、填寫表單或取得商品資訊。Chrome 文件把它描述為試行中的方向，網站需自行決定可提供哪些工具、資料與操作。瀏覽器工具呼叫成功仍要由網站後端驗證身分、權限和狀態，不能只信任前端傳來的欄位。

瀏覽器自動化的優點是可沿用現有網站流程，在沒有 API 時也可能操作使用者介面；缺點是介面變更、驗證和政策限制較難預測，穩定性與可稽核性取決於實作。直接模擬登入或重用個人工作階段尤其需要審慎評估，可能暴露過多資料，也可能與服務條款衝突。網站未提供正式介面時，應先確認是否有合作、授權或其他合規存取途徑。

若網站要求簡訊驗證、顯示新價格或要求勾選聲明，系統應呈現頁面狀態與未完成動作，停止並請使用者接手，不應猜測答案或繼續送出交易。

方式由誰提供介面權限與紀錄主要限制
官方 API（如網站提供 OAuth）網站或服務供應者認證方式依網站設計；可依範圍發放權杖並記錄呼叫須獲網站開放並遵守申請條件
結構化瀏覽器工具（如 WebMCP）網站提供工具，代理透過瀏覽器呼叫網站可逐項定義工具與操作結果WebMCP 仍處試行階段，支援依網站和瀏覽器而異
瀏覽器自動化代理模擬使用者介面需由產品自行建立授權和稽核紀錄易受頁面更新、驗證與網站政策影響

五、操作紀錄與責任如何交接？

至少保存使用者同意內容、代理與使用者識別、請求時間、網站回應、執行結果及是否經過人工確認。 記錄須足以重建任務流程，也要避免把不必要的個人資料或驗證憑證留在日誌中。

留下能重建流程的紀錄

每次任務可用唯一識別碼串起使用者目標、授權版本、代理請求、網站回應、結果和人工接手紀錄。購物或預約也應記下送出前顯示的關鍵條件與確認時間，方便客服還原流程；紀錄本身不會決定法律責任。

操作日誌不應保存完整密碼、長效權杖或與任務無關的頁面內容。記錄欄位、保存期限、存取權限和刪除方式需要依服務需求與適用規範另行設計。台灣團隊可先對照《個人資料保護法》檢視蒐集目的、資料項目、利用範圍及安全維護安排，再依服務實際流程確認告知與委外管理要求；各項義務仍應由法務依個案核對。

例如代理讀取訂位電話時，日誌可保留任務識別碼、授權時間及網站回覆狀態，不必複製完整電話。客服查詢個案應受權限控管並記錄用途；資料保存期限則須兼顧申訴、交易爭議及法定需求。

個案責任仍須依資料流向、服務角色、契約安排和網站條款核對，技術文件不能取代在地法規檢視。

實作時先畫出資料流，標示傳送欄位、保存位置、存取角色與刪除條件，供法務、資安和產品共同核對。若任務從查詢航班改為修改訂位，也要確認新增資料與操作是否仍在原授權範圍。

逾時、拒絕、重複提交及部分完成時的處理

網站回應逾時，不代表交易沒有完成。若代理直接重送付款或訂位請求，可能造成重複交易；系統應先查詢任務或訂單狀態，並使用網站支援的冪等識別方式，降低重複送出的風險。若網站沒有查詢或安全重試機制，應停止自動重送並交由使用者或客服確認。

網站拒絕存取時，系統須保留拒絕狀態與原因類別，讓使用者知道是權限不足、驗證未完成、網站拒絕代理，或服務暫時無法使用；不可把所有錯誤都包裝成代理「再試一次」。如果任務部分完成，例如已選好時段但尚未付款，畫面要指出目前狀態和接續步驟。當代理無法確定網站是否完成操作時，交由人工接手比猜測結果安全。

流程圖依序呈現使用者請求、明確授權、代理操作、網站回應與交易狀態，逾時不明時轉交人工查證。
網站逾時不代表交易失敗，先查明狀態並交由人工確認，可避免重複送出。

六、台灣產品團隊整合前應先檢查什麼？

先確認網站是否提供正式介面及可用條款，再定義代理身分、授權範圍、敏感操作確認、撤銷方式和可追查紀錄。 從低影響、可復原的任務驗證流程，才逐步評估是否擴大操作範圍。

從正式介面、使用者同意到人工接手

產品團隊可以先逐項確認：

  1. 確認網站入口：查閱官方 API、合作文件、OAuth 範圍和使用條款，分清讀取資料與執行交易的許可。

  2. 定義代理與任務：說明代理服務、代表的使用者、操作網站、可讀寫資料及授權期限。

  3. 標出高影響節點：為付款、訂位、取消或資料變更設確認點，並處理價格等條件變動。

  4. 規劃撤銷與復原：提供暫停、撤銷方式，並設計重複請求、逾時及部分完成的處理流程。

  5. 建立可追查紀錄：記錄必要請求、授權、網站回應及人工接手資訊，限制個資留存與存取。

  6. 從低影響情境測試：先測試查詢或草稿，再依網站支援、錯誤率和客服回報評估是否擴大。

不同網站的授權、功能和條款各異。產品應先確認網站支援，再提供清楚且可撤回的授權，並設計可驗證、可停止、可交接的流程。對 AI 代理、網站操作與系統整合有交流需求的團隊，可從上述檢查項目展開討論。

  • 網站驗證、代理身分、使用者同意和網站政策是不同控制層，需各自確認。
  • 授權應限制網站、任務、資料、有效時間與高影響操作，並提供暫停、撤銷和人工接手。
  • 優先使用網站正式介面；WebMCP 等試行工具與瀏覽器自動化都不能自行取代網站許可。
  • 保留可重建任務的必要紀錄，遇到逾時或狀態不明時先查證，避免重複送出交易。

常見問題

Q1: 使用者登入網站後，AI代理就能替他購物嗎？

不能只憑登入狀態判定。登入主要證明帳號完成驗證，仍要確認網站是否允許代理操作，以及使用者是否同意具體商品、金額和送出訂單等行為。

Q2: OAuth可以直接解決AI代理被網站擋住的問題嗎？

不能。OAuth 可在服務提供者支援時處理特定資源的授權，但不會強迫網站開放介面，也不會覆蓋網站條款或代理操作政策。

Q3: WebMCP是否已是所有網站都能使用的正式標準？

不是。Chrome for Developers 公開資料將 WebMCP 描述為 early preview／origin trial 方向，支援狀態會依瀏覽器、網站與試行條件而異。

Q4: 網站操作逾時時，代理可以自動重試嗎？

先確認前一次操作是否已完成。付款、訂位等請求若不具冪等保護，直接重送可能造成重複結果；無法查明狀態時應暫停並交由使用者或客服確認。