Browser 不是標配
每次在規劃 agent workflow 的時候，我都有一個習慣，先問：這個資料有沒有結構化的入口？
這個問題很無聊，但它決定了後面 80% 的事。
很多 PM 在設計 agent 功能的時候，預設 web access 等於 browser automation，邏輯聽起來合理，人類上網就是靠瀏覽器。但這個直覺用在 agent 身上，實際上是在把成本、穩定性、驗證三件事同時做爛。
數字先說清楚
有一組 flight search 的對照測試比較了三種資料獲取方式。Structured API 5/5 成功，每次 $0.49，花 141 秒。Web search + extraction 0/5 成功，$0.96，451 秒。Browser automation 0/5 成功，$1.53，457 秒，而且 34% 的 tool call 都在截圖。
Browser automation 成本是 API 的三倍，成功率是 0。Agent 三分之一的精力在「看畫面」。這不是測試設計問題，是 browser automation 的本質，它在模擬人類，所以繼承了人類看畫面的那些步驟。
成本不一樣，failure 模式也不一樣
三種方式最大的差異不是速度，是 error surface 的大小。
Structured API 的失敗是可預測的。打錯參數、rate limit、token 失效，每一種失敗都有清晰的邊界，你可以設計 retry，可以驗證輸出是不是對的。
Web extraction 的失敗是隱性的。頁面改版、selector 壞掉、反爬蟲機制，你有時候根本不知道自己失敗了，agent 可能拿到一半的資料繼續往下跑，輸出一個「看起來有結果」的東西。PM 在 demo 裡覺得 OK，但那是假成功。
Browser automation 面對最動態的 UI 環境，試圖提取結構化資訊，每一次 UI 改動都是潛在的破壞，34% 截圖就是 agent 在確認「畫面上到底發生了什麼」，必要但代價高。
什麼時候才值得上 browser
我的判斷框架大概是：有 API 或有第三方結構化資料的，先走那條路。資料只在網頁上、沒有 API，或任務本身是互動操作而不只是取資料，才考慮 browser automation。
大部分 agent 功能的早期規劃，值得先花一天確認「有沒有結構化入口」再決定技術路徑。這不是在幫工程師做技術選型，是 PM 該做的 risk surface 評估。
需求階段就要問清楚的三件事
更根本的問題是：「可驗證、可重試、可結構化」這三個條件應該是需求，不是實作細節。
以前我寫 spec 的時候，「系統要穩定」太抽象了。現在我直接問三件事：這個資料有沒有 schema 可以驗證結果？失敗的時候有辦法 retry 嗎？成功和失敗有沒有辦法被明確判斷？三個答案都是不確定，這個 agent 功能就不應該進 sprint，不管 demo 看起來多炫。
Browser automation 在對的 use case 下就是最好的選項。問題是很多時候我們選它，不是因為它最合適，而是因為它看起來最直觀。
那個直觀感，很貴。
作者：MingTech