简介n8n调用playwright-mcp的代码资源包面向需要在n8n中实现浏览器自动化的开发者通过MCP社区节点快速接入Playwright解决网页导航、截图、表单填写与点击等操作的工作流构建问题。包内共9个文件含n8n工作流JSONbrowser-automation.json、Markdown说明文档、YAML配置、JS启动脚本及HTML示例整体仅13KB轻量精炼。目前已有572人浏览学习。资源提供可直接导入的工作流模板和start-mcp-server.js启动脚本附带docker-compose.yml用于快速部署独立MCP服务器同时整理了浏览器交互不完整问题的排查思路并在文档中区分了MCP Client Tool node与n8n-nodes-mcp-client的差异帮助读者理解不同节点的适用场景避免选型踩坑适合有一定n8n基础并希望扩展自动化能力的实践者。 先说结论如果你在 n8n 里遇到一个必须“开浏览器去点一点”才能完成的任务n8n 调用 playwright-mcp 是目前最顺手的解法之一。这个组合的意思是把 n8n 当自动化流程大脑把 Playwright 包装成的 MCP 服务当“遥控器”让工作流能真正去打开页面、点击按钮、填写表单、截图取证。今天这篇就是我实操这个组合的完整记录包含从零部署 n8n、启动 playwright-mcp、配置凭证到跑通一条真实浏览器自动化工作流的全过程也把踩过的坑和排查思路都一并写出来。适合本身就接触过 n8n、想扩展它处理浏览器类任务的开发者也适合刚准备入坑 RPA 和 AI Agent 编排的朋友。1. 为什么 n8n 需要调用 playwright-mcp1.1 HTTP 请求搞不定的动态交互交给真实浏览器n8n 自带的 HTTP Request 节点能应对绝大多数 API 调用但遇到前端渲染的页面就非常吃力。很多后台系统是典型的 SPA 单页应用表格数据全靠 JavaScript 异步加载你直接发一个 GET 请求返回的 HTML 里根本没有数据。还有些场景压根不是“请求-响应”能解决的比如需要登录后点击某个菜单、切换日期筛选器、再翻几页才能看到结果。我最早在这方面吃过大亏想用 n8n 定时拉取一个内部系统的报表结果 HTTP 节点拿到的永远是登录页的空壳。后来我意识到这类任务的本质不是“拿数据”而是“操作浏览器”这时就需要一个能真正驱动浏览器的执行器。1.2 MCP 给 n8n 配了一个“浏览器遥控器”MCP 的全称是 Model Context Protocol它的核心作用是把外部工具能力封装成一套标准接口。放到这个场景里playwright-mcp 就是把 Playwright 的浏览器操作能力比如导航、点击、输入、截图、提取文本统一暴露成一批工具。n8n 通过 MCP Client 节点连到这个服务端之后就能像调用普通函数一样去调用这些能力。说得更直白一点以前 n8n 想控制浏览器要么自己写一堆复杂脚本要么依赖某些第三方 API维护成本很高。现在 playwright-mcp 像遥控器一样把浏览器操作标准化了n8n 不需要关心底层 Playwright 代码是怎么写的只需要发指令、收结果。这个抽象带来的最大好处是你完全可以在不写浏览器自动化代码的情况下用 n8n 的可视化节点把整个流程串起来。1.3 这套组合能解决哪些实际问题我实测下来下面几类需求最值得用这个组合定时巡检某个动态渲染页面比如每天检查价格、库存或公告更新。自动登录后台系统导出报表或抓取内部可访问的数据。做表单自动填写和提交省去人工重复点击。利用 n8n 里的 AI Agent 节点让大模型根据任务自动选择调用哪个浏览器工具实现简单的 Agent 化网页操作。同时也要明确边界它不适合做大规模爬虫因为每个操作都带真实浏览器环境和截图资源开销不小也不适合做性能压测那该用专门工具。合规方面要特别注意只操作你有权访问的站点并遵守目标网站的使用条款和 robots 规则。2. 环境准备搭建 n8n 并启动 Playwright MCP 服务2.1 用 Docker Compose 部署 n8n顺手切中文界面n8n 的官方镜像很成熟最省心的方式是用 Docker Compose 跑一个长期使用的实例。我已经把常用配置整理成一份可直接用的文件比单容器跑多做了三件事数据持久化到卷、时区设为 Asia/Shanghai、界面默认语言切中文。services: n8n: image: n8nio/n8n:latest container_name: n8n restart: unless-stopped ports: - 5678:5678 extra_hosts: - host.docker.internal:host-gateway environment: - N8N_HOSTlocalhost - N8N_PORT5678 - N8N_PROTOCOLhttp - N8N_DEFAULT_LOCALEzh - GENERIC_TIMEZONEAsia/Shanghai - TZAsia/Shanghai volumes: - n8n_data:/home/node/.n8n volumes: n8n_data:这里重点说下extra_hosts这一行。我的 playwright-mcp 跑在宿主机上而 n8n 在容器里容器内访问宿主机端口必须通过host.docker.internal这个特殊域名。如果你是刚接触 Docker 的读者没有这行配置后面连接服务时大概率会碰到“连接拒绝”的错误加上它就能直接从容器里访问http://host.docker.internal:9000了。启动命令很简单在 docker-compose.yml 所在目录执行docker compose up -d然后访问http://localhost:5678。如果界面还是英文进入右上角个人设置在语言选项里可以手动切换为中文环境变量只是改了默认值。2.2 启动 Playwright MCPHTTP 模式playwright-mcp 官方包可以通过 npm 全局安装。安装前请确认本机已经有 Node.js 18 以上版本否则部分依赖会安装失败。整体启动流程分三步npm install -g playwright/mcp npx playwright install chromium playwright-mcp --port 9000第一条命令装包第二条命令下载 Playwright 需要的 Chromium 内核第三条命令以 HTTP 模式启动服务。注意默认情况下 playwright-mcp 走的是 stdio 通信方式也就是给命令行用的而 n8n 需要通过网络请求来调用所以必须显式加--port参数。启动后看到类似HTTP server listening on http://localhost:9000/mcp的日志就说明服务已经就绪。如果你是在服务器上跑建议先用 curl 验证一下端口是否通curl http://localhost:9000/mcp。正常情况下会返回一个 JSON 提示信息光标亮着就说明服务监听正常。另外首次启动建议先手动执行一次npx playwright install chromium避免后续在 n8n 里调用时突然报浏览器内核缺失。2.3 容器间访问与网络配置的常见坑这个环节最容易翻车的就是网络互通问题。我按三种场景整理一下n8n 在 Docker 容器里playwright-mcp 在宿主机docker-compose 里加extra_hosts连接地址填http://host.docker.internal:9000/mcp。n8n 和 playwright-mcp 都在同一个 docker-compose 网络里可以把 playwright-mcp 也定义成一个服务连接地址直接写服务名例如http://playwright-mcp:9000/mcp。两者都直接跑在本机进程里连接地址填http://127.0.0.1:9000/mcp即可。还有防火墙问题。如果你是在云服务器上实验尽量不要把 9000 端口对公网开放。最安全的做法是让 playwright-mcp 只监听本机只允许 n8n 所在的环境访问。如果实在需要跨机器访问建议使用支持加 token 的启动参数给服务加一层鉴权而不是裸奔在公网上。3. 在 n8n 中配置 MCP 凭证并接入节点3.1 找到 MCP Client 节点新建连接n8n 在 AI Agents 相关节点分类里提供了 MCP Client 节点支持连接远程的 MCP 服务。我在工作流编辑页面里直接搜索“MCP Client”就能看到。拖入节点后首先要配置一项 MCP Connection 凭证。新建凭证时关键是把 MCP Server Type 选对。playwright-mcp 用 HTTP 模式启动后协议类型选 HTTP也就是 Streamable HTTP。URL 需要填写完整的端点地址http://host.docker.internal:9000/mcp。如果你在 n8n 的配置里加了自定义鉴权头还可以在 Headers 参数里带上比如Authorization: Bearer xxx。填完之后点击保存n8n 会发起一次预检请求如果 URL 能访问凭证列表里就会出现一条可用记录否则会直接报错提示连接失败。3.2 凭证与工具参数配置参考凭证配置这一块字段不多但每个都很关键。我整理了一张速查表方便你对照填写配置项示例值说明MCP Server TypeHTTP对应 playwright-mcp 的 HTTP 传输模式URLhttp://host.docker.internal:9000/mcp必须以 /mcp 结尾与启动日志一致HeadersAuthorization: Bearer your_token如果服务端开了鉴权就填没有则留空这里有个容易被忽略的点如果 playwright-mcp 和 n8n 不在同一台机器URL 的 IP 必须是 n8n 能直接访问到的地址不要填127.0.0.1因为那个地址在容器里指向容器自身。我就因为这个原因白白排查了半小时换成host.docker.internal后立刻通了。3.3 连接后加载工具列表并验证连上服务后MCP Client 节点会尝试拉取 playwright-mcp 暴露的工具列表。这一步是判断连接是否成功的直观信号。如果节点参数里能选择 Tool并且下拉列表里出现了browser_navigate、browser_click、browser_type、browser_snapshot、browser_screenshot等工具说明连接已经打通。不同版本的 playwright-mcp 工具命名可能略有差异但核心的几个基本都有browser_navigate跳转到指定 URLbrowser_snapshot获取当前页面可交互元素快照browser_click点击指定元素browser_type在输入框输入文本browser_screenshot截图browser_get_text提取页面文本内容建议在正式编排工作流前先用一个最简单的 MCP Client 节点手动调用一次browser_snapshot确认能返回当前页面的快照信息。这一步通过后后面所有操作都会顺畅很多。4. 实战搭建一条“浏览器自动化”工作流4.1 场景自动打开后台页面并提取报表数据为了让过程更具体我拿一个实际的内部场景举例每天早上 9 点自动打开一个需要登录的后台系统进入“运营报表”页面提取昨天订单总数然后把这个数字发给企业微信机器人。整个过程用 n8n 节点完全可视化编排不写传统 Playwright 脚本。核心思路是用 Schedule Trigger 定时触发MCP Client 节点负责打开页面、点击菜单、提取文本Code 节点做数据解析最后用 Webhook 节点把结果推送出去。这样每个环节都能单独调试出问题时定位非常方便。4.2 节点编排与关键配置工作流的节点顺序如下Schedule Trigger设置每天 09:00 触发。MCP Client调用 browser_navigate 打开登录页。MCP Client调用 browser_type 输入账号密码。MCP Client调用 browser_click 点击登录按钮。MCP Client调用 browser_navigate 进入报表页。MCP Client调用 browser_get_text 提取关键数字。Code清洗和格式化数据。Webhook推送到企业微信机器人。以第一个 MCP Client 节点为例参数大概是这样{ tool: browser_navigate, arguments: { url: https://your-internal-system.com/login } }在 n8n 界面里你不需要写 JSON直接在节点的 Tool 下拉框里选browser_navigate然后填 URL 参数就行。后面的登录操作用到 browser_type 时参数通常是两个一个是元素定位符一个是输入文本。实际跑的时候建议先调用一次browser_snapshot看看登录框的定位信息再填参数这样可以大大减少定位失败的概率。4.3 用 Code 节点把浏览器输出清洗成结构化 JSONMCP 节点返回的内容通常比较原始可能是页面快照、结构化 JSON 或纯文本直接拿去推送会显得很乱。我的习惯是在提取步骤后面加一个 Code 节点做剥离和格式化。const rawItems $input.all(); const textContent rawItems[0].json.text || rawItems[0].json.content || ; const match textContent.match(/昨日订单数[:\s]*(\d)/); const orderCount match ? match[1] : 未识别; return [{ json: { date: new Date().toISOString().slice(0, 10), orderCount } }];这段代码做的事情很简单从 MCP 返回文本里用正则把订单数字提取出来再包装成干净的结构化对象。后面推送节点的使用体验会好很多在调试时也能直接看到最终格式化结果。如果你提取的是表格数据可以用正则把行和列拆出来或者直接把返回内容转成 JSON具体看目标页面的结构。4.4 定时触发与失败重试设置工作流跑通后最后一步是让它稳定地每天执行。Schedule Trigger 的配置很简单选自定义 cron 表达式填入0 9 * * *就是每天 9 点。更关键的是在 n8n 的 Workflow Settings 里把失败重试次数打开我一般设置 3 次重试每次间隔 2 分钟。浏览器自动化属于相对脆弱的操作页面加载慢、元素未出现、登录态过期都会导致节点失败。设置重试可以解决大部分偶发问题。同时建议给关键 MCP Client 节点开启“Continue On Fail”前先观察一下日志不要盲目开启否则页面暴露问题时工作流会假装成功排查反而更麻烦。5. 常见问题与排查技巧实录5.1 常见错误速查表这段时间实操下来大部分问题集中在连接、环境和参数三类。我把高频问题整理成一张表格先对号入座再动手排查错误现象常见原因解决方法MCP Client 节点连接超时URL 写错或网络不通确认 URL 以 /mcp 结尾并检查端口401 或鉴权失败服务端要求 token但凭证里没填在 Headers 中补充 Authorization工具列表加载不出来playwright-mcp 未启动或协议选错检查启动日志确认选择 HTTP 类型浏览器启动直接抛错Chromium 内核未安装执行npx playwright install chromium容器内访问宿主机失败缺少 host.docker.internal 映射给 docker-compose 加 extra_hosts页面元素找不到定位符不准确或页面未加载完先调用 browser_snapshot 获取准确快照5.2 浏览器启动报错与系统依赖如果你不是在现成服务器上跑而是在精简版 Linux 容器里跑 playwright-mcp大概率会遇到浏览器启动报错最常见的是缺少libnss3、libatk-bridge2.0等系统库。这时候分别安装对应依赖就行CentOS 用 yumUbuntu 用 apt例如apt-get install -y libnss3 libatk-bridge2.0-0。另一个我踩过的坑是内存不足。Playwright 启动 Chromium 至少需要几百 MB 内存如果服务器只有 512MB很可能出现启动一半被系统杀掉的情况。建议至少 1GB 可用内存并且在启动 playwright-mcp 时不要同时跑多个浏览器实例。5.3 安全合规与资源占用提醒这个组合能力很强但一定不要拿去做违规的事情。我自己的原则是只操作自己拥有或明确获得授权的站点不绕过登录限制不批量抓取个人信息。采集数据时也要控制频率给目标站点留足访问间隔避免触发反爬机制或影响正常用户访问。从资源占用角度看每次浏览器操作都会占用一定 CPU 和内存尤其是截图和渲染多标签页面时。建议在 n8n 里避免用并行分支同时调用多个浏览器节点有需要的话把流程改成串行。我习惯在每次工作流结束时让 playwright-mcp 保持空闲状态而不是在一个流程里开几十个页面这样稳定性会明显提升。5.4 让组合更稳定的 3 个细节最后分享三个让整体稳定性明显提升的小细节第一在 MCP Client 节点参数里尽量给浏览器操作设置合理的超时时间不要让一个等待页面加载的操作卡死整个工作流。第二尽量复用同一个浏览器会话去完成连续操作比如登录后在同一会话里做后续操作不要每一步都重新打开浏览器。第三把 playwright-mcp 的启动命令写成一个系统服务加好自动重启策略这样即使进程意外退出n8n 下一次调用时也能自动恢复省去手动干预的麻烦。我在实际跑这个组合时最舒服的用法其实是把经常要重复的浏览器操作封装成 n8n 子工作流这样团队里其他人不用懂 Playwright也照样能复用这些能力。另外还是想再强调一次别把 playwright-mcp 直接暴露在公网上尤其不要忽略鉴权配置这类工具一旦被外人利用后果会比想象中严重得多。希望这篇记录能帮你少走一些弯路把 n8n 和 playwright-mcp 的组合用得更顺手。本文还有配套的精品资源点击获取