playwright的官方 test agents 文档，把测试智能体拆成了 planner、generator 和 healer 三个独立角色：planner 负责遍历应用输出 markdown 格式的测试计划，generator 照着计划生成 playwright 测试文件，healer 专门处理执行失败的用例，重新校验页面状态尝试自动修复用例。这三个角色既可以单独运行，也能按顺序串成完整循环。这套划分把「要测什么」「怎么写成可执行用例」「用例失败后怎么排查」拆成了独立阶段，目前官方是把它作为 playwright 测试工作流的一部分对外提供的。
来源：Playwright 官方 Test Agents 文档
planner 对应的是测试设计阶段。按照官方文档说明，它可以先自动浏览整个产品，按业务场景梳理出完整的测试计划；你给它的输入可以是一句清晰的任务描述，也可以附带用来初始化环境的种子测试用例，还能直接附上产品需求文档。输出的测试计划会把场景、操作步骤、预期结果分开记录，方便团队在生成代码之前先确认测试覆盖范围是否达标。对需求迭代频繁的项目来说，先审核测试计划再生成代码，相当于把测试意图留在代码层外面，能避免直接从自然语言生成一堆没人能捋清楚的用例，降低后续维护风险。
generator 拿到测试计划之后，就会把 Markdown 格式的场景转成可以直接运行的测试文件。官方说明里提到，它在生成过程中会实时校验定位器和断言是否可用，输出目录完全由项目自行决定，官方示例里是用 specs 目录存测试计划、tests 目录存最终测试用例，同时保留种子测试用来拉起运行所需的环境。注意生成出来的结果不是不能改的最终版本：官方特意提示，刚生成的初稿大概率会存在问题，后续可以交给 healer 继续处理。也就是说，测试计划、测试代码、测试数据这几部分，团队还是要手动维护，保证三者逻辑一致。
来源：Playwright 官方 Test Agents 文档
失败用例仍需要判断
healer 会重放之前失败的操作步骤，检查当前页面的实际状态，尝试判断问题到底是定位器过期、等待条件设置不合理，还是测试数据本身出了问题，之后给出修改建议重新运行。但按照官方的描述，它没法保证所有失败用例都能自动修好：有可能它调整完之后用例就能跑通，也有可能它识别出是产品功能本身有bug，就直接跳过这个用例。所以团队还是要手动审核它给出的所有修改，区分清楚是产品回归、环境故障还是测试代码本身写错了，不能光看修复循环跑完了就直接判定产品质量达标。
Test Agents 的安装入口是和项目现有工具链绑定的。Playwright 文档推荐用 init-agents 命令给对应的编码客户端生成代理定义，同时列了 VS Code、Claude Code、Codex 与 OpenCode 等几个可选的循环运行选项；每次 Playwright 更新之后，记得重新生成代理定义，才能用到最新的工具和指令。生成出来的所有相关文件都要走代码评审，确认智能体能访问的项目上下文、测试权限和文件写入范围都符合团队要求。
这套三段式流程，更适合已经搭好稳定测试环境、需求场景比较明确的 Web 项目。要是用来做初始化的种子测试连稳定登录都做不到，或者外部依赖没做隔离，planner 拿到的页面状态本身就不可靠；要是生成出来的用例只校验了按钮是否存在，根本没加业务逻辑相关的断言，哪怕测试数量涨了也不算有效覆盖。比较稳妥的落地方式，是先挑一个低风险的核心流程试跑，人工把测试计划和断言都确认没问题之后，再考虑要不要扩展到更多业务模块。Playwright 官方展示的只是一套可以自由组合的工具角色，最终的测试覆盖质量，还是取决于项目提供的上下文、测试数据和人工复核的标准。
