Playwright MCP实战指南:从环境搭建到AI驱动浏览器自动化
MCP 协议火了快一年,真正让我觉得“这东西从玩具变成工具”的瞬间,是把 Playwright MCP 跑通的那一刻。说白了,Playwright 负责真的打开浏览器、点按钮、填表单、抓接口,MCP 负责把这些能力包装成标准工具给 AI 调用,你在对话框里说一句“去这个页面把我没看完的文章收藏一下”,剩下的事由模型自己编排。这篇指南不是概念科普,而是从零到能跑通、再到能处理真实业务的完整路径:怎么安装、怎么配置、怎么解决登录态和 iframe 这类“劝退点”、怎么和 Figma MCP 以及自建的 MCP Server 联动。适合正在做 AI Agent 落地、Web 自动化和前端质量保障的同学参考,尤其适合那些已经受够了“脚本一改页面就崩”的人。
1. 先搞清楚一件事:MCP 和 Playwright 是怎么配合的
1.1 MCP 到底解决什么问题
先说 MCP 是什么,给没系统了解过的朋友补个底。MCP 全称是 Model Context Protocol,也就是模型上下文协议。它做的事情非常朴素:把 AI 模型和外部工具之间的连接方式标准化。在没有 MCP 之前,你想让 AI 去操作一个浏览器,要么靠各种插件私有协议,要么靠写死的一段调用代码,换个模型、换个前端界面,全部得重来。MCP 出现之后,工具提供方只需要按照统一规范暴露一个 Server,里面定义好有哪些工具可以被调用,AI 这一侧通过 MCP Host 去发现并调用这些工具,两边不用再互相迁就。
可以把它理解成一个万能插座:MCP Server 是插头,MCP Host 是插座面板,AI 模型是插在上面的电器。比如 Claude Code、Cursor、Codex 这些都是 Host,它们本身不关心你背后是浏览器还是数据库还是设计软件,只看你暴露出来的 tools 列表里有没有它需要的函数。每个工具都有清晰的入参、出参和描述,模型根据任务自己决定调用哪个、按什么顺序调。这也是为什么 MCP 生态这半年能爆发得这么快——它对两端都足够友好。
1.2 为什么偏偏是 Playwright 做这件事
浏览器自动化不是新东西,Selenium 存在很多年了,Puppeteer 也一度是首选。但被选来做官方 MCP Server 的却是 Playwright,这不是偶然。Playwright 核心的几个设计在我看来特别适合“AI 操作浏览器”这个场景。
第一是自动等待机制。传统自动化里最痛苦的就是“元素还没加载完就点击,结果报错”,Selenium 时代大家写了一堆显式等待、轮询、重试。Playwright 的元素操作默认会等待元素可见、可点击、稳定之后再执行,这套逻辑对 AI 来说非常友好,因为模型生成的操作步骤本身可能不够精确,如果底层框架没有自动等待,AI 就得频繁对着报错自我修复,效率极低。
第二是可访问性快照。Playwright MCP 给模型提供页面状态不是靠截图 OCR,而是导出一份可访问性树,模型能看到页面上有哪些按钮、输入框、链接以及它们的层级关系。这就像给 AI 一份“页面地图”,它知道下一步该点哪里。配合截图能力,AI 对页面的理解会比纯视觉方案稳定得多。
第三是跨浏览器和网络拦截能力。Chromium、Firefox、WebKit 统一 API,再加上请求级、响应级的拦截和监听,让 AI 不只是会点击,还能“读取网络包”。这一点在后面讲接口数据监听时会展开,它是 Playwright MCP 相比简单截图方案的核心优势。
2. 从零搭一套可用的 Playwright MCP 环境
2.1 安装 Playwright 与浏览器内核,下载慢的看这里
环境搭建是很多人被劝退的第一关,其实步骤非常固定。先准备一个空目录,初始化 Node 项目,然后安装 Playwright 测试库,再把浏览器内核下载下来。
这里有几个容易踩的坑。第一,@playwright/test 是带测试运行器的版本,里面包含完整的 Playwright 库;如果你只想要纯库版本,可以用 npm i playwright,但对 MCP 场景来说直接装 @playwright/test 没有坏处,后面跑 Test Agents 也用得上。第二,npx playwright install 会下载浏览器二进制文件,体积不小。如果你在公司内网或者网络不好,下载经常卡在某个百分比,解决办法是用国内镜像源:
装完之后可以用 npx playwright --version 确认一下版本。如果你已经装过 Playwright,也建议把版本升到较新的版本,因为 MCP Server 对旧版本的支持没有保证。
2.2 启动官方 MCP Server 与关键参数
Playwright 官方提供的 MCP Server 包叫 @playwright/mcp,这也是目前最省事的方案,不需要自己写代码就能把浏览器能力暴露给 AI。启动命令极其简单:
默认会启动一个基于 stdio 传输方式的 MCP Server,监听来自标准输入的命令。但你实际使用的时候,通常不会直接这样裸跑,而是带着参数跑。下面这几个参数是我实际用下来频率最高的:
| 参数 | 作用 | 我的建议 |
|---|---|---|
--browser |
指定浏览器内核,可以是 chromium / firefox / webkit | 日常工作默认 chromium |
--headless |
无头模式,不弹出浏览器窗口 | 调试阶段不建议加,肉眼能看到过程 |
--user-data-dir |
指定用户数据目录,用于保持登录态和浏览器设置 | 见 3.1 登录态复用 |
--port |
通过 HTTP 方式启动 MCP Server,指定监听端口 | 配合 Codex 或远程调试场景 |
--device |
模拟移动设备 | 做移动端适配测试时很实用 |
--viewport-size |
设置视口尺寸 | 默认 1280 |