微软把浏览器交给 Claude：Playwright MCP 的官方解法

你以为 AI 自动操作浏览器还停留在「截图 + 看图说话」的阶段？Microsoft 官方上个月把 Playwright MCP 推到了 37.7k star，思路彻底变了——它不是让模型「看」网页，而是让模型直接读浏览器的 accessibility tree，把 DOM 当作结构化数据来操作。

对开发者来说，这个差异决定了一件事：你终于可以把浏览器自动化放进长链路 agent 里，而不用担心每点一下页面就烧掉几千 token 截图。

为什么这个 MCP server 值得装

过去一年我看过一堆「AI 操作浏览器」的方案，普遍有三个老毛病：靠截图（贵、要视觉模型）、靠 DOM 解析但容易飘、依赖某个闭源云。Playwright MCP 一次性把这三条都砍了：

• 官方血统 + 开源：微软出品、37.7k star、MIT 协议，最近一次提交就在这两天。
• 不要视觉模型：用 Playwright 的 accessibility snapshot（一种面向无障碍场景的 DOM 投影），结构化、确定性强。
• 一次配置，到处跑：VS Code、Cursor、Claude Desktop、Windsurf、Goose、Grok、Junie 全部支持，写一次 mcpServers 配置就能复用到所有工具。

它和 CLI+SKILLs 怎么选

这次最值得开发者看的是 README 里微软自己画的那张图——Playwright 团队同时维护了一个 CLI + SKILLs 版本（microsoft/playwright-cli），明确告诉你什么场景适合 MCP、什么场景适合 SKILL:

• CLI + SKILLs：每次操作只下发一个简洁的指令，不会把无障碍树整个塞进上下文。token 友好，适合「编码 agent 顺便点两下浏览器」这种高频低复杂度场景。
• MCP server（这个 repo）：保留持久状态、能做反思式推理，适合探索式自动化、自愈测试、长时间自主工作流——也就是你希望 agent 在一个浏览器里「逛一会儿、想一会儿、再点」的场景。

换句话说，微软用一份 README 把「为什么需要 MCP、为什么也需要 CLI」讲透了——这是它和社区项目最大的区别。

5 分钟接入 Claude Code

门槛低到有点侮辱智商：

1. Node.js 18+
2. 在你的 MCP 客户端里塞这一段 JSON：
   { "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }
3. 重启客户端，直接跟 Claude 说「打开 example.com 点登录按钮」即可。

没有 API key、没有 OAuth、没有云服务依赖——浏览器跑在你本机，模型只拿到结构化数据。

我看到的真实使用场景

• 回归测试：让 Claude 跑一遍你刚改过的关键页面，自动截图+核对关键文案。
• 爬虫式数据采集：把动态渲染的列表页直接喂给 agent 抽字段。
• 前端 bug 复现：CI 里跑一次无障碍树比对，比像素 diff 更稳。
• 跨工具能力共享：同一份 mcpServers 配置，VS Code 和 Claude Desktop 共用一套。

对于「我想让 AI 真的能碰浏览器」这件事，Playwright MCP 是目前最干净的官方解。它解决的问题和「AI 写代码」一样朴素，但影响面大得多。

如果你已经在用 Claude Code、Cursor 或者 VS Code 的 MCP，今晚就能装上。

GitHub：https://github.com/microsoft/playwright-mcp

GitHub: https://github.com/microsoft/playwright-mcp