「Agent随笔」03 对比几款Agent浏览器工具

前面两篇文章介绍了 Chrome 的 CDP（Chrome DevTools Protocol），这是一切外部软件操纵 Chrome 的基础，还介绍了 MCP 和 Skills 的一些基本原理，以及选择方法。然后，咱们继续说说具体的几款 Agent 浏览器工具，先做个简要的介绍，最后再进行对比。

Playwright

Playwright 是微软开源的浏览器自动化与端到端测试框架，2020年1月31日正式发布的，是的，早于这波 AI 的大爆发。

Playwright 与当时同类产品相比，充分考虑了页面的各种复杂情况，无需开发者自己编写繁琐的代码来维持使用过程中的可靠性和稳定性。而且还能支持三种浏览器内核，Chromium、Firefox、WebKit。

2024年底 MCP 发布后，Playwright 于 25年3月发布了@playwright/mcp，又在10月提供了专门供 agent 使用的 CLI 的能力。然后在今年初，也就是26年初，将@playwright/cli独立打包发布。

官方建议选择 Skills + CLI 的使用方式接入 agent，你可以通过下面这段命令安装 playwright-cli 这个 Skill：

npx skills add https://github.com/microsoft/playwright-cli --skill playwright-cli

它会引导你安装并使用@playwright/cli来操纵浏览器。

后文中涉及的所有 Skills，你都可以在 https://www.skills.sh/ 搜索到，并通过npx skills add命令安装，我就不重复安装方法了。

Chrome DevTools for agents

Chrome DevTools MCP 是 Google Chrome 团队于2025年9月23日发布的，并在今年2026年3月11日添加了 CLI 功能。然后在5月19日发布了正式版v1.0。

与 Playwright 提供了 MCP 和 CLI 两个 npm 包不同，Chrome DevTools MCP 只有一个chrome-devtools-mcp，MCP 和 CLI 都包含在其中。不过从功能层面看，CLI 只是 MCP 的一个子集，所以如果使用 Chrome DevTools MCP 应该优先选择 MCP。

从官方定位来看，它们只是把 CLI 当做了 MCP 的补充，因为有一些复杂的开发调试工作并不适合通过 CLI 来实现。像wait_for工具，它会持续轮询等待特定元素的出现，显然并不适合做成 CLI。

虽说推荐用 MCP，但是还是需要用到 Skills。之前说过 Skills 是对知识技能的封装，并不是天然与 CLI 组合使用的，也可以和 MCP 组合使用。官方提供了6个 Skills：

• chrome-devtools，指导 agent 如何使用 MCP
• chrome-devtools-cli，指导 agent 如何使用 CLI
• a11y-debugging，指导 agent 做无障碍设计
• debug-optimize-lcp，指导 agent 做 LCP 调优
• memory-leak-debugging，指导 agent 排查内存泄漏
• troubleshooting，指导 agent 排查 CDP 故障 前两个就是我们操作浏览器时需要的 Skills，一个用于 MCP，一个用于 CLI，后四个普通用户一般用不到，我也没用过，就不说了。

Puppeteer

Chrome DevTools MCP 并不是从零做起的，它底层使用了另一个 Node.js 库，就是 Puppeteer，实际使用时负责连接和使用 CDP 的就是它。

Puppeteer 也是 Google Chrome 团队推出的，只是历史更久一些，是2017年首次发布的。而且开发团队的核心成员在2019年加入了微软，然后就对标 Puppeteer 开发了 Playwright。

Puppeteer 只是一个 Node.js 库，并不适合 agent 直接使用，所以 Google 才专门为 agent 场景开发了 Chrome DevTools MCP。Puppeteer 不在咱们今天的选择范围之内，只是因为它跟两款 agent 浏览器工具都有关系，所以顺便提一句。

Browser Use

前面两款分别是微软和谷歌开发的，大家用的都比较多。而这一款是这几个工具中，Github 星最多的，目前有110k，排第二的是 Playwright，94.7k，第三是 Chrome DevTools MCP，49.3k。

2024年11月5日，Gregor Žunič 在 Hacker News 上发布帖子“Show HN: I wrote an open-source browser alternative for Computer Use”，介绍了他与 Magnus Müller 共同开发的产品 Browser Use。

在那不久之前的2024年10月22日，Anthropic 刚刚发布了 Claude 3.5 Sonnet 的 Computer Use 公测版。两位作者敏锐地意识到，多数团队想解决的其实不是如何操作整台电脑，而是更聚焦如何操作浏览器这一个场景。于是他们只花了大概5天时间，就开发出了第一版 Browser User。

第一版 Browser Use 发布时还没有 MCP 这个概念，它是以 Python 库的形式提供给 agent 使用的，也就是说需要 agent 根据用户对话来生成调用 Browser Use 的脚本，然后执行脚本来操作浏览器。而且这版 Browser Use 底层使用的是 Playwright。

也就是说使用路径是，用户对话，agent 生成脚本，脚本调用 Browser Use，Browser Use 调用 Playwright，Playwright 连接 CDP，然后操作浏览器。显然为了快速上线而引入的 Playwright 早晚会成为长期的技术债。

于是到了2025年8月19日，Browser Use 正式放弃了 Playwright，改为通过自研的 cdp-use 直接调用 CDP。然后11月21日发布了 MCP，转年2026年3月22日发布了 CLI 2.0，7月1日发布了 CLI 3.0。

最新发布的 CLI 3.0 值得我们关注一下，因为它操作浏览器的方式已经从过去的单个 CLI 命令，变成了直接编写脚本的方式来操作浏览器了。它底层的思想应该来自于 Anthropic 去年底的一篇文章《Code execution with MCP: Building more efficient agents》。

说的是大量的工具调用，会使上下文过载，消耗过多的 token，直接编写脚本来执行工具可以解决这些问题。而且从 Browser Use 自己的测试来看，由 AI 来编写脚本，处理任务的容错性更高，效果更好。

所以 Browser Use 的 Skills 是在指导 agent 如何编写脚本来操作浏览器的。官方提供了6个 Skills，本地使用的话主要就是 browser-use 和 open-source 两个，第一个教你如何写脚本操作浏览器，第二个是文档说明。

Browser Use 官方是提供云端托管浏览器服务的，你可以直接提交一个自然语言的任务，让托管服务执行，也可以只使用托管浏览器的 CDP。从官方描述看云端托管版能提供更强的隐身反检测、代理轮换、验证码破解、应用集成等能力。不过我没用过，就不细说了。

Agent Browser

Agent Browser 是 Vercel Labs 团队开发的开源浏览器自动化命令行工具，于2026年1月发布。Agent Browser 使用 Rust 开发，所以启动速度，资源占用上比其他工具更有优势。

选这款主要是因为 Vercel，这家有着赛博菩萨之称的网站。同时它的 GitHub star 数是40.9k，仅次于前面几款工具。我的个人网站也像好多站长一样，是部署在他家的，功能强大且免费。前面说的查找 Skills 的网站 https://www.skills.sh/ 也是他家的。

Agent Browser 也只发布了一个包，里面包括了 MCP 和 CLI。CLI 提供了全量工具，而 MCP 默认只提供更精简的能力，但可以按需扩展。官方还是建议使用 Skills + CLI，也只提供了一个 Skill，agent-browser。

对比

侧重

这些工具在产品层面上是有侧重点的。Chrome DevTools MCP 就相当于是 Chrome 浏览器自家的产品，能力上最全面，它主要的适用场景是页面调试，性能测试这类开发场景，在这方面其它工具都没有与它竞争。

Playwright 早在这波 AI 浪潮之前就有了，它主要解决的是自动化测试的问题。虽然它很早就向 agent 工具提供 MCP 能力的，但并非是一个原生的 agent 浏览器。这就给竞品提供了空间。

于是就有了之后的 Browser Use 和 Agent Browser。这两款都是专门针对 agent 场景开发的，就是给 agent 用的，所以在能力上必然会有一些优势。

能力

Agent 通过这些浏览器工具与 CDP 交互，一来一回都要经过 LLM，Browser Use 和 Agent Browser 既然是专为 agent 开发的，那么它们就希望能在这一来一回中做尽可能的优化。

前面也提到了 Browser Use CLI 3.0 的使用方式很特别，它不是一个个 shell 命令，而是需要你直接输入一段 Python 脚本。通过这种方式，Browser Use 可以利用 LLM 针对用户的各种需求，非常灵活的编写脚本来操作浏览器。这样就可以充分发挥大模型的智能，最接近于让 AI 浏览和操作网页。

而 Agent Browser 则在 CLI 层面上支持了批量操作，可以一次传入多条操作命令。虽然它不如 Browser Use 的脚本灵活，但是一个确定性的命令列表可控性更好，而且非常适合反复使用，可以积累成一个长期的测试资产。

Playwright 也支持执行脚本，但它只是 CLI 命令的一个补充，执行的是 Playwright 提供的 API，不像 Browser Use 是完全自由的 Python 脚本，所以灵活性差些，但更像 Agent Browser 那样有更高的可控性和可复现性。

Token

网页的源码包含了大量重复的标签格式和样式信息，而 agent 更多关注的是页面中显示了什么内容，以及可以做什么操作。这些工具都是通过 accessibility tree（a11y tree） 技术来保留语义有意义的元素的，例如标题、列表、表单控件等。

相比于网页源码，使用 a11y tree 可以大大节省 token。不同的工具也都对 a11y tree 有自己的优化方案。Browser Use 在长对话中会维持固定量的快照数据，以避免产生过多 token。Agent Browser 针对同一页面的多次访问会记录增量，如果是只读请求还会干脆不启动浏览器，直接走 fetch 工具。

而 Playwright 采用了渐进式披露的方案，先把数据写入文件，只把文件列表注入上下文，让 agent 根据需要再去读取文件，这样某些场景下可以将 token 减少到极致。

如今各家大模型普遍有了百万上下文，而且我还有无周限额的 Coding Plan，所以对 token 消耗不是很敏感。但如果你没赶上这波无周限额的话，就根据自己的场景和它们的策略选择合适的工具，能省点儿就省点儿。

Pipe？WebSocket？

最后说的这个是架构上的一些取舍，从使用的角度应该是感受不到的，不过还是能从架构取舍上看出各个工具的自我定位，对你的选择也能有所帮助吧。

之前说过 CDP 提供了两种连接通道 Pipe 和 WebSocket，如果是连接外部的 Chrome，必然需要用 WebSocket，而如果是工具自己以子进程启动的 Chrome 则是可以使用 Pipe 的。理论上来说肯定是 Pipe 性能更好，还不用暴露端口，但你又不能放弃连接外部 Chrome 的能力。

Playwright 和 Chrome Devtools MCP 是两种方式都支持的，而 Browser Use 和 Agent Browser 则只支持 WebSocket。我们来看看它们底层的选择逻辑。

Playwright 是 AI 时代之前的产物，它当时为了更加通用，支持了三种浏览器引擎，Chromium、Firefox、WebKit。同时还支持四种编程语言的接入，Typescript/JavaScript、Python、Java、.NET(C#)。

所以它在架构上设计了一个中间翻译层 Node driver，然后中间层选择了性能更优的 Pipe 方式连接到三种不同的浏览器引擎。只有在连接外部 Chromium 时才使用 WebSocket，而另外两种浏览器引擎甚至都不支持连接外部浏览器。

Chrome DevTools MCP 底层使用的是 Puppeteer，Puppeteer 默认是用 WebSocket 连接 CDP 的，但是 Chrome DevTools MCP 对这一策略进行了覆盖，默认使用 Pipe 来连接 CDP。

一方面 Pipe 性能更好，但更重要的是，对于 Chrome DevTools MCP 来说，它们很介意开放 WebSocket 端口所带来的安全隐患。之前介绍过，当你开启这个 WebSocket 端口后，你本地的任何程序都有可能连接到你的这个浏览器，甚至你不小心开放了网络权限，其他网络节点也能连接的话就更不安全了。

Playwright 和 Chrome DevTools MCP 本身主要是用于浏览器相关的开发调试场景的，在这种场景下，通过 WebSocket 连接外部浏览器并不是一个强需求。

而 Browser Use 和 Agent Browser 从一开始就是为 agent 设计的，连接用户平时使用的 Chrome 就是它们的核心使用场景，更别说这两个工具的所属公司都有浏览器的云托管服务，那更是需要 WebSocket 来连接它们的云端产品。

所以对他们来说 WebSocket 才是核心的使用场景。而且它们的技术栈，Browser Use 是 Python，Agent Browser 是 Rust，都没有现成的通过 Pipe 连接 CDP 的工具包，自己开发还是需要不少成本的。

而如果采用 Playwright 的翻译层方案，显然是有些过重了，所以后来 Browser Use 放弃了 Playwright，自己又重新实现了一份。

总结

对于哪一款 agent 浏览器工具好用这个问题，没有一个统一答案，关键还是看你自己的使用场景。你是自动化测试，还是页面性能调优，还是抓取数据，还是自动化操作，你要操作的网页结构是否稳定，你是否对 token 消耗很敏感等等，然后结合自己的场景和工具特点找合适的。

如果你对这些都还没有概念，那就随便找一个先用着，等遇到问题了再说。Agent 发展很快，说不定等你遇到问题时，就又有新的工具，新的方案了，现在这些参考意义就不大了。

我这三篇文章是因为自己整理 Skills 才写的，不过写出来就不只是 Skills 了，浏览器相关的就写这些了，下一篇还没想好，下周再说吧。