★ FEATURED ARTICLE 玩浏览器自动化的朋友应该都听过 Playwright 的大名。做 AI 应用的朋友最近也一定绕不开 MCP。这两个东西放在一起产生了一个很有意思的局面以前写自动化脚本是自己把每一步操作编码成代码定位元素、等加载、处理弹窗全是体力活现在有了 Playwright MCP你可以让 AI 直接“看着”浏览器按你的一句话去执行整套操作流程。这篇内容我会把这对组合从头到尾拆开讲清楚包括 MCP 到底是什么、Playwright MCP 怎么装怎么配、实际能跑出什么效果再把我踩过的坑一并交代出来。不管你是做测试、写爬虫、搞 AI Agent 开发还是只是好奇 MCP 能落地在什么场景这篇内容都能帮你少走不少弯路。1. Playwright 与 MCP先搞清楚这对组合1.1 Playwright 并不是“又一个 Selenium”很多人一听浏览器自动化第一反应是 Selenium。确实Selenium 是元老级工具但它的问题也很明显依赖 WebDriver 这种独立进程安装和维护都麻烦脚本写起来啰嗦等待策略基本靠 sleep多标签页、多浏览器场景处理起来不够顺手。Playwright 是微软开源的一套浏览器自动化方案核心思路和 Selenium 完全不同。它直接通过 CDPChrome DevTools Protocol和 Firefox、WebKit 的原生协议去驱动浏览器不需要额外的 WebDriver。这让它在启动速度、稳定性、对页面底层信息的掌控上都更强。而且 Playwright 内置了自动等待机制你定位一个元素之后它会在后台反复检查元素是否可操作直到超时而不是死板地等固定秒数。这对动态渲染的页面特别友好。再就是用 Playwright 写脚本的体验。它的 API 设计很符合直觉from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(https://example.com) page.get_by_role(button, name登录).click() page.screenshot(pathlogin.png) browser.close()这段代码干了四件事打开浏览器、访问页面、点一个按钮、截图。没有 sleep没有显式等待Playwright 内部会自动处理时序问题。在写这篇内容之前我拿它处理过一个数据量很大的后台表格页面最烦的翻页和动态加载问题用 Playwright 的自动等待基本没操过心。所以 Playwright 的定位不是“又一个 Selenium”而是把浏览器自动化从“能用”提升到了“好用到让人愿意天天用”的水平。现在 MCP 进场之后它又多了一个身份AI 操作浏览器的一双“手和眼睛”。1.2 MCP 协议到底是个什么东西MCP 全称 Model Context Protocol业界常叫“模型上下文协议”。它最早由 Anthropic 在 2024 年底开源目标很直接给 AI 应用和外部工具、数据源之间定义一个统一的标准接口。如果你还没有用过 MCP可以把它理解成“AI 界的 USB-C”。USB-C 解决的是设备接口统一的问题一台电脑用同一个接口就能接显示器、硬盘、手机。MCP 做的事情类似一个 AI 应用MCP Host可以通过同一套协议去连接各种不同的外部工具MCP Server这些工具可能是文件读取、数据库查询、网页搜索也可以是浏览器操控。MCP 里有两个核心角色MCP Host运行 AI 模型的宿主应用比如 Claude Desktop、Cursor、VS Code 插件体系甚至是你自己写的一个 Agent 程序。MCP Server提供具体能力的服务端程序负责把 Host 发来的请求翻译成真实操作。比如 Playwright MCP Server就是接收“打开百度并搜索某某关键词”这样的指令然后驱动真实浏览器去执行。这两者之间的通信协议走的是 JSON-RPC传输方式一般是 stdio 或者 HTTP 流。Host 在启动时会拉起配置好的 Server 进程并通过标准输入输出来收发消息。整个过程对用户是透明的你在界面上感觉是“AI 会操作浏览器了”实际上背后是 Host 发现了一个叫 browser_tool 的工具AI 判断当前任务需要调用它于是发了一个 JSON-RPC 请求Server 执行完再把结果返回给模型。现在很多主流应用都原生支持 MCP 协议生态扩展速度非常快。Figma、蓝湖、Jenkins、数据库这些常用工具都有对应的 Server 实现。1.3 Playwright MCP 能解决什么问题直接说结论Playwright MCP 解决的核心问题有三个。第一把“写脚本”变成“提需求”。传统方式下你想让浏览器自动完成一个流程需要精确写出每一步。有了 MCP 之后你只需要用自然语言告诉 AI 目标比如“打开某网站登录获取页面上所有商品标题和价格整理成表格”。AI 会自己规划步骤调用浏览器工具去完成。第二降低浏览自动化的入门门槛。之前团队里新同学想上手写自动化脚本光是把环境配好、理解选择器、搞明白各种等待策略就要花不少时间。用 Playwright MCP一个人只要会描述自己的操作流程AI 就能在浏览器里执行出来很多理解成本被模型承担了。第三让 AI Agent 具备完整的“感知—决策—行动”闭环。一个 AI Agent 要帮用户完成真实任务光会对话不够还得能去查资料、点按钮、看页面反馈。Playwright MCP 正好补上这一环AI 能看到浏览器截图画面能读取页面内容能操作页面元素能监听网络请求。我给非常明确的应用场景画个范围方便你对号入座测试工程师想用 AI 辅助生成和维护端到端用例爬虫开发者经常要处理动态渲染页面不想再手写一堆选择器AI 应用开发者正在做能真正操作电脑的 Agent需要一个稳定的浏览器操作通道运维和运营有大量重复的网页操作巡检、数据录入需求。2. 环境准备与工具选型2.1 基础环境Node.js 还是 PythonPlaywright 官方支持 Node.js 和 Python 两个主要语言版本MCP Server 的官方实现也主要集中在 Node.js 生态。我的建议是如果你主要用 MCP 模式优先把 Node.js 环境配好如果你更想用代码控制浏览器那 Python 也很顺手。先说 Node.js。安装时直接去官网下载 LTS 版本即可装完在终端验证node -v npm -vNode.js 18 以上基本没问题我用的是 20 系列。再看 Python 环境。Python 3.9 以上就行建议直接建虚拟环境python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate pip install playwright不管哪个环境装完都要记得安装浏览器内核playwright install这一步会把 Chromium、Firefox、WebKit 的内核下载到本地。国内网络环境下这个下载可能比较慢建议设置国内镜像源具体后面在问题排查部分详细说。2.2 安装 Playwright MCP ServerMCP Server 官方包叫playwright/mcp由微软官方维护。安装方式很简单可以直接全局安装也可以不安装用 npx 拉起npm install -g playwright/mcp或者在使用时直接npx playwright/mcplatest默认情况下它会启动一个通过 stdio 通信的 MCP Server并且接管一个真实的 Chromium 浏览器窗口。如果你想调试时看到浏览器界面可以加参数--headlessfalse如果需要保留用户登录状态可以用--user-data-dir指定一个浏览器配置目录这样 AI 操作的浏览器也能保持登录态。这里说一个很多人容易忽略的点playwright/mcp 这个包本身拉的还是 Playwright 那一套浏览器内核所以在运行它之前一定要先确认本机的 Playwright 已经把浏览器内核装好了否则启动会直接报错。2.3 在 MCP Host 中配置 Playwright MCP光有 Server 还不够你得有一个宿主应用去调用它。下面以 Claude Desktop 和 Cursor 为例。Claude Desktop 的配置文件路径macOS 在~/Library/Application Support/Claude/claude_desktop_config.jsonWindows 在%APPDATA%\Claude\claude_desktop_config.json。往里面追加一段配置{ mcpServers: { playwright: { command: npx, args: [ playwright/mcplatest ] } } }保存后重启 Claude Desktop它就会自动拉起 Playwright MCP Server。后面你在对话框里让 AI“打开某个网址并把页面内容总结一下”它就会调用浏览器工具。Cursor 的配置更图形化打开 Settings切到 MCP 标签页点 Add new MCP server类型选 stdioCommand 填npxArgs 填playwright/mcplatest。填完记得点刷新看到状态变成绿色就说明连接成功了。配置过程中最常见的错误是格式问题。JSON 配置文件不能有注释逗号不能多不能少command和args必须是一个数组。我自己遇到过因为 Windows 下 npx 要写成npx.cmd导致连接不上的情况这点后面会细说。2.4 Node 版和 Python 版怎么选Playwright MCP 官方推荐使用 Node 版本因为它的功能和特性更新最快。但如果你本身是一个 Python 技术栈的团队也可以用 Python 生态里的 MCP SDK 来接入。我直接给一个对比表维度Node 版 (playwright/mcp)Python 版 (playwrightmcpSDK)官方维护官方维护更新频繁社区方案为主需要手动组合特性覆盖完整支持录制、WebSocket、多标签页取决于自己封装的深度集成体验配好即用适合已经有 Python 自动化框架的团队调试工具自带 Playwright Inspector依赖已有测试框架推荐场景个人使用、AI Agent 集成企业级 pytest 测试体系简单说想快速上手就选 Node 版想在 Python 测试框架里深度集成就选 Python 方案。3. MCP Server 的配置与调用原理拆解3.1 MCP host 和 MCP server 的工作关系我画个思维模型帮大家理解。MCP Host 是“大脑”负责理解用户的意图、规划任务、组织语言。MCP Server 是“手和眼睛”负责实际执行操作、获取信息、返回结果。举个具体例子。你在 Claude Desktop 里输入“打开 example.com找到页面里的搜索框输入 hello然后截一张图。”这个请求会经历下面几个阶段Host 分析任务发现需要浏览器操作Host 查到自己连接了名为 playwright 的 MCP Server这个 Server 暴露了一些工具比如browser_navigate、browser_click、browser_type、browser_snapshotAI 模型根据任务规划出步骤然后依次向 Server 发起 JSON-RPC 调用Server 收到请求后驱动真实浏览器执行操作并把执行结果可能是截图也可能是页面的可访问性快照返回给 HostHost 拿到结果继续判断下一步动作直到任务完成。这里最关键的机制是“工具调用”。模型本身不会直接操作浏览器它只是决定调用哪个工具、传什么参数真正的操作由 Server 完成。这种设计让同一套 AI 模型可以连接任意能力也方便对每个工具做安全和权限控制。3.2 实战配置一个最简单的 MCP Server如果你不想用现成的 Playwright MCP想自己写一个简单的 MCP Server也不是难事。用官方 SDK 就能快速搭起来。import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; import { z } from zod; const server new McpServer({ name: demo-server, version: 1.0.0 }); server.tool( get_page_title, 获取指定网页的标题, { url: z.string() }, async ({ url }) { const res await fetch(url); const text await res.text(); const title text.match(/title(.*?)\/title/)?.[1] ?? ; return { content: [{ type: text, text: title }] }; } ); const transport new StdioServerTransport(); await server.connect(transport);这段代码定义了一个名字叫get_page_title的工具。Host 启动这个 Server 后会拿到工具列表当 AI 认为用户需要获取网页标题时就会调用它。理解这个流程对排查问题特别有帮助。很多时候 MCP Server 连接失败不是协议的问题而是 Host 进程没有权限启动 Server或者 Server 启动报错后进程直接退出了。只要把你配置里的 command 和 args 拿到终端里手动执行一遍看能不能正常启动大部分问题都能定位。3.3 从“写代码”到“提需求”的心态转变用 Playwright MCP 最大的感受变化是你可以把精力从“怎么写”转移到“要什么”上。传统方式写一个流程你脑子里想的是先怎么定位登录按钮、用什么选择器更稳定、等待几秒、如果出现弹窗怎么办。这些大量细节都是技术性思考和业务目标无关。用 MCP 的方式你只需要描述目标AI 自己会用上一节说的那些工具逐步完成。你上传一个测试用例描述它就能生成可执行的端到端测试。这种模式特别适合业务流程经常变动的场景之前测试脚本一改需求就得改半天现在只需要告诉 AI“登录入口变了现在在右上角”。当然这不是说 Playwright 的基本功不重要了。反而是因为 AI 替你承担了执行层的工作你对“页面结构是否合理”“操作路径是否最优”的判断变得更重要否则 AI 也会跟着走弯路。4. 核心实战场景从录脚本到监听请求4.1 用 codegen 快速拿到可靠选择器不知道别人是不是这样我第一次写 Playwright 脚本时最大的痛点就是选择器。页面源码结构复杂一不小心定位就失效。Playwright 官方提供了一个非常省心的工具codegen它会打开一个录制窗口你在浏览器里的每一次点击、输入、跳转都会被自动转换成代码。启动方式很简单playwright codegen --save-storageauth.json https://example.com执行后你会看到两个窗口一个是浏览器一个是 Playwright Inspector。你在浏览器里手动操作一遍Inspector 里就会实时生成对应的 Python 或 JS 代码。最终操作完成后这段代码可以直接复制到你的测试里。这里有一个非常重要的习惯codegen 生成的选择器不一定是最优的。它会倾向于生成基于文本的定位方式比如get_by_text这在页面内容频繁变化的场景下很容易失效。建议手动换成稳定的># 普通场景找不到 iframe 里的元素 # page.get_by_role(button, name提交).click() # 正确写法先定位 iframe再定位内部元素 frame page.frame_locator(#main-iframe) frame.get_by_role(button, name提交).click()用 MCP 时AI 很少能自动处理这种嵌套结构它可能会尝试在顶层页面查找元素然后失败。这时候有两个办法一是先把 iframe 相关的操作录制成 codegen 脚本生成稳定代码后接入 MCP 流程二是手动打开浏览器的开发者工具确认 iframe 的 id 或 name然后在 AI 提示词里明确告诉它“点击操作在 #main-iframe 这个 iframe 内完成”。我建议把这类页面信息整理成一份“页面操作手册”AI 在操作前先读取手册这样能大幅提升成功率。这个做法我们内部已经用了很久比让 AI 自由探索稳定得多。4.3 监听页面请求与响应Playwright 有一个非常实用的能力监听页面发出的所有网络请求和响应。传统 selenium 很难做到这一点但 Playwright 只需要挂上事件回调。page.on(request, lambda req: print(req.method, req.url)) page.on(response, lambda res: print(res.url, res.status))这个能力放在 MCP 场景里价值更大。AI 在操作页面时不仅能看到静态 DOM还能实时拿到接口返回的数据。比如你让 AI“打开订单管理页面拉取所有订单编号”它可以监听接口响应直接解析 JSON 数据而不是去 DOM 里一个一个抓文本。我自己做过一个供应链比价工具就是利用页面上的请求监听把多个平台的价格接口数据抓下来做对比。用 MCP 的好处是AI 可以在监控请求结果的同时自动进行比对和总结把数据直接整理成表。需要注意事件监听一定要挂在 page 创建出来之后最好在导航之前注册好。如果你在导航完成后才开始监听会漏掉很多关键请求。4.4 登录态保持与鉴权处理自动化操作绕不开登录态。每次脚本执行都要重新登录既慢又容易被风控。Playwright 提供了storageState机制可以把登录后的 cookies 和 localStorage 保存下来后面直接用。# 用 codegen 完成登录并保存状态 playwright codegen --save-storageauth.json https://example.com# 后续脚本直接使用保存的登录状态 context browser.new_context(storage_stateauth.json) page context.new_page()在 MCP 场景里操作方式类似。启动 Playwright MCP 时指定一个用户数据目录npx playwright/mcp --user-data-dir/path/to/chrome-profile这样 AI 操作的浏览器会保留登录状态第一次手动登录之后后面所有操作都是已登录状态。这个方案适合后台系统、数据看板的自动化巡检省去了每次都验证账号的麻烦。不过要注意安全auth.json 里保存的是敏感凭证不要把它提交到代码仓库里更不要随手发到群里。我一般会在 .gitignore 里把它加进去用 CI 环境变量单独管理。4.5 数据采集的合规原则每次聊到浏览器自动化就会有人问能不能用来爬数据。我的答案是能用但必须守住底线。先说安全边界。网上数据采集要认认真真检查目标站的 robots.txt 和服务条款明确允许的路径才做自动化。不要加载额外的隐藏点击、不要绕过鉴权和风控机制、不要高频大量抓取影响对方服务器。尤其要提醒一点“过加密校验”这类操作属于绕过网站技术保护措施无论在法律还是商业伦理层面都极其危险千万不要碰。我见过有人在电商站上做这种事最后账号被封还是小事被平台诉诸法律就很麻烦了。那合法采集怎么做优先看目标站点是否提供官方 API有 API 就用 API。没有 API只抓公开可见的信息控制频率并对数据做脱敏处理。Playwright MCP 适合抓那些必须登录后才能看到的公开业务数据比如自己公司后台的多维度报表这种场景属于正常业务自动化完全没问题。5. 与 AI 深度结合从脚本自动化到智能体5.1 用自然语言驱动浏览器一个真实示例配好 Playwright MCP 之后你可以这样和 Claude Desktop 对话“帮我打开某公开新闻站点获取今天的科技头条标题按时间排列整理成 Markdown 列表。”接下来发生的事情是AI 先把页面导航到指定网站读取页面结构找到新闻列表区域提取出所有标题最后按时间排序整理输出。整个过程你不需要写一行代码AI 通过 MCP Server 在真实浏览器中完成所有操作。这个能力在爬虫和测试场景里潜力巨大。以前写爬虫面对动态页面需要研究接口构造、处理各种加密参数现在 AI 可以像真人一样在页面上操作通过点击、滚动、切换标签页把需要的数据一点点捞出来。但这里我要泼一盆冷水AI 操作浏览器的速度还远达不到“高效爬虫”的水平。每个步骤模型都需要推理一次一次完整的页面操作可能要好几次工具调用耗时比直接写脚本高很多。所以目前的合理定位是“辅助探索、处理复杂流程、波动较大的场景”而不是替代高性能爬虫。5.2 把 Playwright MCP 接入 pytest 体系如果你所在的团队已经用 pytest 做一个自动化测试平台那可以考虑把 MCP 引入测试用例生成和智能断言环节而不是直接替代 pytest。我搭建过一套组合框架pytest 负责用例编排、数据驱动、报告输出Playwright 负责浏览器操作MCP 负责把 AI 能力注入测试过程。大概结构是这样import pytest from playwright.sync_api import sync_playwright pytest.fixture(scopesession) def browser(): with sync_playwright() as p: browser p.chromium.launch() yield browser browser.close() def test_login_flow(browser): context browser.new_context(storage_stateauth.json) page context.new_page() page.goto(https://example.com/dashboard) # 让 AI 基于当前页面状态生成断言建议 # 这里通过 MCP Client 发送页面快照给模型获取断言代码 assert page.locator(.user-name).inner_text() 测试用户这种模式的好处是能用 AI 的地方全用 AI比如生成测试数据、判断页面异常、分析失败截图但框架本身依然由 pytest 稳定掌控保证测试的可靠性和可维护性。5.3 更进一步自建 MCP Server 暴露业务能力阿里和社区里越来越多的团队开始自建 MCP Server把业务能力封装成工具暴露给 AI。你可以封装一个“订单服务”提供查询订单、修改状态、导出报表等接口也可以封装一个“浏览器服务”把你们业务的页面操作流程标准化。比如你的业务里经常要做“登录 → 进入订单页 → 按时间筛选 → 导出 Excel”这个流程就可以把整个过程封装成一个工具。以后 AI 只需要说“帮我导出昨天的订单”MCP Server 就自动完成整条链路比让 AI 一步一步去点击稳定得多。封装时建议遵循一个原则工具粒度不要太小也不要太大。太小了 AI 调用太多次效率低太大了工具不通用AI 难以组合出灵活操作。我一般会封装“打开某页面”“在某区域内搜索”“提取某块数据”这种中等粒度的工具。6. 常见问题与排查技巧实录6.1 选择器定位失败的三种原因选择器定位不到元素是最常见的问题。我把它归成三类来排查。第一类元素在 iframe 或 Shadow DOM 里。普通选择器在顶层文档里找不到它必须按上面说的方法切换到对应上下文。第二类元素是动态渲染的比如点击按钮后才异步加载的内容。Playwright 虽然会自动等待但如果等待时间超出设置还是可能失败。解决办法是调大超时时间或者改用expect轮询断言而不是一次性查找。第三类元素有多个匹配项。页面上很多按钮文本相同get_by_role(button, name提交)可能匹配到多个需要再加限定条件比如嵌套在某个容器内。codegen 生成的选择器偶尔也会出现这个问题跑失败时先检查是不是多个匹配。6.2 元素识别到了但点击不生效能定位到说明元素存在点击没反应常见原因有两个元素被遮挡、元素不在可点击状态。被遮挡是弹窗、固定导航栏盖住了目标Playwright 点击时会报“element is not visible”。排查方法是截图看一眼页面状态或者用locator.scroll_into_view_if_needed()先滚动到可见区域。不在可点击状态比如按钮是 disabled、选项还在加载中这种要用expect(locator).to_be_enabled(timeout...)等它变为可操作状态。千万别用傻等的 sleep不仅慢还不稳定。6.3 MCP 连接不上或工具调用超时MCP 连接失败的原因里配置格式错误占了大多数。我在 Windows 上遇到最多的问题是配置项里的 command 填了npx但实际上需要填npx.cmd否则进程根本起不来。macOS 和 Linux 一般是没问题的。还有一种隐藏情况Host 应用启动 MCP Server 时工作目录可能不是你期望的路径。如果你在配置里用了相对路径很可能找不到文件。解决办法是全部使用绝对路径或者把 server 打成全局命令。工具调用超时通常是浏览器启动失败导致的尤其是首次运行没装好浏览器内核。运行playwright install之后再手动跑一次npx playwright/mcp --headlessfalse验证能否正常弹窗。我把这些问题整理成一张速查表方便你对照排查问题现象排查方向MCP 未连接Host 显示红色错误检查 command 是否含 .cmd、路径是否绝对路径浏览器不启动Server 进程退出了手动运行 npx 看报错确认 playwright 内核已装工具调用超时AI 说操作失败检查浏览器是否被占用、user-data-dir 是否被锁选择器定位失败找不到元素检查是否在 iframe、等待时间是否太短点击无反应元素存在但操作失败截图排查遮挡、检查 disabled 状态6.4 内核下载慢与镜像配置playwright install下载慢这个问题国内用户几乎都会遇到。解决办法是设置镜像源加速浏览器内核和驱动文件的下载。在终端里设置环境变量export PLAYWRIGHT_DOWNLOAD_HOSThttps://npmmirror.com/mirrors/playwright/Windows 在 PowerShell 里用$env:PLAYWRIGHT_DOWNLOAD_HOSThttps://npmmirror.com/mirrors/playwright/设置完之后再执行playwright install速度能快上很多。这个镜像源是 npm 中国镜像团队维护的稳定性和同步频率都还不错我用了挺长时间没出过问题。6.5 几条少有人说的实战建议最后分享几个我踩过不少坑之后沉淀下来的习惯。第一重要流程先人工走一遍。不是让 AI 盲冲是先用 codegen 把每一步录下来让 AI 看一遍完整的代码逻辑后再执行相似任务。这样既给了 AI 经验数据也让你自己对流程有底。第二选择器风格要统一。能加>
阅读完成 · 觉得有帮助？
