COMPARE /先弄明白,再做选择

Playwright MCP vs Playwright CLI

都能让 AI 控制浏览器,但工作方式完全不同。对于 Coding Agent,CLI 通常更轻;对于探索式 Agent Loop,MCP 依然很有价值。

一句话结论

对大多数 Coding Agent 用户,先试 Playwright CLI。

这不是说 Playwright MCP 没用了。不同任务,用不同工具。

主要使用 Coding Agent,并且能执行 Shell

优先试 Playwright CLI

  • 例如 Codex、Claude Code、Copilot 类 Coding Agent
  • 命令更精简,不需要长期加载大型 MCP Tool Schema
  • Skills 可以按需加载
  • 适合同时处理大型代码库和浏览器操作
需要探索式浏览器 Agent

Playwright MCP 更合适

  • 需要 AI 持续探索陌生网页、观察页面并分析结构
  • 长时间保持浏览器状态并连续操作
  • 需要结构化 MCP Tools 或专门的 Agent Loop
  • 已经有成熟的 MCP 工作流

Playwright CLI

命令式工作流

VS

Playwright MCP

结构化工具连接

Playwright 官方怎么区分?

让能执行 Shell 的 Coding Agent 通过简洁命令使用浏览器; 则把浏览器能力作为结构化工具交给 ,适合持续观察页面、操作、再推理的循环。

Playwright 官方将 Claude Code、Copilot 等作为 CLI 的目标场景。对于能直接执行 Shell 的 Codex 工作流,优先试 CLI 是本站结合其工作方式给出的编辑建议,不是声称官方单独要求 Codex 使用 CLI

来源:Playwright Coding Agents 文档MCP 官方定位

核心比较表

先看你要完成什么,再看哪种接口更顺手。

左右滑动,查看两种方案的完整对比 →

你关心的Playwright CLIPlaywright MCP
更适合Coding Agent专门 Agent Loop / 探索式自动化
调用方式Shell CommandsMCP Tools
Context / Token相对更低相对更高
Tool Schema不需要长期加载大型 MCP SchemaMCP Tool Schema 进入上下文
Skills支持按需安装 Skills不以 Skill 为核心调用方式
默认浏览器模式HeadlessHeaded
页面理解Accessibility SnapshotAccessibility Snapshot
浏览器状态Persistent daemon / sessionsPersistent profile / session
配置方式npm 安装 CLIMCP Client 配置
Coding Agent更自然按需
陌生页面探索可以更适合
是否要求 MCP Client

按使用场景选择。这里比较工作方式,不代表本站做过 Token Benchmark 或通用兼容测试。

“相对更低”不等于没有 Context 消耗。 CLI 仍会产生输出和页面 Snapshot。下面会解释为什么这很重要。

工作方式、默认模式和上下文差异参考 官方 MCP / CLI 比较;会话、Skills 与命令参考 CLI 官方文档

CLI 是怎么工作的?

Playwright CLI 让 Agent 直接运行命令。例如,先打开网页,再读取页面快照:

bash
playwright-cli open https://example.com
playwright-cli snapshot

交互命令可以像这样:

bash
playwright-cli click e15
playwright-cli type "hello"
playwright-cli screenshot

CLI 操作后可以返回当前页面状态和 Accessibility Snapshot,Agent 再根据其中的 element ref 继续下一步。

来源:官方命令与元素定位说明

CLI 为什么对 Coding Agent 友好?

1. Agent 本来就会执行 Shell

Coding Agent 日常已经通过 npm、git、test、build、lint 和其他 CLI 工作。浏览器操作也走命令行,可以自然衔接既有的开发流程。

2. Tool 定义更轻

不需要在模型上下文中持续暴露大型 MCP Tool Schemas。浏览器命令和输出可以保持相对精简。

3. Skills 按需加载

Playwright CLI 支持安装 Skills:

bash
playwright-cli install --skills

Coding Agent 可以加载这些 Skills,获得更丰富的命令使用说明,不必一直携带整套 MCP 工具定义。

4. 可以保持浏览器进程

CLI 不意味着每条命令都重新启动浏览器。 Playwright CLI 使用持续的浏览器进程,并支持 Sessions,让多次操作在同一会话中继续。

来源:CLI SkillsCLI Sessions

MCP 是怎么工作的?

Playwright MCP 运行一个 MCP Server。支持它的 AI Client 可以看到一组结构化 Tools,例如:

  • browser_navigate
  • browser_snapshot
  • browser_click
  • browser_hover

Agent 通过结构化参数调用这些工具,而不是自行组织每条 Shell 命令。

来源:Playwright MCP Tools

MCP 为什么仍然有价值?

1. 探索陌生网页

如果 Agent 不知道页面结构,需要在操作过程中不断了解页面,这种循环很适合 MCP:

text
打开页面
↓
读取 Snapshot
↓
判断下一步
↓
点击
↓
再读取
↓
继续推理

2. 持续 Agent Loop

长时间浏览网页、反复分析页面结构、持续保持浏览器状态时,MCP 的工具调用方式很自然。

3. MCP Client 统一工具体验

已经在 MCP 工具体系中管理 GitHub、Notion、Database 和 Browser 的用户,可能更喜欢统一接入与调用方式。

4. 结构化 Tool Calling

Agent 能够明确看到 Browser Tools 及其参数,而不是自己决定 Shell command。

这也是 官方 README仍强调探索式自动化和持续 Agent Loop 的原因。MCP 并没有因为 CLI 出现就失去用途。

为什么大家都在讨论 Token?

是模型处理文本时使用的单位, 则是它当前处理任务能参考的信息。

MCP 通常需要让模型知道:有哪些 Tools、每个 Tool 怎么调用、参数是什么。浏览器交互还会不断产生页面 Snapshot,这些都会占用 Context。

CLI 使用更简洁的命令,也可以通过 Skill 按需提供说明,因此 Playwright 官方比较将 CLI 的 Token Cost 标为相对更低

但不要把它理解为“CLI 不消耗 Context”,更不要把不同 Client、任务和加载方式下的结果混成一个固定百分比。本站没有提供 Token 量化 Benchmark。

同样是测试注册页面,两种方式有什么不同?

MCP:通过结构化工具沟通

text
调用 browser_navigate
↓
读取 Snapshot
↓
调用 browser_click
↓
填写表单
↓
再次读取 Snapshot
↓
判断结果

“填写表单”在这里是流程动作,不是一个叫 browser_fill 的固定 Tool 名称。这是一张沟通方式示意图,不是可以直接执行的测试脚本。

CLI:通过命令沟通

text
执行 CLI 命令
↓
读取命令返回的 Snapshot
↓
执行下一条 CLI
↓
检查结果

最终都可能完成浏览器操作。真正差别是:AI 与浏览器之间“怎么沟通”。

如果你使用 Codex

日常网页开发 / QA / 测试

优先试 Playwright CLI。

Codex 属于能够执行命令、操作代码和运行开发工具的 Coding Agent 类型。Playwright 官方面向 Coding Agents 推荐 CLI;对于能够直接执行 Shell 的 Codex 工作流,这种模式通常很自然。

这是按工作方式给出的编辑建议,不是“Playwright 官方明确推荐 Codex CLI”。

长时间探索网页

Playwright MCP 值得考虑。 特别是需要持续观察、反复推理页面结构和连续操作时。

已有成熟 MCP 工作流

不需要为了 CLI 强制迁移。先看当前工具是否真的带来问题。

如果你使用 Claude Code

Playwright Coding Agents 文档明确将 Claude Code 作为 CLI 的目标场景之一。

  • 日常 Coding:CLI 优先考虑。
  • 探索式自动化:MCP 按需。

同一个人可以在不同任务中使用不同方式,不必做一次永久的二选一。

已经装了 Playwright MCP,要不要删?

不一定。

如果运行稳定、经常使用、Context 没有成为明显问题,而且工作流依赖 MCP Tools,继续用即可。

如果很少调用、主要只是做网页测试、Agent 本身有 Shell,而且你想精简 MCP 数量,可以尝试 CLI。

少装一点,不是为了少而少。 是让每一个留下来的工具都有明确用途。

CLI 安装

下面只展示官方命令,本站不会自动执行。选择适合你项目的安装方式即可。

全局安装

bash
npm install -g @playwright/cli@latest

查看帮助:

bash
playwright-cli --help

安装 Skills:

bash
playwright-cli install --skills

作为项目开发依赖

bash
npm install -D @playwright/cli@latest

然后:

bash
npx playwright-cli --help

来源:Playwright CLI 官方安装方式

CLI 第一次使用

打开官方 TodoMVC 示例,并显示浏览器窗口:

bash
playwright-cli open https://demo.playwright.dev/todomvc/ --headed

然后截图:

bash
playwright-cli screenshot

这是最小体验示例,不是完整测试流程,也不代表本站已实际执行验证。

来源:Playwright 官方 Manual Walkthrough

默认模式有什么区别?

Playwright CLI 默认 Headless,即不显示浏览器窗口。需要看到浏览器时可以这样打开:

bash
playwright-cli open https://example.com --headed

Playwright MCP 默认 Headed,即显示浏览器窗口。

来源:官方默认模式比较

它们其实也有很多共同点

两者都基于 Playwright,能操作浏览器、使用结构化 Accessibility 信息、支持主流浏览器、截图,并保持一定形式的浏览器状态。

它们都服务于 AI / Agent 自动化,区别主要在接入方式和目标工作流,而不是一个“有浏览器能力”、另一个“没有”。

常见误区

CLI 就是“低配 MCP”?

不是。它是不同的 Agent 交互方式,不是删减版接口。

有了 CLI,MCP 就没用了?

不是。两者目标场景不同,探索式 Agent Loop 仍然是 MCP 很有价值的场景。

MCP 一定非常浪费 Token?

过度简化。不同 Client、工具加载方式和任务都会影响实际 Context 使用。当前官方将 CLI 描述为相对更节省 Token,不等于任何任务都能套用同一个比例。

CLI 每次命令都会重新启动浏览器?

不是。Playwright CLI 使用持续浏览器进程,并支持 Sessions。

30秒决定你应该选哪个

从第一问开始;看到“继续下一问”再往下走。

  1. 01

    你的 AI 能执行 Shell 吗?

    YES继续下一问
    NOPlaywright MCP
  2. 02

    主要在大型代码项目里做网页开发 / 测试吗?

    YESPlaywright CLI
    NO继续下一问
  3. 03

    经常让 AI 自己探索陌生网页并持续操作吗?

    YESPlaywright MCP
    NO先试 Playwright CLI

这只是快速建议,不是绝对规则。选择 MCP 的前提是客户端支持 MCP;已有稳定工作流无需强制迁移。

接下来读什么?

需要判断 MCP 是否适合你、以及如何安装和卸载,可以继续看 Playwright MCP 值得装吗?

如果这些词还不熟悉,先看 MCP 是什么CLI 是什么Agent 是什么Context 是什么Token 是什么。不必先掌握所有黑话才开始选择。

相关词条

继续把这些有关联的概念弄明白。

信息来源与最后核对

依据官方文档核对整理。官方定位与本站选择建议分别说明,未进行插件实测或 Token Benchmark。

官方资料

01
Playwright Coding Agents documentationplaywright.dev
02
Playwright CLI Introduction · 官方 READMEgithub.com
03
Playwright MCP Introductionplaywright.dev
04
Playwright MCP GitHub READMEgithub.com
05
Playwright CLI Installationplaywright.dev

最后核对: 2026年9月3日

official-docs