Steel Browser：把 Chrome 打包成 HTTP API 的取捨
🔥 Open Source Browser API for AI Agents & Apps. Steel Browser is a batteries-included browser sandbox that lets you automate the web without worrying about infrastructure.
秒懂
- 它是什麼？
- Steel Browser 用 Docker 把 Puppeteer、CDP 與 session 管理包成一個 HTTP 服務，讓 AI agent 用 URL 換取瀏覽器能力。它省下的是基礎設施，付出的是對瀏覽器細節的控制權。
- 適合誰用？
- 如果你要的是多人共用、需要 session 保存與代理輪換的瀏覽器後端，Steel 的 Docker 鏡像與 REST 介面能省下不少樣板程式；如果你的流程需要精細控制 CDP 事件、自訂啟動參數或非 Chrome 核心，直接寫 Playwright 腳本會更省事。導入前先確認三件事：README 明列的三個 Chrome 執行檔路徑在你的環境是否存在，或改用 CHROME_EXECUTABLE_PATH 指定；你的部署平台是否支援它開放的 3000 與 9223 兩個埠；以及 v0.5.x 仍標示為 beta，你能否接受 API 在升版時變動。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 13 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Steel 想解決的是瀏覽器基礎設施，不是爬蟲邏輯
多數團隊寫瀏覽器自動化的順序是這樣：先寫一支 Playwright 腳本，跑得動之後才發現需要保存登入狀態，於是加 cookie 匯出；接著發現同一台機器開太多 Chrome 會爆記憶體，於是加一個程序池；再來是網站開始封 IP，於是接上代理。這些工作跟你要解決的業務問題無關，但每一項都得做。Steel 的定位就是把這一段抽出來。README 的說明是它「manages sessions, pages, and browser processes」，讓開發者不必從零建置自動化基礎設施。
它的目標使用者寫得很明確：AI agent 與 AI 應用。這類專案通常由模型決定下一步要開哪個網址、點哪個元素，執行端需要的是一個穩定的遠端瀏覽器，而不是一份精心調校的腳本。Steel 因此把操作面收斂成 HTTP 端點，呼叫端只要能發請求就能開一個 session。附帶的工具函式也順著這個方向設計：把頁面轉成 markdown、readability、截圖或 PDF，這些正是餵給 LLM 之前的常見前處理。
反過來說，如果你的需求是每天固定跑同一套流程、頁面結構穩定、也不需要保存登入狀態，那 Steel 提供的大部分能力你都不會用到，多一層 HTTP 只是多一個故障點。
Session 是核心抽象，CDP 是底層通道
從 README 能確認的架構分層大致是這樣：最底層是 Chrome 實例，透過 Puppeteer 與 Chrome DevTools Protocol 控制；往上一層是 session 與 page 的管理，負責保存瀏覽器狀態、cookies 與 local storage，並處理生命週期與自動清理；最上層是 HTTP API 與一個除錯 UI。官方文件把 Swagger 介面放在 http://0.0.0.0:3000/documentation，也就是說 API 的完整形狀以那份規格為準，而不是 README。
這個分層的關鍵在於 session 跨越了單次請求。一般寫 Puppeteer 腳本時，瀏覽器實例跟腳本生命週期綁在一起，腳本結束瀏覽器就關掉。Steel 把 session 變成一個有名字、可重複存取的資源，呼叫端先建立 session，再對它下指令，中間的登入狀態會留著。對 agent 而言這很實際：模型可能分好幾輪才完成一個任務，中間不該重新登入。
連線方式也值得注意。README 說它「allowing you to connect using Puppeteer, Playwright, or Selenium」，並開放 9223 埠作為 console debugger。這意味著你可以只用 HTTP API，也可以繞過它、用自己熟悉的函式庫直接接管瀏覽器。第二條路在除錯時很有用，因為 HTTP 抽象層看不到的細節可以直接從 CDP 檢查。代價是你得自己管連線與清理，等於放棄了 session 管理那層。
部署路徑有三條，選錯會多花半天
README 給的選項其實對應三種不同的使用情境。最省事的是直接用預建的映像檔：docker run -p 3000:3000 -p 9223:9223 ghcr.io/steel-dev/steel-browser。跑起來後 API 在 3000，UI 在 http://localhost:3000/ui。這條路適合先驗證功能，不適合改程式。
第二條是把 API 與 UI 分開跑，指令是 docker compose up。Mac Silicon 使用者需要額外帶平台參數：DOCKER_DEFAULT_PLATFORM=linux/arm64 docker compose up。這點 README 有明講，沒帶的話映像檔平台不符會直接失敗。
第三條是貢獻者路徑，差別在於用的是 docker-compose.dev.yml 而非預設檔，而且必須加 --build 讓每次修改都重建映像檔：docker compose -f docker-compose.dev.yml up --build。這條路會從 api 與 ui 兩個目錄建置，服務埠也換成 3000 與 5173。若你的主機不是 localhost，README 要求建立 .env 檔，變數清單指向 docs/DEVELOPMENT_SETUP.md，或直接改 docker-compose.dev.yml 裡的環境變數。
不想用 Docker 的話，裝好 Node.js 與 Chrome 之後執行 npm install 再 npm run dev 也可以，同樣是 3000 加 5173。這裡有個容易踩的點：Steel 會去固定路徑找 Chrome，Linux 是 /usr/bin/google-chrome，macOS 是 /Applications/Google Chrome.app/Contents/MacOS/Google Chrome，Windows 則有兩個候選路徑。路徑不符就得設 CHROME_EXECUTABLE_PATH，例如 export CHROME_EXECUTABLE_PATH=/path/to/your/chrome 之後再 npm run dev。README 指出判斷邏輯在 api/src/utils/browser.ts，遇到找不到瀏覽器的錯誤時，那個檔案比文件更值得先看。
反偵測與代理輪換是賣點，也是黑箱
README 列出的能力裡，比較需要讀者自己判斷的是兩項：內建代理鏈管理以支援 IP 輪換，以及 stealth 外掛與指紋管理。這兩項在實務上通常是專案的成敗關鍵，網站封鎖與否直接決定流程能不能跑完。
問題在於，README 只給了能力名稱，沒有說明指紋是怎麼生成、代理鏈的失敗處理怎麼運作、輪換的粒度是每個 session 還是每個請求。這些細節決定了它在真實站點上的表現，而它們不在這份材料裡。我不會替它補上「效果很好」之類的評語，因為沒有可查證的依據。可以確定的是，只要依賴反偵測，就等於把流程的穩定性綁在一個會持續變動的對抗面上：網站改偵測方式，你的流程就可能失效，而這與 Steel 本身的程式碼品質無關。
另一個要留意的設計取向是「batteries-included」。預設值幫你決定了指紋、代理與瀏覽器參數，好處是開箱可用，代價是當你需要偏離預設值時，得先弄清楚預設值是什麼。對照組是直接寫 Puppeteer 腳本：所有參數都在你手上，但每一項也都要你自己調。
什麼情況下不該用它
第一種情況是規模很小。如果你只是要每天抓幾個頁面，Docker 映像檔、API 服務、session 管理這三層都是額外成本，一支幾十行的 Playwright 腳本加上排程就夠了。多一層服務意味著多一個要監控、要更新、要處理埠衝突的東西。
第二種是需要非 Chrome 核心。README 通篇圍繞 Chrome，環境變數名稱也是 CHROME_EXECUTABLE_PATH，文件沒有提到 Firefox 或 WebKit 的支援。若你的測試矩陣要求跨瀏覽器引擎，這個專案對不上。
第三種是需要精細控制瀏覽器啟動流程。Steel 幫你決定何時開瀏覽器、何時清理，這在多數情況是優點，但當你要掛自訂的 CDP 攔截、要在特定時機注入腳本、或要重現某個特定的啟動參數組合時，這層抽象會擋在中間。README 提到可載入自訂 Chrome 擴充功能，這是個出口，但不是所有需求都能用擴充功能表達。
最後是版本穩定性。最近的發布是 v0.5.4-beta，前兩版分別是 v0.5.3-beta 與 v0.5.2-beta，全部帶 beta 標記。README 自己也寫著「Steel is in public beta and evolving every day」。把這樣一個 API 放進正式產品的關鍵路徑，等於接受介面在升版時可能變動。這不是缺點，只是要誠實面對的取捨。
跟直接寫 Playwright 的差別在哪裡
最直接的替代方案不是另一個瀏覽器 API，而是 Playwright 或 Puppeteer 本身。差別不在能不能做到，而在誰負責狀態與生命週期。
用 Playwright 時，瀏覽器實例活在你的程式裡，狀態存在你的程式裡，清理也由你負責。要跨請求保存登入狀態，你得自己匯出 storageState 並在下次啟動時載入。要同時跑多個任務，你得自己寫池化邏輯。Steel 把這些變成服務端職責：session 是伺服器上的資源，你的程式只需要記住一個識別碼。
這個差別在單一腳本裡看不出來，在 agent 場景裡就明顯了。Agent 的執行是間歇性的，可能等模型回應幾十秒才繼續下一步，把瀏覽器留在你的程式裡佔記憶體不太划算，交給一個專門的服務管理比較合理。反過來說，如果你的流程是連續的、一次跑完的，Playwright 少一層網路往返，除錯時堆疊追蹤也完整得多。
另一個實際差異是語言綁定。Playwright 有 Python、Java、.NET 等官方綁定，Steel 主要語言是 TypeScript，對外介面是 HTTP。理論上任何語言都能呼叫 HTTP，但型別安全與範例資源會集中在 TypeScript 生態。
授權與維護成本
授權是 Apache-2.0，屬於寬鬆授權，允許商業使用、修改與再散布，通常也包含專利授權條款。具體條文與你所在司法管轄區的適用方式，仍應由法務確認，這裡不做法律判斷。
維護成本有幾個可觀察的來源。映像檔基底與 Chrome 版本會持續更新，而 Chrome 的更新頻率不低，這意味著你不能只部署一次就放著。若你使用反偵測功能，網站端的偵測變化會迫使你跟著調整，這部分的維護節奏由外部決定。
升版成本則取決於你依賴多少 API 表面。專案的發布仍帶 beta 標記，README 也說每天都在演進，因此升級前應該先讀 release notes 再對照你的呼叫點。如果只用到建立 session 與抓取頁面這類核心端點，衝擊面通常比用到代理鏈或指紋設定來得小。
貢獻者路徑的開發體驗 README 交代得算清楚，但要注意它要求每次修改都加 --build 重建映像檔，這個循環比單純的熱重載慢，日常開發要有心理準備。
編輯結論
如果你要的是多人共用、需要 session 保存與代理輪換的瀏覽器後端，Steel 的 Docker 鏡像與 REST 介面能省下不少樣板程式；如果你的流程需要精細控制 CDP 事件、自訂啟動參數或非 Chrome 核心，直接寫 Playwright 腳本會更省事。導入前先確認三件事：README 明列的三個 Chrome 執行檔路徑在你的環境是否存在，或改用 CHROME_EXECUTABLE_PATH 指定；你的部署平台是否支援它開放的 3000 與 9223 兩個埠；以及 v0.5.x 仍標示為 beta，你能否接受 API 在升版時變動。
社群筆記