Playwright 又出新東西了：三個 Agent 幫你全自動寫測試
整理版優先睇
Playwright Test Agents：三個AI Agent幫你全自動寫測試，由規劃到修復一條龍
呢篇文章介紹咗 Playwright 最新推出嘅 Test Agents，係三個專門用嚟做測試嘅 AI Agent。作者本身寫過兩篇關於 Playwright MCP 同 CLI 嘅文章，今次係回應讀者「點樣可以唔使逐句指揮，畀個目標就自動搞掂」嘅問題。
整體結論係：Test Agents 唔係一個工具，而係一個自主系統 — 你只需要話畀佢知要測咩，佢就會自己探索、自己寫測試 code、跑錯咗仲會自己修復。成個過程你主要係做審核，唔係執行。作者認為呢個係 Playwright 喺 AI 時代重新定義「測試自動化」嘅概念：以前係你寫 code 畀機器跑，而家係你講需求畀 AI 自動生成 code 再自動跑。
文章詳細解釋咗三個 Agent 嘅分工（Planner、Generator、Healer）、點樣安裝同初始化、每個 Agent 點用、點樣串成完整 workflow，仲同 MCP 同 CLI 做咗清楚對比，最後畀咗幾點實際使用嘅注意事項。適合想由零開始快速建立測試覆蓋嘅開發者。
- Test Agents 包含三個 Agent：Planner（探索應用出測試計劃）、Generator（將計劃轉成可執行嘅測試 code）、Healer（自動修復失敗嘅測試），可以接力或獨立使用。
- 安裝只需一條命令 `npx playwright init-agents`，之後喺 AI 編碼工具（VS Code 或 Claude Code）直接對話就可以開始。
- Seed 文件係關鍵設計 — 你事先寫好一個基礎測試嚟處理登入、初始化等環境，Planner 會先執行佢再探索，令生成嘅測試風格一致。
- Healer 係最慳力嘅功能：測試因為 DOM 變動或時機問題掛咗，佢會自動重播、揾原因、出修復方案，直到通過或者標記為 skip 並解釋原因。
- MCP 係感知工具（你指揮、AI 執行）、CLI 係執行工具（AI 自動落命令）、Test Agents 係自主系統（你畀目標、AI 完成全程），三者適用唔同場景同粒度。
內容片段
typescript// seed.spec.ts 示例import { test, expect } from './fixtures';test('seed', async ({ page }) => { // 在這裏處理登錄、初始化等準備工作 // 這個測試本身不需要有斷言});Test Agents 係咩？三個 Agent 分工明確
Playwright 官方推出嘅 Test Agents，係三個專門用嚟做測試嘅 AI Agent：Planner、Generator 同 Healer。佢哋可以單獨用，亦可以接力串成一個自動化循環 — 你講低一個目標，佢哋就自己搞掂曬。
Planner 負責探索你嘅應用，產出一份 Markdown 格式嘅測試計劃；Generator 將呢份計劃轉成真正可執行嘅 Playwright 測試 code；Healer 就係跑失敗咗之後，自動揾原因、自動出補丁修好。三個夾埋，成條鏈路基本上唔使有人喺度睇住。
三分鐘裝好，初始化 Agent 定義檔
裝嘅方法好簡單，一條命令就搞掂：<code_blocktextnpx playwright init-agents預設係 VS Code 模式；如果你用 Claude Code，就加個參數 <code_blocktextnpx playwright init-agents --loop=claude呢條命令會喺你項目嘅 .github/ 目錄 生成 Agent 定義檔 — 即係話畀 AI 知有咩工具可以用、點配合。
重要提醒：Playwright 版本更新之後要重新 run 一次，定義檔唔會自動同步。VS Code 要求 v1.105（2025 年 10 月 9 日之後）先完整支援。如果 Agent 功能冇反應，先升一升 VS Code。
三個 Agent 點樣用？由規劃到修復曬有示範
Planer 嘅用法：畀一個清晰嘅任務描述（例如「為訪客結賬流程生成測試計劃」），再加一個 seed.spec.ts 文件 — 呢個係好聰明嘅設計，你預先寫好基礎測試嚟搞掂登入、初始化呢啲「入門」嘢。Planner 會先 run 呢個 seed，然後喺呢個基礎上探索應用，最後產出一個 Markdown 計劃放喺 specs/ 目錄。
- Seed 文件範例：入面只係處理登入同初始化，唔需要有斷言。寫好之後同 Planner 講「基於 seed.spec.ts 幫我生成測試計劃」就得。
- Planer 輸出嘅測試計劃係人類可讀嘅，你可以 check 過先放行，唔啱直接改 Markdown，唔使碰 code。
Generator 嘅用法：將 Planer 輸出嘅 Markdown 計劃翻譯成 .spec.ts 文件，放喺 tests/ 目錄。佢生成過程中會 實時驗證 — 真係去操作瀏覽器，確認選擇器同斷言合理，唔係紙上談兵。
Healer 係最慳力嗰個：測試跑掛咗，你只要同佢講「幫我修復邊個 test file」，佢就會自動重播失敗步驟、睇當前 UI、揾對應元素、出修復方案，再重新跑到通過為止。如果試咗幾次都唔掂，佢會將呢個 test 標記為 skip，並註明佢認為呢個功能本身可能有問題。
完整工作流：串埋三個 Agent 做測試覆蓋
- 1 寫好 seed.spec.ts（處理環境初始化）
- 2 同 Planner 講：「為購物車模塊生成測試計劃」
- 3 Check 嚇生成嘅 specs/cart-operations.md，覺得 OK 就放行
- 4 同 Generator 講：「將呢個計劃生成為測試 code」
- 5 Run 測試，有失敗嘅就同 Healer 講「幫我修復」
- 6 全部通過，merge 入 code repository
成個過程你主要係 審核，唔係執行。呢個就係官方所講嘅 agentic loop。目錄結構好清晰：specs/ 放計劃、tests/ 放生成嘅 code，有咩問題追溯好方便。
同 MCP、CLI 有咩分別？一個對比幫你揀
一句話定性：MCP 係感知工具（畀 AI 裝咗雙眼，你指揮、佢執行），CLI 係執行工具（AI 自己落命令、適合流水線），Test Agents 係自主系統（你畀目標、AI 完成全程）。
MCP 適合你對頁面唔熟、需要一邊調試一邊寫測試；CLI 適合 CI/CD 自動化、批量操作，Token 消耗低；Test Agents 適合由零開始快速建立模塊測試覆蓋，或者測試因前端改動大量掛掉時批量修復。唔係邊個更好，係睇你喺邊個階段、要做咩事。
實際使用注意事項
- Seed 文件一定要寫好：如果應用需要登入但 seed 冇處理，Planner 探索時會撞牆。唔複雜，但要認真寫。
- Agent 定義文件要跟 Playwright 版本走：每次升級後重新 run `npx playwright init-agents` － 新功能先用到。
- Healer 唔係萬能：選擇器大範圍改動、功能邏輯變咗、API schema 變咗 — 呢啲要靠你自己搞。
- 生成嘅 code 要過一過眼：斷言力度係咪啱、邊界情況有冇覆蓋、測試之間有冇依賴 — 仍然需要人判斷。
總括嚟講，Test Agents 係 Playwright 喺 AI 自動化測試嘅一大步。如果你已經用緊 Playwright MCP，可以試下轉用 Agents 嘅方式 — 唔再係一步一步指揮，而係畀一個目標，等佢跑完整個流程。
呢個問題問得好到位。啱啱 Playwright 官方最近推出咗一個新嘢：Test Agents。
今次唔係工具，係三個專門做測試呢件事嘅 AI Agent。你話畀佢測咩，佢自己探索、自己寫 code、跑失敗咗仲可以自己修——成條鏈路可以唔使人睇住。
先講清楚佢係咩
Playwright Test Agents 包含三個 Agent，個名都好直接：
- 🎭 Planner（規劃者）：探索你嘅應用程式，產出一份 Markdown 格式嘅測試計劃
- 🎭 Generator（生成者）：將測試計劃轉成可執行嘅 Playwright 測試 code
- 🎭 Healer（修復者）：跑失敗咗嘅測試，自動揾原因，自動打 patch 修好
三個 Agent 可以單獨用，亦可以按順序接力，又可以串成一個自動化循環——你落任務，佢哋全程自己轉。
講白啲，呢個係 Playwright 喺 AI 時代對「測試自動化」呢個概念嘅重新定義。以前係你寫 code 俾機器自動跑，而家係你講需求俾 AI 自動生成 code 再自動跑。
三分鐘裝好，開始用
初始化 Agent 定義檔案
一條 command 搞掂：
bashnpx playwright init-agents預設係 VS Code 模式。如果你用 Claude Code，加個參數：
bashnpx playwright init-agents --loop=claude呢條 command 會喺你嘅 project 裏面生成 Agent 定義檔案（放喺 .github/ 目錄下面）。呢啲檔案係 Agent 嘅「說明書」——話俾 AI 知有邊啲工具可以用、點樣配合工作。
重要：Playwright 版本更新之後要重新跑一次，定義檔案唔會自動同步。
VS Code 要求 v1.105（2025 年 10 月 9 日之後） 先至可以完整支援。如果 Agent 功能冇反應，先升一升 VS Code。
三個 Agent 分別點樣用
🎭 Planner：唔好咁急寫 code，先俾佢探路
Planner 做嘅嘢係理解你嘅應用，規劃測試範圍。
佢需要咩：
- 你俾一個清晰嘅任務描述（例如「俾訪客結賬流程生成測試計劃」）
- 一個
seed.spec.ts——呢個檔案好關鍵，後面單獨解釋 - 可選：產品需求文檔（PRD），俾佢更多上下文
佢產出啲咩：
- 一個 Markdown 檔案，保存喺
specs/目錄下，例如specs/basic-operations.md
呢份計劃人可以直接睇得明，每個測試場景、步驟、預期結果都寫得好清楚。你可以喺 Generator 跑之前檢查一次，覺得邊度唔啱直接改，唔需要掂 code。
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：將計劃變成真正 run 得起嘅 code
Planner 輸出咗測試計劃，Generator 就將呢個 Markdown 翻譯成 .spec.ts 文件。
佢需要咩：
specs/目錄下嘅 Markdown 計劃檔案
佢產出啲咩：
tests/目錄下嘅測試檔案，同計劃裏面嘅場景一一對應
Generator 喺生成過程中會實時驗證——佢會真係去操作瀏覽器，確認選擇器係咪有效、斷言係咪合理。唔係紙上談兵，生成完就係可以 run 嘅 code（大部分情況）。
如果某啲測試有初始錯誤，唔使手動去改，直接交俾 Healer。
提示語好簡單：
text把 specs/basic-operations.md 裏的測試計劃生成為測試代碼🎭 Healer：測試死咗，唔使急，俾佢修
呢個係我覺得三個 Agent 裏面最省心嘅一個。
你嘅測試 run 死咗——可能係前端改咗 DOM 結構，可能係等待時間唔夠，可能係數據對唔上——以前你要自己睇報錯、揾元素、改 code、重新 run。
而家你話俾 Healer：
text幫我修復 tests/add-valid-todo.spec.ts 裏失敗的測試Healer 會：
- 重新回放失敗嘅測試步驟
- 睇而家嘅 UI，揾到對應嘅元素或流程
- 提出修復方案（更新選擇器、調整等待、修改數據）
- 重新 run 測試，直到通過
如果 Healer run 咗幾次都仲係唔得，佢會將呢個測試標記為 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/ 揾對應嘅計劃，睇係需求層面嘅問題定係 code 層面嘅問題。
同 MCP、CLI 有咩唔同
三篇文章講咗三個嘢，講清楚區別好必要。一句話定性：MCP 係感知工具，CLI 係執行工具，Agent 係自主系統。
Playwright MCP
本質： 俾 AI 裝咗一對「眼」。
MCP 伺服器將瀏覽器當前頁面嘅可訪問性樹（Accessibility Tree）同截圖暴露出來，令 AI 編碼工具（VS Code Copilot、Claude 等）可以「睇到」頁面。你喺 IDE 裏面對話，每發一條指令，AI 就行一步，然後將執行結果拎返嚟話俾你知，你再決定下一步。
關鍵特徵：
- 交互是對話式嘅，你係主導，AI 係執行手
- 每一步都喺你視野裏面，過程可以隨時幹預
- 因為要持續傳輸頁面快照，Token 消耗較高
- 生成嘅 code 可以直接落到編輯器裏面
適合嘅場景：
- 你對呢個頁面唔熟，需要 AI 幫你「讀明」頁面結構再寫選擇器
- 要寫某個特定功能嘅測試，你想一路睇生成結果一路調整
- 除錯測試時，需要 AI 幫你解釋「點解呢個元素揾唔到」
- 你係新手，想喺 AI 陪伴下學寫 Playwright 測試
一句話：你指揮，AI 做嘢，成個過程你在場。
Playwright CLI
本質： 俾 AI 提供咗一套 command line 接口，令佢可以直接遙控瀏覽器。
同 MCP 相比，CLI 唔依賴頁面快照，而係將操作抽象成一條條結構化命令（navigate、click、fill、screenshot 等）。AI 叫呢啲命令嚟完成任務，成個過程更輕量，每條命令嘅 Token 消耗遠低過 MCP 嘅頁面傳輸。
關鍵特徵：
- 無頭（headless）友好，唔需要可視化界面都可以 run
- 命令粒度細，適合喺 code 或 Agent 流程裏面編排調用
- Token 消耗低，成本可控
- 適合集成入更大嘅自動化流程，而唔係獨立使用
適合嘅場景：
- 你要喺 CI/CD 裏面俾 AI 自動完成某個操作（例如定期 run 一次 smoke test）
- 你喺構建一個更複雜嘅 AI 流程，Playwright 只係其中一個執行節點
- 批量自動化任務：爬取數據、批量截圖、自動填表提交
- 對 Token 成本敏感，想用盡量少嘅消耗完成操作
一句話：AI 自己落命令、自己執行，適合接入流水線，唔適合互動除錯。
Playwright Test Agents
本質： 專門為「測試」呢件事設計嘅自主 AI 系統。
MCP 同 CLI 嘅定位都係「工具」——你決定做咩，AI 幫你做。Test Agents 唔同，你只需要俾一個目標（「俾結賬流程建立測試覆蓋」），三個 Agent 自己規劃、自己生成 code、自己 run、自己修——形成一個閉環。
關鍵特徵：
- 有明確嘅分工：Planner 探索 → Generator 生成 code → Healer 修復失敗
- 過程是自主的，唔需要你逐步指揮
- 產出有中間層（Markdown 測試計劃），人可以檢查同幹預
- 更適合「建立測試覆蓋」呢類項目級任務，而唔係單個測試嘅除錯
適合嘅場景：
- 項目從零開始，需要快速建立某個模塊嘅測試覆蓋
- 你有需求文檔（PRD），想俾 AI 直接根據需求生成測試用例
- 測試因為前端改動大量死咗，俾 Healer 批量修復比手動改快得多
- 希望喺 CI 裏面集成「測試自愈」能力，死咗嘅測試自動嘗試修復
一句話：你俾目標，AI 完成全程，適合項目級嘅測試建設，唔適合精細除錯單個測試。
三者對比總結
| 控制權 | |||
| 交互方式 | |||
| Token 消耗 | |||
| 適合粒度 | |||
| 人工介入 | |||
| 典型用途 |
唔係邊個更好，係睇你喺邊個階段、要做咩事：寫單個測試揾 MCP，搭自動化流程用 CLI，建整體測試覆蓋用 Agents。
幾點實際使用嘅注意事項
1. Seed 檔案一定要寫好
呢個係成個 Agent 流程嘅基礎。如果你嘅應用需要登入，seed 裏面冇處理，Planner 探索時會撞牆。唔複雜，但係要認真寫。
2. Agent 定義檔案要跟住 Playwright 版本行
每次升級 Playwright 之後，npx playwright init-agents 重新 run 一次。呢個檔案裏面有工具列表同指令，Playwright 新功能加咗入嚟之後 Agent 先至用得著。
3. Healer 唔係萬能嘅
選擇器大範圍改動、功能邏輯變咗、接口 schema 變咗——呢啲靠 Healer 修唔到，佢處理嘅係「可以 run 但 run 失敗咗」呢類問題，唔處理「需求變咗」。
4. 生成嘅 code 要睇一次
Generator 產出嘅測試基本可用，但唔好完全唔睇就 merge。斷言嘅力度係咪合適、邊界情況有冇覆蓋、測試之間有冇依賴——呢啲仍然需要人判斷。
小結
- 🎭 Planner → 探索應用，輸出人類可讀嘅測試計劃（Markdown）
- 🎭 Generator → 將計劃變成可執行嘅 Playwright 測試 code
- 🎭 Healer → 測試失敗咗，自動修，修唔好就 skip 並說明原因
- 三個 Agent 可以串成完整流程，亦可以單獨按需要調用
- 基礎 command：
npx playwright init-agents，之後喺你嘅 AI 編碼工具裏面直接用
如果你已經用緊 Playwright MCP 幫你寫測試，可以試嚇轉用 Test Agents 嘅方式——唔再係你一步一步指揮，而係俾佢一個目標，等佢 run 完成個流程。
這個問題問得很到位。正好 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 完成全程，適合項目級的測試建設，不適合精細調試單個測試。
三者對比總結
| 控制權 | |||
| 交互方式 | |||
| Token 消耗 | |||
| 適合粒度 | |||
| 人工介入 | |||
| 典型用途 |
不是哪個更好，是看你在哪個階段、要做什麼事：寫單個測試找 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 的方式——不再是你一步一步指揮，而是給它一個目標，讓它跑完整個流程。