为什么 AI Agent 都绕不开 Puppeteer

当 Browser Use、OpenAI Operator、Claude Computer Use 这类项目接连刷屏的时候，浏览器自动化突然成了 AI 圈最热闹的赛道之一。可一旦真的把这几个项目拆开看，会发现一个有点反直觉的事实：几乎所有 Browser Agent 的底层，都站着一个老朋友——Puppeteer。

作为 Google Chrome 团队官方维护的浏览器自动化框架，Puppeteer 在 GitHub 上已经积累了接近 9 万个 Star。它早就不再只是前端同学眼里的“测试工具”。在 AI Agent 逐渐成为主流范法的今天，它正在悄悄演变成整套体系背后的事实基础设施。

今天就从架构设计、工程实践、商业价值与未来趋势几个维度，把这个老项目重新拆开看一遍。

所有 Browser Agent 的底层，都站着 Puppeteer

先说清楚 Puppeteer 到底是什么。它是 Google Chrome 团队推出的浏览器自动化框架，允许开发者用 JavaScript 或 TypeScript 代码直接控制浏览器。一段最简单的用法长这样：

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
await page.screenshot({ path: 'example.png' });
await browser.close();

对开发者而言，整个浏览器在这几行代码里被收编成了一个可编程系统：你的业务逻辑调用 Puppeteer 的 API，Puppeteer 再把指令翻译成 Chrome DevTools Protocol（CDP）发给 Chrome 内核，Chrome 执行后把结果原路返回。链路看起来朴素，但它第一次让“用代码驱动一个真实浏览器”变得像调用一个普通函数那么自然。

也正因为这层抽象足够干净，今天大部分叫得上名字的 Browser Agent，要么直接基于 Puppeteer，要么借鉴了它的思路。这件事本身就值得琢磨：为什么一个 2017 年出生、最初定位是测试的框架，能在八年后的 AI 浪潮里重新成为核心？

Puppeteer 凭什么取代 Selenium

要回答这个问题，得回到它诞生的那个时间点。在 Puppeteer 出现之前，浏览器自动化领域长期被 Selenium 统治。Selenium 不是不好，而是它在工程体验上背着几个甩不掉的包袱：配置复杂、API 笨重、执行效率偏低，再加上跨浏览器兼容带来的一堆玄学问题，调试成本始终居高不下。

Google 这次的思路很直接——不再绕着 WebDriver 走，而是把 Chrome 自己的调试协议 CDP 直接开放出来。Puppeteer 正是这套协议最成功的封装实现。它不再通过 WebDriver 间接和浏览器对话，而是直接和 Chrome 内核通信，少了一层中间商，速度、稳定性、能力上限都上了一个台阶。

这就是 Puppeteer 能快速崛起的底层原因：不是它做了多么革命性的发明，而是它押对了协议，并且把协议包得足够好用。

真正的价值，藏在测试之外

很多人对 Puppeteer 的第一印象停留在自动化测试。这当然没错——模拟点击、输入、滚动、上传文件、提交表单，这些 E2E 测试场景它都覆盖得很成熟，也是它最早立住脚的方向。但如果只把它当测试工具，就严重低估了它的应用边界。

第一个被低估的场景是网页抓取。今天的 Web 早已经被 React、Vue、Next.js 这类 SPA 框架占领，页面内容靠 JavaScript 运行时动态渲染，传统基于 HTTP 拉取 HTML 的爬虫根本拿不到真实内容。而 Puppeteer 会老老实实执行完整的 JavaScript 生命周期，渲染完再给你结果，因此成了动态网页抓取领域几乎是绕不开的工具。

第二个是 PDF 与截图服务。很多 SaaS 产品背后的发票生成、报表导出、海报合成、网页存档，本质上都是同一件事：把 HTML 交给 Chrome 渲染，再输出成 PDF 或 PNG。Puppeteer 天然就是这条流水线的引擎。

第三个，也是当下最热的——AI Agent。Agent 不再只是陪你聊天的对话框，而是开始真正去执行任务：登录网站、检索信息、填表单、下单购买、提交申请。浏览器正在变成 Agent 和互联网世界交互的主要入口，而 Puppeteer 恰恰是这个入口背后最现成的执行引擎。三件事表面上是三个赛道，底层用的是同一套能力。

一套分层架构，把浏览器变成可编程系统

Puppeteer 的架构之所以经典，在于它把一个核心思想贯彻得很彻底：高层 API 和底层协议彻底解耦。开发者完全不需要理解 CDP 那套晦涩的指令，只需要写一句 await page.click('#submit')，Puppeteer 会自动把它翻译成 Input.dispatchMouseEvent 这样的底层协议调用。这种抽象层的设计，极大降低了浏览器自动化的心智门槛。

如果准备读它的源码，有四个模块最值得看。Browser 是整个系统的根节点，负责浏览器的启动、生命周期管理和 Context 隔离。Page 是业务侧用得最频繁的对象，DOM 操作、网络请求、JavaScript 执行几乎都挂在这里，日常开发八成的 API 调用都落在它身上。

再往下，CDPSession 是高级开发者必须掌握的一层——通过它能绕过 Puppeteer 的封装，直接访问 Chrome DevTools Protocol。很多官方还没来得及封装的原生能力，都可以从这里拿到。最后是 Network，整套请求拦截体系就在这个模块：Mock 响应、改 Header、重写 Request、重写 Response，这些是 Puppeteer 在测试和抓取领域能玩出花样的能力来源。理解了这四层，基本就读懂了 Puppeteer 的骨架。

为什么 AI Agent 都绕不开 Puppeteer

过去几年 AI 最缺的能力，其实不是推理，而是执行。模型心里清楚一张机票该怎么订，但它没法真的把手伸进网页里去点那个“预订”按钮。Puppeteer 改变的正是这件事，于是新的 Agent 架构开始成型：模型负责思考和规划，Puppeteer 负责把计划翻译成浏览器动作，浏览器负责与现实世界真正交互。这种“大脑 + 双手”的分工，是 Browser Agent 这波爆发的根本原因。

把视线再放远一点，MCP（Model Context Protocol）正在成为 AI 调用外部工具的新标准，浏览器天然是其中最重要的一类工具。未来典型的链路很可能是这样：LLM 通过 MCP 调用一个 Browser Tool，而这个 Browser Tool 的底层实现，极有可能就是 Puppeteer。换句话说，Puppeteer 不一定会直接暴露给模型，但它大概率会藏在 MCP Browser Tool 的引擎舱里。它正在从一个开发工具，悄悄变成 AI 基础设施的一部分。

顺着这个趋势往下推，未来一两年的判断相对清晰：Browser Agent 会全面爆发；三五年内，MCP 很可能成为 Browser Tool 的统一标准；更长远地看，浏览器或许会成为 AI 操作整个互联网的主要入口，而 Puppeteer 这类框架，会长期蹲守在这条链路的核心位置上。

和 Playwright 比，到底怎么选

每次聊到 Puppeteer，总会有人问：那 Playwright 呢？两者确实渊源很深——Playwright 的核心团队很多就出自 Puppeteer，可以算同门师兄弟。简单对比一下：

如果你的诉求是 Chrome 自动化、Browser Agent 或 AI 工具开发，Puppeteer 依然是起步最快、生态最熟的选择。如果你的重点是企业级跨浏览器测试套件，Playwright 会更顺手。它们不是谁替代谁的关系，而是各自在不同的象限里做到了最好。

写在最后

Puppeteer 最值得关注的地方，从来不是那接近 9 万个 Star，也不是它头顶的 Google 光环。真正重要的是，它解掉了一个长期存在的问题——让程序能够像人一样去操作浏览器。从自动化测试，到网页抓取，再到 Browser Agent，它始终处在每一波技术浪潮的十字路口。

今天重新研究 Puppeteer，学的不只是一个浏览器自动化框架，更是在理解下一代 AI Agent 将怎样接入整个互联网世界。而这，很可能是未来几年软件架构演进里最值得押注的方向之一。