微软33.3k星MCP开源：让AI直接看网页、点按钮

让 AI 操作网页，截图其实不是最稳的办法。截图能让它看见页面，但看见不等于知道哪个是按钮、哪个是输入框、哪个弹窗挡住了提交。你让它“点一下右上角”，它可能理解成另一个图标。

网页自动化更靠谱的方式，是让 AI 读页面结构。按钮、输入框、菜单、错误提示都变成可识别的元素，Agent 才能少猜一点。

截止至 6 月 4 日，微软开源的 Playwright MCP 现在 33.3k Star。它把 Playwright 的浏览器自动化能力，通过 MCP 暴露给大模型，让 Agent 可以打开网页、读取结构、点击按钮、填写表单。做网页测试、后台流程检查、表单验收的人，很值得看。

它让 AI 读的不是截图，而是网页结构

Playwright MCP 使用 accessibility snapshot（可访问性快照），把页面里的按钮、输入框、文本、状态交给模型理解。相比截图，这种方式更适合做稳定的网页操作。

这点对 Agent 很关键。一个后台页面上有十几个按钮，截图看起来差不多；结构化快照能告诉它按钮名字、所在区域、是否可点击。AI 少一层猜测，自动化就少一层翻车。

它和普通 Playwright CLI 也不完全一样。CLI 适合固定测试脚本，高频跑、可重复；MCP 更适合 Agent 边看边判断下一步，保留浏览器状态，做探索式操作。写网页、测表单、查 UI 遮挡时，这个区别挺有用。

安装方式很短，但先确认 Node 版本

Playwright MCP 要求 Node.js 18 或更高版本，并且需要支持 MCP 的客户端。通用配置大概长这样：

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

如果你用 Claude Code，可以直接添加：

claude mcp add playwright npx @playwright/mcp@latest

如果你用 Codex，可以这样加：

codex mcp add playwright npx "@playwright/mcp@latest"

第一次别急着改浏览器参数、权限和持久化配置。先让客户端能看到 Playwright 工具，再打开一个公开页面。工具越能操作真实网页，第一步越要保守。

第一次测试，别登录真实账号

最安全的测试方式，是拿公开页面或本地 demo 做低风险任务。比如让 Agent 打开一个表单页，只检查字段和按钮，不提交任何东西。

请用 Playwright MCP 打开这个本地页面。只查看页面结构，不要提交表单。列出主要按钮、输入框、错误提示位置，以及移动端可能遮挡的地方。

如果它能准确列出元素、说明下一步准备点击哪里，并且在提交前停下来问你，就算第一轮不错。接着可以让它点一个不会产生后果的按钮，比如“预览”“展开”“切换标签”。

我不建议第一次就登录真实后台。浏览器自动化一旦接上账号，风险就从“看错页面”变成“点错按钮”。这个差别很大。

它的第一个实用场景，是验收 AI 改过的页面。以前 Agent 改完代码，你只能看终端说测试通过，或者自己打开浏览器检查。接上 Playwright MCP 后，可以让它打开页面、读元素、检查交互。

第二个场景，是让它复现一个小 bug。比如“点击筛选后列表没有刷新”“移动端输入框被键盘挡住”“弹窗关闭后焦点丢失”。这些问题光读代码不一定看得出来，浏览器里跑一遍更直观。

第三个场景，是把人工检查清单交给它。比如发布前检查导航、表单、空状态、错误提示、移动端布局。它不能替代人眼审美，但能帮你先扫一遍低级问题。

和 Claude Code、Codex、Hermes 怎么配合

Claude Code、Codex、Hermes 更擅长读代码、改文件、跑命令。Playwright MCP 擅长看网页状态。把它们放在一起，比较舒服的流程是：Agent 先改页面，再用 Playwright MCP 打开页面验收。

比如你让 Codex 改一个登录页，不要只看它说“已完成”。可以继续让它打开页面，检查三个地方：桌面端是否对齐，手机端按钮有没有被遮住，错误提示有没有出现。

工具位置

更适合做什么

Claude Code / Codex / Hermes

改代码、读文件、跑测试

Playwright MCP

打开页面、看结构、点按钮、验流程

普通截图识别

看视觉大概效果，但稳定性较弱

这个组合的价值不在“让 AI 更酷”，而在验收更具体。它能把“页面应该没问题”变成“这几个按钮和表单我看过了”。

判断它有没有真正帮上忙，可以看三个信号：它说得出页面上有哪些可操作元素；它点击前会复述准备做什么；它遇到登录、支付、删除、提交这类动作时会停下来确认。如果这三点做不到，就别急着放进真实流程。

还有一种用法很适合非专业程序员：把它当“网页检查助手”。你不需要让它写复杂测试，只让它打开页面、列问题、截图前后状态，就已经能省不少人工点击。

移动端检查也很适合交给它先跑一遍。很多页面桌面端看着没问题，手机上一打开，按钮被底部栏挡住，弹窗高度超出屏幕，输入框获得焦点后布局乱跳。人工每次都查很烦，Agent 可以先扫一轮。

但视觉审美别完全交给它。它能发现“有没有”“能不能点”“有没有遮挡”，对“好不好看”“是否高级”判断并不稳定。把它当验收助手，不要当设计总监。

浏览器工具最怕权限给太顺手

我的顺序是：公开页面，本地 demo，测试账号，真实账号。只读操作，普通点击，填写表单，提交动作。每一层都先确认，再往前走。

后台管理页、支付页面、客户数据、带删除按钮的系统，都不适合第一批测试。哪怕 Agent 表现很好，也要保留人工确认。能点按钮的工具，边界一定要比普通聊天工具更硬。

适合先试的人，是做网页、运营后台、表单、落地页、自动化测试的人。如果你只是写文章、整理资料、普通问答，先收藏就行。它是网页 Agent 的手和眼，不是所有人都需要立刻装。