如何打造能在整個網路上運作的金融代理——Browserbase 的 Jay Sahnan 與 Arik Bird

Browserbase 的 Jay Sahnan 與 Arik Bird 主張，Ramp、Bill、Stripe 這類金融機構若要自動化網路上最難觸及的部分——登入才能進入的入口網站、有防機器人保護的供應商網站、州務卿（Secretary of State）的 KYC 查核——唯一可行的做法，是在為規模化而建的基礎設施上執行瀏覽器代理（browser agent），而不是多僱人手，也不是寫一堆脆弱的 Playwright 指令碼。19 分鐘的內容大半是產品實機展示：一次啟動 100 個託管瀏覽器、讓觀眾透過 QR code 操作其中一個，並從 SEC、投資人關係網站與 NYSE 等來源擷取 Chipotle、JPMorgan、Goldman Sachs 的結構化資料。「金融代理」這個框架確有其事，但著墨不深——Ramp、Bill、Stripe 三段公司案例，主要只是為後半段關於 Chromium 指紋與 Stagehand SDK 的技術論述鋪路。

Sahnan 與 Bird 是 Browserbase 的員工，因此他們談到 Ramp 省下多少工時、Bill 的入口網站難題、Stripe 的 KYC 流程，本質上是廠商對客戶使用情境的自述，並非經獨立驗證的數字。讀者讀完應該帶走三件事：為什麼資料中心裡的原版 Chromium 二進位檔會被偵測出來，以及 Browserbase 改了什麼來解決；Stagehand 的 act／extract／observe 三個基本操作，加上 DOM 精簡，如何讓 Token 成本比直接餵原始 HTML 降低約 30 倍；以及這場展示從哪裡開始不再是展示——防機器人的軍備競賽、驗證碼破解，還有「單一代理能吸收數千個結構各異的入口網站」這個假設。

資料中心裡的原版 Chromium 一看就是可偵測的訪客，所以 Browserbase 自己 fork 了一份

Bird 的核心技術論點是：瀏覽器是每個代理都需要的工具，因為最重要的那些網站——藏在登入後面的入口網站、沒有 API 也沒有 MCP 的網站——只能透過瀏覽器觸及。問題出在把瀏覽器搬離筆電之後。在你自己的機器上，Chromium 呈現的指紋是一致的：瀏覽器版本、作業系統、字型、螢幕尺寸、時區、cookie、登入紀錄，以及住宅網路的信譽。把同一個二進位檔放進 EC2 執行個體，每次啟動都會產生全新指紋、空的 cookie、被迫重新登入，外加一個資料中心 IP。Bird 說，代理（proxy）可以掩蓋位置、減少驗證碼，但改變不了底層的 Chromium 訊號。

Browserbase 的解法是自己 fork Chromium，為自家資料中心推出「已驗證瀏覽器」（verified browser）。Bird 點出三項改動：移除自動化旗標（把 webdriver = true 全面改成 false）、對齊身分識別讓瀏覽器回報為「Chrome」而非「headless Chrome」、讓行程持續存活——Chromium 保持執行、只關視窗，而不是每做完一個任務就把瀏覽器砍掉。他強調這些都不是簡單的修改，因為 Chromium 每兩週就出一次新版，這也正是公司必須自己維護一份建置版本的原因。

Ramp 用瀏覽器代理取代人工催收據，聲稱省下 3 萬小時

Sahnan 的第一個案例是 Ramp，他說 Browserbase 團隊本身就把 Ramp 當客戶在用。Ramp 規模擴大後，需要從愈來愈多難以觸及的入口網站取得收據。最初的解法是養一批人登入各入口網站抓收據——Sahnan 說，這在 A 輪、B 輪的規模還行得通，但到了 Ramp 這種量級就成了瓶頸。換成瀏覽器代理之後的流程是這樣：用 Ramp 卡消費會觸發一個代理，由它登入商家網站（Sahnan 舉的例子是訂了研討會機票後的 Delta），擷取收據，再與交易紀錄比對。照 Sahnan 的說法，Ramp 因此省下超過 3 萬小時的人工資料輸入，規模成長了 5 倍。這些數字是廠商的說法，節目中並未提供出處。

Bill 的難題：一個代理要面對數千個長相各異的入口網站

第二個案例是 Bill，Sahnan 說它要處理數千家供應商的付款。每個供應商入口網站的結帳流程不同、欄位不同，介面還會變，因此 Bill 曾判定代理自動化不可行，改派真人代替客戶點進各入口網站操作。Sahnan 提出的重新框架是「一個代理，數千個不同的入口網站」——同一個代理去適應每個網站，而不是為每個供應商寫專屬指令碼。節目正是在這裡從「存取」轉向「控制」，也是 Stagehand 登場的地方。

頁面一變 Playwright 就掛，Stagehand 在其上加了自然語言控制

Bird 把 Stagehand 定位成架在 Playwright 之上的開源 SDK：page.click 這類確定性呼叫照樣可用，但遇到複雜步驟時，你可以下自然語言指令（「填寫這張表單」、「找到紅色按鈕」）。Stagehand 會把 DOM 與無障礙樹（accessibility tree）交給 LLM 或代理，由它判斷該點哪裡。它要對付的失效模式是選擇器脆弱性——按鈕位置一移，或標籤從「first name」改成「name」，手寫的 Playwright 指令碼就壞了；這對一次性的本機任務還可接受，但對 Ramp 或 Bill 這種量級的公司行不通。

成本論證是整場演講中最銳利的數字。Bird 展示一組對照：把原始 HTML 直接餵給代理，大約要 12.2 萬個 Token；Stagehand 以無障礙樹精簡後，同一個頁面只送約 4,000 個 Token，而且直接回傳選擇器。上下文大約縮減 30 倍，花費與延遲也跟著下降。第二個延遲解法屬於架構層面：Browserbase 把 Stagehand 以 Chrome 擴充功能的形式，跑在託管瀏覽器旁邊，因此執行動作時不必在資料中心與代理之間來回傳送 HTML。

「如果你用代理搭配 Playwright，左邊那些全部都要送出去，那是 12.2 萬個 Token，而且還是原始 HTML。」——Arik Bird

Bird 點出開發者常用的三個基本操作：observe（找到「learn more」按鈕）、act（點選登入按鈕）、extract（把資料抽進 Zod schema）。他說自己最愛 extract，因為它能把雜亂無結構的網頁資料，變成代理可直接取用的有型別、可讀輸出。

flowchart TD
    A["代理發出自然語言指令"] --> B["Stagehand 在託管瀏覽器上執行（Chrome 擴充功能）"]
    B --> C["DOM 與無障礙樹精簡至約 4k Token"]
    C --> D["LLM 選定元素並回傳直接選擇器"]
    D --> E["在 Browserbase 瀏覽器中執行動作"]
    E --> F["擷取進 Zod schema"]
    F --> G["結構化資料回傳給代理"]

Stripe 的 KYC 查核，原本靠人工造訪州務卿入口網站

第三段案例是 Stripe。Sahnan 說 Stripe 每期要讓數萬家商家上線，必須逐一驗證每家企業真實存在。在瀏覽器代理出現之前，這意味著一批人得透過瀏覽器造訪州務卿入口網站把資料抓出來。他提出的替代方案，是讓瀏覽器代理執行 KYC 驗證。和 Ramp、Bill 一樣，這裡的細節很薄——沒有指標、沒有具名的流程負責人——而且這是 Sahnan 對 Stripe 營運方式的描述，並非 Stripe 在此現身說法。

實機展示證明託管瀏覽器真能規模化運作，但仍有保留

Bird 跑了一連串展示，證明這些瀏覽器是真的、而且可受控。他啟動一個瀏覽器並顯示即時 iframe 畫面，接著同時啟動 100 個、分散在不同網站。觀眾掃 QR code 後，會隨機分到這 100 個之中的一個，透過 iframe 在裡面點選、移動。他坦承整套設定很倉促，而且是透過他筆電上的 ngrok 通道、跑在訊號很差的研討會 Wi-Fi 上。

資料展示則層層加碼：Stagehand 先從 Chipotle 網站擷取它賣什麼（輸出顯示 Chipotle Mexican Grill 以及 chips 等選單品項）；接著同一段程式碼針對 Chipotle 查四個來源——公司官網、投資人頁面、SEC 申報檔案、NYSE 掛牌資訊；再擴大到 20 家公司、同樣三個來源，JPMorgan 與 Goldman Sachs 都與 Chipotle 並列出現。Bird 說明即時畫面會落後實際執行，主要供開發使用，不是用來跑正式的大規模任務。他也說已驗證瀏覽器代表驗證碼出現得更少，而真的出現時 Browserbase 會代為破解。他提供一段可從 Browserbase 官網複製貼上的提示詞供入門使用，並提到自己先前做過一個 SEC 擷取範本。

這場演講留下的未解問題

整場的主線是：規模與控制是兩個不同的問題，需要兩套不同的解法——fork 過的 Chromium 加上託管基礎設施解決存取，Stagehand 解決適應性與成本。真正未解的張力，就是防機器人軍備競賽本身。Bird 自己說 Chromium 每兩週改版一次，這意味著 fork 必須持續維護；而破解驗證碼的說法只是點到為止，沒說怎麼做、成本多少。客戶數字——3 萬小時、5 倍規模——出自廠商，需要獨立佐證。最值得持續觀察的，是「一個代理、數千個入口網站」這套模式，在入口網站介面持續漂移之下還站不站得住腳；因為那正是 Stagehand 被打造來吸收的失效模式，也是最可能在正式環境中浮現的問題。