摘要： Browserbase 於 6 月 30 日推出託管服務 Browserbase Agents，把目標描述、結果 schema 和一次 API 呼叫組成瀏覽器任務，不再為每個網站維護一組 selector。每個 run 使用真實 headless browser，採非同步執行並回傳結構化資料，還附即時檢視、回放、追蹤與單次成本。文章提醒 AI 代理的可預測性較低，流程固定或出錯代價高的任務仍可能適合程式化自動化。
以腳本為本的傳統瀏覽器自動化，成本會跟著目標網站一路疊上去：每多一個站，selector、登入流程、重試邏輯就得整套重寫；版面一動，第一個壞掉的幾乎都是 selector，而且往往要等資料斷流才被察覺。Browserbase 於 6 月 30 日推出的 Browserbase Agents，把這條隨站數線性增加的維運負擔，收斂成「講清楚目標、呼叫一次」的託管服務。這裡先把一個數字的範圍講明白：官方宣稱整個平台每月運行 35M+ 個 browser sessions，Ramp、Shopify、Lovable 都列名客戶——指的是 Browserbase 平台整體的量級與客戶背書，而非 Agents 這項產品自己的成績。
Agent 是什麼：一句自然語言加一次 API 呼叫
開一個 agent 不必寫程式：把目標用自然語言講清楚、訂好結果的 schema，接著用一個 API call 讓它動起來。沒有新 framework 要熟悉、沒有部署流程要顧、也沒有瀏覽器環境要養護——整個執行過程都發生在官方的基礎設施上。產品已經 generally available，並且開放給每一個付費層級，評估時可以直接動手測試，不用苦等白名單放行。
運作原理：真實瀏覽器、身分處理與輕量捷徑
真正的 headless browsers 負責所有網站互動，背後是完整平台在撐，並非 DOM 模擬。三項配套決定它能否在真實網站存活：Agent Identity 的任務是幫 agent 突破 anti-bot 系統與 authentication walls——自建方案最難補齊的正是這塊；Search and Fetch 則在開一整個 session 明顯多餘時提供輕量路徑，直接取得 web context 而不必啟動完整瀏覽器；另外 agent 的每個 step 都會留下錄影，事後能一格一格檢查——後文的除錯與信任機制都建立在這之上。
Stagehand 和 Agents 怎麼分工：agent loop 歸誰 host
Browserbase 自己就把這條界線講明白了。Stagehand 是 SDK：agent loop 由你在自家基礎設施上組裝、自己 host，對行為的掌握度最高；Browserbase Agents 走的是全託管路線，官方以 nothing to host 形容——你交出目標描述、他們把 agent 跑完、結構化結果交回你手上。兩者站在同一條平台光譜的兩端，是互補而非取代：想深入客製 agent loop 的內部行為就選 Stagehand，想最快把長尾任務跑起來就選 Agents。
Runs 的執行方式：非同步進行、結構化回傳
Runs 採非同步設計：送出後不卡住請求，等跑完再回頭查結果。每個 run 都按你定義的 result schema 回傳 structured、typed data，拿到就能進系統、不必再解析清洗——這讓 browser agent 從「產出一段文字」躍升為「產出能直接寫進資料庫的欄位」。導航完全交給 agent 自行判斷：面對不同網站自己決定怎麼走，能夠消化 layout 差異，也懂得處理 per-site quirks。這正是它取代 per-site scripts 的關鍵機制：適應能力來自模型本身，而不是你預先鋪好的每一條固定路線。
透明度與 Optimize：把信任做進設計裡
全託管不代表變成黑箱。每個 run 都附帶 live view（agent 動作當下即時觀看）、Session Replay（事後逐格回放）、涵蓋 model 與 tool calls 的 traces，以及 per-run cost breakdown。agent 在某個網站出了差錯，你能回看它實際按了哪些東西，而不是只收到一句「任務失敗」。Optimize 則讓 agent 用得越久表現越好，官方給出三個方向：Make faster 藉減少步驟來加快速度、壓低成本；Debug 修掉錯誤行為；Refactor 伴隨任務成長重構 agent，守住可靠性。官方並把這條路的終點指向 Autobrowse 研究——靠著大量使用不斷讓自己變強的 agent。
應用場景：價值落在長尾
官方列出的應用有共同輪廓：站點數量龐大、每一個長相都不同、單獨為任何一個站寫 script 都不划算。Monitoring 盯著價格與競品變動；KYC 與 KYB 得一一穿越各家的入口網站；document retrieval 要找出 SOC 2 報告與授權表格；automated QA 支援正處於 scaling 階段的產品團隊；而最吃重的案例，要橫越 1,500+ 個 county 與 state 層級的政府網站，把稅務文件與 property records 收集回來。官方的量化說法是一個 agent 能涵蓋過去得靠 200 個 scripts 才能處理的 portals——話說得像行銷，但方向沒錯：價值藏在長尾，而不是任何一座大型網站。
限制與代價
用 AI agent 取代確定性的 script，犧牲掉的是可預測性。流程固定、頁面穩定、出錯代價高的任務，程式化自動化依舊更省錢、也更容易驗證；同一個 agent 跑同一個網站，兩次走的路可能不一樣，失敗時也不再像 selector 壞掉那樣容易預判。非同步模式則把複雜度丟回你的產品端：job 狀態、timeout、retry、重複送出，全都要自己設計。可觀測性能壓低風險，卻無法歸零——登入、送出表單、修改帳戶資料這類操作仍應限縮權限，敏感動作拆成草擬加確認兩段處理，而各網站的服務條款、rate limits、個人資料處理都得列為設計輸入，不能事後再補。
給 Builder 的起步路線：先做長尾讀取
最穩當的切入點是跨多個網站的唯讀資料收集，而非不可逆的操作。動手前先量化四個指標：成功率、每一站的延遲、需要人工介入的頻率，以及單次執行成本；先挑一個「以往 per-script 成本太高、索性整個跳過」的 portal 來驗證，再把既有的 scripts 逐步搬過來。定價門檻低到可以直接做實驗，各方案每月內含的 agent runs 如下：
| Plan | 每月內含的 agent runs |
|---|---|
| Free | 3 |
| Developer | 15 |
| Startup | 50 |
| Enterprise | Custom |