用 Operator 類 Agent API 構建穩定網頁自動化

OpenAI 的 Operator 在2025年1月發布，立刻改變了關於網頁自動化的討論。不再需要脆弱的CSS選擇器和XPath查詢，你可以指著一個網站對AI說「幫我買菜」。它確實能用——有時候。挑戰一直讓它可靠到能用在生產系統中。

我花了六週時間為一個客戶的內部工具建構 Operator 風格的自動化管道。我們處理了大約400個不同工作流程中的12,000次頁面互動。最終確定的架構不是炒作文章描述的那種。不是「AI搞定一切」，而是「AI處理困難的部分，程式碼處理其餘的」。

核心架構：三層模型

我見過的每個生產級 Operator 系統都使用三層架構。跳過任何一層都是團隊出問題的根源。

第一層：瀏覽器控制。 這是基礎——agent可以命令的無頭或有頭瀏覽器執行個體。Playwright 已經成為這裡的主流選擇。對大多數團隊來說，Playwright v1.48+ 配合其無障礙快照 API 是實際的起點。關鍵能力不只是點擊和輸入——而是以結構化格式將頁面狀態讀回給 agent。

第二層：Agent 推理。 這是解釋頁面狀態、決定下一步操作並產生命令的 LLM。截至2026年初，GPT-4o 和 Claude 3.5 Sonnet 是最常見的選擇。Agent 接收頁面的結構化表示——通常是無障礙樹或簡化後的 DOM——然後輸出離散操作：點擊、輸入、滾動、導航或擷取。

第三層：編排與恢復。 這是大多數教程跳過的黏合層。它處理重試邏輯、檢查點管理、錯誤分類和人機協同升級。在生產中，這一層做了80%的重活。

頁面狀態提取的實際工作原理

整個系統的可靠性取決於一件事：agent 能否準確感知頁面的當前狀態？這個搞錯了，其他都白搭。

標準方法是提取無障礙樹。過濾後，一個典型頁面從500個節點縮減到60-80個可操作元素。token消耗減少約70%，agent 在我們內部基準測試套件上的準確率從約72%提升到91%。

錯誤恢復：最重要的部分

這是大多數自動化專案失敗的地方。Agent 會遇到錯誤——元素未載入、驗證碼、工作階段逾時、意外彈窗、Cookie 同意橫幅、A/B 測試變體。

我們建構了三級恢復系統：

一級自動重試處理約60%的錯誤，二級 Agent 引導恢復處理約30%，三級人工介入處理約10%。

在生產中，我們的管道對複雜多步驟工作流程實現了89%的自主完成率。剩下11%需要人工干預，但詳細的故障報告意味著人工通常在2分鐘內解決每個問題。

Token 成本的現實

說說錢的事。執行 Operator 風格的自動化並不便宜。在一個典型的多步驟工作流程（8-12個操作）中，每個任務大約消耗8,000-15,000個輸入 token 和500-1,000個輸出 token。僅 LLM 成本大約每個任務 $0.08-0.15。

我們透過兩個策略將成本降低了40%。第一，對一級錯誤恢復和簡單導航步驟使用更便宜的模型（GPT-4o-mini），保留完整模型用於複雜推理。第二，快取頁面狀態快照。

生產部署清單

在將 Operator 風格的系統推向生產前，確保已處理好這些：

• 瀏覽器池管理：使用可複用執行個體池
• 反檢測措施：無頭瀏覽器會被網站主動屏蔽，需要隱身外掛、使用者代理輪換
• 檢查點持久化：使用 Redis 等持久儲存保存任務檢查點
• 每域名速率限制：尊重目標網站的基礎設施
• 成本監控：從第一天起就建立每任務成本追蹤

89%的自主完成率聽起來不錯，直到你意識到在12步工作流程中，11%的失敗率意味著大約73%的任務完全無需人工干預（0.89^12）。這仍然很好——比傳統自動化在非結構化頁面上的表現好得多——但不是「設好就忘」。為人工介入開銷做預算，精心設計錯誤恢復，並監控一切。