最佳 Puppeteer 替代方案

Puppeteer 給開發者一套驅動 Chrome 的 API。ego(lite) 則直接把瀏覽器本身交給 AI Agent。 ego(lite) 省去選擇器維護,讓工作留在你已授權的本機瀏覽器中。精簡的 Snapshot 與批次動作,能減少模型輪次和 Token 用量。

ego(lite) 對比 Puppeteer

ego(lite) 與 Puppeteer 的功能比較。
功能ego(lite)Puppeteer
工作是怎麼完成的描述任務,你的 Agent 來操作瀏覽器撰寫並維護 Node.js 腳本
如何應對頁面變動Agent 重新讀取 Snapshot 並自行調整選擇器一壞就得自己修腳本
已登入的網站(SSO、2FA)直接沿用你真實的 Chrome 設定檔與登入狀態空白設定檔,得自己寫登入腳本、匯出 cookie
設定安裝應用程式,在你的 AI Agent 中執行 /ego-browserNode 專案、npm install、啟動設定
平行任務Space 讓每項任務在同一個瀏覽器裡彼此隔離,不用規劃池的大小自己管理瀏覽器池、context 和記憶體
與 AI Agent 協作專為它們打造:透過 ego-browser 支援 Claude Code、Codex、Cursor並非原生支援,得靠 MCP 包裝層或自訂膠水程式碼
日常使用的瀏覽器支援:人類和 Agent 共用同一個瀏覽器,各自有獨立 Space不是,這是一款無頭自動化工具
最適合 CI 測試套件不是腳本執行器;由 Agent 直接處理瀏覽器工作是:結果可預期、可寫成腳本,適合 CI
可重複使用的 skills(即將推出)把成功的執行過程萃取成可重複使用的 skills,供重複性任務使用(限量 beta)沒有內建的對應功能
價格免費,無需訂閱免費、開源

最後更新 2026年8月30日

獲得來自以下單位開發者的信賴

  • Vercel
  • OpenAI
  • Anthropic
  • SpaceX
  • Google
  • Microsoft
  • DJI
  • DeepSeek
  • Kimi
  • TikTok
  • MiniMax
  • SAP
  • ZARA
  • eBay
  • Cisco
  • Trip.com
  • LINE
  • NHN
  • Hyundai Motor

為什麼 ego(lite) 比 Puppeteer 更好

使用 Puppeteer 時,工作流程是一支你要自己撰寫、並隨頁面同步維護的程式。使用 ego(lite) 時,你的程式碼 AI Agent 從結果出發,邊做邊調整,不論是查找資訊、擷取資料列、填寫表單、檢查流程,還是處理需要登入的網站。每項任務都不需要一整套選擇器或獨立的執行器。

從任務到完成,更快

Puppeteer 自己的 issue tracker 裡滿是 waitForSelector 逾時的回報,即使元素明明就在 DOM 裡也一樣觸發,得花一整個下午證明這是時機問題,不是你的程式碼寫錯。ego(lite) 省去了等待與輪詢的反覆折騰:你的 Agent 以壓縮過的 Snapshot 讀取頁面,每一輪把多個步驟打包成一次 JavaScript 呼叫。在我們公開的 31 項真實網站任務基準測試中,它完成任務的速度比受測的另外四款工具快 47% 到 63%。

Time to finish a task, shorter is better

  1. ego(lite)
    398 s
  2. agent browser
    605 s

Data source - Task: finish an average live-site job

平行多工,執行更快

Puppeteer 開發者一旦跳脫單一腳本的規模,就得學會平行處理意味著自己管理一個池:啟動選項、瀏覽器 context,還要靠 puppeteer-cluster 這類佇列函式庫限制並行數量,免得 Chrome 把你的記憶體全部吃光。ego(lite) 裡沒有池需要規劃大小。每項任務都有自己的 Space,全都在同一個瀏覽器裡,你想開幾個就開幾個,每個都用各自匯入的 Chrome 設定檔運作。它們都不會碰到你正在用的分頁,而且你隨時能看著任何一個 Space 執行,或直接接手操作。

不再來回往返 消耗更少 Token

純粹的 Puppeteer 腳本不花 Token,因為它根本不會呼叫模型。成本是在你透過 MCP 伺服器(比如原始的 Puppeteer MCP 參考實作)把 Puppeteer 包裝給 Agent 用時才會出現的:每個被包裝的動作都變成一次獨立的工具呼叫,得把上下文重新送回模型一次,而且因為沒有無障礙 Snapshot 工具,它只能靠螢幕截圖來檢查自己做得對不對。ego(lite) 的 Agent 每一輪都用幾行 JavaScript 打包多個動作,再疊加 Snapshot 輸入,同樣的任務整體花費的 Token 少得多,以每項任務計算都是如此。

Claude Code · ego(lite)
>/ego-browser Add the first product to the cart, then check checkout loads
●Bash(
ego-browser nodejs <<'EOF' await openOrReuseTab('localhost:3000') await click('.product-card') await click('.add-to-cart') await click('a[href="/checkout"]') cliLog('checkout loaded') EOF
)
⎿Output:
[t=4480ms] checkout loaded
Done. Both steps work.
─── 1 tool call · ↑ 1.1k tokens ───
Claude Code · Puppeteer MCP
>Add the first product to the cart, then check checkout loads
●puppeteer - puppeteer_navigate (MCP)(url: "localhost:3000")
⎿Screenshot
[image: screenshot://home]
↑ 1.6k tokens sent so far
Storefront rendered. Opening the first product.
●puppeteer - puppeteer_click (MCP)(selector: ".product-card:first-child")
⎿Result
Clicked selector
↑ 3.1k tokens sent so far
Product page is up. Now the Add to cart button.
●puppeteer - puppeteer_click (MCP)(selector: ".add-to-cart")
⎿Result
Clicked selector
↑ 4.9k tokens sent so far
Added, probably. There's no accessibility snapshot to confirm it, so a screenshot is the only way to check.
●puppeteer - puppeteer_click (MCP)(selector: "a[href='/checkout']")
⎿Result
Clicked selector
↑ 6.8k tokens sent so far
Checking whether the checkout page actually rendered.
●puppeteer - puppeteer_screenshot (MCP)(name: "checkout")
⎿Screenshot
[image: screenshot://checkout]
↑ 9.2k tokens sent so far
Hard to tell from a screenshot alone. Probing the DOM directly.
●puppeteer - puppeteer_evaluate (MCP)(script: "document.querySelector('.checkout-form') !== null")
⎿Result
true
↑ 11.2k tokens sent so far
Confirmed. Reading the console for any errors along the way.
●puppeteer - console://logs
⎿Console
… +12 lines (ctrl+o to expand)
↑ 13.6k tokens sent so far
─── 7 tool calls · ↑ 13.6k tokens ───

同一個任務,同一個模型。 左邊:ego(lite) 用一次批次 JavaScript 呼叫,總共 1.1k Token。 右邊:Puppeteer MCP 來回 7 次,Token 攀升到 13.6k。

同一個 Chrome,AI Agent 原生體驗

Puppeteer 每次啟動的都是乾淨空白的 Chrome,沒有 cookie 也沒有任何工作階段,所以只要牽涉到登入,就得自己寫驗證流程的腳本,還得祈禱網站不會對這個陌生的瀏覽器丟出圖形驗證碼或雙重驗證。這道空白設定檔的牆,正是腳本在開發環境跑得動、卻在正式網站失敗的最常見原因。以 Chromium 為核心打造,ego(lite) 只要一鍵就能匯入你整個 Chrome 設定。你的 Agent 直接繼承你的登入狀態、cookie 和擴充功能,完全不會卡關。

不靠選擇器的資料擷取,並設有防護措施

Puppeteer 爬蟲只能點擊或擷取程式碼能辨識的東西:CSS 選擇器、XPath,或手寫的 DOM 查詢。AI 產生的選擇器是有用的鷹架,但只要 class 名稱、清單順序或無障礙標籤一變,它們還是會失效,所以正式環境的工作需要驗證、日誌記錄,以及經過審查的備援方案。使用 ego(lite) 時,只要用自然語言描述你要的結果,例如「蒐集這個結果頁面上可見的商品名稱和價格」,Agent 就會先讀取當下的 Snapshot,再撰寫 JavaScript。當頁面已不再符合任務時,它可以重新核對結果並停下來等待人工審查,而不是默默匯出錯誤的欄位。

尊重反機器人機制的界線,不用繞過伎倆

Puppeteer 和其他瀏覽器框架都可能遇到網站的 robots 政策、速率限制、登入檢查,或 Cloudflare 與 CAPTCHA 頁面的阻擋。隱身外掛或指紋規避手法既不可靠也不恰當,而且沒有任何工具能保證網站不會偵測到自動化;資料擷取應遵守網站條款與相關法律。ego(lite) 在一般、由使用者控制的 Chrome 設定檔中執行,能避免空白瀏覽器常引發額外驗證的不一致問題,但它不會破解存取控制。如果出現驗證關卡,Agent 應該暫停、把頁面呈現出來,讓獲授權的人完成驗證,或選擇經核准的資料來源。

動態頁面需要的是證據,而不是固定等待

現代網站常在載入後才透過 fetch、WebSocket 或內嵌的 JSON 狀態渲染資料。Puppeteer 裡固定的 waitForSelector 逾時,對慢的回應可能太短,對快的回應又太浪費;穩健的腳本會等待有意義的網路或應用程式訊號、擷取它所依賴的回應,並在訊號始終沒出現時記錄發生了什麼。ego(lite) 的 Agent 可以同時檢查渲染後的 Snapshot、頁面文字和允許存取的頁面內資料,再用 JavaScript 解析內嵌的 JSON 物件,或等待可見的狀態變化。這讓擷取路徑明確且可審查,也不必假設每個網站的內部 API 都穩定或已獲授權可直接使用。

可靠的管線仍需要 JavaScript 層面的判斷

JavaScript 依然是網頁自動化的強力選擇,因為它就在瀏覽器旁邊執行,擁有一流的 DOM 與網路 API,也很適合 Node.js 服務和 CI。當你需要確定性、有版本控管的程式碼、可重複的重試、產生 PDF 或螢幕截圖,以及在受控網站上執行大量工作時,Puppeteer 是更好的選擇。ego(lite) 適合那些寫成選擇器成本很高的瀏覽器工作:搜尋、研究、不斷變動的後台工作流程、測試,以及需要沿用某人既有工作階段的任務。請設定檢查點、限制頁數、使用結構化輸出,並在欄位缺漏時發出警示,讓 Agent 驅動的管線在失敗時清楚可見,而不是把版面改動變成錯誤資料。

讓轉換無縫接軌

你不用把 Puppeteer 腳本搬到 ego(lite) 上,而是直接不寫腳本了。把你原本寫成腳本的任務,或是根本放棄寫腳本的任務,都交給你的 Agent 處理。

1

下載 ego(lite)

下載 ego(lite),匯入你的 Chrome 設定檔。那些你的腳本永遠過不去的登入關卡,也會一併帶過來。

2

用 /ego-browser 執行你的第一個任務

在 Claude Code、Codex 或 Cursor 中執行 /ego-browser。

貼到你的 Agent 裡

/ego-browser 打開 ego.app,檢查頁面有沒有主控台錯誤

3

看它實際運作

挑一個你平常會寫腳本處理的任務,比如爬取一個列表頁或填寫後台表單,用一句話描述給 Agent 聽就好。

ego(lite) 的 Space 總覽,四項瀏覽器任務並排執行:Claude Code 在 Yahoo Finance 追蹤蘋果股價、Codex 在 cars.com 依年份篩選車款、Hermes 完成一項 SaaS 後台任務、一位使用者在擷取 X 上的資料,還有一隻手正點擊 + 開啟另一個 Space

在腳本真正佔優勢的地方繼續用 Puppeteer:具確定性的 CI 測試套件和大量排程工作。ego(lite) 則處理那些能受益於 Agent 判斷、即時狀態或可見交接的瀏覽器工作。

何時該用哪個工具

適合選擇 ego(lite) 的情況

  • 任務每週都在變。Agent 會跟著頁面變化調整,不會因為選擇器過時而壞掉。
  • 你需要真實的登入狀態:爬取自己的帳號資料、填寫後台表單、測試 SSO 之後的頁面。
  • 你一直沒空寫腳本處理它。把任務描述給 Claude Code、Codex 或 Cursor 聽,就搞定了。
  • 你想讓多項任務在各自的 Space 中平行執行,不用規劃瀏覽器池的大小,也不用盯著記憶體用量。

適合選擇 Puppeteer 的情境

  • 你需要結果可預期、可重複執行的腳本,版本控管在儲存庫裡,並在 CI 中執行。
  • 你在跑高流量的排程工作:成千上萬次一模一樣的執行,這種情況下 Agent 只會增加成本,不會帶來價值。
  • 你需要在沒有桌面環境的伺服器上跑無頭執行。
  • 你要用程式產生 PDF 或螢幕截圖,這正是 Puppeteer 最擅長的看家本領。

將 ego(lite) 與其他瀏覽器自動化工具比較

與 Playwright MCP、Claude Chrome extension、Browser Harness、Browserbase,以及另外 7 款工具的逐項比較。

FAQ

什麼是 Puppeteer?

Puppeteer 是 Chrome 團隊推出的 Node.js 自動化函式庫,透過 DevTools Protocol 和 WebDriver BiDi 控制 Chrome 與 Firefox。它成熟、速度快、免費,是開發者寫 Chrome 專用爬蟲、產生 PDF、跑無頭測試的常見選擇,儘管 Playwright 在整體測試框架採用率上已經領先。它自己的 issue tracker 記錄了大量 waitForSelector 在導覽和重新連線時的不穩定情況,團隊規模一大,最後都得手動管理瀏覽器池、context 和記憶體,但對於手動調校、版本控管、跑在 CI 裡的自動化程式碼來說,Puppeteer 依然表現優異。下面的比較,談的是當操作瀏覽器的是 AI Agent 而不是腳本時,會發生什麼變化。

ego(lite) 是不是一個好的 Puppeteer 替代方案?

對於由 AI Agent 驅動的瀏覽器工作來說,答案是肯定的:它完全去除了腳本這一層,直接在你真實已登入的 Chrome 中執行任務,是少數幾個真正為 Agent 打造,而不是要你寫更多腳本的 Puppeteer 替代方案之一。至於版本控管、結果可預期、跑在 CI 裡的自動化程式碼,Puppeteer 依然是比較好的工具。許多開發者兩者都用:Puppeteer 負責管線,ego(lite) 負責那些他們一直沒空寫成腳本的工作。

Puppeteer vs Playwright vs Selenium:哪個比較好?

這三者都是以腳本為主的自動化函式庫,playwright vs puppeteer 或 puppeteer vs selenium 該選哪個,通常取決於你在測試什麼、用什麼語言。如果你只鎖定 Chrome、用 Node,又想要一個精簡的 DevTools 層級 API,Puppeteer 會勝出。對於全新的測試套件,Playwright 通常領先:跨瀏覽器覆蓋、自動等待,還有更強大的測試執行器。Selenium vs Puppeteer 則比較接近,selenium 和 puppeteer 哪個比較好,通常取決於語言和 CI 設定,而不是純粹的能力高低:Selenium 的優勢在於 W3C WebDriver 標準,以及最廣泛的語言和舊版瀏覽器支援,代價是要寫更多樣板程式碼。ego(lite) 完全不參與這場辯論,因為它是一款 Agent 瀏覽器,讓 AI Agent 親自操作瀏覽器,而不是用這三者之一寫腳本來操作。這些比較可以參考我們的 ego(lite) vs Playwright 和 ego(lite) vs Selenium 頁面。

那給 AI Agent 用的 Puppeteer MCP 呢?

圍繞 Puppeteer 打造的 MCP 包裝層能讓 Agent 存取瀏覽器,但每個動作都得經過模型來回一次工具呼叫,底層的瀏覽器骨子裡還是一個空白設定檔。ego(lite) 用 JavaScript 打包多個動作,並直接繼承你真實的登入狀態,所以每項任務的 Token 成本能維持在低點,Agent 也不會撞上包裝層過不去的 SSO 高牆。

為什麼我的 Puppeteer 選擇器一直壞掉?

選擇器綁死在頁面精確的標記結構上:class 名稱、DOM 順序、ARIA 結構。目標網站一改版、跑 A/B 測試、或升級框架,都會改變這些標記,你的 waitForSelector 呼叫就開始逾時,而且往往是斷斷續續地發生,這正是 Puppeteer 自己的 tracker 上一再被回報的不穩定情況。ego(lite) 的 Agent 完全不依賴固定選擇器,它每次都把目前的頁面讀成一份 Snapshot,判斷實際上有什麼內容,所以網站改版對它來說只是下次執行時要適應的變化,而不是會弄壞腳本的問題。

用 ego(lite) 需要自己管理瀏覽器執行個體或記憶體嗎?

不需要。把 Puppeteer 擴展到超過單一腳本的規模,通常得自己架設一個池(puppeteer-cluster、generic-pool,或自己寫的佇列),在 Chrome 記憶體用量失控之前限制並行數量。ego(lite) 的 Space 都在你原本就已經開著的同一個瀏覽器程序裡執行,所以同時跑五項任務,並不代表要顧著五個瀏覽器執行個體。

ego(lite) 能搭配 Claude Code 和 Codex 使用嗎?

可以。任何會寫程式碼的 CLI Agent,都能透過採 MIT 授權的 ego-browser shell 接入:Claude Code、Codex、Cursor、Gemini CLI、OpenCode,以及你自己開發的內部 Agent。

ego(lite) 像 Puppeteer 一樣免費嗎?

是的。免費,不用訂閱,而且 ego-browser shell 是開源的。

為什麼網頁自動化常用 JavaScript?

JavaScript 在瀏覽器的執行模型中運作,能直接存取 DOM、事件、fetch 和瀏覽器工具。Node.js 也讓網頁應用程式和 CI worker 之間能輕鬆共用程式碼,這正是 Puppeteer 適合用來寫確定性腳本的原因。ego(lite) 保留了這種 JavaScript 能力,但讓 Agent 針對當下頁面撰寫簡短、專為該任務而寫的程式碼,而不是要你為每個工作流程維護一整套選擇器。

給你的 AI Agent 一個真實瀏覽器

免費,在你的電腦上執行,一鍵匯入你的 Chrome 個人設定檔。適用於 Claude Code、Codex、Cursor,以及任何會寫程式碼的 CLI AI Agent。