Codex 搭配 Playwright Test Agents：planner 与 generator 的配置与验证

1. 从零跑通 Codex 搭配 Playwright Test Agents 的 planner 与 generator 工作流Playwright Test Agents 是 Playwright 官方内置的一套智能测试代理包含 planner、generator、healer 三个角色分别负责测试规划、代码生成和失败自愈。Codex 作为通用编码代理可以通过init-agents命令把这三个代理注册进自己的指令体系让它在本地自动化测试场景里直接调用。这套组合适合谁适合已经在用 Playwright 写端到端测试、但被手写用例慢、断言容易漏、失败定位烦三件事拖住节奏的前端或测试同学。我这次实测的目标很明确让 Codex 调用 planner 产出一份 Markdown 测试计划再让 generator 把计划落地成可执行的.spec.ts最后用npx playwright test验证整条链路真的跑通而不是停在看起来生成了代码这一步。很多人第一次接触会误以为这是AI 帮你写测试这么简单其实它的价值在于把测试设计planner和测试实现generator拆成两个可审查的环节。planner 输出的是人话写的业务场景你能逐条核对有没有漏掉登录失败、权限越权、二次校验这些分支generator 才把它翻译成 Playwright 代码。中间这道人工审查恰恰是防止AI 偷减步骤导致假成功的关键闸门。下面我按初始化、配置、生成、验证、排障的顺序把每一步的命令和踩坑点都摊开讲。2. Codex 接入 Playwright Test Agents 的前置准备与初始化命令在动 Codex 之前先把 Playwright 环境本身跑起来。你需要 Node.js 18 以上、一个能访问的本地或测试环境地址以及一个已经npm init过的项目目录。我这次用的项目结构长这样后面所有路径都基于它pj/ ├── .codex/ # Codex 专属 Agent 指令、MCP 工具配置 ├── specs/ # Planner 产出的 Markdown 测试计划 ├── tests/ │ └── seed.spec.ts # 环境初始化种子用例 ├── playwright.config.ts └── package.json第一步是安装 Playwright 本体和浏览器依赖。如果你项目里还没有执行npm init playwrightlatest这一步会问你用 TypeScript 还是 JavaScript、测试目录叫什么、要不要装 GitHub Actions。测试目录我填的tests语言选 TypeScript。装完之后确认playwright.config.ts里的baseURL指向你要测的应用地址比如http://127.0.0.1:8000。这个 baseURL 很关键后面 generator 生成的page.goto(/admin_login/)会基于它拼接写错了就是一片超时。接着是核心的初始化命令它会把 planner、generator、healer 三个代理的指令文件写进.codex/目录npx playwright init-agents --loopcodex执行完你会看到.codex/下多出代理定义文件。这时候在 Codex 的输入框里敲就能看到playwright_test_planner、playwright_test_generator、playwright_test_healer三个可调用的智能体。如果列表里没有它们八成是命令没在项目根目录执行或者 Codex 没重新加载工作区重启一下 Codex 会话即可。关于模型接入这块Codex 本身需要一个可用的模型后端。我这次用的是 TaoToken 提供的 API 通道它的 Base URL 是https://taotoken.net/api兼容 OpenAI 风格的请求格式Key 在控制台的 API Keys 页面生成。如果你也想让 Codex 走这条通道可以在 Codex 的配置里指定 Base URL、Key 和 Model ID 三件套具体配置片段下一节给。需要说明的是TaoToken 在这里的角色是模型请求的接入层Playwright Test Agents 的代理逻辑仍然跑在本地两者不冲突。种子用例tests/seed.spec.ts建议先手写一个最简单的比如打开首页断言标题存在。它的作用是给 planner 一个环境能跑通的基准planner 会参考它来理解你的项目怎么启动、怎么定位元素。没有种子用例也能生成计划但质量会差一截。3. 可复制的 Codex 与 Playwright 配置片段含 Base URL、Key、Model ID这一节给你能直接抄的配置。先说 Codex 侧的模型接入。Codex 支持通过配置文件指定模型提供方我把它写成 TOML 片段路径放在用户目录下的.codex/config.tomlWindows 是C:\Users\你的用户名\.codex\config.tomlmodel deepseek-v4-flash model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat这里三个关键字段对齐一下Base URL 填https://taotoken.net/apiKey 通过环境变量TAOTOKEN_API_KEY注入不要把 Key 硬编码进文件Model ID 填你在控制台看到的模型名比如deepseek-v4-flash。设置环境变量的方式Windows PowerShell 用$env:TAOTOKEN_API_KEY你的KeymacOS 或 Linux 用export TAOTOKEN_API_KEY你的Key如果你更习惯用auth.json的方式管理凭据Codex 也支持在~/.codex/auth.json里写{ OPENAI_API_KEY: 你的Key, OPENAI_BASE_URL: https://taotoken.net/api }注意auth.json和config.toml二选一即可同时配可能互相覆盖。我实测下来用config.toml 环境变量更清晰换 Key 不用改文件。再说 Playwright 侧。playwright.config.ts里至少要保证baseURL、testDir、use三块对得上import { defineConfig, devices } from playwright/test; export default defineConfig({ testDir: ./tests, timeout: 30000, retries: 1, use: { baseURL: http://127.0.0.1:8000, trace: on-first-retry, screenshot: only-on-failure, }, projects: [ { name: chromium, use: { ...devices[Desktop Chrome] } }, ], });timeout: 30000是单条用例上限后面 healer 排障时那个 Test timeout of 30000ms exceeded 就是撞到了这个值。trace: on-first-retry让失败用例自动留 trace省得你手动加--trace on。retries: 1给不稳定用例一次重试机会但别指望它治本真正的稳定性还得靠 healer 修定位器。.codex/目录下的代理指令文件不用手改init-agents已经写好了。你唯一要确认的是 Codex 能读到这个目录——在 Codex 里执行一次playwright_test_planner看能不能唤起能唤起就说明配置生效。如果报 agent not found检查.codex/是否在项目根目录、Codex 工作区是否指向了项目根。4. 调用 planner 生成测试计划、generator 落地脚本并验证执行结果配置就绪后先让 planner 干活。在 Codex 输入框里发这条提示词playwright_test_planner 基于 seed.spec.ts生成用户注册登录的全流程测试计划输出到 specs/user_login.md我实测时手滑把路径多打了一段Codex 居然自己识别并纠正了这点比想象中聪明。执行完specs/user_login.md里会出现一份 Markdown 计划包含正常登录、密码错误、账号不存在、普通用户访问管理页等场景。这一步必须人工审查逐条看有没有漏掉业务分支缺的场景直接让 planner 补再补充一个登录后 token 过期的场景。planner 只产出文字改起来零成本别急着往下走。计划确认后调 generatorplaywright_test_generator 根据 specs/user_login.md 生成 Playwright 自动化测试代码输出到 tests 目录generator 会在tests/下生成类似admin-login.spec.ts的文件。生成完先别急着信打开文件对照specs/user_login.md数一遍步骤——这是防假成功的第一道关。确认无误后执行单条用例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 就是真失败别自我安慰说可能是环境问题。想看页面实际操作过程用 UI 模式npx playwright test tests/admin-login.spec.ts --uiUI 模式能肉眼看到每一步点击和断言我就是在这一步发现第二条用例偶发失败——页面加载慢导致page.goto超时。想留证溯源就录 tracenpx playwright test tests/admin-login.spec.ts --trace on跑完用npx playwright show-trace xxx.zip打开本地查看器或者把 zip 拖到https://trace.playwright.dev在线回放。trace 里能看到每一步的 DOM 快照、网络请求和控制台日志定位超时到底是前端慢还是选择器错一目了然。5. 常见报错排查401、local proxy failed、reading choices 与 OAuth 问题跑这条链路最容易撞的几类报错我按真实遇到的整理成对照表方便你按图索骥。报错关键词典型原因处理动作401 UnauthorizedKey 无效或环境变量没生效重设TAOTOKEN_API_KEY确认 Base URL 是https://taotoken.net/apilocal proxy failed本地网络或端口被占用检查 8000 端口是否被占确认 baseURL 可达reading choices响应格式与预期不符确认wire_api chat模型名拼写正确OAuth 相关报错凭据模式冲突删掉auth.json或config.toml其中一个别同时用Test timeout exceeded页面加载慢或选择器失效调大 timeout或交给 healer 修定位器401最常见九成是环境变量没在当前终端生效。PowerShell 里$env:TAOTOKEN_API_KEY只在当前会话有效新开终端就没了建议写进系统环境变量。local proxy failed通常是 baseURL 指向的本地服务没起来先curl http://127.0.0.1:8000确认能通。reading choices是解析响应时字段对不上多半是wire_api配错或模型名写错回控制台核对 Model ID。OAuth 报错比较隐蔽根源是auth.json和config.toml同时存在导致凭据来源冲突。我的做法是只保留config.toml把auth.json删掉或改名。如果你用的是 Codex 的 OAuth 登录流程那就别配config.toml的 provider二选一。至于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页面load事件迟迟不触发可能是前端有慢接口。这种就该交给 healer 处理而不是无脑调大 timeout——调大只是掩盖问题。下一节说 healer 怎么修。6. 用 healer 修复失败用例并区分 Codex 原生修复的适用边界接着上面那条超时用例调 healerplaywright_test_healer 自动修复 tests/admin-login.spec.ts 执行失败问题healer 会启动浏览器、实时读取当前页面 DOM、重放失败步骤然后给出修复建议。它和 Codex 原生修复的本质区别在于Codex 只靠代码 终端报错文本推理不启动浏览器、不访问真实页面、不自动重跑healer 内置浏览器执行能力能现场匹配有效元素、循环验证修复结果还能区分是脚本问题还是前端 BUG。判断该用哪个看这张对照维度Codex 原生修复healer 代理修复访问真实页面否纯文本推理是实时读 DOM自动重试验证无改完手动跑自动循环验证动态元素处理差容易瞎改定位器强现场匹配区分页面 BUG不能能异常页面自动 skip适用规模少量临时用例大批量长期维护简单说改个拼写错误、调个断言文案Codex 原生就够涉及定位器失效、等待时机、动态组件必须上 healer。我那条超时用例 healer 修完后连续跑了几次都稳定通过说明它调整了等待策略或定位方式而不是简单加 sleep。还有一条铁律specs 计划必须和生成的代码逐条对比。AI 偷减步骤是假成功的高频原因——只登录不下单、把强断言弱化成元素可见、跳过异常分支。只要代码缺了 md 里定义的步骤哪怕全绿也是无效的。我审查时就发现 generator 漏了一个登录后 token 过期重定向的断言手动补回去才放心。7. 成本、稳定性与长期维护的实操建议我这次用的是 Codex 搭配deepseek-v4-flash高峰期跑完整条链路planner 生成计划 generator 落地 几轮 healer 修复的模型成本大概在 2.6 元左右换来 34 个测试用例、覆盖 22 条路由还顺手发现了一个应用 bug。对比人工 1.5 到 3 天、400 到 600 元的人力这个投入产出比在自动化测试场景里是划算的。当然成本会随模型和用例规模浮动别把它当固定值。长期维护上有几个习惯值得养成。第一specs/目录当资产管每次业务变更先改 Markdown 计划再重新生成代码别直接改.spec.ts否则下次生成会覆盖你的手改。第二healer 修完的用例要 review 它改了什么防止它用waitForTimeout这种硬等待糊弄过去。第三trace 只在失败时留日常跑别开--trace on否则磁盘涨得飞快。第四retries别设太高重试掩盖的不稳定迟早会在 CI 上爆发。如果你还没配好模型通道可以去 TaoToken 控制台生成 Key接入文档里有各语言的调用示例想先验证模型对话是否通用模型对话页面发一条测试请求最快如果打算把这条链路长期跑在 CI 里做 Agent 化测试Coding Plan 的额度模式会比按次调用更省心。配置三件套再强调一遍Base URL 用https://taotoken.net/apiKey 走环境变量Model ID 和控制台保持一致。把这三样对齐Codex 调 Playwright Test Agents 的 planner 和 generator 就能稳定跑起来。