Playwright和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 看不懂网页截图 使用结构化的 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 身上卸下来了，交给了确定性的代码逻辑。