Cloudflare Browser Run 自動化可以在沒有合適受支援 API 時，將 AI 工作流連線到網站。這種靈活性也帶來不同的維運負擔：頁面會變化，工作階段會過期，完成一次點擊並不能證明預期業務操作已經發生。
如果受支援 API 能可靠提供所需操作，應優先使用 API。瀏覽器確實是合適介面時，再使用 Browser Run，並明確已授權工作階段、有限任務，以及對結果頁面或記錄的檢查。遇到不確定結果應停止，在重複有重大影響的操作前先核對。
設想維運團隊從供應商入口網站下載對帳單。助手必須選擇正確帳戶與期間、獲取檔案並驗證內容。後續工作流可能上傳核對說明。這些範圍不同：允許獲取對帳單，不等於允許提交文件。
以下設計是假設示例，不聲稱瀏覽器自動化能夠繞過入口網站存取限制，也不認為 AI 模型可以安全地針對每次介面變化自行變通。
Cloudflare Browser Run 自動化從介面選擇開始
Cloudflare 的 Browser Run 概覽 介紹了目前服務，包括無狀態操作與瀏覽器工作階段，其舊稱為 Browser Rendering。根據任務選擇整合模式，不要將所有操作都視為開放式智慧體工作階段。
公開截圖或簡單頁面提取，可能只需有限請求。已登入入口網站流程則需要工作階段處理、導航檢查和清晰完成條件。API 可能免去大量針對頁面的工作。
| 任務要求 | 優先評估 | 為何重要 |
|---|---|---|
| 獲取受支援業務記錄 | 官方 API | 穩定記錄身分與明確回應 |
| 擷取公開頁面 | 無狀態瀏覽器操作 | 有限導航與工作階段狀態 |
| 從已授權入口網站下載 | 受控瀏覽器工作階段 | 登入與頁面狀態轉換 |
| 提交有重大影響的表單 | API 或明確批准的瀏覽器流程 | 結果與重複處理 |
| 探索任意網站 | 實施前縮小任務範圍 | 無界導航難以驗收 |
記錄為什麼需要瀏覽器。這樣，之後遷移到 API 才是有意識的工程選擇，而不是承認原有整合從未有過穩定契約。
讓任務範圍小於瀏覽器的能力
瀏覽器可能顯示自動化絕不能使用的按鈕。在模型提示詞之外，定義允許的網站來源、帳戶、記錄與操作。將工作流的業務權限保留在啟動作業的應用中。
對於供應商對帳單，任務契約可以標識供應商帳戶、對帳期間和目標複核佇列，也應規定多個帳戶或期間匹配時如何處理。讓模型選擇最像正確答案的帳戶，並不是充分的解決策略。
分開讀取與提交。下載作業不應獲得“在入口網站完成任何事情”的通用指令，後者可能包含修改資料或接受新條款。遇到意外且有重大影響的步驟，應停止任務並報告情況。
Cloudflare 的 Playwright 整合指南 是該方案的實施依據。固定選定套件與相容設定，驗證工作流實際使用的功能。
根據最新頁面狀態決定每次轉換
決定下一步前，檢查頁面目前顯示什麼。在前一頁面有效的選擇器，導航或出錯後可能指向不同控制元件。網站提供有意義標籤和穩定應用識別碼時，應優先使用。
AI 模型可以幫助理解頁面，但選定帳戶、請求期間等關鍵事實應由確定性斷言確認。如果預期控制元件不存在，應記錄頁面狀態並停止，而不是點擊附近看起來相似的元素。
操作後驗證結果狀態。開啟下載選單不等於完成下載。成功提示可能是有用證據，但檔案獲取任務也應確認已取得預期產物。
不要圍繞任意長時間等待來安排工作流。定義等待的狀態與有界逾時。狀態未出現時，報告應指出失敗轉換，並保留適當調查證據。
將瀏覽器工作階段視為敏感應用狀態
已登入瀏覽器可以透過 Cookie 和其他儲存攜帶存取權限。明確分配工作階段，防止一個使用者的任務繼承另一個使用者的已認證狀態。可重用工作階段識別碼，不能證明目前呼叫者有權使用它。
定義登入過期與重新認證的處理。如果入口網站要求重新登入或意外權限授予，自動化不應將其視為允許修改帳戶安全設定。
只保留維運人員需要的截圖與追蹤。它們可能包含帳戶細節、來源文件或工作階段相關材料。為證據儲存設定獨立存取和保留規則，不能假設診斷資料無害。
除了登入，也測試登出與撤銷。應用應知道入口網站帳戶過期或移除如何影響排隊作業與現有工作階段。任務不能僅因另一個帳戶仍登入著，就在那個帳戶下繼續。
驗證下載和提交的產物
對於對帳單作業，將檔案中的供應商、帳戶和期間與任務契約比較。檢查格式，以及內容是否足以完成預期核對。期間錯誤的有效 PDF，仍是失敗任務。
| 證據 | 能夠證明什麼 | 不能證明什麼 |
|---|---|---|
| 預期頁面已載入 | 導航到達可識別狀態 | 已選擇正確記錄 |
| 下載事件 | 檔案傳輸已開始 | 檔案屬於請求帳戶 |
| 已解析檔案後設資料 | 可以檢查帳戶和期間 | 每個業務總計都正確 |
| 目標回執 | 上傳已被接受 | 目標按預期含義應用了內容 |
提交時，識別可以獨立檢查的操作編號或結果記錄。如果點擊提交後瀏覽器丟失回應，在確定目標結果前，不要再次點擊。
保留明確的不確定狀態。尤其當入口網站可能建立重複記錄或作為副作用傳送通知時，這比將每次逾時標為失敗並立即重試更有用。
承諾服務前先測試變化與限制
包含登入過期、標籤改變、多個匹配記錄、下載缺失，以及提交後回應丟失等案例。這些測試展示假設失效時，自動化能否以有用方式停止。
Cloudflare 記錄了 Browser Run 限制 。設計並行處理與逾時的時候，應針對所選方案和整合方式核實限制。不要根據舊教程承諾吞吐量或工作階段壽命。
測試報告應區分入口網站故障、自動化缺陷和應用策略拒絕。每種情況有不同負責人和回應，通用重試按鈕不應成為唯一恢復機制。
網站改變後，應重新執行相關驗收案例，再恢復自動處理。模型找到頁面上的新路徑，並不足以證明該路徑到達相同帳戶、文件或業務結果。
為流程維護編制預算
瀏覽器整合需要有人負責目標介面變化。採購決策應包含這項工作。如果沒人注意指令碼一直下載錯誤報告，最初便宜的指令碼也會變得昂貴。
要求 GBP 估算，指定入口網站、帳戶、任務變體、產物檢查與恢復要求。將初始流程與監控、測試維護和支援分開。說明哪些意外步驟需要交給人工。
| 成本領域 | 方案需要回答的問題 |
|---|---|
| 工作階段處理 | 如何管理登入、過期與帳戶分離？ |
| 導航 | 支援並斷言哪些頁面狀態？ |
| 驗證 | 如何檢查真實產物或目標記錄？ |
| 恢復 | 誰解決不確定提交？ |
| 維護 | 如何檢測並測試入口網站變化？ |
我們可以透過 AI 整合試點 評估 API 與瀏覽器的邊界。請提供入口網站、允許任務及判定完成所需證據，索取瀏覽器自動化方案 。這樣才能交付可支援的工作流，而不只是一連串令人印象深刻的點擊。
常見問題
Browser Run 與 Browser Rendering 是同一服務嗎？ Cloudflare 目前文件將此前名為 Browser Rendering 的服務稱為 Browser Run。使用目前文件並驗證選定整合方式，不要原樣複製舊設定。
存在 API 時還應使用瀏覽器自動化嗎？ 先評估受支援 API。它可能提供更清晰的記錄身分與操作結果。確實需要瀏覽器介面或任務時才使用瀏覽器，並計入頁面和工作階段維護。
AI 模型能修復所有失效選擇器嗎？ 不能。模型可能幫助解釋變化後的頁面，但新導航路徑仍必須滿足任務的帳戶、記錄與結果檢查。無法確認這些事即時應停止。
什麼能證明下載成功？ 取得產物，並驗證帳戶、期間、格式和相關內容符合任務。僅有點擊或下載事件，不能證明正確業務文件已到達。
表單逾時後應該重試嗎？ 先確定目標是否接受。提交成功後仍可能丟失回應。重複可能產生另一次影響的操作前，使用操作編號或檢查結果記錄。
可以重用已登入工作階段嗎？ 只有在明確帳戶隔離與授權設計下才可以。確認工作階段歸屬、哪些任務可使用，以及過期或撤銷後會怎樣。不要意外讓一位使用者的任務繼承另一位使用者權限。
瀏覽器試點應該交付什麼？ 交付受支援流程、帳戶與產物斷言、失敗證據，以及維運恢復流程。除了正常成功路徑，還應包含介面變化與不確定結果。