四个浏览器 AI 工具摆在面前,99%的人第一步就选错了

最近我发了一篇关于 Playwright MCP 的文章，很多人提出疑问：

“Chrome DevTools MCP 呢？”
“和 Agent Browser 比哪个好？”
“Playwright CLI 是不是比 MCP 更省 token？”

说实话，看到这些问题的时候我愣了一下。

不是因为问题不好，而是因为——它们都在用同一个错误的框架在思考。

把这四个东西放在一起横评，就好比有人问你：”螺丝刀和电钻和自动装配机器人，哪个好用？”

你没法回答。因为它们根本不在同一个维度上。

今天这篇文章，我不做工具安利，不做功能搬运。我想做一件更有用的事：

给你一套判断框架，以后不管再出什么新的浏览器 AI 工具，你都知道它该放在哪。

先把维度拉对：你不是在选工具，你是在选工作方式

在逐个拆解之前，你需要先建立一个认知。

大多数人比较这四个工具的时候，脑子里的模型是这样的：

四个工具 → 功能对比 → 选最强那个

这个思路看起来合理，但它有一个致命的前提假设——你认为它们是同一类东西。

它们不是。

这四个工具背后，对应的是三种完全不同的工作方式：

一旦你把维度从”工具功能”切换到”工作方式”，整个选择就清晰了。

值得截图保存的判断：你选的不是工具，是”这次任务的决策权交给谁”。给脚本、给 AI 工具、还是给 Agent——这三个选项背后的代价和收益完全不同。

接下来，我按照从简单到复杂的顺序，逐个拆它们的核心价值和真实边界。

Playwright CLI：上下文越紧，它越值钱

常见误区

评论区最高频的一条是：”CLI 比 MCP 省 token。”

对，但只看到这一点，你对它的理解还是停在表层。

省 token 是结果，不是原因。

真正的价值

Playwright CLI 的本质是什么？

它是一个 terminal 命令。AI agent 跑 shell 命令来完成浏览器操作，不需要启动额外的 MCP server，不需要维持持续的页面状态连接，不需要每次 action 都往模型里塞完整的页面快照。

这意味着什么？

在实际开发场景里，你的 context 是有限的。你在 Cursor 里改着代码，上下文里已经塞了项目结构、相关文件、对话历史。这时候如果还要把整个 Accessibility Tree、tool schema、页面快照反复往模型里灌——你的 token 预算会被迅速吃光。

CLI 不占上下文。它是命令式的：你说什么，它做什么，做完就走。

一个真实的 benchmark 数据：完成同样的浏览器任务，MCP 方案消耗约 114,000 tokens，CLI 方案消耗约 27,000 tokens。差了 4 倍多。

如果你做的是批量测试、CI/CD 集成、或者需要在已经很重的 agent 会话里插入一个浏览器动作——CLI 是成本最优解。

安装也很简单：

npm install -g @playwright/cli@latest
playwright-cli install --skills

边界在哪

但 CLI 有一个你必须知道的边界：

它不会”看”，它只会”执行”。

你说”点击按钮”，它点。你说”截图”，它截。但它不会主动观察页面当前是什么状态，不会判断点完之后跳转成没成功，更不会在遇到意外弹窗时自己处理。

打个比方：CLI 就像一个特别靠谱的快递员，你说送到哪他就送到哪，绝不偷懒。但你要是说”帮我判断一下这个地址对不对”——他做不了。

你交代到的，它精准执行。你没交代的，它当不存在。

这就引出了下一个问题：如果你需要 AI 边看边做呢？

Playwright MCP：不是多了个”M”，是多了一双眼睛

常见误区

很多人觉得 Playwright MCP 和 Playwright CLI 是同一个东西的两种用法。

不是。

它们的工作方式有本质区别。

真正的价值

Playwright MCP 做的事情是：把浏览器的完整能力通过 MCP 协议暴露给 AI，让 AI 在整个任务过程中持续感知页面状态。

什么意思？

它会启动一个真实的浏览器实例，每执行一个动作，都会返回完整的页面快照（通过 Accessibility Tree）。AI 不是盲点盲跑，而是：

看一眼 → 判断 → 行动 → 再看一眼 → 再判断 → 再行动。

这就是它和 CLI 最本质的差别。

举个具体的使用场景：

你让 AI 帮你验证一个注册流程。用 CLI 的话，你得把每一步都写清楚——打开页面、填用户名、填密码、点提交、检查跳转。如果中间有一步不符合预期（比如密码强度校验没过），CLI 不会停下来分析原因，它只会继续执行下一步或者直接报错。

用 Playwright MCP 就不一样了。你可以只告诉它”把这个注册流程往前推进”，它会自己判断当前页面该填什么、点什么，遇到校验失败会看报错提示，然后调整策略。

一句话总结：CLI 卖的是效率，MCP 卖的是感知力。

CLI 像写了一张指令清单交给助理。

MCP 像你站在旁边盯着助理做，它随时能转头问你”老板这一步对吗？”——但现在它自己也能看屏幕了。

边界在哪

Playwright MCP 擅长”做”——推进流程、填表单、点按钮、验证跳转。

但它不擅长”诊断”。

如果你的问题是”页面加载慢是为什么””某个请求返回了 500″”console 里有没有报错”——这些内部状态，Playwright MCP 看不到。

它能看到的是页面的 DOM 结构和可访问性信息。

但 console、network、performance、memory 这些开发者工具层面的信息，不在它的能力范围内。

这就需要另一个工具了。

Chrome DevTools MCP：给 AI 装上一双开发者的眼睛

常见误区

我见过最多的误解是：Chrome DevTools MCP 是”另一个 Playwright MCP”，只不过连的是 Chrome 浏览器。

这个理解差得远了。

真正的价值

Chrome DevTools MCP 的核心不是”操作浏览器”，而是”看浏览器内部在发生什么“。

它能让 AI 看到什么？

• • Console：页面有没有报错、warning
• • Network：请求发了没有、返回了什么、耗时多久
• • Performance Trace：渲染瓶颈在哪、哪个函数执行太慢
• • Memory Snapshot：有没有内存泄漏
• • Lighthouse 审计：页面整体质量评分

这些信息，Playwright MCP 一个都拿不到。

还有一个独有的杀手锏：它能连接你已经打开的浏览器。

什么意思？你平时开发的时候，浏览器里已经登录了各种后台系统。如果用 Playwright MCP，它会启动一个全新的浏览器实例，登录态不在。但 Chrome DevTools MCP 直接 attach 到你正在用的那个 Chrome 上——所有登录态、Cookie、会话状态都保留。

这个能力在实际工作中的价值非常大。

比如你在调试一个线上环境的性能问题，你需要登录后台、打开特定页面、复现特定操作路径，然后抓 performance trace。用 Playwright MCP 的话，你得先解决登录问题。用 DevTools MCP，直接连你当前的浏览器，所有上下文都在。

如果说 Playwright MCP 是一双”能看路的眼睛”，那 Chrome DevTools MCP 就是”X 光机”。它看的不是页面长什么样，而是页面里面在发生什么。

边界在哪

但有一个关键点必须说清楚：

Chrome DevTools MCP 不是一个自动诊断系统。

它能把数据拿给你看，但不能替你做决策。

Performance trace 跑出来了，上面一堆 Long Task，你得自己判断是哪段代码的问题。Memory snapshot 拍了，有没有泄漏，哪个对象该释放，这些决策还是你的。

它是一个极其强大的信息采集工具，但决策者依然是你。

这就引出了最后一个问题：如果连判断也想让 AI 自己做呢？

Agent Browser：从”你告诉它怎么做”到”它自己决定怎么做”

常见误区

最容易犯的错：把 Agent Browser 理解成”工具更多的 MCP”。

不是。

它和前面所有工具的核心区别在一个字：权。

前面三个工具，不管怎么用，决策权都在你手里。你决定开哪个工具、调什么能力、按什么顺序执行。

Agent Browser 是第一次把决策权交给 AI 自己。

真正的价值

Agent Browser 是 Vercel Labs 开源的项目，GitHub 上已经接近 30K stars。

它的工作模式是一个完整的循环：

Goal → Plan → Act → Observe → Retry

你给它一个目标，它自己拆步骤。执行过程中如果遇到问题，它自己观察、自己调整、自己重试。

安装方式：

npm install -g agent-browser
agent-browser install
npx skills add vercel-labs/agent-browser

底层它用的是原生 Rust CLI，做了很多工程优化：紧凑的页面快照（不是粗暴地把整个页面丢给模型）、稳定的元素 refs（不会因为页面动态变化就找不到元素）、持久会话（多步操作之间状态不丢失）。

什么时候用它？

当你的任务是多步骤的、有判断分支的、你自己写步骤都觉得麻烦的。

比如：自动完成一个注册流程——打开注册页、填用户名、生成符合强度要求的密码、填密码、如果有验证码就处理验证码、点提交、检查是否成功、如果失败就根据错误提示调整再来一遍。

这种任务你写成 CLI 命令？步骤太多、分支太多。用 MCP？你还是得告诉它每一步干什么。

但用 Agent Browser，你只需要说：

“完成这个注册流程，用户名随便填，密码满足强度要求，如果遇到验证码或校验失败，自己处理。最终确认进入成功页。”

一旦你的提示词从”点这里、填那里”变成”你自己判断下一步”，你就进入了 Agent Browser 最擅长的区间。

边界在哪

但交出决策权是有代价的。

Agent 可能走弯路，可能重试多次才成功，可能消耗更多的 token 和时间。而且越复杂的页面，Agent 的表现波动越大。

不是所有任务都需要 Agent 来做。能用 CLI 一行命令搞定的事，交给 Agent 就是杀鸡用牛刀。

更重要的是：如果你连任务目标都没想清楚就丢给 Agent，它大概率会迷路。

Agent 不能替你想清楚”到底要干什么”。它只是替你想清楚”具体怎么做”。

完整对比：一张表说清四个工具的定位

这张表建议截图保存。下次纠结选哪个的时候，打开看一眼。

实战决策：三个问题想清楚，选择基本不会错

说了这么多，最后给你一个可以反复使用的决策框架。

以后遇到任何浏览器 AI 工具的选择，就问自己三个问题。

第一问：这次任务，决策权给谁？

• • 给脚本（流程确定、不需要判断）→ Playwright CLI
• • 给 AI 工具（需要 AI 参与判断，但你来引导方向）→ MCP 系列
• • 给 Agent（你只给目标，让它自己搞定）→ Agent Browser

第二问：如果给 AI 工具，重点是”做”还是”看”？

• • 重点是推进流程（填表、点击、验证跳转）→ Playwright MCP
• • 重点是诊断状态（查报错、看请求、抓性能）→ Chrome DevTools MCP

第三问：工具开了几个？

这个问题看似简单，但很多人栽在这里。

你同时开了 Playwright MCP 和 Chrome DevTools MCP，AI 不知道该调哪个。你把 Agent Browser 和 MCP 同时给 Agent，它会在两套能力之间反复横跳。

能只开一个就别开两个。工具重叠，Agent 会迷路。

这三个问题是一套可复用的”元判断”。不管以后再出什么新的浏览器 AI 工具，你都可以用这三个问题把它定位到正确的象限里。

组合使用的正确姿势

虽然我说能开一个就别开两个，但在真实项目中，你不可能只用一个工具打天下。

关键在于分阶段用，而不是同时开。

比如一个完整的前端开发流程：

1. 1. 开发阶段：用 Playwright CLI 做快速冒烟测试，token 消耗低，验证基本功能。
2. 2. 调试阶段：发现问题了，切换到 Chrome DevTools MCP，让 AI 帮你抓 console 报错、网络请求、性能 trace。
3. 3. 回归测试阶段：用 Playwright MCP 做交互验证，让 AI 模拟用户操作路径，边看边推进。
4. 4. 复杂场景验证：多步骤流程（注册、支付、审批）交给 Agent Browser，给目标让它自己跑。

在不同阶段激活不同工具，而不是把四个工具一起丢给 Agent。

还有一个容易踩的坑：不要用 Agent Browser 去做诊断。它擅长推进流程，但看 console 报错不是它的强项。反过来，也不要用 Chrome DevTools MCP 去自动填表——那是 Playwright MCP 的活儿。

让每个工具做它最擅长的事。这不是工具的问题，是你给 AI 定义工作边界的问题。

一个更深层的判断

写这篇文章的时候，我一直在想一个问题。

这四个工具的边界，一定会越来越模糊。

今天 Playwright MCP 不能看 console，明天可能就能了。今天 Agent Browser 不擅长诊断，半年后可能就支持了。今天你还在手动判断该开哪个工具，再过一阵子，Agent 自己可能就知道该调谁了。

工具会融合，能力会趋同。

但有一件事，我觉得很长一段时间内不会变：

你得先想清楚，这次任务的决策权该留在哪。

给人？给脚本？给 AI？给 Agent？

这个判断，目前没有任何工具能替你做。

这也是为什么我不想写一篇”四个工具功能对比”的文章。功能对比三个月就过时了。

但”决策权该给谁“这个思考方式，不会过时。

你以后不管遇到什么新的浏览器 AI 工具，什么新的 MCP 协议，什么新的 Agent 框架——

先别急着装，先问自己：这次任务，我想把决策权放在哪一层？

这个问题一旦想清楚，后面的选择都是顺水推舟的事。