让 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 的手和眼,不是所有人都需要立刻装。

打开网易新闻 查看精彩图片