Puppeteer 最佳替代方案

Puppeteer 给开发者一套驱动 Chrome 的 API。ego(lite) 则把浏览器本身交给 Agent。 ego(lite) 免去了选择器维护,让工作留在你已授权的本地浏览器里。精简的 Snapshot 和批量操作减少了模型轮次和 Token 用量。

ego(lite) 对比 Puppeteer

ego(lite) 与 Puppeteer 的功能对比。
功能ego(lite)Puppeteer
任务是怎么完成的描述任务,Agent 来操作浏览器编写并维护 Node.js 脚本
应对页面变化Agent 重新读取 Snapshot 并自动调整选择器失效,你去补脚本
已登录的网站(SSO、2FA)继承你真实的 Chrome 配置文件和会话状态空白 profile,得自己写登录脚本、导出 Cookie
设置安装应用,在你的 Agent 中运行 /ego-browserNode 项目、npm install、启动配置
并行任务Space 在同一浏览器内隔离任务,无需计算池大小自己管理浏览器池、上下文和内存
AI Agent 支持专为它们打造:通过 ego-browser 支持 Claude Code、Codex、Cursor原生不支持,需要 MCP 包装层或自定义胶水代码
日常使用的浏览器支持:人和 Agent 共用一个浏览器,各自有独立的 Space不支持,是无头自动化工具
最适合 CI 测试套件不是脚本运行器;Agent 直接处理浏览器工作适合:结果确定、可编写脚本,对 CI 友好
可复用技能(即将上线)把成功的运行提炼成可复用的技能,用于重复任务(限量测试中)没有内置的同类功能
价格免费,无需订阅免费,开源

最近更新 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),你的编程 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 开发者一旦不满足于单个脚本,就会发现所谓的并行,意味着要自己搭一套池:启动参数、浏览器上下文,还要靠 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,为 Agent 而生

Puppeteer 启动的是一个干干净净的空白 Chrome,没有 cookie 也没有会话,所以任何需要登录才能访问的内容,都得自己写认证流程的脚本,还要祈祷网站不会对着一个它不认识的浏览器扔出验证码或 2FA 提示。这道空白 profile 的墙,是脚本在开发环境跑得通、到真实网站上就失败的最常见原因。ego(lite) 基于 Chromium 构建,一键就能导入你完整的 Chrome 环境。你的 Agent 继承你的登录状态、Cookie 和扩展程序,不会卡在任何地方。

不靠选择器的抓取,也有护栏

Puppeteer 爬虫只能点击或提取代码里标识出来的东西:CSS 选择器、XPath 或手写的 DOM 查询。AI 生成的选择器是有用的脚手架,但只要类名、列表顺序或无障碍标签一变,它们照样会过时,所以生产任务需要校验、日志和经过审核的兜底方案。用 ego(lite),只需用自然语言描述你要的结果(比如「收集这个结果页上可见的商品名称和价格」),Agent 会先读取当前的 Snapshot,再编写 JavaScript。它可以复核结果,并在页面不再符合任务时停下来交给人工审核,而不是悄悄导出错误的字段。

守住反机器人边界,不玩绕过把戏

Puppeteer 和其他浏览器框架都可能被网站的 robots 政策、速率限制、登录检查,或 Cloudflare 和 CAPTCHA 页面拦下。stealth 插件或指纹伪装并不是可靠或恰当的解法,也没有任何工具能保证网站检测不到自动化;抓取应当始终遵守网站条款和适用法律。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 profile。那些脚本一直过不去的登录,也会一起带过来。

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 款工具的逐项对比。

常见问题

什么是 Puppeteer?

Puppeteer 是 Chrome 团队推出的 Node.js 自动化库,通过 DevTools Protocol 和 WebDriver BiDi 控制 Chrome 和 Firefox。它成熟、速度快、免费,是开发者编写仅限 Chrome 的抓取脚本、生成 PDF 和无头测试的常见选择,尽管 Playwright 在测试框架整体采用率上已经领先。它自己的 issue tracker 里记录了不少 waitForSelector 在导航和重连时出现的真实抖动问题,规模化运行的团队最终要手动管理浏览器池、上下文和内存,但对于精心调试、提交入库、跑在 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 该选哪个,通常取决于你测的是什么、用什么语言。如果你在 Node 里只做 Chrome,想要一个精简的 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 获得浏览器访问能力,但每个操作都是一次独立的工具往返,要经过模型,而且底层浏览器依然是空白 profile。ego(lite) 用 JavaScript 打包操作,并继承你真实的登录态,所以按任务计算的 Token 成本一直很低,Agent 也永远不会撞上那种包装层过不去的 SSO 高墙。

为什么我的 Puppeteer 选择器老是失效?

选择器绑定的是页面精确的标记结构:类名、DOM 顺序、ARIA 结构。目标网站的一次改版、一次 A/B 测试,或者一次框架升级,都会改变这些标记,你的 waitForSelector 调用就会开始超时,还往往是断断续续地出现,这正是 Puppeteer 自己的 issue 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 也让 Web 应用和 CI worker 之间很容易共享代码,这正是 Puppeteer 适合编写确定性脚本的原因。ego(lite) 保留了 JavaScript 的这些能力,但让 Agent 针对当前页面写简短、面向具体任务的代码,而不是要你为每个工作流维护一棵选择器树。

为你的 Agent 配备真实浏览器

免费使用,运行在你的电脑上,一键导入 Chrome 浏览器配置文件。支持 Claude Code、Codex、Cursor,以及任何能写代码的 CLI Agent。