Trae + Playwright + MCP：AI智能体驱动的Web自动化测试实操记录

最近我把手头一个 Web 项目的回归测试从 Selenium 迁到了 Trae + Playwright + MCP 这套组合上，最大的感受是：以前写脚本半小时、调选择器一下午的日子，现在缩短成了几句自然语言指令。Trae 负责当大脑，Playwright 通过 MCP 协议给大脑装上一双能操作真实浏览器的“手”，智能体则把这两者串成一条可自动运转的流水线。这篇文章不是概念科普，而是我在项目里完整跑通这套流程的实操记录，从 Trae 安装、Playwright 准备，到 MCP Server 配置、智能体执行任务，再到调试踩坑，全都覆盖。适合正在做 Web 自动化测试、想用 AI 减轻脚本维护负担的同学参考，哪怕你之前没用过 Playwright，跟着步骤也能把环境搭起来。

1. 先聊清楚：这套组合到底解决了什么问题

1.1 写脚本和维护用例，才是自动化测试真正的成本

做 Web 自动化测试的朋友应该都有同感：真正的成本从来不是跑测试的那几分钟，而是前期脚本编写和后期用例维护。页面元素一改，选择器失效，脚本就得重写；业务流程一变，用例结构就要跟着动。传统做法里，写一条完整的用例往往要反复打开控制台、复制 XPath、调等待时间，这些机械劳动消耗了大量时间。

AI 辅助自动化测试的出现，正好切在这个痛点上。让 AI 生成 Playwright 脚本在圈内已经不算新鲜事，但过去的做法大多是“你描述场景，AI 给一段代码，你再复制到项目里跑”。中间多了好几道手工环节，模型看不到页面实际长什么样，遇到动态元素、iframe、异步加载就很容易瞎猜。这也是很多人觉得 AI 写测试“中看不中用”的原因。

Trae + Playwright + MCP 这套组合改变的是交互模型：AI 不再是“离线”写代码，而是直接通过 MCP 协议驱动一个真实浏览器。它自己打开页面、自己看 DOM 快照、自己点按钮、自己读断言结果，再根据反馈修脚本。这等于把“人盯着页面反馈给 AI”这个环节，变成了 AI 自己闭环。智能体在这里不是噱头，而是让测试脚本从“一次性生成”走向“自我修正”的关键。

1.2 MCP 在这里扮演的桥梁角色

MCP（Model Context Protocol，模型上下文协议）解决的是 AI 应用怎么统一接入外部工具和数据源的问题。你可以把它理解成 AI 世界的 USB-C 接口：以前每个 AI 工具连外部设备都要定制一条线，现在大家按同一个协议对接就行。Anthropic 把协议开源之后，社区跟进速度非常快，微软官方也发布了 Playwright MCP Server，这也侧面说明这套思路确实踩中了需求。

在这套方案里，Trae 是 MCP 客户端，Playwright MCP Server 是服务端。Trae 里的智能体发现需要操作浏览器时，会通过 MCP 调用 Playwright 提供的工具（打开页面、点击、输入、截图、执行 JS 等），然后拿到页面结构作为上下文，再决定下一步动作。整个过程对用户来说，就是“说一句话，看它自己跑”。

为什么要专门讲这个协议层？因为理解了 MCP 的边界，你才不会把它当黑魔法用。MCP 本身不产生智能，它只是把“模型”和“工具”之间的消息规范化了。真正干活的是 Playwright，真正做决策的是模型。理解了这一点，你在配置和调试时遇到问题就不会不知所措：报错要么出在模型侧（提示词、上下文长度），要么出在 MCP 传输层（命令、路径、鉴权），要么出在浏览器侧（元素找不到、超时），排查路径清晰很多。

2. 环境准备：把 Trae、Playwright 和 MCP 一条龙装好

2.1 Trae 安装与模型环境确认

第一步是装 Trae。它目前提供 macOS 和 Windows 两个版本，到官网下载对应安装包即可。国内用户直接访问国内版下载，安装后需要登录账号才能使用 AI 能力。装完之后别急着写代码，先去设置里把模型环境确认一遍。Trae 内置了多个模型可供选择，我习惯选 Claude 系列模型做 Agent 任务，因为它在工具调用和多步推理上的表现比较稳定。模型调用消耗的是账号积分，轻度使用的话，账户免费额度基本够用；如果跑大规模任务，可以通过官方渠道购买积分，不用在这上面纠结太久。

如果你之前用 VS Code，装完 Trae 会发现界面非常熟悉。它兼容大量 VS Code 扩展，快捷键也能无缝迁移，学习成本很低。我经常碰到从 VS Code 切过来的同事，装上就能直接用，几乎没有适应期。

2.2 Node.js 与 Playwright 的落地安装

Playwright 是微软开源的浏览器自动化框架，Node.js 版本通过 npm 安装。先确认本机有 Node.js 环境，建议版本 18 以上。检查方法很直接：终端里执行node -v，如果没装，去官网下载 LTS 版本装上即可。

然后新建一个测试项目目录，执行初始化：

mkdir playwright-demo && cd playwright-demo npm init -y npm i -D @playwright/test playwright

装完之后，必须下载浏览器内核才能跑自动化。Playwright 默认支持 Chromium、Firefox、WebKit 三种，日常 Web 项目最常用的是 Chromium。执行下面这条命令，它会下载浏览器并放到本机的固定目录：

npx playwright install chromium

如果你用的是 Linux 服务器，还需要额外装系统依赖：

npx playwright install --with-deps chromium

装完可以用一段最简单的脚本验证环境是否正常：

const { chromium } = require('playwright'); (async () => { const browser = await chromium.launch({ headless: true }); const page = await browser.newPage(); await page.goto('https://example.com'); console.log(await page.title()); await browser.close(); })();

能打印出页面标题，就说明 Playwright 环境已经通了。这一步非常关键，跑通了再往上接 MCP，后面排查问题时能少一半麻烦。

2.3 浏览器内核下载失败怎么办

浏览器内核下载是国内用户大概率会遇到的一道坎。默认下载地址在国外 CDN，速度慢甚至直接失败。遇到这种情况，把下载地址切到国内镜像即可。在终端里设置环境变量：

export PLAYWRIGHT_DOWNLOAD_HOST=https://npmmirror.com/mirrors/playwright/ npx playwright install chromium

Windows PowerShell 下对应命令是：

$env:PLAYWRIGHT_DOWNLOAD_HOST="https://npmmirror.com/mirrors/playwright/" npx playwright install chromium

另外一个常见坑是 npm 本身装包慢，建议在项目里配置 npmmirror 镜像源：

npm config set registry https://registry.npmmirror.com

这两处设置完，下载速度和成功率都会明显改善。如果依然失败，检查磁盘空间和网络设置，通常都能解决。

3. 关键一步：在 Trae 里接入 Playwright MCP Server

3.1 MCP 配置的完整 JSON 与路径选择

环境装好后，接下来是让 Trae 认识 Playwright。打开 Trae，进入 MCP 管理面板（侧边栏里类似插头的图标），选择手动添加 MCP Server，类型选 stdio，然后在配置区填 Server 名称和启动命令。

核心配置代码如下：

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

这里有个非常隐蔽的坑：Windows 下直接写npx经常起不来，因为系统里实际的可执行文件是npx.cmd。遇到这种情况，把配置改成：

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

还是不行，就直接把 command 写成npx.cmd。这个细节在官方文档里写得不够明显，但现实中踩到的人非常多，我见过好几个同事卡在这一步半天。

如果你不想让浏览器弹窗干扰桌面操作，可以给 MCP Server 加参数，让它以无头模式运行：

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

我个人的建议是：初次验证连接、观察智能体动作的时候，保留有头模式，能看到浏览器自己在动，心里踏实；等流程稳定了，再切成--headless跑批量和 CI。

3.2 验证连接：从工具列表看 server 是否真的工作

配置填完，点击保存。Trae 会尝试启动 MCP Server，并自动获取它声明的工具列表。这一步建议等几秒，如果工具列表里能看到类似browser_navigate、browser_click、browser_type、browser_snapshot、browser_screenshot、browser_evaluate这些名字，说明 Server 启动成功，协议层已经通了。

如果工具列表是空的，或者状态一直显示连接失败，先别急着检查 Trae，回终端手动执行一次启动命令：

npx @playwright/mcp@latest

看它是否有报错输出。这一步能把问题定位到三分之二：是命令本身起不来，还是 Trae 与 Server 之间的通道有问题。注意，手动启动时会一直处于运行状态，这是正常的，确认没问题后按 Ctrl+C 停掉即可，Trae 会自己拉起它的实例。

这里要提一个容易被忽略的点：MCP Server 启动成功后，你在 Trae 的对话窗口里直接和模型聊天，模型并不会自动使用这些工具。智能体只有在“判断需要操作浏览器”时才会调用工具。所以验证完工具列表后，最好给它一个明确指令，比如“帮我打开一个浏览器页面访问 example.com”，看它是否真的行动。这一步走通，说明整套链路已经激活。

4. 跑通第一个智能体任务：从自然语言到浏览器操作

4.1 一个最典型的演示场景

环境都接好之后，来跑一个完整的任务。我建议 Demo 场景选一个无登录、无验证码、加载快速的网站，例如 example.com，或者你自己写一个本地 HTML 页面。为什么特意强调这一点？因为自动化测试里最容易翻车的恰恰是那些需要登录、验证码、短信的环境，第一次跑通链路时没必要把它们加进来增加变量。

我在项目里做演示时，用的是本地的一个购物车页面。任务描述是这样给的：

“打开本地页面 http://localhost:8080/cart，把商品数量改成 2，点击结算按钮，然后截图给我看最终结果。”

请注意，这句话包含了一个完整任务所需的几个要素：起始位置（打开什么页面）、动作（改数量）、事件（点击结算）、验证（截图）。给智能体的指令越接近这种结构化描述，它执行的成功率越高。

4.2 智能体执行过程的完整观察

提交任务后，可以在 Trae 的对话窗口里实时看到智能体输出的日志。它一般会经历这样几个步骤：

1. 调用browser_navigate打开页面；
2. 调用browser_snapshot获取页面的可访问性快照（不是截屏，而是 DOM 结构），AI 靠这个“看懂”页面里有哪些输入框、按钮和文本；
3. 结合快照决定下一步动作，调用browser_click或browser_type操作页面元素；
4. 再次获取快照，确认操作结果；
5. 最后调用browser_screenshot截屏，并把图片作为结果反馈给你。

整个过程看起来就像是有一个远程操作员在替你操作浏览器，但每一步都是模型根据页面快照实时决策的。这也解释了为什么动态内容、iframe、异步加载这些传统脚本最怕的场景，对智能体来说反而没那么致命——它每次都重新读快照，页面状态变了，它的下一步也会跟着变。

如果中途执行出错，比如某个按钮在快照里找不到，智能体通常会尝试换一个选择器，或者重新获取快照再操作。这是它和传统脚本最本质的区别：传统脚本是写死的线性流程，智能体是带有反馈循环的决策流程。

4.3 结果检查与后续迭代

任务跑完后，对照截图和日志检查结果。如果发现智能体点错了按钮或输入了错误的值，可以直接在对话里追加指令：“你刚才点错了，应该点购物车页面右下角的绿色按钮，重新执行一下。”它会基于新的指令，结合已有上下文纠正动作。

这一轮之后，建议把验证过的用例沉淀成可复用的脚本。也就是说，让智能体在执行过程中把实际用到的 Playwright 代码整理出来，保存到项目里，或者直接在 Trae 里要求它“把刚才的操作写成一个可重复执行的测试文件”。这样，智能体负责探索和验证，落地的脚本进版本库做回归，两边各司其职，才是这套组合比较理想的使用姿势。

5. 从能用走向好用：工作流编排与提示词技巧

5.1 让模型“逐步执行”而不是一把梭

智能体和纯聊天的另一个区别是：它会在一次任务里连续调用很多次工具，上下文会越积越长。如果你一次性把十个步骤全部塞进任务描述，模型容易在中途跑偏，而且出了问题不好定位是哪一步造成的。

我的经验是：把大任务拆成小步骤，一次只下达一个目标。跑通后再把步骤合到一起做成脚本。这不是退回到传统模式，而是给智能体留出足够的中间反馈空间。

另外，指令里尽量带上“校验点”。比如“打开页面后，先读取页面标题告诉我”“点击之后，检查页面上是否出现了‘订单提交成功’这段文字”。这些校验点让模型在关键节点停下来确认状态，比最后一次性看截图更容易发现问题。

5.2 结合 Trae 的 Chat 与 Build 模式做测试闭环

Trae 的交互模式有两类：Chat 模式偏重对话式任务，适合让智能体操作浏览器、查资料、做分析；Build 模式偏重代码工程，AI 会自动创建和修改项目文件。做自动化测试闭环时，我建议把两者串起来用。

举个例子：先用 Chat 模式让 Agent 跑一遍探索性测试，确认页面元素和流程没问题；然后切到 Build 模式，描述需求“把这个验证通过的流程封装成 Playwright 测试用例，用 Page Object 模式，放到 tests 目录下”，让它生成工程化代码并直接写入文件。测试框架搭好之后，后续新功能的冒烟测试、回归测试都能在此基础上增量扩展。

这套流程跑顺之后，可以再配合 Trae CLI 做批处理，在终端和 IDE 之间衔接任务，适合需要脚本化触发测试或定时回归的场景。它的价值在于把 IDE 里的能力延伸到命令行，让自动化测试的触发方式更灵活。

5.3 通过 MCP 扩展自己的测试工具

Playwright MCP Server 的工具集虽然已经很能打，但真实项目的断言往往需要业务定制。好消息是 MCP 是开放的，你完全可以把自定义工具注册成一个额外的 MCP Server，然后让 Trae 同时连接多个 Server。

比如，你可以在本地写一个非常简单的 MCP Server，暴露一个check_inventory工具，负责读取测试环境的库存接口并判断商品余量。智能体在跑下单用例前，可以主动调用这个工具判断前置条件，再进行页面操作。这样，AI 测试的覆盖面就不只停留在 UI 层面，还能和接口、数据库、测试数据准备打通。

对于不熟悉 MCP SDK 的团队，也可以先在 Playwright MCP Server 支持的浏览器工具范围内，通过browser_evaluate执行自定义 JavaScript 来模拟部分业务断言，成本低、见效快。

6. 实操中的高频问题与我的处理经验

6.1 npx 相关报错

• npx: command not found：通常是 Node.js 没装或没进 PATH，重新安装 Node LTS 即可。
• 在 Windows 下 Server 启动失败：优先把 command 改为cmd、args 改["/c", "npx", "@playwright/mcp@latest"]，或者 command 直接写npx.cmd。
• 启动非常慢：MCP Server 首次启动要加载依赖，耐心等一会儿；如果每次都超过几十秒，考虑在全局或项目内预先安装@playwright/mcp，减少实时解析依赖的时间。

6.2 浏览器权限与选择器不稳定

Playwright 默认在无头模式下没有图形界面权限，移动端设备和多显示器环境下偶尔会启动异常。遇到浏览器起不来，先看错误信息里是否提到Missing X server或 GPU 相关字样，在启动参数里加--headless或者装好系统依赖即可。

选择器不稳定是自动化测试的老大难。智能体读的是可访问性快照，对这类问题的适应能力比传统脚本强，但也不是万能的。复数同类型按钮、隐藏元素、重叠浮层，都会让快照出现歧义。我的做法是在出现歧义的节点，让智能体优先使用getByRole、getByLabel这类语义选择器，而不是一上来就抓 CSS 选择器；如果项目里元素实在不规范，优先给测试环境补充稳定的>