Playwright-MCP 使用教程

9.3万星微软开源浏览器自动化,让Codex自己点网站找bug

⭐ 开源免费

📖 项目简介

Playwright 是微软开源的浏览器自动化与端到端测试框架,GitHub 上 9.3 万 Star,Apache-2.0 协议,一套 API 同时驱动 Chromium、Firefox、WebKit 三大浏览器内核。 而 Playwright MCP@playwright/mcp)是官方基于它做的 MCP 服务器,单独就有 3.5 万 Star——它把「操作浏览器」这件事变成了 AI 可以直接调用的工具。

它最关键的技术选择是:不靠截图让模型「看图猜按钮在哪」,而是直接读取页面的无障碍树(accessibility snapshot)。 页面上每个按钮、输入框、链接都以结构化文本的形式交给模型,带着角色、名称和可交互状态。 这带来三个直接好处:不需要多模态视觉模型也能跑、定位是精确的而不是靠坐标估算、token 消耗远低于反复传截图。

装上之后,Codex 就从「只能改代码」变成「能自己打开浏览器验证代码」:你说一句「把注册流程走一遍」, 它自己导航、点击、填表、断言,跑完告诉你卡在第几步、报了什么错,还能把整套复现步骤落成一个 Playwright 测试脚本。 官方文档里明确把 Codex 列在支持的客户端名单中,配置只要三行。

核心亮点

🎯
读结构不看截图
基于无障碍树精确定位元素,不用多模态模型,也不会因为按钮挪了几像素就点错
👀
默认有头模式
浏览器真的弹出来,你能全程看着它点击填表,出问题一眼看出卡在哪一步
🧩
三行配置接 Codex
官方支持客户端名单里就有 Codex,改一下 config.toml 即可,无需写任何胶水代码
🏢
微软官方维护
Playwright 主仓 9.3 万 Star、Apache-2.0,MCP 由同一团队维护,跟随主线版本更新

🧩 它能做什么、输出什么

项目说明
输入自然语言指令,例如「打开这个页面,把注册流程走一遍」「点提交按钮,看有没有报错」
核心动作导航、点击、输入、下拉选择、悬停、拖拽、上传文件、按键、等待、断言、截图、导出 PDF
感知方式无障碍树快照(结构化文本),可选开启 vision 能力组走截图坐标模式
输出页面快照、控制台日志、网络请求记录、截图 / PDF、Playwright 测试脚本、可回放的 trace 文件
浏览器兼容chromium(默认)、firefoxwebkit,也可指定 chrome / msedge 品牌通道
能力组core / core-navigation / core-tabs / core-input / network / storage / testing / vision / pdf / devtools
默认超时动作 5000ms、导航 60000ms、断言 5000ms,均可在配置文件里调整

🖥️ 环境要求

环境建议配置
操作系统Windows 10/11、macOS、Linux 均可
运行环境Node.js 18 及以上(用 npx 拉起服务,装完用 node -v 确认)
硬件不需要显卡。纯 CPU 运行,内存建议 8GB 以上(浏览器本身吃内存)
磁盘浏览器内核约 300MB 到 1GB,取决于装几个内核
关键依赖Playwright 浏览器内核,需要单独跑一次 npx playwright install 下载
无图形界面环境服务器 / CI / Docker 里没有显示器,必须加 --headless 参数,否则起不来
AI 客户端Codex CLI 或 Codex 桌面端(官方支持名单里也包含 Claude Code、Cursor、Cline 等)

🚀 如何使用

💡
整个流程就三件事:装 Node → 改一次 Codex 配置文件 → 下载浏览器内核。全程五分钟,不用写一行代码。
1

确认 Node.js 环境

MCP 服务是靠 npx 拉起来的,所以必须先有 Node.js 18 以上。在终端里执行下面的命令,能打印出版本号就说明没问题;没有的话去 Node.js 官网下载 LTS 版安装。

bash node -v npx -v
2

下载浏览器内核(这一步别跳过)

Playwright 用的是它自己管理的浏览器,不是你电脑上装的那个 Chrome。 不先跑这一步,后面十有八九会报「chrome executable not found」——这是新手最常踩的坑。

bash # 只装 Chromium(够用,体积最小,推荐) npx playwright install chromium # 或者三个内核全装 npx playwright install
3

写进 Codex 配置文件

找到 Codex 的配置文件:Windows 在 C:\Users\你的用户名\.codex\config.toml, macOS 和 Linux 在 ~/.codex/config.toml。文件不存在就新建一个,把下面三行加进去。

toml [mcp_servers.playwright] command = "npx" args = ["@playwright/mcp@latest"]

保存后重启 Codex,用下面两条命令确认它认到了:

bash codex mcp list codex mcp get playwright
4

跑通第一个例子

直接在 Codex 里用大白话说就行,不需要任何命令。默认是有头模式,你会看到浏览器自己弹出来开始操作:

text 先启动我的项目,然后用浏览器打开首页,告诉我页面标题是什么 进入登录页,邮箱填一个测试账号、密码随便填一个, 然后点提交,告诉我有没有报错、报的什么错 把刚才这套操作写成一个 Playwright 测试脚本,存到 tests 目录
⚠️
建议先拿自己的本地项目或官方示例站练手。不要拿它去批量访问别人的网站,既容易触发风控,也可能违反对方的服务条款。
5

进阶:常用启动参数

参数都加在 args 数组里,跟在包名后面。比如要在服务器上跑无界面模式加断网调试:

toml [mcp_servers.playwright] command = "npx" args = [ "@playwright/mcp@latest", "--headless", "--isolated", "--viewport-size", "1280x720", "--save-trace", "--output-dir", "./pw-artifacts" ]

常用参数说明:

参数作用
--headless无界面运行。服务器 / CI / Docker 里必须加,本地调试建议不加,方便肉眼看它怎么点的
--browser选内核:chromium(默认)/ firefox / webkit / chrome / msedge
--isolated每次用全新的内存态配置,不留 Cookie 和登录态,跑测试要的就是这种可重复性
--user-data-dir与上一条相反,把配置持久化到指定目录,登录态跨会话保留
--storage-state指向一个登录态 JSON 文件,让它一启动就是已登录状态,省去每次跑登录流程
--viewport-size指定窗口尺寸,如 1280x720。截图要稳定就固定住它
--device模拟设备,用来测移动端页面的响应式布局
--caps开启额外能力组,逗号分隔,如 tabs,pdf。排查「一个工具都没有」时先把它去掉
--save-trace录制完整操作轨迹,事后用 npx playwright show-trace 逐帧回放它干了什么
--proxy-server让浏览器走代理,公司内网环境常用
--config参数太多时改用 JSON 配置文件,超时时间、网络白名单等高级项只能在这里设
6

结合 Codex 的三种实用姿势

① 改完代码顺手自测。让 Codex 改完前端后直接说「起服务,把这个页面点一遍看有没有报错」, 它会自己开浏览器验证,而不是嘴上说「应该没问题」。

② 把手工回归变成脚本。先让它手动走一遍流程,走通后说「把刚才的操作写成 Playwright 测试」, 以后这条用例就进 CI 了,等于用大白话攒测试用例。

③ 复现线上 bug。把用户描述的操作步骤丢给它,让它照着点一遍, 配合 --save-trace 录下轨迹,网络请求和控制台报错全都在里面。

核心变化是:Codex 从「只能改代码」变成了「能自己验证代码」,改完到确认之间那一段手工点击彻底省掉了。

🎯 典型应用场景

🐛
改完代码自测
前端改完让它自己点一遍,报错、白屏、按钮失效当场暴露,不用等测试同学
📝
用大白话攒用例
手动走通一遍流程后让它落成 Playwright 脚本,回归用例越攒越多
🔁
复现线上问题
照着用户描述的步骤点一遍,配合 trace 回放,网络请求和控制台报错全留痕
📱
响应式验收
用 device 参数模拟不同机型,一次性检查移动端布局有没有错位
🔀
跨浏览器对拍
同一套操作在 Chromium、Firefox、WebKit 各跑一遍,揪出内核兼容问题
📄
页面转 PDF / 截图
开启 pdf 能力组后,让它把指定页面批量导出成 PDF 或长截图存档

📈 项目现状与技术原理

指标数据
Playwright 主仓 Star93,738(微软官方,Apache-2.0 协议)
Playwright MCP Star35,664(同团队维护,随主线更新)
支持浏览器内核Chromium、Firefox、WebKit 三大内核,一套接口通吃
硬件门槛纯 CPU,无需显卡,与本地大模型方案相比几乎零成本
默认超时动作 5000ms / 导航 60000ms / 断言 5000ms
🧠
为什么它比「截图给模型看」的方案准得多:浏览器本身为读屏软件维护了一棵无障碍树, 上面标注了每个元素的角色(按钮 / 输入框 / 链接)、可见文本和交互状态。 Playwright MCP 直接把这棵树序列化成文本交给模型,模型返回的是元素引用而不是像素坐标—— 所以按钮换个位置、页面缩放比例变了都不影响命中,而且省掉了传图片的那部分 token。

常见问题

Q: 报错「chrome executable not found」怎么办?

这是最高频的问题,原因是只配了 MCP 但没下载浏览器内核。 执行 npx playwright install chromium 装一次就好。 如果装完还报错,可以先 npm install -g @playwright/mcp 做全局安装再试。

Q: Playwright 和 Playwright MCP 是什么关系?两个都要装吗?

Playwright 是底层的自动化框架,Playwright MCP 是官方基于它封装的 MCP 服务器。 你不需要单独安装 Playwright 框架npx @playwright/mcp@latest 会自动把需要的部分拉下来, 你只要额外下载一次浏览器内核即可。

Q: 配好了但 Codex 里一个工具都看不到?

按顺序排查:① codex mcp list 看服务在不在;② 确认改的是 .codex/config.toml 而不是别的配置文件; ③ 确认改完重启过 Codex;④ 如果加了 --caps,先把它整个删掉——写了不存在的能力组名会导致工具列表变空, 恢复默认后确认工具出现,再逐个加回去。

Q: 一定要弹出浏览器窗口吗?能不能后台跑?

默认是有头模式,方便你看它在干什么。加 --headless 就是后台运行。 注意反过来也成立:服务器、CI、Docker 这类没有图形界面的环境必须加 --headless,否则浏览器根本起不来。

Q: 需要显卡吗?配置要求高不高?

完全不需要显卡。它不在本地跑模型,只是驱动浏览器,推理还是走你 Codex 原本用的模型。 内存 8GB 以上就够,主要开销来自浏览器进程本身。

Q: 要测的页面需要登录,每次都得让它走一遍登录流程吗?

不用。先用 Playwright 把登录态导出成一个 storage state 的 JSON 文件,然后用 --storage-state 指向它, 服务一启动就是已登录状态。实践中常和 --isolated 搭配用:每次都是干净环境,但登录态是注入好的,既可重复又免登录。

Q: 它和 browser-use 这类工具有什么区别?

最大区别在感知方式。多数同类工具靠截图 + 视觉模型判断点哪里,依赖多模态能力且容易点偏; Playwright MCP 读的是无障碍树,定位精确、不吃视觉模型、token 开销也更低。 另外它出自微软 Playwright 团队,和成熟的测试生态(trace 回放、测试脚本生成、CI 集成)是打通的。

Q: 出问题了怎么知道它到底点了什么?

--save-trace--output-dir,它会把整个会话录成 trace 文件, 之后用 npx playwright show-trace 文件路径 打开,每一步动作、每个网络请求、每个 DOM 快照都能逐帧回看。

Q: 可以商用吗?

可以。Playwright 采用 Apache-2.0 协议,允许商用、修改和再分发,只需保留版权声明。 但要注意:协议管的是软件本身,不代表你可以随便去自动化访问第三方网站——那要看对方网站的服务条款。