2026 Agent Browser 專案 Top 10：持久登入、CLI 與 Token 效率深度分析

AI
, , , ,
1

深度比較 10 大 Agent Browser 專案，解析持久登入、CLI 整合與 Token 效率，助你選出最適合自動化瀏覽器操作的工具組合。

核心概念：持久登入與操作記憶的分離

要解決「瀏覽器登入狀態持久化」與「Token 效率」的問題，必須先區分兩個層面：

  1. 記住登入狀態：透過持久化 Chrome Profile 保存 Cookies、localStorage、IndexedDB、Service Workers、Cache 與登入 Session。這不是 Agent 的長期記憶，而是瀏覽器層面的狀態保存。
  2. 記住操作方法：Agent Memory 層面，例如記住「如何登入後台、在哪裡下載報表、按鈕位置、失敗後怎麼恢復」。這需要 Skill、Script、Workflow 或自建網站操作函式庫。

目前最成熟的專案通常只完整解決第一項。第二項仍需開發者自行建立可重複使用的操作腳本。

最符合需求的架構不是單一 Browser Agent，而是分層協作：

Claude Code / Codex
        ↓
Browser Skill
        ↓
CLI Browser Controller
        ↓
Persistent Chrome Profile
        ↓
Accessibility Snapshot / DOM
        ↓
必要時才使用 Screenshot + Vision

這比每一步都讓模型讀完整畫面、完整 Accessibility Tree 省掉大量 Token。

評分標準與方法論

評分項目 權重
持久登入與 Profile 能力 25%
Browser 操作準確度 25%
Token 效率 20%
CLI／Codex／Claude Code 整合 15%
GitHub 社群與發展速度 15%

GitHub Stars 為 2026 年 8 月 5 日附近約數。Stars 只能代表社群關注度，不能直接代表瀏覽成功率。

Top 10 專案深度分析

1. agent-browser

GitHub：vercel-labs/agent-browser

目前最接近「專門給 Coding Agent 使用的 Browser CLI」。2026 年 1 月建立，至 8 月累積約 39,925 Stars，成長極快。支援 Persistent Profile，可保存完整登入狀態。

優點

  • 原生 CLI 設計，極適合 Claude Code、Codex、Cursor
  • 使用 Accessibility Snapshot 與穩定 Element Reference
  • 不必每個操作都傳 Screenshot
  • --profile 可保存完整登入狀態
  • 支援連接本機或遠端 CDP
  • Rust 核心，啟動速度與執行效率好
  • Vercel Labs 維護，社群成長快

缺點

  • 是 Browser Tool，非具規劃能力的完整 Agent
  • 複雜 Canvas、拖曳或非標準元件仍可能需 Screenshot
  • 早期版本曾有 Profile 未正確落盤問題
  • Agent 每次重新要求完整 Snapshot 仍消耗 Token
  • 缺乏成熟 Workflow Recorder 或跨任務操作記憶

洞察
最合理的通用預設選擇。適合「Claude 規劃 → Codex 執行 → agent-browser 控制 → Persistent Profile 保留登入」的流程。對固定網站應建立 Skill，把高頻操作封裝成 Shell Function 或 Script，才能真正降低成本。

2. PinchTab

GitHub：pinchtab/pinchtab

最值得注意的「Token-efficient Browser Control Plane」。約 16 MB Go Binary，提供 CLI、HTTP API、MCP、常駐 Daemon、多 Chrome Instance 與 Persistent Profile。

優點

  • Profile 為一等公民，登入一次後重啟仍保留
  • 本機常駐 Daemon，不必每次重新啟動環境
  • 支援多個隔離 Profile（work、personal、client-a 等）
  • 支援 Headed 與 Headless Chrome
  • CLI、HTTP API、MCP 皆可用
  • Accessibility-first，官方宣稱文字擷取約 800 Tokens／頁面
  • 官方 Benchmark 顯示長流程較 agent-browser 減少約 25% Token
  • 適合長時間執行與多帳號隔離

缺點

  • 社群規模低於 Browser Use、Playwright MCP、agent-browser
  • 瀏覽推理能力由外部 Agent 提供
  • 複雜網站可能需更底層 Playwright 或 JavaScript
  • 遠端部署涉及高安全風險
  • 預設安全策略限制外部網站，初次設定較繁
  • 真實長任務準確度 Benchmark 不足

洞察
極精準命中「本機 CLI、長期保持登入、多 Profile、常駐 Browser Service、低 Token」需求。推薦作為「瀏覽器基礎設施」，再由 Codex 或 Claude Code 負責規劃。

3. Browser Harness

GitHub：browser-use/browser-harness

Browser Use 團隊推出的薄型 CDP Harness，核心特色是直接把 LLM 接到你正在使用、已經登入的真實 Chrome。

優點

  • 直接控制日常使用中的真實 Chrome
  • 不必搬移 Cookie 或重做登入
  • 架構薄，Agent 可直接寫 Python 操作
  • 適合 Claude Code 與 Codex Skill
  • 支援本機 Chrome 與 Browser Use Cloud
  • 可把常用網站操作累積成 Domain Skills
  • 比黑箱式 Browser Agent 更容易除錯

缺點

  • 早期專案
  • Chrome 144 後連接真實 Profile 可能跳出確認視窗
  • 完全無人值守需另外建立隔離 Profile
  • 操作邏輯更依賴 Coding Agent 自己寫程式
  • 缺乏大型公開 Benchmark

洞察
最接近 ChatGPT／Claude Chrome Extension 使用感，但更透明、更易控制 Token。核心價值在於「Agent 先探索找到方法 → 寫成可重複使用的 Python Helper → 未來不再重新推理整個網站」，這才是逐次降低 Token 的架構。

4. Playwright CLI

GitHub：microsoft/playwright-cli

Microsoft 明確把 Coding Agent 使用情境從 Playwright MCP 導向 CLI。支援 --persistent 保存瀏覽器 Profile 到硬碟。

優點

  • Microsoft 官方，Playwright DOM 操作精度高
  • 支援 Persistent Profile
  • CLI 比 MCP 更易控制輸出量
  • 適合讓 Agent 產生可重複執行的 Script
  • 網路等待、Selector、Frames、Downloads、Uploads 成熟
  • 可混合確定性程式碼與 Agent 判斷
  • 除錯工具完整

缺點

  • 非完整自主 Agent
  • Agent 必須知道如何使用 CLI 或撰寫 Playwright
  • 對未知網站首次探索開發成本高於 Browser Use
  • Selector 寫得不好仍可能因網站改版失效
  • 使用真實日常 Chrome Profile 有安全限制
  • 無內建語意自我修復能力

洞察
對「已知流程」而言，通常比任何通用 Browser Agent 更準確、更省 Token。第一次讓 Agent 探索，成功後轉成 Playwright Script，之後模型只需呼叫一條 CLI。

5. Browser Use

GitHub：browser-use/browser-use

最完整、最知名的開源 Browser Agent Framework 之一，約 95K Stars。支援透過 CDP 連接既有瀏覽器與 Persistent Browser Profile。

優點

  • 社群最大，Python 生態成熟
  • 支援本機真實 Chrome Profile
  • 可連接既有 CDP
  • 對未知網站、開放式任務自主性強
  • 支援自訂 Tool、System Prompt、Structured Output
  • 可搭配不同 LLM
  • 有 Cloud Browser、Stealth、Proxy、CAPTCHA 商業能力
  • CLI 已針對 Codex、Claude Code 等設計

缺點

  • 完整 Agent Loop 仍非常耗 Token
  • 每 Step 都需模型重新判斷
  • Vision、DOM、Memory、Action History 累積易膨脹上下文
  • 使用通用模型時成本較高
  • 開源版與 Cloud 版能力有差異
  • 對固定流程不如確定性 Playwright Script 經濟

洞察
適合「探索」，不適合把所有重複操作永久留在 Agent Mode。合理用法：第一次用 Browser Use 探索 → 成功後轉成 Playwright/PinchTab/agent-browser Skill → 未來直接執行 Skill，失敗時才重新啟用 Browser Use。

6. Playwright MCP

GitHub：microsoft/playwright-mcp

最普及的 Browser MCP 之一，約 35.8K Stars。透過 Structured Accessibility Snapshot 操作網頁，不依賴 Vision。

優點

  • Microsoft 官方，MCP Client 支援面廣
  • Playwright 操作準確度高
  • 不用 Vision 時成本低於純 Screenshot Computer Use
  • 支援 Persistent User Data Directory 與 Storage State
  • 適合 QA、Web App 測試與開發
  • Accessibility Tree 對標準網頁穩定

缺點

  • Snapshot 可能極大，大型頁面塞滿 Context Window
  • MCP Tool Schema、Tool Call 與 Snapshot 都佔 Token
  • 長時間執行後 Shell Log 與 Interaction History 持續增加
  • 純 MCP 模式通常比 CLI 模式冗長
  • 公開 HTTP/SSE 部署需額外注意權限與認證
  • 不適合直接暴露在網路上

洞察
非最省 Token 選擇。對 Coding Agent 而言，「Playwright CLI + Skill」優於「Playwright MCP + 每一步完整 Snapshot」。MCP 適合通用整合；CLI 適合高頻、長時間、成本敏感工作。

7. Stagehand

GitHub：browserbase/stagehand

Browserbase 推出的 AI Browser Automation Framework，核心是混用 Playwright/CDP 確定性程式碼與 act() 語意操作、extract() 結構化擷取、Agent Mode。

優點

  • 確定性 Script 與 AI 判斷可混用
  • 比完全自主 Browser Agent 更易控制
  • 適合把成功操作逐步固化
  • 支援 Browserbase Persistent Session
  • 生產環境基礎設施成熟
  • 對網站小幅改版具自我修復能力

缺點

  • 完整 Session、Stealth、Proxy 體驗偏向 Browserbase Cloud
  • 本機真實 Chrome Profile 非核心使用方式
  • 自架 Persistent Profile 需額外設計
  • AI act() 仍產生模型成本
  • 抽象層比直接 Playwright 複雜
  • 對單純 CLI 使用者不如 agent-browser 或 PinchTab 直接

洞察
最適合生產型 Browser Workflow，不一定最適合直接控制個人日常 Chrome。若目標是建立每天自動登入多個 SaaS、下載資料、後台操作、具備恢復能力，Stagehand 是很好的中間層。

8. Skyvern

GitHub：Skyvern-AI/skyvern

使用 LLM、Computer Vision 與 Playwright 執行複雜 Browser Workflow，約 22.7K～23K Stars。

優點

  • 適合複雜表單與多步驟後台 Workflow
  • 同時使用 DOM 與 Vision
  • 提供 API、SDK 與 Workflow Builder
  • 對網站結構變動比純 Selector Script 有韌性
  • 適合企業級流程與批次任務

缺點

  • 部署較重
  • Token 使用量通常高於純 CLI Controller
  • Vision 增加成本與延遲
  • 本機日常 Chrome Profile 非主要設計中心
  • 對簡單任務屬於過度設計
  • AGPL License 對部分商業整合需評估

洞察
解決「企業 Workflow Automation」，非「極低 Token 個人 Chrome Copilot」。處理大量不同網站、格式表單有價值；控制固定幾個網站則 PinchTab、agent-browser 或 Playwright CLI 更合適。

9. Browser MCP

GitHub：BrowserMCP/mcp

使用 Chrome Extension 連接現有瀏覽器，天然沿用使用者目前登入狀態。

優點

  • 最容易直接沿用日常 Chrome
  • 不需重新登入
  • 本機執行
  • 支援 Claude、Cursor、VS Code、Windsurf 等 MCP Client
  • 安裝概念簡單

缺點

  • 仍依賴 Chrome Extension，未必根本改善 Token 消耗
  • MCP Snapshot 仍可能很大
  • 對 CLI-first 工作流不如 PinchTab 或 agent-browser
  • 長流程穩定性取決於 Extension、Tab 與瀏覽器狀態
  • 缺乏成熟多 Profile 管理

洞察
解決「怎麼快速接上已登入 Chrome」，非「怎麼最低成本長期執行」。適合短期驗證，非最終架構首選。

10. Steel Browser

GitHub：steel-dev/steel-browser

可自架的 Open-source Browser API，管理 Browser Process、Sessions、Pages 與 Automation Infrastructure，類自架版 Browserbase。

優點

  • 開源可自架
  • Session 與 Browser Process 管理完整
  • 適合遠端伺服器或多 Agent
  • 支援 CDP、Playwright 類整合
  • 可建立長時間存在的 Browser Infrastructure
  • 適合多 Agent 共用一套瀏覽器服務

缺點

  • 不直接提供最強 Agent 推理層
  • 本機日常 Chrome Profile 非核心
  • 部署與維護成本高於單一 CLI Binary
  • 需自行處理安全、隔離與 Credentials
  • 對個人單機使用可能過重

洞察
適合未來建立多 Sub-agent、多 Profile、多伺服器、多帳號平行任務、統一 Browser API。但對目前單機、已登入 Chrome、低 Token 需求，PinchTab 更直接。

值得關注的新興專案

ego-lite

GitHub：citrolabs/ego-lite

三者中最符合原始需求，應進入 Top 3。它不是控制另一個 Chrome 的 Framework，而是直接提供專門讓人類與 Agent 共用的瀏覽器。首次啟動可匯入 Chrome 資料（Cookies、登入狀態、Extensions、Bookmarks、瀏覽資料），Agent 透過 ego-browser Skill 存取真實登入狀態，在獨立 Space 執行，不干擾使用者 Tabs。

Token 效率：鼓勵 Agent 一次產生 JavaScript 組合多步驟，減少 Tool Call 次數、Tool Schema Token、Tool Result Token、Shell Output、中間推理 Token、多輪 Snapshot。官方宣稱複雜任務可比 agent-browser 快最多 2.5 倍並用更少 Token（為專案自測數據）。

優點：可匯入真實 Chrome 登入資料、Agent 獨立 Space 不干擾人類、多 Agent 平行執行、直接面向 Claude Code/Codex/Cursor、JavaScript code-based interaction 減少 Tool Call、Persistent Login 為核心設計、MIT License、四個月達 8.6K Stars、2026 年 8 月仍高度活躍。

缺點：主要只支援 macOS、要求使用 ego-lite Browser 而非原生 Chrome、Browser Binary 開源程度需確認、效能宣稱待獨立驗證、Experience accumulation 仍標示 coming soon、專案新缺長期驗證、64 個 Open Issues、Chromium fork 可能有版本更新、Extension 相容性與安全更新延遲風險。

web-access

GitHub：eze-is/web-access

非新瀏覽器，而是聰明的 Agent Skill，建立三層存取策略：WebSearch/WebFetch → curl/Jina → 必要時才進入 CDP Browser。可直接連接日常 Chrome/Edge，天然沿用登入 Session、Cookies、Extensions、權限、紀錄、Bookmarks。

核心價值：提供「何時不應該使用 Browser」的決策框架，避免 Agent 遇到任何網址都啟動 Browser，節省大量 Token。支援站點經驗累積（URL Pattern、平台特徵、已知錯誤、操作陷阱、成功做法）。

優點：直接沿用日常 Chrome/Edge 登入、不需另外匯入 Cookie、與 Claude Code/Codex CLI/Gemini CLI/Cursor 相容、安裝即一個 Skill、分層策略有效減少不必要 Browser Token、提供 HTTP API 可從 Shell 直接操作、支援 JS Click、真實 CDP Mouse Event、Upload、Screenshot、本機 History/Bookmark 搜尋、依 Domain 累積操作經驗、多 Tab 平行任務、五個月達 8.5K Stars。

缺點：本質仍是 Chrome/Edge CDP、未根本消除 CDP Snapshot 或 Agent 重複推理、與不滿意的 Extension/CDP 架構有重疊、直接控制日常 Browser 有誤關 Tab、誤操作帳號、隱私風險、Agent 與使用者仍可能同時操作相同頁面、非 ego-lite 那種完整 Browser Space 隔離、Repo 無標準 License Metadata（README 雖寫 MIT 需再確認）、2026 年 5 月 16 日後無 Push 但 Stars 持續增加、內容以中文為主國際驗證相對不足。

Camoufox

GitHub：daijro/camoufox

不應與上述專案同層比較。它是基於 Firefox、針對反偵測與 Web Scraping 改造的 Browser Runtime，解決 Fingerprinting、Headless Detection、WebDriver Detection、Canvas/WebGL Fingerprint、Locale/Timezone/Navigator Fingerprint、Anti-bot 系統、Playwright 自動化環境暴露等問題。約 10.8K Stars，建立於 2024 年。

正確架構位置：位於最底層，取代 Chromium 或普通 Firefox。上層仍需 Browser Use、Playwright、Stagehand 或自訂 Agent Controller。

優點：反偵測能力最強、適合自動化敏感網站、Playwright 生態可整合、可搭配 Persistent Profile、適合大規模 Scraping、社群基礎不弱、持續更新、MPL-2.0 License 清楚、Firefox-based 提供 Chromium 替代選擇。

缺點：非 Agent Browser、不直接降低 Token、無內建 Agent Skill、不自動使用目前 Chrome 登入狀態、Chrome Extension 難移植到 Firefox fork、對 Google/Microsoft/企業 SSO 登入可能觸發額外驗證、需自行管理 Profiles、Anti-detect 設定錯誤可能導致 Fingerprint 不一致、官方標示不一定適合穩定 Production、開發分散到多 Repo 增加治理複雜度。

修正版排名與推薦組合

依據實際需求而非單純 Stars：

排名 專案 核心原因
1 ego-lite 最直接解決登入共享、獨立 Space 與低 Tool Call
2 agent-browser 最成熟的通用 Agent Browser CLI
3 PinchTab 常駐 Daemon、多 Profile、Token-efficient
4 Browser Harness 直接控制已登入 Chrome，可逐步建立 Helper
5 web-access 最好的分層 Web Skill，避免不必要 Browser 使用
6 Playwright CLI 固定任務最準確、最容易固化
7 Browser Use 未知網站與探索任務能力強
8 Stagehand AI 與確定性 Script 的良好混合
9 Playwright MCP 生態成熟，但 Snapshot Token 成本偏高
10 Steel Browser 適合自架多 Agent Browser Infrastructure

Camoufox 列為特殊底層，不占 Agent Controller Top 10 名額。

最佳實踐架構

一般登入後台與日常網站

Claude Code / Codex
        ↓
ego-browser
        ↓
ego-lite Spaces
        ↓
匯入 Chrome 登入資料

目前最值得先測試的方案。

搜尋、讀資料與偶爾操作 Chrome

Claude Code / Codex
        ↓
web-access
        ├── Jina / curl / WebFetch
        └── 必要時才用 Chrome CDP

最適合降低「研究型任務」Token。

容易阻擋自動化的網站

Claude Code / Codex
        ↓
Playwright / Browser Use
        ↓
Camoufox
        ↓
Persistent Profile + Proxy

Camoufox 僅在網站有明確 Anti-bot 問題時加入，不應當成所有任務預設底座。

固定高頻流程（如每週匯出報表）

第一次：Browser Use 探索並完成任務
成功後：將操作軌跡轉成 Playwright/PinchTab/agent-browser Skill
之後：直接執行 Skill，模型只接收 JSON 結果
失敗時：回退到 Accessibility Snapshot → 局部 Screenshot → LLM 修復 → 更新 Script

結論

ego-lite 是最直接命中「持久登入、獨立 Space、低 Token」需求的專案，甚至優於 PinchTab；web-access 是極佳的節流與調度層；Camoufox 則是反偵測底座，非低 Token Agent Browser 直接答案。

建議採用「探索 Agent + 固化 Script」模式：第一次用 Browser Use 或 ego-lite 探索，成功後立即轉為確定性腳本（Playwright CLI、PinchTab Script、agent-browser Skill），日常僅執行腳本，失敗才啟動探索模式。這才是真正能隨時間降低 Token 成本、提高準確度的架構。