Agent 執行網頁任務時，失敗常發生在元素定位、等待逾時、狀態保存和環境攔截四個環節。把步驟做成冪等、讓可恢復失敗可重試、定期將狀態持久化，並按任務隔離執行環境，成功率會穩定許多。
剛開始做網頁自動化時，思路往往很直接：把流程寫出來，讓腳本跑起來。邏輯看起來沒有問題，任務卻仍會零星失敗，帳號狀態也不時出現異常。第一反應通常是檢查程式碼，但排查到最後會發現，問題主要集中在四個地方。
頁面一改，定位就失效
多數腳本依靠選擇器尋找元素。選擇器一旦寫死，頁面上任何一次調整都可能讓它失效：按鈕換了 class 名稱、文案改了一個字、某個區塊從伺服器端渲染改成非同步載入，或元素被包進新的容器。營運側做一輪 A/B 測試時，同一個頁面在不同帳號看到的結構甚至可能不同。
常見表現是找不到元素、點擊偏位，或點到同名但位置不同的控制項。這類失敗不是網路抖動，重試幾次也不會改善。
可行的做法是少依賴絕對路徑：優先使用可存取性屬性、穩定的業務 ID，或元素之間的相對關係來定位；針對同一類頁面準備備用選擇器，主選擇器失效時自動降級。頁面中如果有 iframe 或 Shadow DOM，要先切換到正確的 context，否則定位一定會失敗。
等待和逾時設錯了區間
等待時間設得太短，元素還沒完成渲染就被判定失敗，看起來像腳本有 bug；設得太長，單一任務耗時會被無限拉長，吞吐量下降，過長的逾時還可能掩蓋真正的錯誤。
比固定 sleep 更可靠的是明確等待：等待一個具體條件成立，例如目標元素出現、某個 request 回傳，或載入動畫消失。逾時預算要分層設定，單一步驟、單一頁面和整個任務各自有一套，並逐層收斂，不要所有環節都使用同一個值。
還要區分「頁面可用」和「業務結果已產生」這兩種等待。前者通常等 DOM ready 就夠；後者可能需要等待 API callback，或頁面上的狀態文字變化。等錯訊號就會出現操作看似成功、資料其實沒有寫入的情況。
多步驟任務做到一半，進度丟失
註冊、下單、發布這類任務動輒十幾個步驟。程序中途退出，例如被逾時終止、瀏覽器崩潰或主機重新啟動時，如果狀態只放在記憶體裡，下次執行不是得從頭再來，就是會把上一步重複提交一次。
重複執行的後果比單純失敗更難查：同一筆操作被執行兩次，上游系統多出一筆記錄，還很難追查來源。
做法是讓每一步都有落點。每完成一步，就把進度寫進可持久化的位置，並帶上任務的唯一識別碼；重新啟動後從最後一次成功的位置繼續。這一步不需要複雜框架，一個檔案或一筆狀態記錄就足夠。
環境側被攔截，表現和程式碼錯誤一樣
前三類問題出在任務內部，還有一類來自環境側。網站會綜合瀏覽器特徵、存取行為和網路來源判斷流量來源，一旦判定可疑，可能回傳驗證頁、空白內容，或直接逾時。從任務 log 來看，這和執行錯誤幾乎沒有差別。
常見誘因有：
- 出口 IP 的所在地、時區和語言三者對不上
- 所有任務都從同一個瀏覽器環境發出 request，單位時間內的請求密度明顯高於真實使用者
- 環境頻繁更換，或帳號反覆重新登入
四件把成功率拉高的事
- 每一步都做成冪等。執行前先確認前置條件是否已滿足，讓動作重複執行也不產生額外副作用。查詢類操作天然冪等，寫入操作要靠唯一識別碼或去重鍵兜底。
- 對失敗分類。暫時性的失敗，例如元素還沒渲染、網路抖動、API 回傳 5xx，可以用 backoff 重試；確定性的失敗，例如帳號受限、參數不合法、目標資源不存在，重試多少次都一樣，直接標記終止，避免它一直占用並行額度。
- 定期將狀態持久化。把進度、中間產物和目前步驟保存下來，任務重新啟動後接著跑，而不是從第一步重來。
- 按任務隔離執行環境。每個帳號或每條任務對應一個獨立的瀏覽器環境，Cookies 與本機儲存空間互不共享，fingerprint 特徵有合理差異，時區與語言則和出口 IP 所在地區保持一致。
第四件事在任務規模上來後尤其關鍵。當幾十到幾百條任務並行執行時，環境這一層決定了穩定性的上限，也決定出問題時影響面有多大。PurpleMark 在這類場景中提供的，就是按需建立、批次回收獨立環境的能力；每個帳號都有自己的一套環境，任務之間的狀態不會互相污染。
以上內容僅用於技術研究與開發實務分享。請在合法合規的前提下使用相關技術，並遵守目標平台的服務條款。
