以前聊 Playwright，重点多半落在“怎么点按钮、怎么找元素、怎么稳定跑 CI”。到了 Agent 这一步，问题其实变了：不是让 AI 多会操作浏览器，而是让它别把测试写成一锅粥。
Playwright Test Agents 有意思的地方就在这儿。它没有把“写测试”塞给一个万能 Agent，而是拆成三个角色：Planner 先把测试计划写出来，Generator 再生成代码，Healer 最后处理失败测试。中间产物是 Markdown 计划和 Playwright spec 文件，人能看、能改、能追责。
适合场景：给已有 Web 项目补 E2E 覆盖、把 PRD 转测试场景、批量修复因 UI 变动挂掉的测试。
它不是又一个 MCP
Playwright MCP 给 Agent 一双“眼睛”：把页面结构、可访问性树、操作结果喂给编码工具，让它在对话里帮你一步步写测试。
Playwright CLI 更像一套“命令手”：导航、点击、填表、截图都能被脚本化调用，适合放进更大的自动化流程里。
Test Agents 往前走了一步。它不是工具，而是一条面向测试的流水线：
- Planner：探索应用，输出人能读懂的测试计划。
- Generator：把测试计划变成可执行的 Playwright Test。
- Healer：测试失败后回放现场，尝试修复选择器、等待、断言或测试数据。
这三个角色可以单独用，也可以顺序接力。关键不是“AI 自动点网页”，而是把测试建设从“开发者手写脚本”改成“开发者审核计划和 diff”。这就靠谱多了，不然 Agent 一顿猛写，最后没人知道它测了啥、没测啥。
先把 Agent 定义放进项目
在已有 Playwright 项目里，先执行：
npx playwright init-agents如果你在 Claude Code、VS Code 或 OpenCode 里跑，可以按官方文档选择对应 loop，例如：
npx playwright init-agents --loop=claude这一步会把 Playwright 提供的 Agent 定义写进项目。它们本质上是“给编码 Agent 看的操作手册”：有哪些 MCP 工具、每个阶段该读什么文件、产物应该放哪儿、失败后怎么处理。
有个细节别忽略：Playwright 升级以后，最好重新跑一次 `init-agents`。Agent 定义不是魔法，它跟着 Playwright 工具和指令变化走；版本升了，说明书也要同步。
Seed 文件决定上限
Test Agents 工作流里最容易被低估的是 `seed.spec.ts`。它不是为了断言某个业务功能，而是为了告诉 Agent：这个项目怎么进门。
比如登录、创建测试账号、加载 fixture、切换租户、进入目标页面，这些最好写进 seed。Planner 会先跑 seed，让环境进入一个可探索状态；Generator 也会把 seed 当成测试风格样本，沿用你的 fixture、封装和断言习惯。
一个简化版 seed 可以像这样：
import { test, expect } from './fixtures';
test('seed', async ({ page }) => {
await page.goto('/login');
await page.getByLabel('Email').fill(process.env.E2E_USER!);
await page.getByLabel('Password').fill(process.env.E2E_PASSWORD!);
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page.getByRole('navigation')).toBeVisible();
});这里不一定要测完整业务，但要把“进系统”这件事做稳。没有 seed，Planner 很容易卡在登录页、权限页、引导页，然后生成一堆看起来像测试、实际跑不起来的东西。
一个更稳的实战流程
别一上来就说“帮我给整个系统生成测试”。Agent 最怕目标太大，最后变成一堆泛泛的点击流。
更稳的做法是按模块走：
1. 准备 seed.spec.ts，让环境能进入目标模块。
2. 让 Planner 为“购物车结算流程”生成测试计划。
3. 人先审 specs/checkout-flow.md，补边界条件和异常路径。
4. 让 Generator 基于这份计划生成 tests/checkout-flow.spec.ts。
5. 本地跑测试，失败的交给 Healer 修。
6. 人审最终 diff，再合并到仓库。Planner 的产物应该先看一眼。它可能漏掉优惠券、库存不足、地址为空、支付失败这些边界；也可能把“看起来能点通”误认为“真正应该覆盖”。这一步人不需要写代码，但需要像测试负责人一样判断覆盖面。
Generator 会把 Markdown 计划翻译成 `.spec.ts`，并在生成过程中验证选择器和断言。它比纯文本生成代码靠谱，因为会真的面对浏览器。但“能跑”不等于“测试质量好”。断言是不是太浅？有没有只检查 toast，不检查数据库状态？测试之间会不会互相污染？这些仍然要看。
Healer 适合处理前端小改动带来的失败，比如按钮文案变了、DOM 层级调整、等待条件不稳定。它不适合处理需求变化。产品逻辑改了，接口 schema 改了，旧测试本来就应该失败，这时候让 Healer 硬修，容易把 bug 修成“测试沉默”。
别把自愈直接接到主分支
测试自愈听着爽，但生产里要收着点用。比较安全的落地方式是：
- Healer 只能在临时分支或 PR 里提交修复，不能直接推主分支。
- 修复 PR 必须带上失败原因、修改文件、重新运行结果和 trace 链接。
- 如果 Healer 选择 skip，必须把 skip 原因写进 issue，不能当成通过。
- 对核心链路设置更严格规则：登录、支付、权限、数据删除这类测试不能自动降级。
- CI 里保留 trace、video、screenshot，方便人复查 Agent 到底看到了什么。
这套规则有点啰嗦，但很必要。测试是质量闸门，不是为了让红灯变绿。Agent 可以修脚本，但不应该替团队决定“这个失败不重要”。
和传统测试工程怎么配合
比较现实的分工是：
- 人负责测试策略、核心路径、边界条件、断言标准。
- Planner 负责把目标模块拆成可执行场景。
- Generator 负责把计划落成 Playwright 代码。
- Healer 负责处理因 UI 小变动导致的测试维护成本。
这样用，Test Agents 不是“替代测试工程师”，更像把重复劳动往后推了一层。以前你花半天搭第一版 E2E，现在可能先花半小时审计划，再把生成和修复交给 Agent。省下来的不是脑子，是那些反复找 selector、补 wait、看 trace 的体力活。
什么时候该用，什么时候别上头
适合用 Test Agents 的场景很明确：项目已经有基本 Playwright 配置；你要补某个模块的 E2E 覆盖；需求相对清楚；团队愿意审测试计划和代码 diff。
不适合的场景也很明确：页面还在天天改；需求没有定；系统登录和测试数据都没理顺；团队只是想“一键生成全部测试”。这种时候 Agent 只会把混乱放大。
Playwright Test Agents 真正带来的变化，不是“AI 帮我写了几个测试”，而是把 E2E 测试变成一条可审计的 Agent 流程：先计划，再生成，再修复，最后由人判断能不能进仓库。这个顺序对了，测试自动化才有机会从苦力活变成工程资产。