如果你想用 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 看不懂网页截图	使用结构化的 accessibility tree，不需要视觉模型，不是像素识别，纯结构化数据操作
自动化脚本容易挂	基于语义定位，比 CSS/XPath 更稳定
不同浏览器行为不一	跨浏览器支持 - Chrome、Firefox、WebKit、Edge 全支持
Token 消耗太大	只传结构化数据，不传图片

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 核心特点

特点	具体说明
跨浏览器兼容	基于 Playwright 底层，支持 Chromium、Firefox、WebKit（Safari），突破 Chromium 限制
上层封装友好	不是裸协议调用，而是结合 Playwright 的 API 风格（异步 /await、链式调用），新手易上手
自动化优先	设计初衷是服务自动化测试、爬虫、浏览器操控场景，而非纯调试
生态整合性	可无缝对接 Playwright 的其他能力（如录制脚本、截图、视频录制、网络拦截）
版本稳定	Playwright 会做浏览器版本兼容适配，无需手动处理不同浏览器的协议差异

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"
      ]
    }
  }
}

重要参数说明：

参数	说明
--browser	浏览器类型：chrome, firefox, webkit, msedge
--headless	无头模式（不显示浏览器窗口）
--device	设备模拟，如 "iPhone 15"（注意有空格）
--viewport-size	视口大小，如 "1920x720"（格式：宽x高）
--caps	额外能力：vision, pdf, devtools
--cdp-endpoint	连接到远程 CDP 端点
--extension	连接到运行中的浏览器（需要安装扩展）
--isolated	内存模式，不保存浏览器配置到磁盘
--save-trace	保存 Playwright Trace 用于调试
--snapshot-mode	快照模式：incremental, full, none
--console-level	控制台日志级别：error, warning, info, debug

比如启动无头模式：

{
  "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. 启动浏览器并导航到页面
2. 通过 accessibility tree 定位输入框
3. 填写表单并提交
4. 检查结果

场景 2：数据抓取

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

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

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 的解法
想操作当前浏览器	通过 --browserUrl 或 --autoConnect 连接
登录状态要保留	复用现有 session，不用重复登录
调试开发中的页面	实时获取 DevTools 信息
想看网络请求	内置 Network 工具类别
性能分析	内置 Performance 工具类别
需要简化操作	--slim 模式只暴露3个基础工具

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

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

3.2 核心特点

特点	具体说明
原生适配	由 Chrome 团队维护，完全对齐 Chrome DevTools 协议的最新特性，无兼容层损耗
底层通用	只负责通信协议转换，不封装上层业务逻辑，是 “基础积木” 而非 “成品工具”
仅限 Chromium	仅支持 Chromium 内核浏览器（Chrome、Edge、Opera 等），不支持 Firefox/Safari
调试优先	设计初衷是服务 DevTools 调试场景，而非自动化测试

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"
      ]
    }
  }
}

重要参数说明：

参数	说明
--browserUrl	连接到已运行的 Chrome（如 http://127.0.0.1:9222）
--wsEndpoint	通过 WebSocket 连接（如 ws://127.0.0.1:9222/devtools/browser/<id>）
--autoConnect	自动连接到本地运行的 Chrome 144+
--headless	无头模式（不显示浏览器窗口）
--viewport	视口大小，如 1280x720
--channel	Chrome 渠道：stable, beta, canary, dev
--isolated	使用临时用户数据目录，退出后自动清理
--slim	轻量模式，只保留3个基础工具
--categoryNetwork	设为 false 禁用网络相关工具
--categoryPerformance	设为 false 禁用性能相关工具
--categoryEmulation	设为 false 禁用模拟相关工具
--acceptInsecureCerts	忽略自签名证书错误（谨慎使用）

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

使用Chrome DevTools MCP 的 slim 模式

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

slim 模式只暴露3个工具：

1. 导航
2. 执行 JavaScript
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 专属调试场景。

维度	chrome-devtools-mcp	@playwright/mcp
维护方	Chrome 官方团队	微软 Playwright 团队
核心定位	DevTools 原生 MCP 通信层（底层）	Playwright 封装的 MCP 适配层（上层）
浏览器支持	仅 Chromium 内核	Chromium、Firefox、WebKit
主要用途	调试、底层协议操作	自动化测试、跨浏览器操控
易用性	低（裸协议调用，需手动处理细节）	高（Playwright 风格封装，API 友好）
生态整合	仅对接 Chrome DevTools 生态	无缝对接 Playwright 全能力

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

日常页面操作和 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。简单、高效、不纠结！

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

相关链接

• Playwright MCP GitHub
• Playwright CLI + SKILLS
• Chrome DevTools MCP GitHub
• MCP 官方文档
• MCP Servers 仓库