支持的 API 覆蓋所需字段、動作和權限時，優先用 API。任務需要網頁上的專屬控件或可視檢查時，再用獲准訪問的瀏覽器。MCP 連接器可以封裝任一路徑。先定義最終業務狀態，再選擇接口。
從業務結果開始
寫清記錄 ID、期望狀態、操作權限和事後可讀取的證據。實驗是把一條訂單標為已審核。通過條件是目標訂單正確，狀態為 reviewed，版本為 2。狀態提示或單個 HTTP 響應不足以驗證這三項。
選擇接口和權限
受支持的 API 給調用方提供請求和響應契約。瀏覽器使用授權會話中可見的控件。MCP 讓 Agent 查找並調用有名稱的工具。檢查工具底層調用的是哪條路徑、用的是哪個賬號或服務權限。批准不可逆動作前核對記錄和具體變更。
| 路徑 | 適用情況 | 前提 | 獨立核對 |
|---|---|---|---|
| API | 受支持的接口動作 | 賬號或服務權限 | 讀取記錄和版本 |
| MCP | 工具覆蓋所需動作 | 有名稱的工具契約 · 工具許可和底層權限 | 回讀底層記錄 |
| Browser | 頁面專屬動作或可視證據 | 授權瀏覽器會話 | 重新加載並讀可見狀態 |
MCP Tools · Playwright MCP 入門 · 瀏覽器 Agent
用相同需求測試兩條路徑
API 路徑讀取 API-01 的版本 1 與 ETag，再發條件更新，返回 200。用同一個舊 If-Match 重試得到 412，獨立回讀仍是 reviewed、版本 2。UI 路徑用 Tabbit 打開 UI-01，點擊一次 Mark reviewed 並重新加載。頁面仍顯示 reviewed、版本 2。這些結果來自同一個合成系統。
| 試驗 | 觀察結果 |
|---|---|
| API 寫入 | API-01 · HTTP 200 · reviewed · r2 |
| 舊 If-Match | API-01 · HTTP 412 · reviewed · r2 |
| Tabbit 點擊並重載 | UI-01 · reviewed · r2 |
| 獨立 API 回讀 | UI-01 · reviewed · r2 |
RFC 9110 If-Match · 瀏覽器自動化 · 介面測試
混用時傳遞明確的記錄 ID
批量讀取和獨立核對可用已獲准的 API。瀏覽器只承擔必須從 UI 操作的環節，把同一個記錄 ID 交給下一步。本次獨立 API 回讀 UI-01，與重新加載的頁面一致。沒有獲准的讀接口時，用授權界面重新打開記錄並回讀狀態。
Playwright API testing · 讓 AI Agent 操作瀏覽器 · 接入現有瀏覽器
為變化和失敗留出檢查點
API 依賴接口契約、權限和併發規則。UI 依賴頁面路徑、控件和會話。遇到超時，先查動作是否已經生效。舊版本條件失敗時重新讀取業務狀態，再決定是否重試。按鈕缺失或含義變化時停止。
一位 QA 從業者描述了瀏覽器執行和 API 斷言組合的做法。一位 n8n 用戶把沒有 API 的網頁操作腳本封裝成調用入口。封裝能簡化調用，頁面依賴仍在。 Reddit QA · Reddit n8n
明確甚麼時候算完成
輸出目標 ID、路徑、最終狀態和獨立回讀結果，釋放會話前保存必要回傳結果。日誌不要存憑據和個人數據。若無法核對最終狀態，標記待查，重要的變更交給人確認。
常見問題
甚麼時候優先使用 API？
API 的支持範圍覆蓋授權動作和狀態讀取時優先使用。必須通過頁面完成的環節再走 UI。
MCP 連接器就是 API 嗎？
MCP 把工具暴露給客戶端。工具可封裝服務 API、瀏覽器動作或其他實現。
可以混用 API 和瀏覽器嗎？
可以。用穩定的記錄 ID 銜接，最後獨立回讀業務狀態。
只有 Web UI 的系統可以自動化嗎？
可以在授權賬號內操作獲准控件。提前約定預期狀態，遇到訪問限制時停止。
HTTP 200 能證明業務完成嗎？
在系統允許時，另讀目標記錄和最終業務狀態。
條件更新失敗或超時後怎麼辦？
先讀當前狀態，弄清實際變更後再判斷是否需要重試寫入。