上两篇分别讲了 Playwright MCP 和 Playwright CLI，有朋友看完之后问：
"我现在用 MCP 让 Copilot 帮我生成测试，但还是要我一步一步指挥，能不能更自动一点，告诉它一个目标，它自己搞定？"
这个问题问得很到位。正好 Playwright 官方最近推出了一个新东西：Test Agents。
这次不是工具，是三个专门干测试这件事的 AI Agent。你告诉它测什么，它自己探索、自己写代码、跑失败了还能自己修——整个链路可以不用人盯着。
— — —
先说清楚它是什么
Playwright Test Agents 包含三个 Agent，名字都很直接：
🎭 Planner（规划者）：探索你的应用，产出一份 Markdown 格式的测试计划
🎭 Generator（生成者）：把测试计划转成可执行的 Playwright 测试代码
🎭 Healer（修复者）：跑失败的测试，自动找原因，自动打补丁修好
三个 Agent 可以单独用，也可以按顺序接力，也可以串成一个自动化循环——你下达任务，它们全程自己转。
说白了，这是 Playwright 在 AI 时代对"测试自动化"这个概念的重新定义。以前是你写代码让机器自动跑，现在是你说需求让 AI 自动生成代码再自动跑。
— — —
三分钟装好，开始用
初始化 Agent 定义文件
一条命令搞定：
bashnpx playwright init-agents
默认是 VS Code 模式。如果你用 Claude Code，加个参数：
bashnpx playwright init-agents --loop=claude
这条命令会在你的项目里生成 Agent 定义文件（放在 .github/ 目录下）。这些文件是 Agent 的"说明书"——告诉 AI 有哪些工具可以用、怎么配合工作。
重要：Playwright 版本更新后要重新跑一次，定义文件不会自动同步。
VS Code 要求 v1.105（2025 年 10 月 9 日之后） 才能完整支持。如果 Agent 功能没反应，先升一下 VS Code。
— — —
三个 Agent 分别怎么用
🎭 Planner：先别急着写代码，先让它探路
Planner 干的事情是理解你的应用，规划测试范围。
它需要什么：
你给一个清晰的任务描述（比如"给访客结账流程生成测试计划"）
一个 seed.spec.ts——这个文件很关键，后面单独解释
可选：产品需求文档（PRD），给它更多上下文
它产出什么：
一个 Markdown 文件，保存在 specs/ 目录下，比如 specs/basic-operations.md
这份计划人能直接读懂，每个测试场景、步骤、预期结果都写得清清楚楚。你可以在 Generator 跑之前检查一遍，觉得哪里不对直接改，不需要碰代码。
Seed 文件是什么？
这是一个很聪明的设计。seed.spec.ts 是你提前写好的一个基础测试，负责处理"进门"的事——比如登录、初始化数据、设置 fixture。
Planner 会先跑这个 seed 测试，把环境配置好，然后在这个基础上探索应用。它还会把 seed 文件当作后续生成测试的样本，风格、结构、用到的 fixture 都会保持一致。
typescript// seed.spec.ts 示例import { test, expect } from './fixtures';test('seed', async ({ page }) => {  // 在这里处理登录、初始化等准备工作  // 这个测试本身不需要有断言});
写好之后，跟 Planner 说"基于 seed.spec.ts 帮我生成测试计划"就行。
— — —
🎭 Generator：把计划变成真正能跑的代码
Planner 输出了测试计划，Generator 就把这个 Markdown 翻译成 .spec.ts 文件。
它需要什么：
specs/ 目录下的 Markdown 计划文件
它产出什么：
tests/ 目录下的测试文件，和计划里的场景一一对应
Generator 在生成过程中会实时验证——它会真的去操作浏览器，确认选择器是否有效、断言是否合理。不是纸上谈兵，生成完就是能跑的代码（大部分情况）。
如果某些测试有初始错误，不用手动去改，直接交给 Healer。
提示语非常简单：
text把 specs/basic-operations.md 里的测试计划生成为测试代码
— — —
🎭 Healer：测试挂了，别急，让它修
这是我觉得三个 Agent 里最省心的一个。
你的测试跑挂了——可能是前端改了 DOM 结构，可能是等待时间不够，可能是数据对不上——以前你要自己去看报错、找元素、改代码、重新跑。
现在你告诉 Healer：
text帮我修复 tests/add-valid-todo.spec.ts 里失败的测试
Healer 会：
重新回放失败的测试步骤
查看当前 UI，找到对应的元素或流程
提出修复方案（更新选择器、调整等待、修改数据）
重新跑测试，直到通过
如果 Healer 跑了几次还是不行，它会把这个测试标记为 skip，并注明它认为这个功能本身可能有问题。
— — —
一个完整的工作流
把三个 Agent 串起来，测试覆盖这件事可以这样做：
text1. 写好 seed.spec.ts（处理环境初始化）         ↓2. 告诉 Planner："给购物车模块生成测试计划"         ↓3. 检查 specs/cart-operations.md（可选，觉得OK就放行）         ↓4. 告诉 Generator："把这个计划生成为测试代码"         ↓5. 测试跑起来，有失败的？告诉 Healer 去修         ↓6. 全部通过，合并进代码仓库
三个 Agent 接力，整个过程你主要在审核，不在执行。这就是官方说的"agentic loop"。
— — —
目录结构是这样的
生成的文件按规范放，审计很清晰：
textrepo/  .github/                    # Agent 定义文件（由 init-agents 生成）  specs/                      # 人类可读的测试计划    basic-operations.md    cart-operations.md  tests/                      # 生成的 Playwright 测试代码    add-valid-todo.spec.ts    checkout-flow.spec.ts  seed.spec.ts                # 环境初始化的种子测试  playwright.config.ts
计划文件和测试文件一一对应，出了问题追溯很方便——测试失败了，去 specs/ 找对应的计划，看是需求层面的问题还是代码层面的问题。
— — —
和 MCP、CLI 有什么不一样
三篇文章讲了三个东西，讲清楚区别很必要。一句话定性：MCP 是感知工具，CLI 是执行工具，Agent 是自主系统。
— — —
Playwright MCP
本质： 给 AI 装了一双"眼睛"。
MCP 服务器把浏览器当前页面的可访问性树（Accessibility Tree）和截图暴露出来，让 AI 编码工具（VS Code Copilot、Claude 等）能"看到"页面。你在 IDE 里对话，每发一条指令，AI 就执行一步，然后把执行结果拿回来告诉你，你再决定下一步。
关键特征：
交互是对话式的，你是主导，AI 是执行手
每一步都在你视野里，过程可随时干预
因为要持续传输页面快照，Token 消耗较高
生成的代码可以直接落到编辑器里
适合的场景：
你对这个页面不熟，需要 AI 帮你"读懂"页面结构再写选择器
要写某个特定功能的测试，你想一边看生成结果一边调整
调试测试时，需要 AI 帮你解释"为什么这个元素找不到"
你是新手，想在 AI 陪伴下学着写 Playwright 测试
一句话：你指挥，AI 干活，整个过程你在场。
— — —
Playwright CLI
本质： 给 AI 提供了一套命令行接口，让它能直接遥控浏览器。
和 MCP 相比，CLI 不依赖页面快照，而是把操作抽象成一条条结构化命令（navigate、click、fill、screenshot 等）。AI 调用这些命令来完成任务，整个过程更轻量，每条命令的 Token 消耗远低于 MCP 的页面传输。
关键特征：
无头（headless）友好，不需要可视化界面也能跑
命令粒度细，适合在代码或 Agent 流程里编排调用
Token 消耗低，成本可控
适合集成进更大的自动化流程，而不是独立使用
适合的场景：
你要在 CI/CD 里让 AI 自动完成某个操作（比如定期跑一遍冒烟测试）
你在构建一个更复杂的 AI 流程，Playwright 只是其中一个执行节点
批量自动化任务：爬取数据、批量截图、自动填表提交
对 Token 成本敏感，想用尽量少的消耗完成操作
一句话：AI 自己下命令、自己执行，适合接入流水线，不适合互动调试。
— — —
Playwright Test Agents
本质： 专门为"测试"这件事设计的自主 AI 系统。
MCP 和 CLI 的定位都是"工具"——你决定做什么，AI 帮你做。Test Agents 不一样，你只需要给一个目标（"给结账流程建测试覆盖"），三个 Agent 自己规划、自己生成代码、自己跑、自己修——形成一个闭环。
关键特征：
有明确的分工：Planner 探索 → Generator 生成代码 → Healer 修复失败
过程是自主的，不需要你逐步指挥
产出有中间层（Markdown 测试计划），人可以检查和干预
更适合"建立测试覆盖"这类项目级任务，而不是单个测试的调试
适合的场景：
项目从零开始，需要快速建立某个模块的测试覆盖
你有需求文档（PRD），想让 AI 直接根据需求生成测试用例
测试因为前端改动大量挂掉，让 Healer 批量修复比手动改快得多
希望在 CI 里集成"测试自愈"能力，挂掉的测试自动尝试修复
一句话：你给目标，AI 完成全程，适合项目级的测试建设，不适合精细调试单个测试。
— — —
三者对比总结
 MCP CLI Test Agents 控制权 你指挥，AI 执行 AI 自主执行命令 AI 自主完成目标 交互方式 对话式，逐步 命令式，可批量 目标式，自主规划 Token 消耗 高（页面快照） 低（结构化命令） 中（有中间产物） 适合粒度 单个测试/操作 批量操作/流程节点 模块级/项目级 人工介入 全程在场 不需要介入 关键节点审核即可 典型用途 边调试边写测试 CI 自动化、AI 流程 测试覆盖建设
不是哪个更好，是看你在哪个阶段、要做什么事：写单个测试找 MCP，搭自动化流程用 CLI，建整体测试覆盖上 Agents。
— — —
几点实际使用的注意事项
1. Seed 文件一定要写好
这是整个 Agent 流程的基础。如果你的应用需要登录，seed 里没处理，Planner 探索时会撞墙。不复杂，但要认真写。
2. Agent 定义文件要跟着 Playwright 版本走
每次升级 Playwright 之后，npx playwright init-agents 重新跑一遍。这个文件里有工具列表和指令，Playwright 新功能加进来之后 Agent 才能用上。
3. Healer 不是万能的
选择器大范围改动、功能逻辑变了、接口 schema 变了——这些靠 Healer 修不了，它处理的是"能跑、跑失败了"这类问题，不处理"需求变了"。
4. 生成的代码要过一遍眼
Generator 产出的测试基本可用，但不要完全不看就合并。断言的力度是否合适、边界情况有没有覆盖、测试之间有没有依赖——这些仍然需要人判断。
— — —
小结
🎭 Planner → 探索应用，输出人类可读的测试计划（Markdown）
🎭 Generator → 把计划变成可执行的 Playwright 测试代码
🎭 Healer → 测试失败了，自动修，修不好就 skip 并说明原因
三个 Agent 可以串成完整流程，也可以单独按需调用
基础命令：npx playwright init-agents，之后在你的 AI 编码工具里直接用
如果你已经在用 Playwright MCP 帮你写测试，可以试试迁到 Test Agents 的方式——不再是你一步一步指挥，而是给它一个目标，让它跑完整个流程。
— — —