Playwright 官方怎么区分?
让能执行 Shell 的 Coding Agent 通过简洁命令使用浏览器; 则把浏览器能力作为结构化工具交给 ,适合持续观察页面、操作、再推理的循环。
Playwright 官方将 Claude Code、Copilot 等作为 CLI 的目标场景。对于能直接执行 Shell 的 Codex 工作流,优先试 CLI 是本站结合其工作方式给出的编辑建议,不是声称官方单独要求 Codex 使用 CLI。
来源:Playwright Coding Agents 文档和 MCP 官方定位。
核心比较表
先看你要完成什么,再看哪种接口更顺手。
左右滑动,查看两种方案的完整对比 →
| 你关心的 | Playwright CLI | Playwright MCP |
|---|---|---|
| 更适合 | Coding Agent | 专门 Agent Loop / 探索式自动化 |
| 调用方式 | Shell Commands | MCP Tools |
| Context / Token | 相对更低 | 相对更高 |
| Tool Schema | 不需要长期加载大型 MCP Schema | MCP Tool Schema 进入上下文 |
| Skills | 支持按需安装 Skills | 不以 Skill 为核心调用方式 |
| 默认浏览器模式 | Headless | Headed |
| 页面理解 | Accessibility Snapshot | Accessibility Snapshot |
| 浏览器状态 | Persistent daemon / sessions | Persistent profile / session |
| 配置方式 | npm 安装 CLI | MCP Client 配置 |
| Coding Agent | 更自然 | 按需 |
| 陌生页面探索 | 可以 | 更适合 |
| 是否要求 MCP Client | 否 | 是 |
按使用场景选择。这里比较工作方式,不代表本站做过 Token Benchmark 或通用兼容测试。
“相对更低”不等于没有 Context 消耗。 CLI 仍会产生输出和页面 Snapshot。下面会解释为什么这很重要。
工作方式、默认模式和上下文差异参考 官方 MCP / CLI 比较;会话、Skills 与命令参考 CLI 官方文档。
CLI 是怎么工作的?
Playwright CLI 让 Agent 直接运行命令。例如,先打开网页,再读取页面快照:
playwright-cli open https://example.com
playwright-cli snapshot交互命令可以像这样:
playwright-cli click e15
playwright-cli type "hello"
playwright-cli screenshotCLI 操作后可以返回当前页面状态和 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:
playwright-cli install --skillsCoding Agent 可以加载这些 Skills,获得更丰富的命令使用说明,不必一直携带整套 MCP 工具定义。
4. 可以保持浏览器进程
CLI 不意味着每条命令都重新启动浏览器。 Playwright CLI 使用持续的浏览器进程,并支持 Sessions,让多次操作在同一会话中继续。
MCP 是怎么工作的?
Playwright MCP 运行一个 MCP Server。支持它的 AI Client 可以看到一组结构化 Tools,例如:
browser_navigatebrowser_snapshotbrowser_clickbrowser_hover
Agent 通过结构化参数调用这些工具,而不是自行组织每条 Shell 命令。
MCP 为什么仍然有价值?
1. 探索陌生网页
如果 Agent 不知道页面结构,需要在操作过程中不断了解页面,这种循环很适合 MCP:
打开页面
↓
读取 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:通过结构化工具沟通
调用 browser_navigate
↓
读取 Snapshot
↓
调用 browser_click
↓
填写表单
↓
再次读取 Snapshot
↓
判断结果“填写表单”在这里是流程动作,不是一个叫 browser_fill 的固定 Tool 名称。这是一张沟通方式示意图,不是可以直接执行的测试脚本。
CLI:通过命令沟通
执行 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 安装
下面只展示官方命令,本站不会自动执行。选择适合你项目的安装方式即可。
全局安装
npm install -g @playwright/cli@latest查看帮助:
playwright-cli --help安装 Skills:
playwright-cli install --skills作为项目开发依赖
npm install -D @playwright/cli@latest然后:
npx playwright-cli --helpCLI 第一次使用
打开官方 TodoMVC 示例,并显示浏览器窗口:
playwright-cli open https://demo.playwright.dev/todomvc/ --headed然后截图:
playwright-cli screenshot这是最小体验示例,不是完整测试流程,也不代表本站已实际执行验证。
来源:Playwright 官方 Manual Walkthrough。
默认模式有什么区别?
Playwright CLI 默认 Headless,即不显示浏览器窗口。需要看到浏览器时可以这样打开:
playwright-cli open https://example.com --headedPlaywright 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秒决定你应该选哪个
从第一问开始;看到“继续下一问”再往下走。
- 01
你的 AI 能执行 Shell 吗?
是 YES继续下一问否 NOPlaywright MCP - 02
主要在大型代码项目里做网页开发 / 测试吗?
是 YESPlaywright CLI否 NO继续下一问 - 03
经常让 AI 自己探索陌生网页并持续操作吗?
是 YESPlaywright MCP否 NO先试 Playwright CLI
这只是快速建议,不是绝对规则。选择 MCP 的前提是客户端支持 MCP;已有稳定工作流无需强制迁移。
接下来读什么?
需要判断 MCP 是否适合你、以及如何安装和卸载,可以继续看 Playwright MCP 值得装吗?。
如果这些词还不熟悉,先看 MCP 是什么、CLI 是什么、Agent 是什么、Context 是什么和 Token 是什么。不必先掌握所有黑话才开始选择。
相关词条
继续把这些有关联的概念弄明白。
信息来源与最后核对
依据官方文档核对整理。官方定位与本站选择建议分别说明,未进行插件实测或 Token Benchmark。
官方资料
01最后核对: 2026年9月3日
official-docs