AI Agent 在 2025 年從「會聊天」進化到「會點按鈕」之後，背後跑的是哪一台 Chrome 開始變成正式的工程問題。Anthropic 的 Computer Use、OpenAI 的 Operator、開源的 browser-use 與 Stagehand，這些 framework 共同的前提都是有一個能被 LLM 控制、能維持 session 狀態、能應付網站反爬的瀏覽器執行環境。本機跑 Playwright 寫範例還行，正式服務要服務多個 Agent 並發、保留 cookie、過 Cloudflare 的 challenge，這層基礎建設就得獨立出來。
Browserbase 在 2024 年用 SaaS 模式接管了這個位置，每月訂閱費用按並發 session 計算，定價對個人開發者偏貴。Steel Browser 在 2024 年底由 steel-dev 團隊以 Apache 2.0 釋出，把同一套功能——session 管理、stealth、proxy chain、CDP 控制——做成可以一支 docker run 拉起來的服務。2026 年 3 月的 v0.5.2 把請求追蹤搬到 Chrome Network domain、4 月的 v0.5.3 補上 session lifecycle hook 與 fullscreen mode，自架版本已經穩定到可以放進正式 Agent 工作流。
AI Agent 為什麼不能直接用 Playwright 就好
Playwright 跟 Puppeteer 在 CI/CD 跑 E2E 測試的世界已經是預設選項，但把它直接搬去支撐 Agent 工作流會撞到幾個本質上的不匹配。
第一個是 session 的生命週期。E2E 測試一輪跑完瀏覽器就關，狀態不需要保留；Agent 的場景剛好反過來——使用者半小時前登入了某個 SaaS，現在要求 Agent 接著操作，cookie、localStorage、登入態都得跨多次請求保留。Playwright 的 BrowserContext 是設計給單一進程內用的物件，要做到「Agent 第一次呼叫建立 session，半小時後第二次呼叫接續同一個瀏覽器」就得自己做 session pool、context 持久化、超時回收，這套東西寫起來不複雜，但每個團隊都得從頭刻一遍。
第二個是反偵測。Cloudflare、PerimeterX、DataDome 在 2024 年之後對 headless Chrome 的識別率高得很——navigator.webdriver、CDP runtime detection、字型清單、WebGL renderer 一堆指紋，原生 Playwright 走過 Cloudflare Turnstile 的成功率大約只有兩到三成。社群有 playwright-extra 加 stealth plugin 可以打補丁，但這個生態系本來就有點半維護狀態，新版本的 Chrome 出來後 stealth 規則跟不上是常態。
第三個是 IP 跟 proxy。Agent 工作流常常要訪問跟使用者地理位置一致的網站，住宅代理或 ISP 代理的整合得自己接 API、做 IP 健康度判斷、按請求輪換。這部分沒有開源套件能直接吃下來，多數團隊的做法是寫一坨 middleware 然後祈禱代理供應商的 API 不要改。
把這三件事疊在一起，就會得出「需要一層介於 Playwright 跟 Agent 之間的服務」的結論。Browserbase 看準的是這個位置，Steel 補上的是同一個位置的開源版本。
Steel 跟 Browserbase 拿的是同一塊地
兩個專案的功能對應幾乎是一比一。Browserbase 提供 hosted browser session、stealth、residential proxy、extension 載入、recording；Steel 提供同一組功能，差別在於前者按 session-minute 收費，後者讓使用者自己跑在 VPS 上。
API 設計上 Steel 對齊了業界已經形成的習慣：POST /v1/sessions 建立 session 回傳 connection URL，client 拿這個 URL 用 Playwright 或 Puppeteer 的 connect 模式接上去；session 在伺服器端維持，TTL 預設一小時，可以隨時用 DELETE /v1/sessions/:id 收掉。對於已經寫好 Playwright 程式碼的團隊，遷移成本只是把 chromium.launch() 換成 chromium.connectOverCDP(steelConnectionUrl)，腳本內部的 selector、wait、action 完全不用改。
stealth 是 Steel 比較有差異化的部分。它預設整合 puppeteer-extra-plugin-stealth 的維護分支，把 navigator.webdriver、Chrome runtime、permissions API、WebGL vendor 這些常見指紋打掉；CAPTCHA 的部分內建可以串第三方 solver 服務（2captcha、CapMonster），對於 reCAPTCHA v2 跟 hCaptcha 大致夠用。Cloudflare Turnstile 沒有任何瀏覽器自動化能 100% 過——這是設計上的對抗——但 Steel 的內建配置實測通過率比裸 Playwright 高出一截。
proxy 這層 Steel 做了 BYOP（Bring Your Own Proxy）跟 managed 兩種模式。BYOP 是給 session 設定 proxy URL 就好，managed 則是直接用 Steel 官方的 residential proxy（這部分是雲端版才有的 add-on）。自架的場景大多走 BYOP，把 Bright Data、Oxylabs 或 Soax 的 endpoint 餵進去，IP 輪換交給上游處理。
架構上 Steel 是怎麼運作的
Steel 自架版本拆成兩個容器：API server 跟 UI dashboard，分別是 ghcr.io/steel-dev/steel-browser-api 跟 ghcr.io/steel-dev/steel-browser-ui。Chrome 是內建在 API 容器裡的，不需要另外裝。整套服務暴露三個 port——API 在 3000、UI 在 5173、CDP debugging 在 9223——9223 是 client 拿來連 Chrome DevTools Protocol 的，是整個自架部署最容易設定錯的地方。
session 的生命週期由幾個 hook 控制。v0.5.3 補上的 onSessionStart、onBeforeSessionEnd、onAfterSessionEnd 讓使用者可以在 session 建立時注入 cookie 或 localStorage、在 session 結束前 dump 出狀態做下次續用、在 session 完全收掉後清理外部資源。這套設計把「session 持久化」這件事從應用層搬進服務層，Agent 框架不需要自己管 BrowserContext 的儲存。
請求追蹤從 page event 換成 Chrome 的 Network domain，這是 v0.5.2 的核心變動。差別是後者能完整捕捉到 fetch、XHR、WebSocket、redirect 鏈，前者會漏掉一些非主 frame 的請求。對於需要 inspection 跟 replay 的 Agent debugging 場景，Network domain 是必要的。
資源消耗的數字大致是這樣：閒置一個 Steel API 容器約佔 800 MB 記憶體，每個活躍 session 額外吃 250 到 400 MB；CPU 在 session 沒做密集渲染時幾乎可忽略，碰到複雜 SPA 全力渲染瞬間會把單核打滿幾秒。實務上一台 4 vCPU、8 GB RAM 的 VPS 可以同時跑 8 到 12 個 session，再多就會碰到記憶體跟 swap 的瓶頸。
自架部署的實務細節
最直接的部署是 docker-compose：
1 | services: |
幾個重點。一是 port 一律綁到 127.0.0.1，再透過 SSH tunnel 或反向代理對外，因為 Steel 的 CDP debug port 一旦對公網開啟，等同於讓任何人遠端控制這台機器上的瀏覽器，做什麼都有可能。
二是 shm_size 一定要拉到 2 GB 以上。Chrome 在 /dev/shm 放共享記憶體，Docker 預設只給 64 MB，session 一開分頁就會看到 Tab crashed 或 Cannot allocate memory。
三是 Cloudflare Tunnel、Caddy、Tailscale 任選一個做對外接入點。前面再擺一層 OAuth proxy（oauth2-proxy 或 Pomerium）擋掉未授權的 API 呼叫，避免 API key 一旦外洩等同送人一台無限制的雲端 Chrome。
四是 session 數量上限的調整。Steel 預設沒有硬限制，但實務上得在 application 層加一個 semaphore 控制併發，否則 LLM Agent 偶爾失控狂建 session，記憶體很快就會掛。
對於要打外網的 Agent 工作流，proxy 用 Steel 的 BYOP API 在每個 session 建立時傳入，不要寫死在 Steel 設定檔。原因是不同 Agent 場景需要的 IP 地理位置不同——抓臺灣本地網站要用臺灣 IP、抓美國 SaaS 要用美國住宅 IP——按 session 傳 proxy URL 才能做到動態切換。
跟 browser-use、Stagehand 接起來
Steel 把自己定位成基礎建設層，上面接的 Agent framework 才是處理 LLM 邏輯的地方。最常見的兩個組合是 browser-use 跟 Stagehand。
browser-use 是 Python 生態的開源 Agent framework，58K 星，給 LLM 一段任務描述，它會把 DOM 解析成可被模型理解的格式，輪詢決策、執行 action。預設它會在本機開 Playwright；要接 Steel 只需要把 browser 物件改成 connect_over_cdp 模式指向 Steel 的 connection URL，其他程式碼一行不改。
Stagehand 是 Browserbase 自家推的 TypeScript framework，原生支援 Browserbase 跟 local Playwright 兩種模式，社群有人寫了 connector 讓它接 Steel，但官方支援不直接——這部分要評估是不是值得投入。對於從零開始的專案，直接用 browser-use 加 Steel 更乾淨。
實務上一個典型的部署拓樸是這樣的：應用伺服器跑 Agent framework（Python 或 Node）、Steel API 跟 Chrome 跑在獨立的 VPS、Redis 做 session metadata 跟任務佇列、PostgreSQL 存 Agent 執行紀錄。Agent server 跟 Steel server 之間走內網或 WireGuard，Steel 不對公網直接暴露。這套拓樸在臺灣本地部署的好處是 Agent 跟瀏覽器之間的網路延遲控制在毫秒級，比起 Steel 跑在海外雲再讓 Agent 控制要省下 100 到 200 毫秒的每步往返。
什麼時候 Steel 不是對的選擇
Steel 不是萬靈丹，幾個情境用它反而是過度設計。
純粹的爬蟲——抓固定網站的結構化資料、不需要登入、不需要 stealth——直接用 requests 加 selectolax 就夠快，硬塞 headless Chrome 進來只是讓事情慢十倍。Steel 的價值在於對抗網站防禦跟維持 session 狀態，這兩件事都不需要的場景不該用它。
E2E 測試也不適合。CI 跑測試的本質是隔離、可重複、快速啟動結束，Steel 的 session 模型反而會引入不必要的狀態。Playwright 直接在 CI runner 裡跑就好。
大規模並發（每秒幾百個 session）的場景，Steel 目前的單機架構會撐不住。橫向擴展需要在前面架 load balancer、後面做 session 親和性，這部分官方還沒做出對應的 cluster mode。需要大規模並發的團隊現階段還是會回去買 Browserbase 的 enterprise plan，或自己花時間刻 Kubernetes 編排。
結論
AI Agent 從操作 chat 進化到操作瀏覽器之後，「跑在哪一台 Chrome」會變成 Agent 工作流裡跟 LLM 同等重要的基礎設施問題。Browserbase 把這個位置變成 SaaS 標準答案、Steel 用 Apache 2.0 把同樣的功能拉回自架的選項。對於中型 Agent 專案，自架 Steel 在成本、資料主權、定制空間上都比 SaaS 方案有優勢，前提是團隊願意投入維運。
把 Steel 跟 Agent 服務一起放在臺灣本地有兩個務實的好處：Agent 控制每一步動作的往返延遲壓在毫秒級，配合住宅代理還能讓對外請求看起來來自任意地理位置，兩者之間的內網流量則完全不出國。NCSE Network 在臺灣是方電訊機房提供配備 Intel Gold CPU 與 NVMe SSD 的 VPS 主機，足夠應付 Steel 自架所需的記憶體與 CPU 突發負載，適合作為 Agent 工作流的瀏覽器執行層落腳點。需要把 AI Agent 的瀏覽器基礎建設收回自家手裡的團隊，可以參考 NCSE Network 的 VPS 方案。
