如果你写过端到端（E2E）测试，一定对这个场景不陌生：功能改了一个按钮的文案，昨天还是绿色的 CI 今天全线飘红，你花了一上午时间不是在开发新功能，而是在修那些"看起来没坏、其实是选择器坏了"的测试。

Playwright 1.56 带来了一个新东西——Test Agents，专门用来解决这个痛点。它内置三个 AI 助手：负责规划的 🎭 planner、负责写代码的 🎭 generator、负责修复的 🎭 healer。三者配合，能把"从零开始写测试"到"测试挂了自动修好"这条链路基本交给 AI 来做。

这篇文章会带你从零上手 Test Agents，包含环境准备、三个 agent 的具体用法、如何让它们自动串联运行，以及一些实际使用中的注意事项。

一、这三个 Agent 分别做什么

三者可以单独使用，也可以按顺序串起来，形成"从一句需求到一套能跑的测试"的完整流水线。

二、准备工作

在开始之前，确认几件事：

• Playwright 版本 ≥ 1.56
• 如果你用 VS Code，需要 VS Code v1.105 及以上版本，agent 体验才能正常工作
• 你需要一个支持 agent 模式的 AI 编码工具，比如 VS Code Copilot Chat、Claude Code 或 OpenCode
• 目前 Test Agents 只支持 JS/TS 的 Playwright Test runner，Python 版暂时还没有官方支持

三、五分钟完成初始化

1. 安装最新版 Playwright

npm install -D @playwright/test@latest
npx playwright install chromium

2. 初始化 Agent 定义

根据你用的 AI 工具，选择对应的 --loop 参数：

# VS Code（Copilot / Cursor 也适用）
npx playwright init-agents --loop=vscode

# Claude Code
npx playwright init-agents --loop=claude

# OpenCode
npx playwright init-agents --loop=opencode

执行后会自动生成：

• 三个 agent 的定义文件（提示词 + 可用工具），比如 Claude Code 下会放在 .claude/agents/ 里
• 对应的 MCP 配置文件，用来让 AI 连接到真实浏览器
• 一个空的 seed 测试文件

⚠️ 提醒：每次升级 Playwright 之后，建议重新跑一遍 init-agents，把新的工具和指令同步进来。

3. 写好 seed 测试

Seed 测试是所有 agent 工作的起点——planner 会先跑这个测试，完成登录之类的初始化，然后才开始探索你的应用。

// tests/seed.spec.ts
import { test } from '@playwright/test';

test('seed', async ({ page }) => {
  await page.goto('https://your-app.com');
  // 如果应用需要登录，把登录流程写在这里
});

四、三个 Agent 怎么用

🎭 Planner：让 AI 帮你梳理测试场景

在你的 AI 工具聊天窗口里，把 seed 测试带入上下文，然后提需求，比如：

请探索一下应用，为登录功能生成一份测试计划，
用 tests/seed.spec.ts 作为起点。

Planner 会真的打开浏览器，像一个 QA 工程师一样点来点去，把正常路径、异常输入、边界情况都摸一遍，最后在 specs/ 目录下生成一份 Markdown 文档，类似这样：

# 登录功能测试计划

## 场景 1：正确账号密码登录
1. 打开登录页
2. 输入正确的用户名和密码
3. 点击登录按钮

预期结果：
- 跳转到首页
- 页面显示欢迎语

## 场景 2：密码错误
...

这份文档人类能看懂，同时又足够精确，可以直接喂给下一步的 generator。

🎭 Generator：把计划变成能跑的代码

把上一步的 Markdown 文件带入上下文，告诉它：

请根据 specs/login.md 里的测试计划生成 Playwright 测试代码。

Generator 不是照着模板套代码，而是真的打开应用，一边走场景一边在真实 DOM 里验证选择器和断言是否成立，所以生成出来的代码相对稳，不容易是"拍脑袋"写的。输出大概长这样：

// spec: specs/login.md
// seed: tests/seed.spec.ts
import { test, expect } from '../fixtures';

test.describe('登录功能', () => {
  test('使用正确的用户名密码登录成功', async ({ page }) => {
    await page.getByRole('textbox', { name: '用户名' }).fill('testuser');
    await page.getByRole('textbox', { name: '密码' }).fill('123456');
    await page.getByRole('button', { name: '登录' }).click();

    await expect(page.getByText('欢迎回来')).toBeVisible();
  });
});

刚生成的测试有可能跑不过——这很正常，接下来交给 healer 处理。

🎭 Healer：测试挂了，它自己会修

当测试失败时，把失败的测试名交给 healer：

运行 tests/login.spec.ts，如果失败，帮我修复并验证通过。

Healer 会：

1. 重放失败的步骤，检查当时的页面、日志和网络请求
2. 判断是"测试本身写错了"还是"应用真的坏了"
3. 如果是选择器过时、等待时间不够这类"测试问题"，它会更新代码并重新跑，直到通过
4. 如果发现是应用功能真的出了问题，它不会硬修，而是把测试标记为跳过，并提示你这是个真 bug

这一点很关键：healer 不会为了让 CI 变绿而掩盖真实的产品问题。

五、让三步自动串起来，而不用你手动发三次请求

Playwright 本身没有提供一个"一键全自动"的命令，串联三个 agent 靠的是你所用编码工具（Claude Code、Copilot 等）自身的多步自主执行能力。做法是：

把三步写进同一个 prompt，让 AI 自己依次调用 planner、generator、healer，而不是你分三次手动触发：

请按顺序完成以下工作，中途不要停下来等我确认：
1. 用 planner 探索应用，为登录和结账流程生成测试计划
2. 用 generator 根据计划生成测试代码
3. 运行生成的测试，如果有失败，用 healer 自动修复直到全部通过
4. 最后把生成了哪些文件、修复了什么问题总结给我

关键是要打开"自动批准"模式。很多编码工具默认会在每次写文件、执行命令前停下来等你点确认，即使你写了一次性 prompt，它中途还是会一步步问你。想真正做到"发一次消息、跑完整个流程"，需要提前开启对应工具的自动批准/自动接受设置（比如 Claude Code 的 auto-accept edits 模式，或 VS Code Copilot agent 模式里的自动批准选项）。

如果你想要完全无人值守（比如每天定时跑一次 healer，检查有没有因为 UI 改动产生的失败），可以用编码工具的无交互 CLI 模式，把同样的 prompt 写进脚本，挂到定时任务或 CI 里执行，而不用打开聊天界面。

六、生成后的项目结构

your-project/
├── .claude/                 # agent 定义（VS Code 下是 .github/）
├── specs/                   # AI 生成的 Markdown 测试计划
│   └── login.md
├── tests/
│   ├── seed.spec.ts         # 环境初始化用的 seed 测试
│   └── login.spec.ts        # AI 生成的测试
├── playwright.config.ts
└── .mcp.json                # MCP 服务配置

这个结构很直白：specs/ 放人能看懂的计划，tests/ 放机器能跑的代码，两者一一对应，方便审查和追溯。

七、生成的测试怎么接入 CI

Agent 本身是给你在开发阶段交互使用的工具，但它们生成出来的文件就是标准的 Playwright 测试，跟平时手写的测试一样接入 CI，不需要额外配置：

# .github/workflows/playwright.yml
name: Playwright Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 18
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/

八、几个实际使用中要留心的点

• 生成代码要过一遍眼：同样的 prompt 跑两次，断言写法、变量命名可能不完全一致，别不加审查就合并。
• 不用每次 PR 都跑一遍完整循环：一次完整的 plan → generate → heal 会消耗不少 token，成本会累积。比较实际的做法是新功能上线时用 planner + generator 建立覆盖，healer 按周或按需触发，而不是每次提交都跑一遍。
• healer 修的是"测试"，不是"产品"：如果是大的界面改版，不只是换了个选择器，healer 修不了测试逻辑，这部分还是需要人工介入重写。
• 敏感信息别写进 seed 测试或计划文件里：agent 定义和生成文件本质上是会被 AI 读取和处理的文本，账号密码这类敏感信息建议走环境变量。

小结

Playwright Test Agents 把"写测试"这件重复劳动的大头交给了 AI：planner 帮你把测试场景想全，generator 把场景变成能跑的代码，healer 让测试在应用变化后还能自己活下去。它不是让你完全撒手不管——生成的代码依然需要你审查、维护，但对于团队里"需要覆盖的场景太多、人手却不够"的情况，这是一个很实际的效率工具。

如果你还没试过，不妨从一个小功能开始：写一个 seed 测试，让 planner 探索一遍，看看它给你的测试计划靠不靠谱。