文章目录Playwright MCP让 AI 直接操作浏览器的工具工作原理支持哪些客户端实际能做什么和 Playwright CLI 的区别使用门槛我的看法Playwright MCP让 AI 直接操作浏览器的工具微软最近开源了 Playwright MCP 项目Star 数已经到了 3.4 万。这个项目做的事情很明确给 AI 提供一套标准化的浏览器操作接口。做 AI 应用开发的人应该都有这个体会想让 AI 帮你操作网页要么写一堆 Selenium 脚本要么用截图让视觉模型去识别页面元素。前者代码量大后者识别准确率不稳定。Playwright MCP 走了第三条路。工作原理Playwright MCP 的核心思路是用**可访问性树Accessibility Tree**来描述网页结构而不是截图。可访问性树是浏览器内部用来辅助无障碍功能的数据结构每个页面元素在树里都有明确的角色、名称和状态。AI 拿到这棵树之后就能像人类一样理解这是一个按钮“那是一个输入框”然后直接调用对应的 Playwright API 去操作。这套方案有几个好处速度快。生成结构化数据比截图渲染快得多。不依赖视觉模型。普通的语言模型就能用不需要专门的多模态能力。确定性高。同样的页面结构每次生成的描述基本一致不像截图识别那样容易出错。支持哪些客户端这个工具遵循 MCPModel Context Protocol协议理论上所有支持 MCP 的客户端都能用。官方列出的包括VS Code、Cursor、WindsurfClaude Desktop、Claude CodeGoose、Junie、CopilotLM Studio、Gemini CLI、Codex基本覆盖了目前主流的 AI 编程工具。配置方式也简单JSON 里加一段 MCP 服务器配置就行或者直接用 CLI 命令一行搞定。实际能做什么从配置选项来看这个工具的功能比想象中丰富基础操作点击按钮、填写表单、导航页面、读取文本内容这些都在可访问性树的描述范围内完成。浏览器控制支持无头模式和有头模式切换可以指定 Chrome、Firefox、WebKit 等不同浏览器还能模拟手机设备。会话管理支持持久化配置文件和隔离模式。持久化模式下登录状态会保留下次启动还在隔离模式每次都是干净环境适合测试场景。高级功能支持通过 CDPChrome DevTools Protocol连接已运行的浏览器实例支持代理配置支持自定义初始化脚本。这些功能组合起来能覆盖的场景很多自动化测试、网页数据采集、AI 辅助的表单填写、跨页面的信息整合都可以做。和 Playwright CLI 的区别官方文档里专门解释了 MCP 和 CLI 的区别这个值得说一下。CLI 方式是给编码代理Coding Agent用的通过命令行直接调用 Playwright 的能力token 消耗更低适合需要在代码编写和浏览器操作之间频繁切换的场景。MCP 方式更适合需要持续维护浏览器状态的场景比如探索性的自动化任务、自愈测试、长时间运行的自主工作流。浏览器上下文一直保持AI 可以反复查看和操作同一个页面。选择哪种方式取决于你的具体需求。如果是写代码时偶尔需要浏览器辅助CLI 更轻量如果是构建一个需要持续与网页交互的 AI 工作流MCP 更合适。使用门槛Node.js 18 以上就能跑。安装方式就是标准的 npm 包一行命令npx playwright/mcplatest然后在你的 AI 客户端里配置 MCP 服务器地址就行。整个过程不需要额外注册账号不需要申请 API Key本地直接运行。我的看法这个项目解决的是 AI 和真实世界交互的一个基础问题。之前大家做 AI 浏览器操作要么写大量自动化脚本要么上视觉模型两种方案都有明显的短板。Playwright MCP 用可访问性树这个中间层把问题简化了。微软在浏览器自动化这块的积累本来就深Playwright 本身已经是事实标准了。现在把它和 MCP 协议打通等于是给整个 AI 工具生态提供了一个统一的浏览器操作层。如果你在做 AI Agent 相关的开发这个工具值得试试。特别是需要让 AI 处理网页表单、读取网页内容、或者做跨站信息整合的场景它能省掉不少工作量。在做 AI Agent 相关的开发这个工具值得试试。特别是需要让 AI 处理网页表单、读取网页内容、或者做跨站信息整合的场景它能省掉不少工作量。