首頁 / 技術文章 / AI 代理卡在網站哪裡？保留驗證關卡、修正操作摩擦的自查清單
技術文章
AI 代理卡在網站哪裡？保留驗證關卡、修正操作摩擦的自查清單
網站應保留必要的驗證與授權關卡，將它們設計成人類交接點；非刻意造成的操作摩擦則應優先修正。判斷重點是阻擋是否符合原本目的，而不是代理能否一路通過。
先問阻擋的目的，再決定要修什麼
代理停在登入畫面，與代理找不到被橫幅遮住的按鈕，應視為不同問題。前者可能是網站要求確認身分的正常結果，後者才可能是介面造成的額外阻力。本站的判斷是：網站對代理開放操作的工作，應從辨識這條界線開始，而非把所有失敗都交給前端或資安團隊排除。
可以先用一個問題檢查每個卡點：如果由人類操作，要求他在此停下、驗證或做選擇，是否就是原本的目的？密碼與 MFA 用於身分驗證，CAPTCHA 是驗證挑戰，同意授權則要求使用者做決定；它們不該因為代理卡住就直接取消。相反地，欄位沒有清楚標記、選項改變後狀態不明，通常不是網站希望使用者承受的成本。
這是網站治理上的分類建議，不是代理相容性標準。也不宜只按元件名稱分類：cookie 同意選擇可能需要保留，但橫幅遮住主要操作、關閉後又無法接續流程，仍應列入改善。應保留的是決策與權限邊界，不必連同糟糕的呈現方式一起保留。
網站代理卡點對照表：哪些保留，哪些修正
以下可作為產品、前端與資安團隊共同檢查流程的起點。每個項目都應回到阻擋目的判斷；同一個頁面可能同時包含必要關卡與不必要摩擦，不需要整頁只選一邊。
| 保留並設交接點 | 應修正 |
|---|---|
| CAPTCHA：若目的是執行驗證挑戰，應保留並清楚標示需要使用者接手。 | cookie 橫幅遮擋操作：若遮擋並非取得選擇所必需，調整呈現方式，讓選擇完成後能繼續任務。 |
| 密碼登入：若操作需要確認帳號身分，保留驗證要求，讓使用者辨識登入入口與完成狀態。 | 表單依輸入變動卻缺乏穩定標記：動態欄位可以保留，但應提供清楚名稱、必填狀態與錯誤提示。 |
| MFA：若目的是追加驗證，保留關卡，說明等待中的動作，以及完成、失敗或逾時狀態。 | 每次載入結構不同：若變化並非產品或防護需求，應檢查能否穩定控制項的語意、位置與識別方式。 |
| 同意授權：若必須由使用者決定權限或用途，保留接受、拒絕與取消路徑，避免替使用者預選。 | 彈窗與流程狀態不一致：若不是刻意阻擋，修正重複彈出、完成後未更新及無法返回的情況。 |
| 敏感步驟的接手點：若網站政策要求使用者確認，明示確認對象與完成後的下一步。 | SPA 狀態沒有穩定 URL：列為待驗證風險；若重整或返回會遺失必要狀態，評估 URL 或其他恢復機制。 |
穩定 URL 這一項尤其需要保留但書：現有來源沒有直接證據，能量化動態路由對代理完成任務的影響。因此不宜宣稱 SPA 必然讓代理失敗，也不必替每個暫時狀態建立公開網址。較合理的驗收目標，是確認任務中斷後能否回到可理解、可繼續的位置。
人類交接點要交代原因、接手動作與返回位置
OpenAI 對 Operator 的官方說明指出，遇到登入欄位、密碼或 CAPTCHA 時，Operator 會把控制權交還使用者。這提供了一個產品設計參考：代理停下來可以是任務流程的一部分，不必直接判定為執行失敗。
網站端可據此設計清楚的接手畫面：說明目前需要登入、完成驗證或確認授權，保留相關輸入與操作入口，並讓成功、取消及逾時有不同的可見狀態。訊息應直接指出下一個動作，避免只顯示含糊的錯誤，讓使用者與代理都難以判斷是否該重試。
交接也需要返回路徑。以預約流程為例，建議驗收使用者完成驗證後，能否回到原先選擇的服務與時段；若狀態已失效，應明確要求重新選擇。這是建議的測試情境，並非已驗證的產品成效。關卡標示清楚，也不代表所有代理都會自動辨識或接續，仍須用預計支援的產品驗收。
對經營者而言，較可控的方向是先決定哪些操作可委派、哪些需要本人確認，再設計介面。這可延伸參考網站開放代理操作的能力與權限分級。若代理帶來的預約或交易在交接時中斷，可能形成商業損失，但目前不能據此估算損失比例，更不能把所有流程跳出都歸因於代理。
渲染成功之後，還要驗收互動流程
Escape 的 Agentic Browser 文件把多步驟登入、依輸入改變的表單、cookie 同意橫幅、MFA，以及每次登入嘗試時不同的頁面結構，列為適合使用 agentic 驗證模式的情境。其說明涵蓋檢查頁面狀態、判斷下一步，以及填表、點擊和導覽。
從網站端解讀，這些情境提醒的是：內容出現在畫面上，還不足以證明任務能完成。驗收應追蹤每次操作後的狀態，例如新增欄位是否說明用途、送出失敗是否指出原因、同意對話框結束後是否回到原任務。這是根據文件情境提出的工程判斷，不代表文件已證明各種設計的失敗率。
不穩定 DOM 也不等於所有動態介面都該改成靜態頁面。較適合優先修正的，是相同用途的控制項在不同狀態下缺乏一致標記，或畫面已更新卻沒有清楚表達結果。這類改善以降低人類與代理的理解成本為目標；是否真的改善完成率，仍應另外驗證。
可直接執行的自查：從任務停在哪一步開始
Skyvern 的除錯文件建議先透過 get_run 查看 status、failure_reason 與 errors，代理執行另有 failure_category；接著開啟 app_url 或觀看錄影。網站端可借用這個思路：先還原停住時的畫面與狀態，再決定該調整防護、表單或交接設計。
- 選定需要驗收的任務，例如完成預約；先定義成功狀態，以及必須由使用者接手的步驟。
- 走完整段流程，記錄每個停點的畫面、觸發動作與預期下一步，依阻擋目的填入保留或修正清單。
- 逐一測試關卡的完成、取消、失敗與逾時路徑，確認接手者能理解狀態，並回到適當位置。
- 改變表單輸入、重新載入及返回上一步，檢查欄位標記與任務狀態是否仍可理解；動態路由問題以結果判斷。
- 使用預計支援的代理重跑相同任務，保留失敗原因與必要畫面供比對；紀錄應避開密碼、驗證碼與其他敏感內容。
若要建立網站端的事件紀錄，建議先分開記錄驗證待完成、使用者取消、表單錯誤與任務完成。這些是流程狀態，不是代理身分證明。現有來源沒有提供可靠的方法，能只靠一般流量分析分辨代理卡關與人類跳出，因此應以可對照的測試紀錄診斷，避免把推測寫成流量結論。
robots.txt 與 llms.txt 不能代替操作驗收
RFC 9309 的狀態為 Proposed Standard，規範的是服務擁有者如何控制爬蟲存取內容，並涵蓋錯誤處理與快取；它沒有規範登入或表單送出等互動流程。也不能直接從這份規範推論，所有使用者即時委派的代理都具有相同的適用身分。
llms.txt 原始提案則建議網站提供 Markdown 檔，包含簡短背景、指引與更詳細文件的連結。它是內容提供方式的提案，不是登入、CAPTCHA 或任務交接標準。網站可以同時改善內容取得與操作流程，但不能用新增這個檔案代替互動驗收；相關政策界線可參考robots.txt 之外的代理存取政策。
網站端較合理的優先順序，是修正沒有防護目的的摩擦，再把必要關卡做成可辨識、可接手、可返回的流程。驗收標準也應包含代理是否在正確位置停下，以及使用者接手後能否繼續。能完成任務與守住權限邊界，應放在同一份產品需求裡評估。
常見問題
為了讓 AI 代理完成任務，應該移除 CAPTCHA 或 MFA 嗎？
不應只因代理卡住就移除。建議先確認關卡的防護目的，再設計清楚的人類接手與返回路徑。OpenAI 對 Operator 的說明即包含在登入、密碼或 CAPTCHA 處交還控制權的做法。
cookie 同意橫幅應該保留還是移除？
應分開評估同意決策與介面呈現。必要的選擇應保留；遮住操作、選擇後反覆出現、無法回到任務等問題，則建議修正，不能把排除摩擦等同於替使用者同意。
加上 llms.txt 就能讓代理順利操作網站嗎？
不能據此保證。llms.txt 是提供背景、指引與文件連結的提案，沒有處理登入、表單或 CAPTCHA。操作流程仍需要另外驗收。
SPA 沒有穩定 URL，一定會讓代理失敗嗎？
目前沒有足夠的直接證據支持這種結論。建議測試重新載入、返回與人工接手後能否恢復任務，再決定是否需要穩定 URL 或其他狀態恢復機制。