90% 的人都用错了！Playwright vs Chrome DevTools MCP到底该怎么选？

如果你想用 AI Agent 来操作浏览器，目前基本绕不开两个最常用 MCP：一个是微软的 @playwright/mcp ，另一个是Google 的 chrome-devtools-mcp。

但你是不是也有这些困惑？🤔

• • MCP 到底是什么鬼？
• • Playwright MCP 和 Chrome DevTools MCP 到底有什么区别？
• • 我该用哪一个？还是两个都要装？
• • 为什么我的 AI 助手控制浏览器总是出问题？

如果你有以上任何一个问题，这篇文章就是为你准备的。我发现 90% 的人都在错误地使用它们——不是因为工具不好，而是因为选错了场景。今天把我踩过的坑和总结的经验分享出来，帮你少走弯路。

一、先搞懂：什么是 MCP？

MCP (Model Context Protocol) 是 Anthropic 推出的一个开放协议，让 AI 模型（如 Claude）能够安全地连接外部工具和数据源。

简单说：

传统方式：AI → 只能聊天
MCP 方式：AI → 可以操作浏览器、读写文件、调用 API...

MCP 的核心价值：

• • 🔌 标准化：统一的接口规范，一次配置到处运行
• • 🔒 安全性：权限可控，操作可审计
• • 🔄 可组合：多个 MCP 服务器可以协同工作

二、Playwright MCP 是什么？

@playwright/mcp 是微软 Playwright 团队基于 MCP 协议封装的库，将 Playwright 的跨浏览器自动化能力与 MCP 协议结合。Playwright 本身是一站式的浏览器自动化工具，而这个库是让 Playwright 能通过 MCP 协议和各类 DevTools 后端通信，同时保留 Playwright 上层的易用性封装。

简单来说，Playwright MCP 就是一套由AI 驱动的浏览器自动化引擎。

由 Microsoft 官方维护，基于成熟的 Playwright 框架，通过**结构化的无障碍树（Accessibility Tree）**而非像素截图来操作网页。

2.1 它的出现，能解决什么问题？

Playwright MCP 的解题思路是"像用户一样看页面"， 它不给 AI 看原始 HTML，而是给一棵可访问性树（Accessibility Tree）。什么 <div class="css-1a2b3c">、什么 data-analytics-id="xxx"，全部过滤掉，只留下 AI 真正需要的信息：这是个按钮，叫"提交"，可以点击。

这带来两个直接好处：一是 Token 消耗暴降，同一个页面，原始 DOM 可能吃掉 5 万到 10 万 Token，可访问性树只要 2000 到 5000，省了 70% 到 80%；

二是 AI 不容易"看花眼"，信噪比高了，推理准确率自然上去了。

另外它还有个杀手锏：Auto-wait（自动等待）。AI 发出"点击"指令后，Playwright 不是立刻就点，而是先确认元素已经加载、可见、位置稳定、没被弹窗挡住，全部满足了才执行。这个机制把"等待"的活从 AI 身上卸下来了，交给了确定性的代码逻辑。

2.2 核心特点

2.3 适用场景

• • 跨浏览器自动化测试：需要同时测试 Chrome、Firefox、Safari，且希望用统一的 MCP 协议通信；
• • Playwright 生态扩展：已有 Playwright 项目，需接入 MCP 协议与其他 DevTools 工具互通；
• • 自动化 + 调试结合：既需要自动化操控浏览器，又需要通过 MCP 协议获取调试层面的信息（如性能数据、DOM 解析日志）；
• • 通用浏览器操控：不想针对不同浏览器写不同的协议调用代码，追求 “一次编码，多端运行”。

2.4 Playwright MCP 安装配置

在AI客户端工具（比如Claude Desktop）设置中添加 MCP 服务器

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

或者

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--browser", "chrome",
        "--headless",
        "--viewport-size", "1920x720",
        "--device", "iPhone 15"
      ]
    }
  }
}

重要参数说明：

比如启动无头模式：

{
  "mcpServers": {
    "playwright-headless": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--headless",
        "--viewport-size", "1920x1080",
        "--browser", "chrome"
      ]
    }
  }
}

也可以，用来模拟移动端：

{
  "mcpServers": {
    "playwright-mobile": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--device", "iPhone 15"
      ]
    }
  }
}

2.5 Playwright MCP 使用示例

场景 1：自动化测试

用户：帮我测试 https://testfather.cn 的登录功能
     1. 打开页面
     2. 输入用户名 test@example.com
     3. 输入密码 password123
     4. 点击登录按钮
     5. 验证是否跳转到仪表盘

AI 会通过 Playwright MCP：

1. 1. 启动浏览器并导航到页面
2. 2. 通过 accessibility tree 定位输入框
3. 3. 填写表单并提交
4. 4. 检查结果

场景 2：数据抓取

打开AI客户端工具，直接输入

从某电商网站抓取前 10 个商品的信息

三、Chrome DevTools MCP 是什么？

chrome-devtools-mcp 是 Chrome 官方提供的、基于 MCP 协议的基础库，是 Chrome DevTools 生态的 “原生通信层”。它的核心作用是让外部工具能标准化地和 Chrome DevTools 后端（比如 Chrome 浏览器、Chrome for Testing、Edge 等 Chromium 内核浏览器）通信，本质是 DevTools 协议与 MCP 协议的 “翻译器”。

简单来说，Chrome DevTools MCP是Google 官方的浏览器自动化 MCP，通过 Chrome DevTools Protocol (CDP) 控制浏览器。既可以连接已有浏览器，也可以启动新浏览器。

3.1 解决什么问题？

Chrome DevTools MCP 的解题思路是"像开发者一样看页面"， 它直接封装了 Chrome DevTools Protocol，给 AI 开放的是浏览器的内部运行时状态：网络请求瀑布图、JS 调用栈、计算样式、性能轨迹，几乎就是把 Chrome 开发者工具的每个面板都映射成了 AI 可调用的工具。

信息极其丰富，但代价也明显：一次页面加载可能产生几 MB 的日志和 DOM 数据，如果不做过滤，AI 的上下文窗口直接被撑爆，忘记自己本来要干什么。

3.2 核心特点

3.3 适用场景

• • 开发 Chrome 调试工具：比如自定义 DevTools 插件、二次开发浏览器调试面板；
• • 深度浏览器调试：需要直接操作 DevTools 底层能力（如监控网络请求、调试 V8 引擎、分析性能）；
• • Chromium 专属场景：仅需适配 Chrome/Edge，且需要紧跟 Chrome 最新调试特性；
• • 底层协议研究：学习 / 扩展 MCP 协议与 DevTools 协议的映射关系。

3.4 Chrome DevTools MCP 安装配置

方法一：启动新浏览器（最简单）

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

方法二：连接到已运行的 Chrome

Step 1：启动 Chrome（带调试端口）

# Windows (PowerShell)
& "C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222

# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

# Linux
google-chrome --remote-debugging-port=9222

Step 2：配置 MCP 连接

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--browserUrl", "http://127.0.0.1:9222"]
    }
  }
}

方法三：常用配置参数

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--headless",
        "--viewport", "1280x720",
        "--isolated"
      ]
    }
  }
}

重要参数说明：

方法四：轻量模式（减少 token 消耗）

使用Chrome DevTools MCP 的 slim 模式

{
  "mcpServers": {
    "chrome-devtools-slim": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--slim"
      ]
    }
  }
}

slim 模式只暴露3个工具：

1. 1. 导航
2. 2. 执行 JavaScript
3. 3. 截图

方法五：禁用特定工具类别

{
  "mcpServers": {
    "chrome-devtools-minimal": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--categoryPerformance=false",
        "--categoryNetwork=false"
      ]
    }
  }
}

3.5 Chrome DevTools MCP 使用示例

场景 1：调试辅助

用户：帮我检查当前页面的性能问题

AI 可以：

• • 获取 Performance 数据
• • 分析 Network 请求
• • 检查 Console 错误

场景 2：操作已登录的网站

用户：帮我在 GitHub 上创建一个新仓库

因为连接的是你正在使用的 Chrome，所以：

• • ✅ 已登录状态直接可用
• • ✅ 不需要重新认证
• • ✅ 操作可见可控

四、两者如何选择？什么场景用什么？

要搞懂它们两个该如何选择，首先你得知道它们两者之间的核心区别，以及各自侧重点：

• • @playwright/mcp 封装更友好，是跨浏览器的上层封装库，无需关心底层调试端口 / 协议差异，适合自动化场景；
• • chrome-devtools-mcp 是 Chromium 专属的底层 MCP 通信库，更贴近原生，适合 Chrome 专属调试场景。

与其争论谁好谁差，不如直接看场景：

日常页面操作和 E2E 测试 → Playwright

导航、点击、填表、验证流程，这些高频操作 Playwright 做得又稳又省。Auto-wait 机制几乎杜绝了"片状测试"（同样的操作有时成功有时失败），语义选择器对前端重构免疫，不会因为 CSS 类名从 btn-primary 变成 css-3x7k9z 就挂掉。

复杂自动化脚本 → Playwright

需要跨页面、跨 iframe、处理文件上传下载的自动化流程，Playwright 的 browser_run_code 封装得更完整，写起来也更可靠。

性能排查和网络调试 → DevTools

"首页加载为什么要 5 秒？"这种问题只有 DevTools 能回答。它能录制 Performance Trace，分析主线程哪个脚本阻塞了渲染；能列出所有网络请求的 Header、Timing、状态码，精确定位是哪个 API 拖了后腿。Playwright 只能告诉你"慢了"，DevTools 能告诉你"为什么慢"。

CSS 排查和环境模拟 → DevTools

要检查某个元素的 computed style、模拟暗色模式、限速到 3G 网络看加载表现，这些都是 DevTools 的独占能力。

场景选择，简单小结一下：

• • 若只需操作 Chrome/Edge，且聚焦调试 / 底层协议 → 选 chrome-devtools-mcp；
• • 若需跨浏览器自动化，或已有 Playwright 项目 → 选 @playwright/mcp。

五、90% 的人用错了什么？

错误 1：不知道 Chrome DevTools MCP 也能启动新浏览器

❌ 误解：Chrome DevTools MCP 只能连接现有浏览器
   结果：总是手动启动 Chrome，麻烦

✅ 正确：Chrome DevTools MCP 默认就会启动新浏览器
   只在需要复用登录态时才连接现有浏览器

错误 2：场景错配

❌ 错误：用 Playwright MCP 操作需要复杂登录的网站
   结果：每次都要重新登录，浪费时间

✅ 正确：
   - 用 Chrome DevTools MCP 的 --browserUrl 连接已登录的浏览器
   - 或用 Playwright MCP 的 --extension 模式

错误 3：忽视隔离性需求

❌ 错误：用 Chrome DevTools MCP（非隔离模式）做自动化测试
   结果：测试污染了你的日常浏览器

✅ 正确：
   - Playwright MCP 默认隔离
   - Chrome DevTools MCP 加上 --isolated 参数

错误 4：不知道 Playwright MCP 有 Extension 模式

Playwright MCP 支持 Extension 模式，可以连接到你正在使用的浏览器！

{
  "args": ["@playwright/mcp@latest", "--extension"]
}

需要先安装 Playwright MCP Bridge 浏览器扩展。

错误 5：不知道 CLI + SKILLS 更高效

对于 Coding Agent，Microsoft 官方推荐使用 CLI + SKILLS 而非 MCP：

CLI 调用更 token 高效，避免加载大型工具 schema 和冗长的 accessibility tree。

# 安装 Playwright CLI
npm install -g @anthropic-ai/playwright-cli

# 在 agent 中使用 SKILL
playwright skill:navigate --url "https://example.com"

错误 6：不知道 Chrome DevTools MCP 有 slim 模式

如果只需要基础浏览器操作，使用 --slim 模式大幅减少 token 消耗：

{
  "args": ["-y", "chrome-devtools-mcp@latest", "--slim"]
}

slim 模式只有3个工具：导航、执行JS、截图。

六、进阶技巧

技巧 1：两者结合使用

场景：测试需要登录的功能

1. 用 Chrome DevTools MCP 登录并获取 cookies
2. 将 cookies 注入到 Playwright MCP
3. 用 Playwright MCP 执行隔离测试

技巧 2：使用 CDP Endpoint 共享

Playwright MCP 支持 --cdp-endpoint，可以连接到现有浏览器：

{
  "args": ["@playwright/mcp@latest", "--cdp-endpoint=http://localhost:9222"]
}

技巧 3：远程浏览器

{
  "args": [
    "@playwright/mcp@latest",
    "--cdp-endpoint=ws://remote-browser:9222",
    "--cdp-header=Authorization=Bearer token"
  ]
}

七、小结

用了这么久，我把两个工具的分工浓缩成一条很简单的规则：

Playwright 是默认选择，DevTools 是按需补充。

具体来说：

• • Playwright 负责"干活"： 页面导航、点击、填写、获取页面结构（用 browser_snapshot），所有常规交互都走 Playwright。
• • DevTools 负责"诊断"： 遇到性能问题用 performance_start_trace 录 Trace，遇到网络异常用 list_network_requests 看请求详情，遇到样式问题用 evaluate_script 查 computed style，遇到报错用 list_console_messages 看完整日志和堆栈。

95% 的场景 Playwright 就够了，剩下 5% 的疑难杂症才需要 DevTools 上场。但那 5% 的场景里，DevTools 是不可替代的。

这跟配工具箱一个道理，螺丝刀天天用，万用表不常用但没有不行。

回到最开始的问题：Playwright MCP 和 Chrome DevTools MCP 怎么选？

答案是都装上，然后分清主次。Playwright 当主力输出，稳定、省 Token、不容易出错；DevTools 当精密仪器，在需要深度诊断的时候随时待命。

选对工具，事半功倍！

Playwright 是默认选择，DevTools 是按需补充。

💡 一句话总结：测试用 Playwright，调试用 Chrome DevTools。简单、高效、不纠结！

你现在用的是哪个？还是两个都在用？欢迎留言聊聊你的实战体验。

相关链接

• • https://github.com/microsoft/playwright-mcp
• • https://github.com/ChromeDevTools/chrome-devtools-mcp
• • https://modelcontextprotocol.io/
• • https://github.com/modelcontextprotocol/servers