playwright-mcp 项目全解析:从理论到实践
前言
大模型,调用浏览器操作工具playwright-mcp,执行自动化任务。
开始
一、项目功能说明
playwright-mcp
是一个基于 Playwright 的增强型自动化工具包(推测 "MCP" 意为 "Multi-Control Platform" 或 "Managed Crawling & Testing"),旨在简化网页自动化、测试与数据采集的全流程。其核心功能包括:
-
多浏览器统一控制
支持 Chrome、Firefox、WebKit(Safari 内核)三大浏览器的自动化操作,无需针对不同浏览器编写差异化代码。 -
可视化任务配置
提供配置文件(如 JSON/YAML)方式定义自动化任务,无需深入编码即可实现页面导航、元素交互、数据提取等操作。 -
批量任务调度
支持并行执行多个自动化任务,自带任务队列与资源管理,避免浏览器进程冲突。 -
结果自动化处理
自动记录任务执行日志、截图、录屏,并支持将提取的数据导出为 CSV/JSON 格式。 -
反反爬增强
集成常见反检测策略(如规避自动化特征识别、随机请求间隔、代理池对接),提升数据采集稳定性。 -
跨平台兼容
支持 Windows、macOS、Linux 系统,可在本地环境或服务器(如 Docker、云服务器)中运行。
二、核心理论基础
1. 什么是 Playwright?
Playwright 是微软开发的开源自动化工具,专注于网页端的自动化测试、爬虫与交互模拟。与传统工具(如 Selenium)相比,其核心优势在于:
- 自动等待机制:无需手动添加
sleep
或等待条件,Playwright 会自动等待元素加载完成后再执行操作。 - 多上下文隔离:可在单个浏览器实例中创建多个独立上下文(类似隐私窗口),互不干扰,节省资源。
- 强大的元素选择:支持 CSS、XPath、文本内容、属性等多种选择器,甚至可通过视觉特征(如位置、尺寸)定位元素。
- 全场景模拟:支持文件上传 / 下载、键盘鼠标操作、网络请求拦截(修改请求 / 响应)、地理定位模拟等。
2. playwright-mcp 与 Playwright 的关系
与标准Playwright不同,playwright-mcp是使用 Playwright 提供浏览器自动化功能的模型上下文协议 (MCP) 服务器。该服务器通过结构化的可访问性快照与网页进行交互,无需屏幕截图或视觉调整模型,
是专为大型语言模型(LLM)设计,核心价值在于:
- LLM友好性
- 通过结构化可访问性快照(非像素截图)提供页面信息,避免依赖视觉模型。
- 支持自然语言指令驱动浏览器操作(如导航、表单填写)。
- 轻量化与高效
- 比传统Playwright响应更快,资源占用更低。
- 应用场景
- AI代理自动操作网页(如数据抓取、测试)。
- 与GitHub Copilot/Cursor等IDE集成,实现代码生成+浏览器联动
三、架构说明
1. 架构设计
- 客户端-服务器模型:
- MCP服务器:启动浏览器实例(Chrome/Firefox等),执行操作。
- MCP客户端:将用户/AI指令转为服务器请求(如VS Code、Cursor IDE)。
- 交互流程:
LLM指令 → 客户端 → MCP服务器 → 浏览器执行 → 返回结果(如快照/PDF)
2. 两种工作模式
模式 | 数据来源 | 适用场景 | 启动参数 |
---|---|---|---|
快照模式 | 可访问性树(默认) | 高效操作结构化元素(按钮/输入框) | 无需额外参数 |
视觉模式 | 屏幕截图 | |基于坐标的交互(如拖拽) | --vision |
3. 与标准Playwright对比
特性 | 标准Playwright | Playwright MCP |
---|---|---|
核心目标 | 通用自动化测试 | LLM集成浏览器控制 |
交互方式 | 代码编写(XPath/CSS) | 自然语言指令 |
性能 | 通用 | 轻量级+低延迟 |
适用场景 | 测试工程师 | AI代理/自动化任务 |
四、部署与使用教程
官网地址
https://github.com/microsoft/playwright-mcp
前置知识:环境依赖
- Node.js(推荐 v16+):playwright-mcp 通常基于 Node.js 开发(Playwright 支持多语言,但 Node.js 生态最成熟)。
- npm/yarn:Node.js 包管理工具,用于安装依赖。
- Git:克隆项目代码
安装MCP服务(Trae为例)
配置信息:
{"mcpServers": {"playwright": {"command": "npx","args": ["@playwright/mcp@latest"]}}
}
配置界面:
确认后,系统会开始安装,完成后可以查看具体的服务列表:
五、测试
测试准备
我在Trae中创建了Agent,并配置了可用的工具列表,如下图:
工具列表如同:
测试考题
然后,我给出了考题:
在网站http://localhost:8000/,搜索关于“Generate Image Workflow”的工作流,并下载工作流对应的json文件,部署到本地n8n系统:http://localhost:5678/
Trae的思考过程
看看他的思考过程,有模有样:
我现在需要帮助用户完成一个关于n8n工作流的任务。用户的要求是在网站http://localhost:8000/搜索“Generate Image Workflow”的工作流,下载对应的JSON文件,然后部署到本地的n8n系统(http://localhost:5678/)。
首先,我得理清楚整个流程。用户提到的两个本地地址,一个是8000端口,另一个是5678端口。n8n默认的端口通常是5678,所以http://localhost:5678/应该是n8n的本地实例。而8000端口可能是另一个网站,可能是一个工作流库或者示例展示页面,用户需要从那里搜索并下载特定的工作流JSON文件。
接下来,我需要确定如何一步步实现这个任务。根据提供的工具列表,我有几个可能的工具可以使用,比如run_mcp调用浏览器相关的工具,或者使用web_search,但web_search主要用于互联网搜索,而这里是本地网站,所以可能不太适用。另外,还有run_command可以执行命令,但用户需要的是在网页上操作,所以可能需要使用mcp服务器中的playwright工具来模拟浏览器操作。
查看mcp_servers部分,有一个mcp.config.usrlocalmcp.playwright服务器,提供了浏览器相关的工具,比如browser_navigate、browser_click、browser_type等。这些工具可以用来自动化浏览器操作,访问http://localhost:8000/,搜索工作流,下载JSON文件,然后上传到n8n。
步骤分解:
1. 使用browser_navigate工具导航到http://localhost:8000/。
2. 在该网站上找到搜索框,输入“Generate Image Workflow”并提交搜索。
3. 找到搜索结果中对应的工作流,点击下载JSON文件的链接。
4. 确认文件下载到本地文件系统。
5. 导航到n8n的本地实例http://localhost:5678/。
6. 在n8n中导入下载的JSON文件,完成部署。
不过,我需要考虑如何实现这些步骤。首先,使用playwright的browser_navigate工具访问8000端口的网站。然后,需要找到搜索框的元素,使用browser_type工具输入搜索关键词。接着,点击搜索按钮或按回车键提交搜索。然后,在搜索结果中找到正确的工作流链接,使用browser_click工具点击下载。下载文件后,需要知道文件保存的路径,可能默认下载到用户的下载文件夹,但根据工作区上下文,用户的工作目录是e:\00traePjs\tmp,所以可能需要指定下载路径,或者后续移动文件到该目录。
然后,访问n8n的5678端口,导入工作流。在n8n中,导入工作流通常是通过UI上的导入按钮,选择JSON文件。因此,可能需要使用browser_click工具点击导入按钮,然后使用browser_file_upload工具上传下载的JSON文件。
不过,这里可能存在一些问题。比如,如何确定元素的ref和element描述,因为playwright工具需要这些参数来定位元素。由于我无法直接查看网页的结构,可能需要假设一些常见的元素结构,或者用户需要提供更多信息。但根据问题描述,用户可能希望我直接操作,所以可能需要使用通用的元素描述。
另外,考虑到用户的工作区中已经有一个ai_image_generator_workflow.json文件,可能这个就是要下载的文件?但用户明确说要从8000端口的网站搜索并下载,所以应该不是现有的文件。
现在,我需要确定使用哪些工具步骤:
步骤1:使用run_mcp调用playwright的browser_navigate工具,导航到http://localhost:8000/。
步骤2:在该页面上找到搜索框,使用browser_type输入搜索关键词“Generate Image Workflow”。这里需要元素描述和ref,但由于无法查看实际页面,可能需要使用通用描述,比如“搜索框”作为element,ref可能需要通过snapshot获取,但根据工具描述,browser_snapshot可以获取页面快照,但我不确定如何在当前流程中使用它。或者,可能需要假设搜索框的常见选择器,比如input[type="search"]或name="q"等,但playwright工具需要element和ref参数,这可能需要用户的页面有可识别的元素。
这可能是一个障碍,因为没有实际页面结构的信息,我无法准确提供element和ref。因此,可能需要使用更通用的方法,比如按Tab键导航到搜索框,但browser_press_key工具可以模拟按键操作。
或者,可能用户的8000端口网站是n8n的另一个实例或工作流库,具有标准的搜索功能。例如,假设搜索框的id是“search-input”,那么element描述可以是“搜索输入框”,ref可能需要通过snapshot获取,但我无法在当前上下文中执行snapshot。
这似乎是一个死胡同,因为没有页面元素的具体信息,无法正确设置browser_type的参数。因此,可能需要另一种方法,或者用户需要提供更多关于页面结构的信息。但根据问题描述,用户可能希望我直接操作,所以可能需要做出一些假设。
替代方案:如果8000端口的网站是一个简单的文件列表,可能可以通过HTTP请求直接下载文件,而不需要模拟浏览器操作。例如,使用HTTP Request节点或curl命令。但根据工具列表,有search_codebase和search_by_regex工具,但这些是用于搜索代码库,而不是网页内容。
或者,使用run_command工具执行curl命令来访问http://localhost:8000/,搜索工作流。但这需要知道网站的API或搜索接口,否则无法直接通过命令行搜索。
另一个可能性是,用户提到的8000端口网站可能是n8n的另一个实例,或者是一个静态网站,其中包含工作流的JSON文件列表。例如,可能有一个页面列出了所有工作流,用户需要搜索特定名称的工作流并下载其JSON。
在这种情况下,可能需要使用playwright工具模拟完整的浏览器操作:
1. 导航到http://localhost:8000/
2. 找到搜索框并输入关键词
3. 提交搜索
4. 在结果中找到“Generate Image Workflow”对应的链接
5. 点击下载链接
6. 导航到n8n(http://localhost:5678/)
7. 导入下载的JSON文件
但问题在于如何定位这些元素。由于无法查看实际页面,我需要假设一些常见的元素结构。例如,搜索框可能有placeholder“Search workflows...”,或者id为“search”。假设搜索框的element描述为“搜索工作流的输入框”,ref可能需要通过snapshot获取,但我无法执行snapshot。因此,这可能无法实现,除非工具允许使用更通用的选择方式。
或者,可能用户的8000端口网站提供了直接下载链接,比如http://localhost:8000/workflows/Generate%20Image%20Workflow.json,这样可以直接使用browser_navigate或curl下载。但用户要求“搜索”,所以可能不是直接可用的链接。
这似乎陷入了困境,因为没有页面结构信息,无法准确模拟用户操作。因此,可能需要告知用户需要更多关于8000端口网站的信息,比如页面结构、搜索框的位置等。但根据问题描述,用户可能希望我直接完成任务,所以可能需要继续假设。
另一个角度:根据工作区上下文,用户的目录中有一个ai_image_generator_workflow.json文件,可能这就是要下载的文件?但用户明确说要从8000端口网站搜索下载,所以可能不是。不过,也许可以直接使用这个文件来部署到n8n,省去下载步骤?但用户的要求是从8000端口下载,所以应该按照用户的指示来。
回到工具选择,必须使用提供的工具。可用的工具中,run_mcp调用playwright的工具是唯一可以模拟浏览器操作的方式。因此,我需要尝试构建这些步骤。
首先,调用browser_navigate工具导航到http://localhost:8000/:
参数:
server_name: mcp.config.usrlocalmcp.playwright
tool_name: browser_navigate
args: { "url": "http://localhost:8000/" }然后,需要在页面上找到搜索框。假设搜索框的element描述为“搜索框”,ref可能需要通过snapshot获取,但我无法执行snapshot。因此,可能需要使用browser_snapshot工具先获取页面快照,然后从中提取元素ref。
所以步骤可能是:
1. browser_navigate到8000端口
2. browser_snapshot获取页面快照,得到元素ref
3. 使用browser_type在搜索框中输入关键词
4. 提交搜索
5. 找到下载链接并点击
6. 导航到n8n,导入文件
但根据playwright工具的描述,browser_snapshot返回页面的可访问性快照,可能包含元素的ref信息。因此,可能需要先调用browser_snapshot,获取搜索框的ref,然后才能使用browser_type。因此,第一个工具调用应该是run_mcp,使用browser_navigate,然后调用browser_snapshot获取元素信息。
不过,根据工具调用规则,每次只能调用一个工具,所以需要分步骤进行。
现在,我需要确定第一步应该调用哪个工具。根据用户的要求,首先需要访问8000端口的网站,所以第一步是使用browser_navigate工具。
因此,第一个工具调用是:
工具:run_mcp
参数:
server_name: mcp.config.usrlocalmcp.playwright
tool_name: browser_navigate
args: { "url": "http://localhost:8000/" }然后,下一步是获取页面快照,找到搜索框的ref。
但根据工具调用流程,每次只能调用一个工具,所以需要分多次调用。
现在,根据用户提供的工具列表,run_mcp是一个工具,可以调用mcp服务器的工具。因此,第一个工具调用应该是run_mcp,调用browser_navigate。
因此,生成的JSON应该是:
{
"toolcall": {
"thought": "导航到http://localhost:8000/以开始搜索工作流。",
"name": "run_mcp",
"query_language": "Chinese",
"params": {
"server_name": "mcp.config.usrlocalmcp.playwright",
"tool_name": "browser_navigate",
"args": {
"url": "http://localhost:8000/"
}
}
}
}这是第一步,导航到目标网站。接下来,需要获取页面快照以找到搜索框元素,但这需要另一个工具调用。不过,根据当前的思考,用户可能希望我先完成这一步,然后再进行下一步。
因此,最终的JSON响应应该是调用run_mcp工具,导航到8000端口的网站。
实际执行结果
Trae打开了一个浏览器,出色的完成了:
1:使用run_mcp调用playwright的browser_navigate工具,导航到http://localhost:8000/。
2:在该页面上找到搜索框,使用browser_type输入搜索关键词“Generate Image Workflow”。
3:打开搜索到的项目,下载json文件
4:把json文件复制到了当前trae的工作空间
接下来,悲剧发生了:
他想通过n8n行命令来导入json,检测n8n命令不可用,就开始下载n8n,因为我已经在docker里运行了n8n实例,还是运行状态,所以他就遇到了端口占用,强制终止运行实例,我实在看不下去,就给他停了,结果,我在打开docker desktop,就瘫痪了,整了半天没整好那种,被建议重装。。。
我的神啊,我有一种让孩子干点活,结果他给你闯祸的感觉。。。。。。
结束语
总的来说,playwright-mcp 配合大模型,完成浏览器的控制,还是可以的~