BrowserOS 評測：把登入狀態交給 AI 代理的開源瀏覽器，值得嗎？

它解決什麼問題：代理的登入障礙

多數 AI 代理工具在瀏覽器自動化上遇到的最大障礙，是它們啟動的瀏覽器實例沒有你的登入狀態。Playwright 或 agent-browser 會開啟全新的 Chrome 子程序，裡面沒有你的 Gmail、LinkedIn 或 CRM 憑證。對 CI 測試來說這沒問題，但對「幫我讀收件匣」或「更新 CRM」這類真實工作，代理就卡在登入牆前。BrowserOS 的 neo 產品直接針對這個痛點：它是一個次要瀏覽器，與 Chrome 並存，讓你把 Chrome 的登入、書籤與擴充功能一次匯入。代理在另一個分頁中操作這些已登入的帳號，就像你親自操作一樣。這個設計的目標使用者很明確：已經付費使用 Claude Code、Codex、Cursor 等代理工具，卻苦於無法讓代理碰自己真實帳號的人。它不是給喜歡從零開始的測試工程師，而是給想讓代理接手日常網路雜務的實際工作者。

neo 與主瀏覽器的雙軌架構

README 揭露了這個專案其實包含兩個產品。第一個是 BrowserOS neo，描述為「給代理用的瀏覽器」，它匯入你的登入，讓代理在獨立分頁中平行執行，並提供即時儀表板與可回放的工作階段。第二個是 BrowserOS 本身，一個 Chromium 分支，內建代理於每個新分頁，支援超過 20 個內建工具與 40 個應用整合，並可搭配 Ollama 在本機執行模型。這兩個產品共用同一個儲存庫，但定位不同：neo 是輔助瀏覽器，不是 Chrome 的替代品；而主 BrowserOS 則試圖成為日常瀏覽器。這種雙軌架構容易造成混淆，因為名稱相近，但功能與使用情境差異很大。從資料夾結構推測，`packages/browseros` 下分別有 `browserclaw` 與 `browseros` 的資源目錄，暗示兩者確實是分開的實作。若你只想用 neo，可能不需要接觸主瀏覽器的程式碼，但下載與安裝時仍需注意選擇正確的版本。

實際運作機制：本機代理與 MCP 連接

neo 的運作依賴於 MCP（Model Context Protocol）連接。README 提到它會自動連接各種代理框架，包括 Claude Code、Codex、Cursor、VS Code、OpenClaw 與 Hermes，並提供一鍵連接的 MCP 安裝面板。這代表 neo 不是獨立的代理，而是代理的工具供應者：你的 Claude Code 或 Codex 透過 MCP 呼叫 neo 提供的瀏覽器工具，而 neo 負責實際的網頁操作。每個代理在獨立分頁中執行，你可以即時觀看，或事後重播整個過程。重播功能將每個工作階段儲存為可拖曳的影片，並附帶逐步動作時間軸。這些資料儲存在本機的 `~/.browserclaw/` 目錄下，包括工作階段、螢幕截圖與歷史記錄，不會上傳到雲端。這個設計有兩個含義：其一，代理的動作可被稽核，這對需要追蹤自動化行為的場合有價值；其二，所有運算都在本機，隱私風險較低，但也代表你需要有足夠的磁碟空間來存放這些影片與記錄。

安裝與開始使用：真實指令與步驟

根據 README，安裝 neo 的方式是下載 macOS 的 DMG 或 Windows 的安裝程式，網址分別是 `https://cdn.browseros.com/download/BrowserOS_neo.dmg` 與 `https://cdn.browseros.com/download/BrowserOS_neo_installer.exe`。安裝後，第一步是從 Chrome 一鍵匯入登入、書籤與擴充功能。第二步，neo 會自動偵測你已安裝的代理工具，如 Claude Code 或 Codex，並提供一鍵連接。第三步，你從代理端給出任務，例如「訂最便宜的倫敦機票」，然後在新分頁中觀看代理執行。這個流程強調「一鍵」，但實際的依賴是：你必須已經安裝並設定好支援 MCP 的代理工具。如果你使用的是 Ollama 這類本機模型，README 提到主 BrowserOS 支援，但未明確說明 neo 是否也支援 Ollama。從描述推測，neo 可能依賴外部代理框架，而不是內建模型。這意味著，若你沒有任何 MCP 代理，neo 可能無法獨立運作。安裝前最好確認你的代理工具清單是否在支援之列。

授權與維護成本：AGPL 的雙面刃

BrowserOS 採用 AGPL-3.0 授權。這對開源使用者是好事，代表你可以檢視與修改程式碼，但對商業整合有嚴格限制：若你將修改後的版本作為網路服務提供，必須公開原始碼。這對內部工具影響不大，但對想將 BrowserOS 整合進付費產品或 SaaS 的團隊，可能是重大障礙。維護成本方面，專案更新頻繁，最近的釋出記錄顯示 `agent-server` 在兩天內從 v0.0.161 更新到 v0.0.162，`ext-agent` 也有獨立版本 v0.0.154.0。這代表元件版本各自獨立，你可能需要追蹤多個套件的更新。由於它是 Chromium 分支，上游 Chromium 的安全更新必須持續合併，這是一筆長期的維護負擔。若你只是使用者而非貢獻者，這些更新會透過安裝程式提供，但若你自行編譯或修改，就得承擔合併上游的責任。文件提到資料儲存在 `~/.browserclaw/`，但沒有說明升級時是否會保留或遷移這些資料，這在升級前值得確認。

限制與不適用的場景

README 明確指出 neo 不是 Chrome 的替代品，而是次要瀏覽器。這意味著，若你期望它成為日常主要瀏覽器，可能會失望。更關鍵的限制是，它依賴本機代理框架，若你使用的代理不支援 MCP，或你根本不用代理，neo 就沒有用途。此外，它強調使用真實登入狀態，這帶來安全風險：代理有權操作你的真實帳號，若任務指令錯誤或代理誤判，可能造成不可預期的後果，例如誤刪郵件或發布錯誤內容。雖然有重播功能可事後稽核，但無法即時阻止。另一個限制是，它對抗雲端瀏覽器（如 browser-use 或 browserbase）的論點是「本機 IP 不會被封鎖」，但這假設你的本機 IP 沒有被網站封鎖。若你使用 VPN 或公司網路，可能同樣觸發反機器人機制。最後，README 宣稱它比 Claude 的 Chrome 擴充功能消耗更少 token，但沒有提供具體數據或方法論，這點需要自行驗證。

替代方案的真實差異

README 直接比較了三類替代方案。第一類是無頭驅動器，如 Playwright 與 agent-browser，它們啟動全新的 Chrome 子程序，沒有登入狀態，適合 CI 但不適合需要真實帳號的任務。第二類是雲端瀏覽器，如 browser-use 與 browserbase，它們在資料中心執行，登入困難且容易被 Twitter 或 LinkedIn 封鎖，因為資料中心 IP 信譽差。第三類是封閉的 AI 瀏覽器，如 ChatGPT Atlas、Perplexity Comet 與 Dia，這些服務綁定自己的 AI 模型，無法與你既有的代理工具整合。BrowserOS 的定位是第四條路：本機執行、保留登入、與外部代理整合。這個差異是實質的：Playwright 給你控制但沒有狀態，雲端瀏覽器給你狀態但 IP 受限，Atlas 給你整合但綁定生態。BrowserOS 試圖同時解決狀態與整合問題，但代價是你必須自己管理代理與瀏覽器的連線。若你只需要偶爾抓取公開網頁，Playwright 的輕量與無狀態反而是優點；若你需要跨裝置同步，雲端瀏覽器可能更適合。

編輯結論

BrowserOS 適合那些已經使用 Claude Code、Codex 或 Cursor，且需要代理操作真實登入帳號的開發者或自動化工作者。它不適合需要無狀態、可重現測試環境的 CI 場景，也不適合不願維護 Chromium 分支或 AGPL 授權的團隊。採用前應先確認：你的代理框架是否支援 MCP 連接，你的網站是否允許本機自動化，以及你能否接受 `~/.browserclaw/` 下的資料儲存方式。若你只需要簡單的網頁抓取，Playwright 或 browser-use 可能更輕量。若你重視雲端協作與跨裝置同步，Atlas 或 Comet 的封閉生態反而提供了便利。最終，BrowserOS 的價值在於它把登入狀態與代理執行綁在同一台機器上，這是它與其他方案最根本的差異，也是你評估時必須權衡的核心。

官方來源

1. browseros-ai/BrowserOS on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases