Playwright、大模型与 Playwright MCP：UI 自动化的新工作流

前面写 UI 自动化时，我提到过自己用 YOLOv5 训练目标检测模型，让模型在页面截图里识别按钮、输入框、弹窗等元素。这是一条偏视觉的路线：当 DOM 不可靠、页面结构拿不到、或者界面本身就是 Canvas/远程桌面时，让自动化系统先“看见”页面，再决定怎么操作。

这篇换一个角度，聊聊现在 Web UI 自动化里非常重要的工具：Playwright。更准确地说，是三层东西：

1. Playwright 本身解决“稳定控制浏览器”的问题；
2. Playwright 结合大模型，解决“生成、维护、解释测试”的问题；
3. Playwright MCP 把浏览器自动化包装成标准工具，让 AI Agent 可以通过 MCP 调用浏览器能力。

Playwright 是什么

Playwright 是 Microsoft 维护的浏览器自动化框架，主要用于端到端测试、页面自动化、截图、爬取、回归验证等场景。它支持 Chromium、Firefox、WebKit，也支持多语言生态，比如 JavaScript/TypeScript、Python、Java、.NET。

如果只看表面，Playwright 和 Selenium 都是在控制浏览器：打开页面、点击按钮、输入文本、等待结果、做断言。但 Playwright 的体验更像现代前端测试框架，很多以前要自己处理的细节，被它放进了框架能力里。

Playwright 为什么更稳

UI 自动化最怕 flaky test：本地能过，CI 失败；单跑能过，批量跑失败；今天能过，明天因为页面慢一点就挂了。

Playwright 比较核心的优势，是它把“等待”和“可操作性检查”做成了默认能力。比如点击一个元素之前，框架会检查它是否存在、是否可见、是否稳定、是否能接收事件、是否没有被遮挡。Playwright 官方文档也把 Locator 描述为 auto-waiting 和 retry-ability 的核心。

这意味着测试代码可以少写很多 sleep，也更接近用户行为：用户不会在按钮还没出现时点击按钮，自动化脚本也不应该这么做。

常见的 Playwright 能力包括：

• 使用 role、label、text、test id 等语义定位元素；
• 自动等待元素达到可操作状态；
• Web-first assertions，断言会在超时时间内自动重试；
• trace viewer，可以回放失败时的页面、动作、网络和控制台信息；
• 截图、录像、网络拦截、mock 接口；
• 多浏览器、多上下文、多用户会话；
• CI 友好，适合做稳定的回归测试。

一个简单的测试大概长这样：

import { test, expect } from '@playwright/test';

test('用户可以登录', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('账号').fill('demo');
  await page.getByLabel('密码').fill('password');
  await page.getByRole('button', { name: '登录' }).click();
  await expect(page.getByRole('heading', { name: '工作台' })).toBeVisible();
});

这里最关键的不是代码短，而是定位方式更接近用户语义。getByRole('button', { name: '登录' }) 比一串很长的 XPath 更容易读，也更不容易因为 DOM 层级变化而失效。

Playwright 的测试哲学

我理解 Playwright 的测试哲学不是“把浏览器点一遍”，而是“从用户可感知的界面出发验证业务”。

所以它鼓励我们写这样的测试：

• 找“登录按钮”，而不是找 .container > div:nth-child(3) > button；
• 断言“页面出现成功提示”，而不是只断言接口返回 200；
• 等待“元素可见且可操作”，而不是固定 sleep 3 秒；
• 失败时留下 trace、截图、录像，方便复盘。

这和我的视觉检测思路其实有相通的地方：测试越接近用户看到和理解的东西，越能抵抗技术实现细节的变化。

Playwright 结合大模型能做什么

大模型不是 Playwright 的替代品。更合理的关系是：Playwright 负责确定性执行，大模型负责理解、生成、解释和维护。

我觉得可以分成几个场景。

1. 从自然语言生成测试草稿

以前写测试，需要测试人员或开发人员手写脚本。现在可以把需求、页面说明、用户流程、验收标准给大模型，让它生成 Playwright 测试草稿。

例如：

写一个 Playwright 测试：用户进入登录页，输入账号密码，登录成功后进入工作台，并能看到用户名。

模型可以生成基本脚本，工程师再补充稳定的 test id、mock 数据、断言边界和异常场景。

这能节省初稿时间，但不应该完全不审查。测试代码和业务代码一样，需要可读、可维护、可复现。

2. 根据页面结构生成定位器

大模型很擅长根据上下文做判断。给它 HTML、accessibility tree 或 Playwright trace，它可以推荐更稳的定位器：优先 role、label、text、test id，最后才考虑 CSS/XPath。

比如它可以把一个脆弱选择器：

page.locator('#root > div > div:nth-child(2) > button')

改成更语义化的写法：

page.getByRole('button', { name: '保存' })

如果项目里有规范，也可以让模型按照规范生成：业务关键元素必须有 data-testid，普通按钮优先 role，表单项优先 label。

3. 失败诊断和自愈建议

真实项目里，UI 测试失败以后，最耗时间的是判断原因：是产品真的坏了，还是测试脚本脆了？是接口慢了，还是按钮文案改了？是 CI 环境问题，还是前端 hydration 延迟？

Playwright 的 trace、截图、录像、控制台日志已经提供了很多证据。大模型可以在这些证据上做分析：

• 这一步失败前页面处于什么状态；
• 元素没找到是因为文案变了、结构变了，还是根本没渲染；
• 应该改定位器、加断言等待，还是修业务代码；
• 给出一个候选 patch，但由人审查后合入。

这类“辅助诊断”很有价值，因为它减少的是维护成本，而不是只炫技地生成几行脚本。

4. 探索式测试

大模型还可以扮演探索式测试助手。给它一个目标，比如“测试注册流程的异常情况”，它可以驱动浏览器尝试空字段、错误邮箱、弱密码、重复提交、返回再进入等路径。

不过这类测试最好用于发现问题和补充测试思路，不要直接当成稳定回归测试。稳定回归测试仍然需要固定数据、固定环境、明确断言和可复现脚本。

大模型结合 Playwright 的风险

大模型会让 UI 自动化更灵活，但也会带来新风险。

第一是不可复现。模型每次生成的步骤可能不同，而回归测试最需要稳定。解决方法是：让模型生成测试，最终落地为固定 Playwright 脚本。

第二是误判。模型可能觉得“页面看起来没问题”，但业务状态其实错了。解决方法是：关键断言仍然要写成确定性检查，比如页面文本、接口结果、数据库状态、消息队列事件。

第三是权限和安全。让 Agent 操作真实浏览器时，要避免把生产账号、支付页面、后台管理权限直接交给模型。最好使用隔离环境、测试账号、最小权限和人工确认。

第四是上下文成本。页面快照、trace、DOM、截图都可能很大。给模型的信息越多，成本越高，也越容易噪声过多。所以要把上下文做成摘要，而不是一股脑塞进去。

Playwright MCP 是什么

MCP 是 Model Context Protocol，可以理解成一种让大模型连接外部工具和数据源的标准协议。MCP 里常见的能力包括 tools、resources、prompts：工具负责执行动作，资源负责提供上下文，提示模板负责组织工作流。

Playwright MCP 是 Microsoft 维护的 MCP Server，它把 Playwright 的浏览器自动化能力暴露给支持 MCP 的 AI 客户端。官方说明里提到，它通过 Model Context Protocol 提供浏览器自动化能力，让 LLM 可以使用结构化 accessibility snapshot 与网页交互。

更直白地说：

• 以前：人写 Playwright 脚本，脚本控制浏览器；
• 现在：AI Agent 通过 MCP 调用 Playwright 工具，工具控制浏览器，再把页面状态返回给模型。

它常见的启动方式类似：

npx @playwright/mcp@latest

在支持 MCP 的编辑器或 Agent 客户端里配置这个命令后，模型就可以拿到浏览器相关工具，比如打开页面、点击元素、输入文本、截图、读取页面结构等。

Playwright MCP 的工作方式

Playwright MCP 不只是把鼠标坐标交给模型乱点。它更强调结构化页面信息，尤其是 accessibility snapshot。模型看到的不是完整像素图，也不是无限长 DOM，而是更接近“页面上有哪些可交互元素、它们的名称和角色是什么”的结构。

这种方式有几个好处：

• 比纯截图更省上下文；
• 比 CSS/XPath 更接近用户语义；
• 更适合让模型选择下一步操作；
• 可以减少“看图猜坐标”的不稳定性；
• 和 Playwright 的 role/locator 思路一致。

这也解释了为什么 Playwright MCP 很适合和测试结合：它不是让 Agent 绕过测试框架，而是让 Agent 用测试框架的语义能力操作页面。

Playwright MCP 适合什么场景

我认为 Playwright MCP 很适合这些工作：

• 快速探索一个页面，理解主要交互路径；
• 让 Agent 根据需求试跑流程，然后生成 Playwright 测试脚本；
• 在本地开发时让 AI 帮忙复现 UI bug；
• 让 AI 读取页面状态、控制浏览器、截图，再给出诊断意见；
• 做内部工具、管理后台、低风险页面的自动化辅助；
• 和代码编辑器结合，一边改代码一边让 Agent 打开页面验证。

它不太适合这些工作：

• 无审查地操作生产后台；
• 处理支付、删除、发货等高风险动作；
• 替代所有确定性回归测试；
• 在没有测试账号和隔离环境时做自动化；
• 把大段敏感页面内容直接交给外部模型。

和我之前 YOLOv5 方法的关系

Playwright MCP 和 YOLOv5 视觉检测，其实是两种不同的“让自动化理解界面”的方式。

YOLOv5 方案看的是截图，适合没有 DOM、DOM 不可信、或者界面是图形化渲染的场景。它的优点是黑盒、跨端、接近真实视觉；缺点是需要标注数据、训练模型，并且要配合 OCR 和规则层。

Playwright MCP 看的是浏览器结构，尤其是 accessibility tree。它的优点是语义清晰、操作稳定、和 Web 测试天然贴合；缺点是主要服务于浏览器场景，对 Canvas、远程桌面、原生桌面软件这类界面不一定够用。

所以更好的组合不是二选一：

• Web 页面优先用 Playwright / Playwright MCP；
• 无结构界面或视觉强相关场景，用 YOLOv5 / OCR / 截图检测；
• 大模型负责调度、解释、生成候选脚本；
• 最终稳定回归仍然沉淀成可版本管理的测试代码。

一个比较务实的落地架构

如果我要把 Playwright、大模型和 MCP 放进一套测试平台，我会这样分层：

1. 测试执行层：Playwright 负责打开页面、操作元素、断言结果；
2. 语义定位层：优先 role、label、test id，必要时补充视觉定位；
3. Agent 工具层：Playwright MCP 暴露浏览器动作和页面快照；
4. 大模型层：生成测试、选择下一步、解释失败、提出修复建议；
5. 证据层：保存 trace、截图、录像、网络日志、控制台日志；
6. 审核层：关键脚本变更和 self-healing 建议需要人确认。

这个架构的重点是边界清楚。模型可以很聪明，但不要让它变成不可控的黑盒执行器。Playwright 提供确定性，大模型提供理解力，MCP 提供标准连接方式。

我的判断

Playwright 代表的是现代 UI 自动化的确定性基础：稳定定位、自动等待、可观测调试、跨浏览器执行。

大模型带来的不是“以后不用写测试了”，而是测试工作流会变得更像协作：人描述目标，模型生成草稿和诊断建议，Playwright 执行可复现脚本，工程师把关键路径固化下来。

Playwright MCP 则是把这件事往前推了一步：它让 AI Agent 不只是读代码，还能真实打开浏览器、观察页面、执行操作、反馈结果。对于 UI 自动化来说，这很可能会变成未来几年很常见的基础设施。

但越是强大的工具，越需要边界。我的看法是：让 Agent 帮我们探索，让 Playwright 帮我们验证，让人来决定什么才算正确。

参考资料

• Playwright Locators 文档
• Playwright Auto-waiting 文档
• Playwright Trace Viewer 文档
• Microsoft Playwright MCP GitHub 仓库
• Playwright MCP 官方说明
• Model Context Protocol 官方架构说明