简介这份资源面向希望在 n8n 中实现浏览器自动化的开发者与运维人员围绕 MCP 协议与 playwright-mcp 的协同展开解决工作流中网页导航、截图、表单填写、按钮点击等自动化操作难以落地的问题。压缩包共 9 个文件约 13KB包含 2 个 json 工作流与配置、2 个 md 说明文档、1 个 yml 编排文件、1 个 html 页面、1 个 js 启动脚本及 gitignore、inscode 等辅助文件覆盖从 MCP 服务器启动到测试工作流搭建的完整链路。已有 577 人学习。读者可获得可直接参考的 browser-automation 工作流示例、start-mcp-server 脚本与 docker-compose 编排并了解凭证创建、社区节点配置及浏览器交互不完整时的排错思路附录还区分了 MCP Client Tool node 与 n8n-nodes-mcp-client 的差异适合具备一定 n8n 基础、想快速上手 MCP 浏览器自动化的中高级用户。1. n8n 调用 playwright-mcp把浏览器自动化塞进工作流的那条暗线很多团队用 n8n 做数据搬运、定时抓取、表单回填流程跑到“打开网页、点按钮、等元素出现”这一步就卡住了。n8n 自带的 HTTP Request 节点只能拿静态响应遇到 JS 渲染、登录态、文件上传就抓瞎。playwright-mcp 的出现把这块补上了它把 Playwright 的浏览器控制能力封装成 MCP 协议服务n8n 通过 MCP Client 节点调用等于给工作流装了一双能点鼠标、能读 DOM 的手。这个方案适合两类人一是已经用 n8n 编排业务、但被动态页面挡住的后端工程师二是想用低代码方式跑浏览器自动化、又不想写完整 Playwright 脚本的测试或运营开发。核心链路是 n8n 触发 → MCP Client 发工具调用 → playwright-mcp 执行浏览器动作 → 结果回传节点。下面按“先跑通、再调参、后避坑”的顺序拆开讲。2. 先搞懂 playwright-mcp 在 n8n 里到底扮演什么角色2.1 MCP 协议不是 HTTP 的替代品而是工具调用的约定层MCPModel Context Protocol本质是一套“客户端问、服务端答”的 JSON-RPC 约定。playwright-mcp 服务端启动后暴露一组工具比如browser_navigate、browser_click、browser_type、browser_snapshot。n8n 里的 MCP Client 节点不关心浏览器怎么启动它只负责把工具名和参数打包发过去再把返回的文本或截图接回来。这跟直接写 Playwright 脚本的区别在于脚本里await page.click()是命令式代码而 MCP 调用是声明式工具请求n8n 的节点可以复用、可以串在任意分支后面。常见做法是让 playwright-mcp 以 stdio 或 SSE 两种模式之一运行。stdio 模式适合 n8n 和 MCP 服务在同一台机器上n8n 通过子进程方式拉起SSE 模式适合 MCP 服务单独部署n8n 用 URL 连接。选哪种取决于你的部署边界如果 n8n 跑在容器里、浏览器也要跑在容器里stdio 更省事如果浏览器需要独立资源池SSE 更稳。2.2 为什么不用 n8n 的 Execute Command 直接跑脚本有人会想我直接在 n8n 里用 Execute Command 节点跑node script.js不就行了能跑但会丢三样东西。第一状态保持。Playwright 脚本每次执行都是新浏览器上下文登录态、cookie、localStorage 全丢而 MCP 服务可以维持一个长驻浏览器实例多次工具调用共享同一个 page。第二错误结构化。脚本报错是 stderr 一堆堆栈n8n 节点拿到后很难判断是超时还是选择器失效MCP 返回的是结构化错误码和消息方便走 IF 分支。第三并发控制。多个工作流同时触发脚本会抢浏览器端口MCP 服务端可以内置队列n8n 侧只需要处理等待。我一般会这样选一次性、无状态的任务用 Execute Command 更轻需要登录态、多步骤交互、截图回传的一律走 playwright-mcp。2.3 最小可跑通的部署命令与 n8n 节点配置先装 playwright-mcp 服务端。假设你已经有一个 Node.js 环境浏览器依赖用 Playwright 自带的安装命令拉齐# 安装 playwright-mcp 服务端包包名以实际发布为准这里用占位 npm install -g playwright/mcplatest # 安装 Chromium 浏览器二进制避免运行时缺依赖 npx playwright install chromium # 以 SSE 模式启动监听本地 3001 端口 playwright-mcp --port 3001 --host 127.0.0.1启动后它会打印一个 SSE 端点类似http://127.0.0.1:3001/sse。接着在 n8n 里加一个 MCP Client 节点连接方式选 SSEURL 填上面这个地址。节点里会列出可用工具先选browser_navigate做连通性测试参数url填一个静态页面地址。执行后如果返回页面标题说明链路通了。参数说明--port是 MCP 服务监听端口别和 n8n 自身端口冲突--host建议绑 127.0.0.1除非你有反向代理做鉴权--browser可以指定 chromium/firefox/webkit默认 chromium 兼容性最好。n8n 侧 MCP Client 节点有一个timeout字段默认 30 秒浏览器冷启动可能超过建议先调到 60000 毫秒。提示第一次跑browser_navigate如果卡住先看 MCP 服务端日志有没有 “browser launched” 字样没有就是浏览器二进制没装好。3. 把“打开页面→填表单→取结果”串成一条 n8n 工作流3.1 用 browser_snapshot 代替盲目选择器Playwright 脚本里最头疼的是选择器写错。MCP 提供了一个browser_snapshot工具返回当前页面的可访问性树accessibility tree里面每个可交互元素都带 ref 标识。你不需要猜 CSS 选择器直接拿 snapshot 里的 ref 去调browser_click或browser_type。这比page.locator(.btn-submit)稳得多因为 ref 是运行时生成的跟 DOM 结构解耦。操作步骤先调browser_navigate打开目标页再调browser_snapshot把返回文本里目标按钮的 ref 记下来比如ref_12。然后调browser_click参数element填 “ref_12”elementType填 “ref”。如果页面有 iframesnapshot 会嵌套展示ref 仍然有效。{ tool: browser_click, arguments: { element: ref_12, elementType: ref } }这段 JSON 是 MCP Client 节点实际发出的调用体。逻辑说明element是 snapshot 里读到的引用标识elementType告诉服务端按 ref 解析而不是按文本或选择器。参数坑在于 ref 有时效性——页面刷新或 DOM 大改后 ref 会失效必须重新 snapshot。我一般会在每个可能引起页面跳转的动作后重新 snapshot 一次宁可多一步也不赌 ref 不变。3.2 表单填写与文件上传的参数细节browser_type用于文本输入关键参数是text和submit。submit设为 true 时会在输入后按回车适合搜索框设为 false 则只填不提交适合多字段表单。文件上传用browser_file_upload参数paths是本地文件绝对路径数组。注意 MCP 服务端和 n8n 如果不在同一台机器路径必须是服务端能访问到的路径不能填 n8n 容器里的路径。{ tool: browser_type, arguments: { element: ref_5, elementType: ref, text: {{ $json.searchKeyword }}, submit: false } }这里{{ $json.searchKeyword }}是 n8n 表达式把上游节点数据注入 MCP 调用。逻辑说明n8n 的 MCP Client 节点支持表达式插值所以工作流前面可以接一个 Set 节点或数据库查询节点来动态生成输入。参数坑在于text里如果包含特殊字符比如换行、引号需要先经过 n8n 的字符串转义否则 JSON 解析会失败。稳妥做法是在 Set 节点里用{{ JSON.stringify($json.searchKeyword) }}包一层。3.3 等待策略别用 sleep用 browser_wait_for页面加载慢的时候新手容易在 n8n 里加 Wait 节点硬等 5 秒。这既不精准又拖慢整体流程。playwright-mcp 提供browser_wait_for可以等文本出现、等元素可见、等网络空闲。参数text填目标文本time填超时毫秒数。比如等结果列表里出现“共 20 条”再继续。{ tool: browser_wait_for, arguments: { text: 共 20 条, time: 15000 } }逻辑说明服务端会轮询页面内容直到匹配到文本或超时。参数坑在于text是子串匹配如果页面有多个地方出现同样文字可能提前返回。更稳的是等某个结果容器的 ref 出现但 ref 需要先 snapshot所以折中方案是等一个不太可能重复的文本片段。超时时间建议按目标站点历史响应时间上浮 50%不要一律 30 秒否则失败分支要等太久。3.4 把截图和页面文本回传到 n8n 后续节点browser_take_screenshot返回 base64 图片数据n8n 可以接一个 Move Binary Data 节点存成文件或者直接传给对象存储。browser_get_text返回指定 ref 的文本内容适合抓取表格或列表。这两个工具是工作流“出口”的关键没有它们浏览器动作的结果就烂在 MCP 服务里了。{ tool: browser_get_text, arguments: { element: ref_20, elementType: ref } }逻辑说明返回的文本会放在 MCP Client 节点的输出字段里后续可以用 n8n 的 Item Lists 节点拆分。参数坑在于browser_get_text只取该元素及其子元素的可见文本隐藏元素不返回。如果目标内容在display:none的折叠面板里得先用browser_click展开再取。4. 避坑n8n 调用 playwright-mcp 最常见的 5 个翻车现场4.1 现象MCP Client 节点报 “connection refused”但服务端明明在跑原因通常是 n8n 跑在 Docker 容器里而 MCP 服务跑在宿主机容器内127.0.0.1指向容器自己。解决把 MCP 服务启动时的--host改成0.0.0.0n8n 侧 URL 填宿主机局域网 IP 或 Docker 网桥地址。如果 n8n 也在 Docker用--network host或自定义网络让两个容器互通。改完记得检查防火墙有没有放行端口。4.2 现象browser_click 执行成功但页面没反应原因多半是点到了不可见元素或遮罩层下面的元素。snapshot 返回的 ref 包含隐藏节点直接点不会报错但也不生效。解决先调browser_snapshot确认目标 ref 的visible属性为 true如果被弹窗遮挡先点关闭按钮或按 Escape。另一个可能是点击触发了新标签页而 MCP 默认还在原 page 上操作需要调browser_tab_list切换。4.3 现象工作流跑几十次后浏览器进程堆积内存爆掉原因是没有在流程结束时关闭页面或浏览器上下文。MCP 服务默认保持浏览器常驻方便复用但 n8n 工作流如果高频触发page 会越开越多。解决在流程末尾加一个browser_close调用参数closeAll设为 true。如果确实需要复用登录态至少定期调browser_tab_close关掉多余标签页。我一般会在工作流最外层加一个错误分支无论成功失败都执行 close。4.4 现象文件上传报 “path not found”但文件确实存在原因是 MCP 服务端运行在容器或另一台机器它看到的文件系统跟 n8n 不一样。解决把待上传文件放到 MCP 服务端能访问的共享目录n8n 侧传绝对路径。如果做不到共享存储先用 n8n 的 Write Binary File 节点把文件写到 MCP 服务端挂载的卷里再传路径。注意路径分隔符在 Windows 和 Linux 之间不通用统一用正斜杠。4.5 现象browser_wait_for 超时但手动打开页面明明很快原因是 MCP 启动的浏览器默认无头模式某些站点对无头 UA 返回不同内容或触发验证。解决启动参数加--no-headless先验证是不是无头导致如果确认是可以加--user-agent伪装常规浏览器或者用--storage-state加载已登录的 cookie 文件。另一个常见原因是代理设置MCP 服务端如果没配代理访问外网资源会超时需要在启动时加--proxy参数。5. 进阶用 storage-state 复用登录态把 MCP 调用压到 3 步以内登录态复用是 n8n playwright-mcp 组合里最值得花时间优化的点。默认每次工作流触发都要重新走登录流程既慢又容易触发风控。playwright-mcp 支持--storage-state参数指定一个 JSON 文件存放 cookie 和 localStorage。你只需要手动登录一次导出状态文件后续所有工作流启动时加载它。导出状态的做法先用非无头模式启动 MCP手动完成登录然后调browser_storage_state工具把返回内容保存成state.json。之后启动命令改成playwright-mcp --port 3001 --host 127.0.0.1 --storage-state /data/state.json这样每次browser_navigate打开目标站都是已登录状态。注意状态文件有过期时间跟站点 session 策略有关一般几天到几周。我习惯在 n8n 里加一个定时工作流每周一凌晨跑一次登录检查如果发现跳转到登录页就发告警人工重新导出。另一个进阶技巧是把常用操作封装成 n8n 子工作流。比如“打开报表页→等表格加载→取指定列文本”这三步在多个主流程里重复出现。用 Execute Workflow 节点调用子工作流子工作流内部只维护一套 MCP 调用参数。这样主流程看起来就是“触发→调子工作流→拿数据”MCP 的 ref 变化、等待时间调整都收敛在一个地方。参数传递用子工作流的输入 schema 定义避免直接传大段 JSON。验证方法在子工作流里加一个browser_snapshot后接 IF 节点判断 snapshot 文本里是否包含预期关键词。如果不包含走错误分支重试一次重试仍失败就记录当前 URL 和截图到数据库。这套验证逻辑比单纯看 MCP 调用是否抛异常更可靠因为很多页面问题是“成功返回但内容不对”。最后说个血泪经验别在 n8n 的 MCP Client 节点里写太长的表达式。我见过有人把整个 JavaScript 函数塞进参数里结果 n8n 表达式引擎解析慢加上 MCP 超时整个工作流卡死。正确做法是前面用 Code 节点算好输出扁平字段MCP 调用只做变量替换。浏览器自动化本身就有玄学成分把可控的部分做简单出问题时才排查得动。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/14 8:22:06 · 阅读 1.2k n8n 集成 playwright-mcp：浏览器自动化工作流实战与避坑指南
简介这份资源面向希望在 n8n 中实现浏览器自动化的开发者与运维人员围绕 MCP 协议与 playwright-mcp 的协同展开解决工作流中网页导航、截图、表单填写、按钮点击等自动化操作难以落地的问题。压缩包共 9 个文件约 13KB包含 2 个 json 工作流与配置、2 个 md 说明文档、1 个 yml 编排文件、1 个 html 页面、1 个 js 启动脚本及 gitignore、inscode 等辅助文件覆盖从 MCP 服务器启动到测试工作流搭建的完整链路。已有 577 人学习。读者可获得可直接参考的 browser-automation 工作流示例、start-mcp-server 脚本与 docker-compose 编排并了解凭证创建、社区节点配置及浏览器交互不完整时的排错思路附录还区分了 MCP Client Tool node 与 n8n-nodes-mcp-client 的差异适合具备一定 n8n 基础、想快速上手 MCP 浏览器自动化的中高级用户。1. n8n 调用 playwright-mcp把浏览器自动化塞进工作流的那条暗线很多团队用 n8n 做数据搬运、定时抓取、表单回填流程跑到“打开网页、点按钮、等元素出现”这一步就卡住了。n8n 自带的 HTTP Request 节点只能拿静态响应遇到 JS 渲染、登录态、文件上传就抓瞎。playwright-mcp 的出现把这块补上了它把 Playwright 的浏览器控制能力封装成 MCP 协议服务n8n 通过 MCP Client 节点调用等于给工作流装了一双能点鼠标、能读 DOM 的手。这个方案适合两类人一是已经用 n8n 编排业务、但被动态页面挡住的后端工程师二是想用低代码方式跑浏览器自动化、又不想写完整 Playwright 脚本的测试或运营开发。核心链路是 n8n 触发 → MCP Client 发工具调用 → playwright-mcp 执行浏览器动作 → 结果回传节点。下面按“先跑通、再调参、后避坑”的顺序拆开讲。2. 先搞懂 playwright-mcp 在 n8n 里到底扮演什么角色2.1 MCP 协议不是 HTTP 的替代品而是工具调用的约定层MCPModel Context Protocol本质是一套“客户端问、服务端答”的 JSON-RPC 约定。playwright-mcp 服务端启动后暴露一组工具比如browser_navigate、browser_click、browser_type、browser_snapshot。n8n 里的 MCP Client 节点不关心浏览器怎么启动它只负责把工具名和参数打包发过去再把返回的文本或截图接回来。这跟直接写 Playwright 脚本的区别在于脚本里await page.click()是命令式代码而 MCP 调用是声明式工具请求n8n 的节点可以复用、可以串在任意分支后面。常见做法是让 playwright-mcp 以 stdio 或 SSE 两种模式之一运行。stdio 模式适合 n8n 和 MCP 服务在同一台机器上n8n 通过子进程方式拉起SSE 模式适合 MCP 服务单独部署n8n 用 URL 连接。选哪种取决于你的部署边界如果 n8n 跑在容器里、浏览器也要跑在容器里stdio 更省事如果浏览器需要独立资源池SSE 更稳。2.2 为什么不用 n8n 的 Execute Command 直接跑脚本有人会想我直接在 n8n 里用 Execute Command 节点跑node script.js不就行了能跑但会丢三样东西。第一状态保持。Playwright 脚本每次执行都是新浏览器上下文登录态、cookie、localStorage 全丢而 MCP 服务可以维持一个长驻浏览器实例多次工具调用共享同一个 page。第二错误结构化。脚本报错是 stderr 一堆堆栈n8n 节点拿到后很难判断是超时还是选择器失效MCP 返回的是结构化错误码和消息方便走 IF 分支。第三并发控制。多个工作流同时触发脚本会抢浏览器端口MCP 服务端可以内置队列n8n 侧只需要处理等待。我一般会这样选一次性、无状态的任务用 Execute Command 更轻需要登录态、多步骤交互、截图回传的一律走 playwright-mcp。2.3 最小可跑通的部署命令与 n8n 节点配置先装 playwright-mcp 服务端。假设你已经有一个 Node.js 环境浏览器依赖用 Playwright 自带的安装命令拉齐# 安装 playwright-mcp 服务端包包名以实际发布为准这里用占位 npm install -g playwright/mcplatest # 安装 Chromium 浏览器二进制避免运行时缺依赖 npx playwright install chromium # 以 SSE 模式启动监听本地 3001 端口 playwright-mcp --port 3001 --host 127.0.0.1启动后它会打印一个 SSE 端点类似http://127.0.0.1:3001/sse。接着在 n8n 里加一个 MCP Client 节点连接方式选 SSEURL 填上面这个地址。节点里会列出可用工具先选browser_navigate做连通性测试参数url填一个静态页面地址。执行后如果返回页面标题说明链路通了。参数说明--port是 MCP 服务监听端口别和 n8n 自身端口冲突--host建议绑 127.0.0.1除非你有反向代理做鉴权--browser可以指定 chromium/firefox/webkit默认 chromium 兼容性最好。n8n 侧 MCP Client 节点有一个timeout字段默认 30 秒浏览器冷启动可能超过建议先调到 60000 毫秒。提示第一次跑browser_navigate如果卡住先看 MCP 服务端日志有没有 “browser launched” 字样没有就是浏览器二进制没装好。3. 把“打开页面→填表单→取结果”串成一条 n8n 工作流3.1 用 browser_snapshot 代替盲目选择器Playwright 脚本里最头疼的是选择器写错。MCP 提供了一个browser_snapshot工具返回当前页面的可访问性树accessibility tree里面每个可交互元素都带 ref 标识。你不需要猜 CSS 选择器直接拿 snapshot 里的 ref 去调browser_click或browser_type。这比page.locator(.btn-submit)稳得多因为 ref 是运行时生成的跟 DOM 结构解耦。操作步骤先调browser_navigate打开目标页再调browser_snapshot把返回文本里目标按钮的 ref 记下来比如ref_12。然后调browser_click参数element填 “ref_12”elementType填 “ref”。如果页面有 iframesnapshot 会嵌套展示ref 仍然有效。{ tool: browser_click, arguments: { element: ref_12, elementType: ref } }这段 JSON 是 MCP Client 节点实际发出的调用体。逻辑说明element是 snapshot 里读到的引用标识elementType告诉服务端按 ref 解析而不是按文本或选择器。参数坑在于 ref 有时效性——页面刷新或 DOM 大改后 ref 会失效必须重新 snapshot。我一般会在每个可能引起页面跳转的动作后重新 snapshot 一次宁可多一步也不赌 ref 不变。3.2 表单填写与文件上传的参数细节browser_type用于文本输入关键参数是text和submit。submit设为 true 时会在输入后按回车适合搜索框设为 false 则只填不提交适合多字段表单。文件上传用browser_file_upload参数paths是本地文件绝对路径数组。注意 MCP 服务端和 n8n 如果不在同一台机器路径必须是服务端能访问到的路径不能填 n8n 容器里的路径。{ tool: browser_type, arguments: { element: ref_5, elementType: ref, text: {{ $json.searchKeyword }}, submit: false } }这里{{ $json.searchKeyword }}是 n8n 表达式把上游节点数据注入 MCP 调用。逻辑说明n8n 的 MCP Client 节点支持表达式插值所以工作流前面可以接一个 Set 节点或数据库查询节点来动态生成输入。参数坑在于text里如果包含特殊字符比如换行、引号需要先经过 n8n 的字符串转义否则 JSON 解析会失败。稳妥做法是在 Set 节点里用{{ JSON.stringify($json.searchKeyword) }}包一层。3.3 等待策略别用 sleep用 browser_wait_for页面加载慢的时候新手容易在 n8n 里加 Wait 节点硬等 5 秒。这既不精准又拖慢整体流程。playwright-mcp 提供browser_wait_for可以等文本出现、等元素可见、等网络空闲。参数text填目标文本time填超时毫秒数。比如等结果列表里出现“共 20 条”再继续。{ tool: browser_wait_for, arguments: { text: 共 20 条, time: 15000 } }逻辑说明服务端会轮询页面内容直到匹配到文本或超时。参数坑在于text是子串匹配如果页面有多个地方出现同样文字可能提前返回。更稳的是等某个结果容器的 ref 出现但 ref 需要先 snapshot所以折中方案是等一个不太可能重复的文本片段。超时时间建议按目标站点历史响应时间上浮 50%不要一律 30 秒否则失败分支要等太久。3.4 把截图和页面文本回传到 n8n 后续节点browser_take_screenshot返回 base64 图片数据n8n 可以接一个 Move Binary Data 节点存成文件或者直接传给对象存储。browser_get_text返回指定 ref 的文本内容适合抓取表格或列表。这两个工具是工作流“出口”的关键没有它们浏览器动作的结果就烂在 MCP 服务里了。{ tool: browser_get_text, arguments: { element: ref_20, elementType: ref } }逻辑说明返回的文本会放在 MCP Client 节点的输出字段里后续可以用 n8n 的 Item Lists 节点拆分。参数坑在于browser_get_text只取该元素及其子元素的可见文本隐藏元素不返回。如果目标内容在display:none的折叠面板里得先用browser_click展开再取。4. 避坑n8n 调用 playwright-mcp 最常见的 5 个翻车现场4.1 现象MCP Client 节点报 “connection refused”但服务端明明在跑原因通常是 n8n 跑在 Docker 容器里而 MCP 服务跑在宿主机容器内127.0.0.1指向容器自己。解决把 MCP 服务启动时的--host改成0.0.0.0n8n 侧 URL 填宿主机局域网 IP 或 Docker 网桥地址。如果 n8n 也在 Docker用--network host或自定义网络让两个容器互通。改完记得检查防火墙有没有放行端口。4.2 现象browser_click 执行成功但页面没反应原因多半是点到了不可见元素或遮罩层下面的元素。snapshot 返回的 ref 包含隐藏节点直接点不会报错但也不生效。解决先调browser_snapshot确认目标 ref 的visible属性为 true如果被弹窗遮挡先点关闭按钮或按 Escape。另一个可能是点击触发了新标签页而 MCP 默认还在原 page 上操作需要调browser_tab_list切换。4.3 现象工作流跑几十次后浏览器进程堆积内存爆掉原因是没有在流程结束时关闭页面或浏览器上下文。MCP 服务默认保持浏览器常驻方便复用但 n8n 工作流如果高频触发page 会越开越多。解决在流程末尾加一个browser_close调用参数closeAll设为 true。如果确实需要复用登录态至少定期调browser_tab_close关掉多余标签页。我一般会在工作流最外层加一个错误分支无论成功失败都执行 close。4.4 现象文件上传报 “path not found”但文件确实存在原因是 MCP 服务端运行在容器或另一台机器它看到的文件系统跟 n8n 不一样。解决把待上传文件放到 MCP 服务端能访问的共享目录n8n 侧传绝对路径。如果做不到共享存储先用 n8n 的 Write Binary File 节点把文件写到 MCP 服务端挂载的卷里再传路径。注意路径分隔符在 Windows 和 Linux 之间不通用统一用正斜杠。4.5 现象browser_wait_for 超时但手动打开页面明明很快原因是 MCP 启动的浏览器默认无头模式某些站点对无头 UA 返回不同内容或触发验证。解决启动参数加--no-headless先验证是不是无头导致如果确认是可以加--user-agent伪装常规浏览器或者用--storage-state加载已登录的 cookie 文件。另一个常见原因是代理设置MCP 服务端如果没配代理访问外网资源会超时需要在启动时加--proxy参数。5. 进阶用 storage-state 复用登录态把 MCP 调用压到 3 步以内登录态复用是 n8n playwright-mcp 组合里最值得花时间优化的点。默认每次工作流触发都要重新走登录流程既慢又容易触发风控。playwright-mcp 支持--storage-state参数指定一个 JSON 文件存放 cookie 和 localStorage。你只需要手动登录一次导出状态文件后续所有工作流启动时加载它。导出状态的做法先用非无头模式启动 MCP手动完成登录然后调browser_storage_state工具把返回内容保存成state.json。之后启动命令改成playwright-mcp --port 3001 --host 127.0.0.1 --storage-state /data/state.json这样每次browser_navigate打开目标站都是已登录状态。注意状态文件有过期时间跟站点 session 策略有关一般几天到几周。我习惯在 n8n 里加一个定时工作流每周一凌晨跑一次登录检查如果发现跳转到登录页就发告警人工重新导出。另一个进阶技巧是把常用操作封装成 n8n 子工作流。比如“打开报表页→等表格加载→取指定列文本”这三步在多个主流程里重复出现。用 Execute Workflow 节点调用子工作流子工作流内部只维护一套 MCP 调用参数。这样主流程看起来就是“触发→调子工作流→拿数据”MCP 的 ref 变化、等待时间调整都收敛在一个地方。参数传递用子工作流的输入 schema 定义避免直接传大段 JSON。验证方法在子工作流里加一个browser_snapshot后接 IF 节点判断 snapshot 文本里是否包含预期关键词。如果不包含走错误分支重试一次重试仍失败就记录当前 URL 和截图到数据库。这套验证逻辑比单纯看 MCP 调用是否抛异常更可靠因为很多页面问题是“成功返回但内容不对”。最后说个血泪经验别在 n8n 的 MCP Client 节点里写太长的表达式。我见过有人把整个 JavaScript 函数塞进参数里结果 n8n 表达式引擎解析慢加上 MCP 超时整个工作流卡死。正确做法是前面用 Code 节点算好输出扁平字段MCP 调用只做变量替换。浏览器自动化本身就有玄学成分把可控的部分做简单出问题时才排查得动。希望帮到你。本文还有配套的精品资源点击获取