1. 为什么要在 n8n 里接 playwright-mcp浏览器自动化工作流的真实痛点n8n 本身是个很能打的工作流引擎HTTP 请求、数据库、定时任务、消息推送这些都能编排得明明白白。但一旦工作流里出现「打开网页、点按钮、填表单、抓渲染后的 DOM」这类需求纯 HTTP 节点就开始力不从心了。原因很直接现代前端大量依赖 JavaScript 动态渲染你直接请求接口拿到的 HTML 往往是个空壳真正的内容要等浏览器执行完脚本才出现。playwright-mcp 这个项目解决的就是这一段。它把 Playwright 的浏览器操控能力通过 MCPModel Context Protocol模型上下文协议暴露成一组标准工具任何支持 MCP 的客户端都能调用它去开浏览器、导航、点击、截图、读取页面内容。你可以把它理解成一个「浏览器操作遥控器」遥控器那头是真实的 Chromium 实例这头是标准化的工具调用协议。那为什么要在 n8n 里调它而不是直接写个 Playwright 脚本因为工作流的价值在于编排。你可能希望每天早上定时触发让浏览器去某个后台系统登录、导出报表、把结果写进数据库、再发一条通知。这一整套流程里浏览器操作只是其中一环前后还有大量非浏览器逻辑。用 n8n 把这些串起来比写一个几百行的脚本再自己处理调度、重试、日志要省心得多。我试过把 playwright-mcp 单独跑起来再用 n8n 的社区节点去连它整体链路是通的。这篇就把从 MCP 服务启动、社区节点安装、凭证配置到工作流触发验证的完整路径记下来中间踩过的坑也一并说清楚。适合已经在用 n8n、想把手伸到浏览器自动化、又不想把整个工作流拆成两套系统的人。核心检索词先摆出来n8n 调用 playwright-mcp、n8n 社区节点配置、MCP 服务启动、浏览器自动化工作流。这几个词后面会反复出现因为整篇就是围绕它们展开的。需要先明确一个前提n8n 和 playwright-mcp 是两个独立进程。n8n 通常跑在 Docker 里playwright-mcp 跑在宿主机或者另一个容器里。它们之间靠 HTTP 通信所以网络可达性是第一道坎后面会专门讲host.docker.internal这个关键点。2. 前置准备playwright-mcp 服务启动与 n8n 社区节点安装这一节把两边的准备工作做完后面配置才有东西可连。2.1 启动 playwright-mcp 独立服务playwright-mcp 支持多种启动方式最省事的是用 npx 直接拉最新版。在宿主机不是 n8n 容器内部执行npx playwright/mcplatest --port 8931这条命令会做几件事下载并缓存 playwright-mcp 包、启动一个 HTTP 服务、监听 8931 端口、同时准备好 Playwright 需要的浏览器内核。第一次跑会慢一些因为要下 Chromium耐心等它输出监听日志。启动成功后你会看到类似Listening on http://localhost:8931的输出。这时候在宿主机浏览器里访问http://localhost:8931/mcp如果返回一段 JSON 或者协议握手信息说明服务活着。这一步很关键很多人跳过验证直接去 n8n 配结果连不上都不知道是哪边的问题。这里有个必须提前说清楚的坑n8n 如果跑在 Docker 容器里容器内的localhost指的是容器自己不是宿主机。所以你在 n8n 凭证里填http://localhost:8931/mcp是永远连不上的。正确做法是用host.docker.internal这个特殊域名它会被 Docker 解析成宿主机的地址。最终要填进 n8n 的 URL 是http://host.docker.internal:8931/mcp这个地址先记下来第 3 节配置凭证时直接用。如果你用的是 Linux 上的 Dockerhost.docker.internal默认可能不生效需要在启动 n8n 容器时加--add-hosthost.docker.internal:host-gateway参数或者在 docker-compose 里配extra_hosts。这个细节后面排障章节还会提。2.2 安装 n8n 社区节点 n8n-nodes-mcpn8n 的节点分两类内置节点和社区节点。社区节点需要手动装一次装完之后就能像内置节点一样在工作流里拖出来用。我们要装的是n8n-nodes-mcp注意大小写敏感写错了装不上。操作路径进入 n8n 工作空间左下角点「设置」Settings找到「社区节点」Community Nodes点「安装」Install在输入框里填n8n-nodes-mcp点安装等它拉包、编译、注册。装好后在节点列表里能看到它。这里要区分一个容易混的东西n8n 里还有一个叫「MCP Client Tool node」的节点那是给 AI Agent 用的工具节点和我们装的社区节点不是一回事。社区节点在列表里带一个方盒图标MCP Client Tool node 不带。两者用途不同本篇用的是社区节点因为它能更直接地控制 MCP 工具的列举和执行。装完社区节点前置准备就齐了一边是跑着的 playwright-mcp 服务一边是能调 MCP 的 n8n 节点。接下来进入配置环节。3. 可复制配置n8n 凭证、社区节点参数与工作流 JSON这一节是整篇的核心所有能直接抄的东西都放这里。3.1 创建 MCP 凭证在 n8n 里新建凭证类型选MCP Client (HTTP Streamable)。目前实测下来HTTP Streamable 这种方式是通的其他传输方式没测通所以别在这上面浪费时间。凭证里主要填一个字段{ mcpServerUrl: http://host.docker.internal:8931/mcp }保存。如果保存时提示连接失败先回到 2.1 确认服务在跑再确认host.docker.internal在容器里能解析。可以在 n8n 容器里执行getent hosts host.docker.internal验证有输出就说明能解析。3.2 社区节点参数配置工作流里需要放两个社区节点一个负责「列出工具」一个负责「执行工具」。第一个节点操作选List Tools凭证选刚才建的那个。这个节点会返回 playwright-mcp 暴露的所有方法比如browser_navigate、browser_click、browser_snapshot、browser_type这些。跑一次就能看到完整列表确认服务端工具都注册上了。第二个节点操作选Execute Tool关键参数有两个{ toolName: {{ $fromAI(toolname) }}, toolParameters: {{ $fromAI(toolparameters) }} }toolName用$fromAI表达式意思是让上游的大模型根据任务自己决定调哪个工具。toolParameters同理让模型生成参数。n8n 1.105.2 之后的版本支持点那个星星按钮自动生成表达式省得手写。如果你不想让模型自由发挥也可以把toolName写死成具体工具名比如browser_navigate参数里固定好 URL。调试阶段建议先写死确认单个工具能跑通再放开给模型。3.3 完整工作流结构一个能跑的最小工作流长这样{ nodes: [ { name: Chat Trigger, type: n8n/n8n-nodes-langchain.chatTrigger, parameters: {} }, { name: AI Agent, type: n8n/n8n-nodes-langchain.agent, parameters: { promptType: define, text: {{ $json.chatInput }}, systemMessage: 分析用户需求结合可用 MCP 工具制定方案必要时调用工具完成任务。 } }, { name: MCP List Tools, type: n8n-nodes-mcp.mcpClient, parameters: { operation: listTools } }, { name: MCP Execute Tool, type: n8n-nodes-mcp.mcpClient, parameters: { operation: executeTool, toolName: {{ $fromAI(toolname) }}, toolParameters: {{ $fromAI(toolparameters) }} } } ] }这个结构里Chat Trigger 接收输入AI Agent 做决策两个 MCP 节点分别负责列举和执行。Agent 需要绑定一个大模型模型选哪个看你自己手头有什么能调工具调用的都行。配置时注意MCP 节点要挂到 Agent 的工具位上这样 Agent 才知道有这些工具可用。挂载方式是在 Agent 节点的工具连接点连过去。4. 验证请求一次端到端调试的完整过程配置完不验证等于没配。这一节走一遍完整的触发流程。4.1 触发工作流在 Chat Trigger 里输入一个需要浏览器的任务比如在百度查询「n8n 常用的社区节点工具」然后总结1、有哪些工具 2、工具的说明和简要使用信息 3、标注信息来源。点执行。n8n 1.105.2 之后支持执行过程跟踪能看到每个节点的输入输出。4.2 观察工具调用先看MCP List Tools节点的输出应该返回 playwright-mcp 提供的完整方法列表。确认里面有browser_navigate、browser_snapshot这些。再看MCP Execute Tool节点它应该被调用了toolName是browser_navigate参数里带着百度 URL。执行后返回浏览器导航成功的信息。接着看后续调用理想情况下应该继续调browser_type往搜索框填词、调browser_click点搜索按钮、调browser_snapshot读取结果。但实测下来这里会出现一个典型现象模型反复打开浏览器、访问百度、然后关掉再打开没有真正在页面里做搜索交互最后直接凭自己的知识给了答案。4.3 结果分析这个现象说明链路是通的——工具确实被调用了浏览器确实开了MCP 通信没问题。问题出在模型对工具调用序列的规划上它没有把「导航→输入→点击→读取」串成一条完整链而是停在第一步就以为任务完成了。从调试角度这已经算验证成功n8n 能调 playwright-mcp工具能执行返回值能回到工作流。剩下的交互深度问题属于提示词工程和模型能力的范畴可以通过更明确的系统提示词、或者把工具调用步骤写死来改善。验证成功的标志有三个List Tools 返回了工具列表、Execute Tool 被实际调用、浏览器进程真的启动了。这三个都满足说明配置没问题。5. 常见报错排查401、local proxy failed、reading choices 与 OAuth配置过程中最容易卡在几个固定报错上逐个说。401 UnauthorizedMCP 服务端要求认证但凭证没带对。playwright-mcp 默认本地启动是不需要认证的如果你遇到 401先确认是不是连到了别的需要 token 的服务。检查凭证里的 URL 有没有写错端口8931 别写成别的。local proxy failed / connection refusedn8n 容器连不到宿主机服务。九成是localhost和host.docker.internal搞混了。在 n8n 容器里执行curl http://host.docker.internal:8931/mcp如果报连接拒绝说明宿主机防火墙挡了或者服务只监听了 127.0.0.1 没监听 0.0.0.0。启动 playwright-mcp 时可以加--host 0.0.0.0让它监听所有网卡。reading choices of undefined这个报错通常出现在 Agent 节点意思是模型返回结构里没有choices字段。原因可能是模型没绑定成功、或者模型不支持工具调用、或者 API 返回了错误但被吞了。先单独测模型节点能不能正常对话再排查工具调用。OAuth 相关报错如果你连的 MCP 服务需要 OAuth凭证类型要选对应的 OAuth 方式不能选 HTTP Streamable。playwright-mcp 本地跑不需要 OAuth遇到这类报错基本是连错服务了。工具列表为空List Tools 返回空数组。检查 playwright-mcp 是否真的启动成功访问http://localhost:8931/mcp看有没有响应。另外确认社区节点版本和服务端协议版本兼容。Linux 下 host.docker.internal 不解析这是 Docker 在 Linux 上的默认行为。启动 n8n 容器时加参数docker run --add-hosthost.docker.internal:host-gateway ...或者在 docker-compose.yml 里extra_hosts: - host.docker.internal:host-gateway改完重启容器再试。排查顺序建议先确认服务端活着再确认网络可达再确认凭证正确最后才怀疑节点配置。大部分问题在前两步就能定位。6. 把 MCP 接入做稳凭证、模型与 Coding Plan 的配合链路跑通之后接下来要考虑的是怎么让它稳定可用。几个实际经验。凭证管理上MCP 的 URL 建议用环境变量注入别硬编码在工作流里。n8n 支持在凭证里引用环境变量这样换环境时不用改工作流。playwright-mcp 的端口如果变了改一处就行。模型选择上工具调用能力强的模型体验明显更好。有些模型对$fromAI生成的参数格式把握不准会导致工具执行失败。调试阶段可以先把toolName和参数写死确认工具本身没问题再逐步放开给模型。如果你打算长期跑这类带 Agent 的工作流可以考虑用 Coding Plan 这类面向持续编码和 Agent 场景的方案在工具调用稳定性和额度上会更从容。接入文档里有完整的凭证配置说明API Keys 页面可以管理你的密钥。对于需要频繁验证模型行为的场景模型对话入口可以快速试提示词不用每次都跑整个工作流。这样调提示词的效率会高很多。最后说个实用技巧playwright-mcp 的浏览器实例是有状态的同一个会话里导航、点击、读取是连续的。但 n8n 每次执行工作流可能是新会话所以别指望跨执行保持登录态。需要保持状态的场景要么在单次执行里把操作做完要么用持久化上下文的方式启动服务。这个细节在官方文档里有说明配之前值得看一眼。整套下来n8n 调 playwright-mcp 的路径是清晰的服务启动、社区节点安装、凭证配置、工作流编排、触发验证。卡点主要集中在网络可达性和模型工具调用规划上前者靠host.docker.internal解决后者靠提示词和模型选择优化。把这两块处理好浏览器自动化工作流就能稳定跑起来了。