傳統瀏覽器自動化的成本結構很殘酷：每新增一個目標網站，就要再寫一支 script，selector、登入處理、retry 全部重來一次；版面一改，最先壞的永遠是 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 的分工：誰來 host agent loop
Browserbase 自己把界線畫得很清楚。Stagehand 是 SDK：你在自家基礎設施上組裝並 host agent loop，對行為的控制力最大；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 隨任務成長重構以維持可靠。官方把這條線的終點指向 Autobrowse 研究——隨使用大量自我改進的 agent。
實際場景：長尾才是主戰場
官方列舉的場景有一個共同形狀：網站數量多、彼此長得都不一樣、逐一寫 script 不划算。Monitoring 追蹤價格與競品變動、KYC 與 KYB 穿越各家入口網站、document retrieval 找 SOC 2 報告與授權表格、automated QA 支援 scaling 中的產品團隊，以及最硬的例子：跨 1,500+ 個 county 與 state 政府網站抓稅務文件與 property records。官方的量化說法是一個 agent 涵蓋原本需要 200 個 scripts 的 portals——這是行銷級表述，但方向正確：價值在長尾，不在任何單一大站。
取捨與限制
把確定性 script 換成 AI agent，代價是可預測性。固定流程、頁面穩定、錯誤成本高的任務，程式化自動化仍然更便宜、更容易驗證；同一個 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 |
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。