Playwright MCP 怎么装：不用订阅、不用账号，3 种接入方式

Playwright MCP 是微软开源的本地 MCP 服务器，装好后 AI 客户端就能直接操作浏览器。它没有订阅档位，不需要账号，也不需要 API key，你只需弄明白两件事：装进哪个客户端、怎么确认装成了。

先说清楚下文信息的来源归属：下文标「推导」的地方，是我按官方页面推出来的结论，不是官方原话；其余事实都能在对应的链接里逐字找到。

现在值得花十分钟看的原因：截至 2026 年 11 月抓取，Playwright 官网首页把面向 agent 的两条路并列摆在一起，MCP 用 npx @playwright/mcp@latest，CLI 用 npm i -g @playwright/cli@latest。问题已经从“要不要装”变成“装哪一条”，先花两分钟确定路线，比装完再返工更省事。

开装之前的 3 个硬条件

1. Node.js 18 或更新。仓库 Requirements 一节原文是 Node.js 18 or newer。在终端运行 node -v，看主版本号是否 ≥ 18；如果不满足，先升级 Node 再继续。
2. 一个 MCP 客户端。官方仓库列出的可用客户端包括 VS Code、Cursor、Windsurf、Claude Desktop、Goose、Grok、Junie，以及任何支持 MCP 的客户端。先确认你手上装的是哪一个，因为后面三种接入方式就是按客户端区分。
3. 终端可以运行 npx。服务器不是下载安装包，配置里写的启动命令就是 npx，第一次会被拉取到本地缓存。

三项里最容易忽略的是第 1 条：客户端启动服务器进程时用的是它自己继承的环境，如果 Node 版本不对，后面所有配置都白费。

没有套餐这回事：价格与账号的真实答案

搜“Playwright MCP 订阅”的人，想要的通常是三件事：多少钱、免费额度多少、怎么开通。答案分别是：软件成本为 0；它没有额度这个概念；它也没有开通步骤，把配置粘进去就算通了。

仓库页上的许可证是 Apache-2.0，页面里没有价格、订阅、配额这类入口，README 也从“用你的客户端安装”直接进入配置示例。这是可核验的事实。至于“所以永远不会有额度限制”这个推论，属于我的推导，因为服务器是本地进程，计费入口在架构上就不存在。

最后一行最容易被误解。Claude Desktop、Cursor 这些客户端本身要登录，但那是客户端的账号体系，跟 Playwright MCP 无关；换句话说，你换一台新机器，只要 Node 和客户端在，配置贴过去就能跑，没有“迁移账号”这一步。

三种接入方式：按你手上的客户端选

这三种方式的差别不在功能，而在你把配置写在哪。选错的典型后果不是报错，而是客户端里什么都看不到。

方式一，标准配置，覆盖面最广。 把下面这段粘进客户端的 MCP 配置（仓库 README 开头的 Standard config，原文注明 “works in most of the tools”）：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Claude Desktop 走它的 MCP 安装向导，粘的就是上面这段；VS Code、Cursor、Windsurf 这类在 MCP 设置里找 JSON 编辑入口。

方式二，Claude Code，一条命令写入。 不用碰 JSON，仓库 Claude Code 小节的原文命令：

claude mcp add playwright npx @playwright/mcp@latest

方式三，Amp，两种写法二选一。 CLI 版：

amp mcp add playwright -- npx @playwright/mcp@latest

也可以直接改 settings.json，注意这里的键是 amp.mcpServers，不是 mcpServers：

{
  "amp.mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

装完怎么确认：3 个可观察信号

信号一：客户端的工具列表里出现 playwright。 名字来自你配置里的键，写 playwright 就该显示 playwright。这一条最直接：看不到这一项，就是配置没被读到，先回去查键名和文件位置。

信号二：让它做一次只读操作，返回的是元素结构而不是截图。 这是 MCP 的工作方式决定的，仓库原文写它用 structured accessibility snapshots（无障碍树快照：把页面元素按角色、名称、引用编号组织成文本结构）而不是像素输入，所以不需要视觉模型。如果你的客户端返回一堆“按钮、链接、输入框”的描述，说明通了。

信号三：手动跑一次启动命令，看进程能不能起来。 在终端执行 npx @playwright/mcp@latest，能正常拉起再 Ctrl+C 退出，说明包和 Node 环境没问题，剩下的都是客户端配置问题。这个命令也是排查“到底是服务器坏了还是客户端没读到”的最快分界线。

真会卡住的 4 个地方

一是 Node 版本落后。 唯一在官方 Requirements 里被明确写死的门槛就是 Node.js 18。现象是客户端里工具一直不出现。解法是先 node -v，低于 18 就升级，然后重启客户端，只重启终端不够。

二是键名照抄反了。 标准配置外层是 mcpServers，Amp 是 amp.mcpServers。把 Amp 那段粘进只认 mcpServers 的客户端，或者反过来，常见结果是客户端安安静静，一个新工具都没有（推导：这类客户端通常不会提示“你键名写错了”）。解法很简单：回到上表确认你用的是哪一行。

三是 @latest 是滚动版本。 命令里带 @latest，意味着每次拉起都可能换成新版本，参数和行为会变，昨天能跑的配置今天未必一致。要复现就钉死版本号：去 官方 Releases 页看当前版本，或在终端跑 npm view @playwright/mcp version 直接打印最新号，再把 @latest 换成具体号。

四是长会话里上下文被撑爆。 仓库自己写了：MCP 这条路要把大段 tool schema 和啰嗦的无障碍树塞进模型上下文，所以上下文消耗比命令行高。表现是越用越慢、越用越贵（推导）。如果你的 agent 要在一个会话里连续跑几十步，这条几乎一定会撞上，解法在下一节。

官方自己劝退 MCP 的场合

仓库 README 里专门有一节叫 “Playwright MCP vs Playwright CLI”，结论写得相当直白：如果你在用 coding agent，可能该用 CLI + SKILLS。 理由原文给的是 CLI 更省 token，调用时不用把庞大的工具定义和冗长的无障碍树加载进上下文，只发一条条短命令；而 SKILLS 是把一组命令行用法打包成可安装的技能，让 agent 按需调用。

反过来说，MCP 仍然有它的位置。README 说它适合需要持久状态、丰富内省、对页面结构反复迭代推理的循环，比如探索式自动化、自愈测试、长时间自治工作流；在这些场景里，连续保持浏览器上下文带来的价值超过 token 成本。

按这个口径，我给一条判断线（推导，不是官方说法）：只让 Claude Code 或 Copilot 帮你写测试、跑一次页面检查，装 CLI 就够了，一条 npm i -g @playwright/cli@latest 完事；如果你的 agent 要在同一个页面上下文里连续操作几十步、还要根据结构变化改策略，MCP 的持续会话才值回票价。迁移成本也不高，两边都是 npx 或全局包，配置互不影响。

两者的共同点值得再说一遍：都不收费、都不要账号。所以“选错了”的唯一代价是 token 和时间，不涉及任何退订流程，这也是这篇里唯一让人省心的地方。

参考来源

• Playwright 官网首页（npx @playwright/mcp@latest、npm i -g @playwright/cli@latest、客户端列表）
• Playwright MCP 官方仓库（Requirements、标准配置、Claude Code 与 Amp 命令、MCP vs CLI 章节、Apache-2.0 许可）
• Playwright MCP 官方 Releases 页（查当前版本号，替换 @latest 用；等价的命令是 npm view @playwright/mcp version）