一、核心测试代理（内置）

Playwright 内置三款开箱即用的智能测试代理：planner、generator、healer，三种使用模式：独立调用、串行执行、代理循环链式调用；串行运行可完整产出产品测试覆盖用例。

• 🎭planner（测试规划器）- 生成 Markdown 测试方案
• 🎭generator（代码生成器）- 转换测试方案为 Playwright 测试代码
• 🎭healer（自动修复器）- 修复执行失败的测试用例

传送门

Agents | Playwright

二、初始化 Codex 对应的代理配置

这里我拿codex 举例测试

1. 执行初始化命令

npx playwright init-agents --loop=codex

执行完上面的命令，在输入框，输入@可以看到智能体这里，可以调用Planner,Generator,Healer

2. 项目结构

pj/ ├── .codex/ # Codex 专属 Agent 指令、MCP工具配置 ├── specs/ # Planner 产出的Markdown测试计划 ├── tests/ │ ├── seed.spec.ts # 环境初始化种子用例

3. 添加被测试项目的地址

这里我添加了一个测试项目的地址；

三，调用 Planner，产出测试计划（md 文件）

提示词

@playwright_test_planner 基于 seed.spec.ts， 生成用户注册登录的全流程测试计划，输出到 specs/user_login.md

这里打多了个路径，ai也是识别到了(⊙o⊙)…

可以看到这里ai已经输出了测试计划。需要人工审查一遍场景，有缺失场景可以让ai继续补充。

四，调用 Generator，生成可执行测试代码

提示词

@playwright_test_generator 根据 specs/user_login.md 生成 Playwright 自动化测试代码，输出到 tests 目录

可以让ai指定一个目录存放生成的testcase；

让codex帮忙执行下测试用例

1.验证测试用例

1. 单条用例执行

# 单条用例执行 npx playwright test tests/admin-login.spec.ts

PS G:\Traepj\pyrgt> npx playwright test tests/admin-login.spec.ts Running 2 tests using 1 worker ✓ 1 tests\admin-login.spec.ts:4:7 › 管理员登录 › 管理员登录入口可访问 (5.6s) ✓ 2 tests\admin-login.spec.ts:16:7 › 管理员登录 › 普通用户无法访问管理功能 (7.2s) 2 passed (15.2s)

• 输出绿色Passed=真实执行成功，浏览器完整跑完所有步骤、全部断言通过；
• 输出红色Failed= 确实失败

2. UI 可视化模式：肉眼直观确认页面操作

npx playwright test tests/xxx.spec.ts --ui

这里可以看到第二个步骤有点不稳定执行失败了，后面我们在使用Healer的时候，拿这个步骤利用Healer自动修复这个错误；

3. 录制 Trace 追踪，完整回放全流程（留证溯源）

npx playwright test tests/admin-login.spec.ts --trace on

npx playwright test tests/admin-login.spec.ts --trace on Running 2 tests using 1 worker ✓ 1 tests\admin-login.spec.ts:4:7 › 管理员登录 › 管理员登录入口可访问 (6.3s) ✓ 2 tests\admin-login.spec.ts:16:7 › 管理员登录 › 普通用户无法访问管理功能 (9.6s) 2 passed (19.3s)

回放方式：
方式一：本地命令直接打开查看器 npx playwright show-trace xxx.zip
方式二：网页在线打开 https://trace.playwright.dev 拖拽 zip

五，调用 Healer 自动修复

接着上面UI可视化模式testcase执行失败的步骤，接下来我们调用 Healer修复一下，这个步骤；

提示词

@playwright_test_healer 自动修复 tests/admin-login.spec.ts 执行失败问题，# Instructions - Following Playwright test failed. - Explain why, be concise, respect Playwright best practices. - Provide a snippet of code with the fix, if possible. # Test info - Name: admin-login.spec.ts >> 管理员登录 >> 普通用户无法访问管理功能 - Location: tests\admin-login.spec.ts:16:7 # Error details Test timeout of 30000ms exceeded. Error: page.goto: Test timeout of 30000ms exceeded. Call log: - navigating to "http://127.0.0.1:8000/admin_login/", waiting until "load"

调用完healer修复case后，ai也全跑了一遍testcase。

再次执行case也是通过了，多试了几次，也是执行成功了，经过Healer的修复，可以提高case执行的稳定性

六，需要注意点

1. 需要对比 specs 测试计划与生成代码（排查 AI 偷减步骤）

Planner 产出的specs/xxx.md是标准完整业务流程，拿它和 Generator 生成的.spec.ts对比：
虚假成功高频原因：AI 简化、删减核心逻辑

1. 删掉关键业务步骤（比如只登录，跳过下单、支付核心流程）；
2. 弱化断言：把校验文案 / 数量 / 接口数据的强断言，简化成仅判断元素可见；
3. 跳过异常分支、二次校验逻辑。

只要代码缺失 md 里定义的步骤，哪怕跑通也属于无效假成功。

2. 需要区分使用 Codex 原生修复 / Healer 代理修复 判断标准

先理清核心本质：

• Codex：通用代码 AI，仅靠「代码 + 终端报错文本」推理修改，不会启动浏览器、不会访问真实页面、不会自动重跑测试；
• Healer：Playwright 专用测试自愈代理，内置浏览器执行能力，能实时读取当前页面 DOM、自动重放步骤、循环验证修复结果，还能区分是测试脚本问题还是前端页面本身 BUG。

1. 是否需要读取真实运行中的页面 DOM
   • 不需要页面：只用 Codex
   • 需要现场扫描页面元素、动态组件：必须 Healer
2. 是否需要自动重复运行测试验证修复效果
   • 手动执行一次即可：Codex
   • 多次自动重试、动态调整定位 / 等待：Healer
3. 是否需要自动区分「脚本错误」和「产品功能 BUG」
   • 只改代码，不用管页面是否正常：Codex
   • 页面本身失效时自动跳过用例：Healer

七，api成本

我使用的codex+deepseek，在高峰期内，整体使用的模型是deepseek-v4-flash

¥2.62 ≈ 差不多一个茶叶蛋的价格，换来了 34 个测试用例，还顺手发现了一个应用 bug。成本还算可以控制；；