別再讓 AI 盯着網頁發呆了：Playwright-CLI 正在改寫瀏覽器自動化
整理版優先睇
Playwright-CLI 唔係另一個瀏覽器工具，而係微軟為 AI Coding Agent 重新設計嘅瀏覽器操作接口，用更短命令、更省上下文嘅方式，令 AI 可以低成本、高頻次咁開頁面、點擊、截圖、睇 console，真正完成開發閉環。
呢篇文章係由一位關注 AI 編程工具發展嘅開發者撰寫，佢指出雖然 AI 已經可以讀寫程式碼、改動項目、跑測試，但成日卡喺一個關鍵位：瀏覽器操作。微軟推出嘅 Playwright-CLI 就係為咗填補呢個缺口。作者嘅核心論點係：AI Agent 唔單止要「能夠」操作瀏覽器，仲要喺有限嘅模型上下文入面，以低成本、高頻率同可控嘅方式去操作。Playwright-CLI 嘅設計正好滿足呢個需要，佢唔係取代 Playwright MCP，而係提供一個更輕量、更慳上下文嘅選項。
Playwright-CLI 嘅關鍵設計係將瀏覽器操作濃縮成好短嘅命令，例如 `playwright-cli open`、`click`、`type`、`screenshot`，而唔係每次傳一大堆工具 schema 或者可訪問性樹畀模型。佢仲支援 Skills，即係畀 Agent 用嘅操作手冊，可以按需要加載，唔使一次過塞曬所有資訊。Session 設計令 Agent 可以保持瀏覽器狀態，唔使每次由零開始。`show` dashboard 就畀人類可以觀察同接管 Agent 嘅操作，解決信任問題。
整體嚟講，Playwright-CLI 代表住一個大趨勢：工具開始為 AI Agent 重新設計。將來會有愈嚟愈多開發工具唔單止畀人用，仲要畀 AI 用。而能夠令 AI 更省上下文、更穩定操作真實世界嘅工具，就會成為下一代軟件工程嘅入口。作者建議已經用緊 Cl…
- Playwright-CLI 係微軟面向 AI Coding Agent 嘅瀏覽器控制接口，核心賣點係 token-efficient，用短命令操作瀏覽器，大幅減少模型上下文負擔。
- 同 Playwright MCP 嘅分別在於：MCP 適合複雜、需要深入頁面結構嘅場景，而 CLI 更適合高頻、明確嘅工程閉環動作，例如復現 bug、截圖、檢查 console。
- CLI 支援 session 設計，可以保存 cookies 同 storage state，令 Agent 可以連續操作而唔使每次重新登錄，真正模擬人類開發者嘅工作流程。
- `playwright-cli show` 提供可視化 dashboard，畀人類觀察 Agent 嘅瀏覽器操作，必要時可以接管，解決自動化嘅信任問題。
- Skills 機制實現 progressive disclosure，Agent 可以按需讀取操作指南，避免一次性將大量資訊塞入模型上下文，係未來 Agent 工具設計嘅重要方向。
Playwright-CLI GitHub Repository
微軟官方專案，CLI for common Playwright actions with SKILLS
Playwright CLI 官方文檔
Getting started with Playwright CLI
@playwright/cli NPM Package
npm install -g @playwright/cli@latest
安裝 Skills 指令
`playwright-cli install --skills`，默認安裝喺 .claude/skills 目錄，可以複製到其他工具嘅 skills 目錄。
內容片段
Test the "add todo" flow on
https://demo.playwright.dev/todomvc using playwright-cli.Check playwright-cli --help for available commands.點解 Playwright-CLI 值得關注？
呢個項目嘅定位好直接：CLI for common Playwright actions. Record and generate Playwright code, inspect selectors and take screenshots. 官方 README 仲特別強調一句：Playwright CLI with SKILLS。呢句好關鍵，因為佢唔係單純將 Playwright 能力包一層命令行，而係將 CLI 同 Skills 綁埋一齊，專門畀 Claude Code、GitHub Copilot 呢啲 coding agents 用。
新舊 Playwright CLI 嘅本質分別
好多開發者一聽到 Playwright CLI，可能會諗起 `npx playwright test`、`npx playwright codegen` 呢啲傳統命令。但新嘅 @playwright/cli 目標對象唔同咗：佢唔係畀人類開發者嘅測試運行器，而係一個 面向 AI Agent 嘅瀏覽器控制接口。
安裝方式好簡單：npm install -g @playwright/cli@latest，然後可以執行 `playwright-cli --help`。仲可以安裝 skills：playwright-cli install --skills，默認裝喺 `.claude/skills` 目錄。如果喺其他工具用，就複製去對應嘅 skills 目錄就得。
CLI 點樣比 MCP 更慳上下文？
好多人一講 AI Agent 就諗起 MCP，但 MCP 有個現實問題：上下文成本。MCP 會向模型暴露工具 schema、結構化返回、頁面信息，複雜網頁嘅可訪問性樹、DOM 摘要可能好長。如果 Agent 只係想做簡單動作——開頁面、撳掣、打字、截圖、睇 console——每次都塞咁多結構入去，未必划算。
Playwright CLI 嘅思路係：別將瀏覽器搬入模型上下文，等模型發命令就得。例如：`playwright-cli open https://... --headed`、`playwright-cli type "Buy groceries"`、`playwright-cli press Enter`、`playwright-cli screenshot`。呢啲命令好短，Agent 唔使「讀懂成個網頁世界」，只需要喺必要時透過 snapshot 拎可交互元素引用，然後用 ref 操作。
Session 設計同 Show Dashboard：狀態管理同人類監督
Playwright CLI 有一個好重要但容易被低估嘅設計：session。默認情況下，Playwright CLI 會將瀏覽器 profile 保存喺內存，同一個 session 內 cookies 同 storage state 會喺 CLI 調用之間保留；如果用 --persistent，仲可以持久化到磁盤。
- 1 Agent 唔使每次重新登錄、重新初始化，可以「繼續之前嘅瀏覽器」做落去。
- 2 支援 `playwright-cli list` 睇曬所有 session，仲可以透過 `PLAYWRIGHT_CLI_SESSION` 環境變量指定 session。
- 3 呢個對真實工程場景好重要，因為大量問題係發生喺連續狀態入面：登錄後、多標籤頁、表單填一半、特定權限下。
另一個好玩嘅功能係 playwright-cli show，佢會打開一個可視化 dashboard，顯示所有運行緊嘅瀏覽器 session：session grid 展示活躍 session、URL、頁面標題、實時預覽；session detail 展示實時視圖、標籤頁、導航控制；人類可以點擊 viewport 接管鼠標鍵盤，或者關閉 session。
Skills 機制同 AI 工具新方向
playwright-cli install --skills 呢點尤其值得留意。Skills 唔係多一份文檔咁簡單，而係畀 Agent 嘅「操作手冊」。傳統文檔係寫畀人睇，Skill 係寫畀 Agent 用：幾時 call 咩命令、遇到某類任務點拆解、複雜能力點按需加載。
第三方文章提到一個關鍵詞：progressive disclosure（漸進披露）。即係唔好一次過將所有複雜資訊塞畀模型，而係等 Agent 需要時再讀取具體操作指南。呢個同 Playwright CLI 嘅 token-efficient 目標一致。真正優秀嘅 Agent 工具，唔係暴力提供更多上下文，而係 減少不必要上下文。
所以如果你而家用緊 Claude Code、GitHub Copilot、Cursor、Windsurf 之類嘅 coding agent，不妨留意呢個項目。唔係因為佢命令多，而係因為佢透露咗一個好明確嘅方向：下一代開發工具，唔單止畀人用，佢哋都會畀 AI 用。而邊個能夠令 AI 更省上下文、更穩定操作真實世界，邊個就更接近下一代軟件工程嘅入口。
如果話過去一年，AI編程工具最大嘅變化，係模型終於識得讀code、改動項目、跑test。
咁接下來更重要嘅一步，就係：AI可唔可以好似一個真正嘅開發者咁，打開瀏覽器，撳頁面，填表單，睇報錯，截圖，復現問題，然後自己修返好。
呢件事聽落唔係新鮮。
Playwright一早就可以自動化瀏覽器，Playwright MCP都已經令AI Agent可以透過MCP控制瀏覽器。好多人會問：既然已經有MCP，點解微軟仲要另外做一個playwright-cli呢？
答案好簡單，亦好現實：
AI Agent唔單止要‘識得操作瀏覽器’，仲要喺有限上下文入面，低成本、高頻率、可控咁操作瀏覽器。
呢個就係Playwright CLI出現嘅真正意義。
佢唔係另一個俾人類手打命令嘅傳統CLI。
佢更加似係微軟俾AI Coding Agent準備嘅一對‘機械手’：唔使每次都將成個頁面結構、冗長工具schema、大量可訪問性樹塞入模型上下文，而係令Agent透過簡短、明確、可組合嘅命令完成瀏覽器操作。
一句講曬：
MCP令AI Agent睇到瀏覽器，Playwright CLI令AI Agent更平、更輕、更似工程師咁用瀏覽器。
總體使用的感覺也是相當哇塞！
一、點解呢個項目值得睇？
先睇項目本身。
microsoft/playwright-cli 嘅定位好直接：
CLI用嚟做常見嘅Playwright操作。錄製同生成Playwright代碼，檢查selector同截圖。
官方README入面講得更清楚：
Playwright CLI with SKILLS.
呢句好關鍵。
佢唔止係將Playwright嘅能力包咗一層命令行，而係將CLI同Skills綁埋一齊，面向Claude Code、GitHub Copilot呢啲coding agents嚟用。
根據項目README同Playwright官方文檔，Playwright CLI嘅核心賣點係：
• 命令行控制瀏覽器； • 面向coding agents； • 支持安裝skills； • 默認強調token-efficient； • 識得打開頁面、撳掣、輸入、截圖、生成locator、保存狀態、管理session、睇網絡請求、錄製trace/video； • 仲可以透過 playwright-cli show打開可視化dashboard，觀察多個瀏覽器session。
呢個代表咩？
代表微軟已經唔滿足於‘AI識得調用瀏覽器工具’。
佢喺度行得更深一層：為AI Agent重新設計瀏覽器自動化接口。
二、舊Playwright CLI、新Playwright CLI，唔係同一回事
呢度好容易混淆。
好多開發者一聽Playwright CLI，就會下意識諗到：
npx playwright test
npx playwright codegen
npx playwright install呢啲當然都係Playwright嘅命令行能力，但佢哋主要係俾人類開發者用嘅：跑test、生成test、安裝瀏覽器。
而新的 @playwright/cli，從項目表述睇，目標對象變咗。
佢唔係傳統意義上嘅‘測試運行器’，而係一個面向AI Agent嘅瀏覽器控制接口。
安裝方式都好清楚：
npm install -g @playwright/cli@latest
playwright-cli --help然後可以安裝skills：
C:\Users\Administrator\playwright-cli install --skills如果你喺OpenClaw入面用，就要入去.openclaw\workspace\skills目錄，複製上面講嗰個文件夾然後貼喺呢個目錄。如果係用codex、cursor或者Trae，都可以用類似嘅方法。
使用例子
輸出結果
如果唔裝skills，都可以直接俾Agent自己睇help：
Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.呢個就係設計上嘅變化：
過去嘅CLI，係人睇文件，人打命令。
而家嘅CLI，係Agent睇help/skill，Agent決定下一步點操作。
工具嘅使用者，由人，變成咗AI。
呢個唔係小修小補，而係開發工具範式嘅變化。
三、CLI同MCP相比，關鍵唔係‘邊個更高級’，而係邊個更慳
而家好多人一講AI Agent，就會將MCP當成萬能答案。
MCP當然重要。
佢提供咗標準化工具協議，令Agent可以調用文件系統、數據庫、瀏覽器、設計工具、企業系統。Playwright MCP都好適合嗰啲需要持續狀態、豐富頁面結構、反覆探索網頁嘅自動化場景。
但MCP有一個現實問題：
上下文成本。
MCP工具通常會向模型暴露工具schema、結構化返回、頁面資訊。對於複雜網頁，返回嘅可訪問性樹、DOM摘要、工具調用細節都可能好長。
如果Agent只係想做一個簡單動作：
• 打開頁面； • 撳一個掣； • 輸入一段文字； • 截圖； • 睇下console； • 保存trace；
咁每次都將大量結構塞入上下文，未必抵。
Playwright CLI嘅思路係：
唔好將瀏覽器搬入模型上下文，俾模型發命令就得。
比如：
playwright-cli open https://demo.playwright.dev/todomvc --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli screenshot呢啲命令好短。
Agent唔需要‘讀明成個網頁世界’，只需要喺必要時透過snapshot拎到可交互元素引用，然後用ref操作。
官方README入面都強調：CLI + Skills嘅方式可以避免將大型工具schema同冗長accessibility tree加載入模型上下文，從而更適合高吞吐嘅coding agents。
呢個先係Playwright CLI嘅核心價值：
佢唔係比MCP更萬能，而係喺大量工程場景入面，比MCP更輕。
四、佢真正解決嘅係AI編程入面嘅‘最後一公里’
今日嘅AI Coding Agent已經可以做好多嘢：
• 讀code； • 改code； • 寫test； • 跑命令； • 睇log； • 修error； • 開PR。
但佢哋成日卡喺一個地方：瀏覽器現場。
例如你叫Agent修一個frontend bug：
登錄之後撳設置頁，切換主題，再刷新頁面，掣嘅狀態唔啱。
純code視角下，Agent可能會估：係唔係狀態冇持久化？係唔係localStorage key錯咗？係唔係hydration出問題？
但人類開發者會點做？
打開瀏覽器，復現一次。
睇頁面有冇報錯。
睇Network請求有冇失敗。
睇localStorage有冇寫入。
截個圖，確認UI狀態。
必要時錄trace。
Playwright CLI啱啱好將呢啲動作變成Agent可以穩定調用嘅命令：
• open/goto：打開同跳轉；• click/fill/type/press：模擬用戶操作；• snapshot：獲取頁面狀態同元素ref；• screenshot/pdf：保存結果；• console：睇console訊息；• network：睇網絡請求；• state-save/state-load：保存登錄狀態；• route：mock網絡請求；• tracing-start/tracing-stop：錄製trace；• video-start/video-stop：錄屏；• generate-locator：生成Playwright locator。
呢個就令Agent由‘code編輯器入面嘅聰明助手’，向‘可以跑完整開發閉環嘅工程夥伴’行咗一步。
唔止係會改code，而係可以：
呢個就係AI編程真正有生產力嘅地方。
五、Session設計：令Agent唔使每次都從頭開始
Playwright CLI仲有一個好重要但容易被低估嘅設計：session。
README入面寫得好清楚：默認情況下，Playwright CLI會將瀏覽器profilesave喺內存入面。同一個session入面，cookies同storage state會喺CLI調用之間保留；如果使用 --persistent，仲可以持久化到磁碟。
亦即係話，Agent唔使每次操作都重新登錄、重新初始化。
例如：
playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com --persistent
playwright-cli list仲可以透過環境變量指定session：
PLAYWRIGHT_CLI_SESSION=todo-app claude .呢個對真實工程場景好重要。
因為大量問題唔係發生喺一個靜態頁面，而係發生喺一組連續狀態入面：
• 登錄後嘅狀態； • 多標籤頁狀態； • 表單填寫一半嘅狀態； • 某個用戶權限下嘅狀態； • 某次接口mock後嘅狀態； • 某個項目workspace對應嘅瀏覽器狀態。
Session令Agent可以似人類開發者咁‘跟住頭先嘅瀏覽器繼續做’，而唔係每次都似失憶咁重新開。
呢個都係CLI面向Agent嘅關鍵體驗。
六、show dashboard：人類重新返到監督位置
另一個好有趣嘅功能係：
playwright-cli show佢會打開一個可視化dashboard，俾你睇到所有正在運行嘅瀏覽器session。
根據README，呢個dashboard包含：
• session grid：展示活躍session、當前URL、頁面標題、實時預覽； • session detail：展示揀中session嘅實時視圖、標籤頁、導航控制； • 人類可以撳viewport接管滑鼠鍵盤； • 可以關閉session或者刪除inactive session嘅數據。
呢件事背後其實有一個好重要嘅產品判斷：
AI Agent唔應該係黑盒。
尤其係當Agent喺後台操作瀏覽器嘅時候，人類需要一種方式觀察、接管、糾偏。
呢個同好多自動化系統嘅方向一致：
• AI做重複操作； • 人類做監督同關鍵判斷； • 系統提供可觀測性； • 必要時容許人工介入。
如果冇 show 呢種能力，Agent自動化好容易變成‘佢好似喺度跑，但我唔知佢喺度做咩’。
有咗dashboard，開發者可以睇到Agent到底撳咗邊度、卡喺邊個頁面、係咪進入咗錯誤狀態。
呢個對團隊採用AI Agent好重要。
因為真正阻礙落地嘅，往往唔係工具能力，而係信任。
七、Playwright CLI + Skills：微軟喺度押注一種新交互方式
playwright-cli install --skills 呢一點尤其值得注意。
Skills嘅價值，唔係多一份文檔。
佢更加似係俾Agent嘅‘操作手冊’。
傳統文檔係寫俾人睇嘅：概念、教程、API、例子。
Skill係寫俾Agent用嘅：幾時調用咩命令，遇到某類任務應該點拆解，複雜能力如何按需加載。
第三方文章都提到一個關鍵詞：progressive disclosure，漸進披露。
意思係：唔好一次過將所有複雜資訊塞俾模型，而係俾Agent喺需要嗰陣先讀取具體操作指南。
呢個同Playwright CLI嘅token-efficient目標係一致嘅。
真正優秀嘅Agent工具，唔係暴力提供更多上下文，而係減少不必要嘅上下文。
因為模型上下文唔係垃圾桶。
上下文越滿，推理越容易被噪音幹擾，成本亦越高。
所以Playwright CLI + Skills嘅組合，本質上係喺度探索一種新嘅Agent工具形態：
命令短、狀態外置、指南按需、結果可驗證。
八、佢適合邊啲場景？
我認為Playwright CLI最適合以下幾類場景。
1. Frontend Bug復現
例如：某個掣撳咗冇反應、表單提交失敗、彈窗狀態異常、路由跳轉錯誤。
Agent可以直接打開頁面，跟住步驟復現，保存screenshot/console/network，再返轉頭改code。
2. Agent自測
開發者叫Agent改完code之後，唔止係跑單元測試，仲要打開頁面做一次真實路徑驗證。
例如：
修改登錄頁樣式之後，用playwright-cli打開本地頁面，驗證掣可以撳，截圖保存。
呢個比‘code睇落冇問題’更可靠。
3. 輕量E2E探索
喺未寫正式Playwright測試之前，Agent可以先透過CLI探索頁面流程，然後再沉澱成測試code。
配合 generate-locator，仲可以生成更穩定嘅locator。
4. 多Agent並行瀏覽器任務
session支持令唔同Agent用唔同瀏覽器實例。
例如一個Agent負責用戶A嘅路徑，另一個Agent負責管理員路徑，互相唔幹擾。
5. 帶人工監督嘅自動化
通過 playwright-cli show，人可以觀察Agent操作，必要時接管。
呢個特別適合早期團隊試用，唔使將瀏覽器完全交俾黑盒自動化。
九、但唔好神化佢：CLI唔係萬能鑰匙
要寫清楚少少：Playwright CLI唔係要取代所有嘢。
佢唔等於Playwright Test。
正式、穩定、可維護嘅自動化測試，仍然應該沉澱成測試code，進入CI，配合斷言、報告、trace、重試、並發策略。
佢都唔等於Playwright MCP。
如果你嘅場景需要長期、多輪、深度理解頁面結構，或者需要richer introspection，MCP仍然有價值。
CLI嘅優勢在於輕、快、慳、適合coding agent高頻調用。
MCP嘅優勢在於結構化、協議化、適合更複雜嘅工具生態。
所以最好嘅判斷唔係‘CLI同MCP邊個贏咗’。
而是：
• 高頻、明確、工程閉環入面嘅瀏覽器動作：優先CLI； • 複雜、長程、需要豐富頁面結構推理嘅Agent流程：考慮MCP； • 穩定回歸測試：沉澱到Playwright Test。
工具唔係宗教，場景先係答案。
十、真正嘅大趨勢：工具開始為Agent重新設計
Playwright CLI最值得關注嘅，唔止係佢本身。
而係佢代表嘅趨勢：
未來會有越來越多工具，唔再淨係面向人類開發者，而係同時面向AI Agent。
過去我哋設計CLI，係為咗令人打命令方便。
而我哋設計CLI，要考慮：
• Agent可唔可以低成本發現命令？ • 返回資訊可唔可以夠短？ • 狀態可唔可以外置？ • 失敗可唔可以診斷？ • 結果可唔可以被截圖、trace、日誌驗證？ • 人類可唔可以隨時觀察同接管？
呢個係一整套新嘅工程設計原則。
Playwright CLI啱啱好踩中咗呢個方向。
佢唔係炫技項目，而係一個好具體嘅工程答案：
當AI Agent開始接管越來越多開發流程嘅時候，瀏覽器自動化必須由‘俾人用嘅測試工具’，進化成‘俾Agent用嘅操作接口’。
結尾：AI編程嘅分水嶺，唔係識唔識寫code
好多人仲用‘可唔可以生成code’嚟判斷AI編程工具。
但呢個已經唔係最關鍵嘅問題喇。
真正嘅分水嶺係：
佢可唔可以完成閉環。
可唔可以理解需求。
可唔可以改code。
可唔可以跑起嚟。
可唔可以打開瀏覽器驗證。
可唔可以睇到錯誤。
可唔可以留低證據。
可唔可以自己修正。
Playwright CLI嘅意義，就喺呢度。
佢將瀏覽器呢件原本偏‘人類現場操作’嘅事，進一步壓縮成Agent可以調用嘅工程接口。
呢個會令AI Coding Agent由‘會寫code嘅助手’，更接近‘能交付結果嘅工程協作者’。
所以，如果你而家已經在用Claude Code、GitHub Copilot、Cursor、Windsurf，或者任何coding agent，不妨留意呢個項目。
唔係因為佢命令多。
而係因為佢透露咗一個非常明確嘅方向：
下一代開發工具，唔止係俾人用嘅。佢哋都會俾AI用。
而邊個可以令AI更慳上下文、更穩定咁操作真實世界，邊個就更接近下一代軟件工程嘅入口。
參考資料
• https://github.com/microsoft/playwright-cli • https://playwright.dev/docs/getting-started-cli • https://www.npmjs.com/package/@playwright/cli
如果說過去一年，AI 編程工具最大的變化，是模型終於能讀懂代碼、改動項目、跑測試。
那接下來更關鍵的一步，就是：AI 能不能像一個真正的開發者一樣，打開瀏覽器，點頁面，填表單，看報錯，截圖，復現問題，然後自己修掉。
這件事聽起來並不新。
Playwright 早就能自動化瀏覽器，Playwright MCP 也已經讓 AI Agent 可以通過 MCP 控制瀏覽器。很多人會問：既然已經有 MCP 了，為什麼微軟還要單獨做一個playwright-cli呢？
答案很簡單，也很現實：
AI Agent 不只是要“能操作瀏覽器”，還要在有限上下文裏，低成本、高頻率、可控地操作瀏覽器。
這就是 Playwright CLI 出現的真正意義。
它不是又一個給人類手敲命令的傳統 CLI。
它更像是微軟給 AI Coding Agent 準備的一雙“機械手”：不需要每次把整棵頁面結構、冗長工具 schema、大量可訪問性樹都塞進模型上下文，而是讓 Agent 通過簡短、明確、可組合的命令完成瀏覽器操作。
一句話：
MCP 讓 AI Agent 看見瀏覽器，Playwright CLI 讓 AI Agent 更便宜、更輕、更像工程師一樣使用瀏覽器。
總體使用的感覺也是相當哇塞！
一、為什麼這個項目值得看？
先看項目本身。
microsoft/playwright-cli 的定位很直接：
CLI for common Playwright actions. Record and generate Playwright code, inspect selectors and take screenshots.
官方 README 裏把它說得更明確：
Playwright CLI with SKILLS.
這句話很關鍵。
它不只是把 Playwright 的能力包了一層命令行，而是把 CLI 和 Skills 綁定在一起，面向 Claude Code、GitHub Copilot 等 coding agents 使用。
根據項目 README 和 Playwright 官方文檔，Playwright CLI 的核心賣點是：
• 命令行控制瀏覽器； • 面向 coding agents； • 支持安裝 skills； • 默認強調 token-efficient； • 能打開頁面、點擊、輸入、截圖、生成 locator、保存狀態、管理 session、查看網絡請求、錄製 trace/video； • 還能通過 playwright-cli show打開可視化 dashboard，觀察多個瀏覽器 session。
這意味着什麼？
意味着微軟已經不滿足於“AI 能調用瀏覽器工具”。
它在往更深的一層走：為 AI Agent 重新設計瀏覽器自動化接口。
二、舊 Playwright CLI、新 Playwright CLI，不是一回事
這裏很容易混淆。
很多開發者一聽 Playwright CLI，會下意識想到：
npx playwright test
npx playwright codegen
npx playwright install這些當然也是 Playwright 的命令行能力，但它們主要是給人類開發者使用的：跑測試、生成測試、安裝瀏覽器。
而新的 @playwright/cli，從項目表述看，目標對象變了。
它不是傳統意義上的“測試運行器”，而是一個面向 AI Agent 的瀏覽器控制接口。
安裝方式也很清楚：
npm install -g @playwright/cli@latest
playwright-cli --help然後可以安裝 skills：
C:\Users\Administrator\playwright-cli install --skills如果你在OpenClaw中使用，則進入.openclaw\workspace\skills目錄，複製上述文件夾並粘貼至此目錄。如果使用codex、cursor或Trae，可採用類似處理。
使用示例
輸出結果
如果不裝 skills，也可以直接讓 Agent 自己讀 help：
Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.這就是設計上的變化：
過去的 CLI，是人看文檔，人敲命令。
現在的 CLI，是 Agent 看 help / skill，Agent 決定下一步怎麼操作。
工具的使用者，從人，變成了 AI。
這不是小修小補，而是開發工具範式的變化。
三、CLI 相比 MCP，關鍵不是“誰更高級”，而是誰更省
現在很多人一談 AI Agent，就會把 MCP 當成萬能答案。
MCP 當然重要。
它提供了標準化工具協議，讓 Agent 能調用文件系統、數據庫、瀏覽器、設計工具、企業系統。Playwright MCP 也非常適合那種需要持續狀態、豐富頁面結構、反覆探索網頁的自動化場景。
但 MCP 有一個現實問題：
上下文成本。
MCP 工具通常會向模型暴露工具 schema、結構化返回、頁面信息。對於複雜網頁，返回的可訪問性樹、DOM 摘要、工具調用細節都可能很長。
如果 Agent 只是想做一個簡單動作：
• 打開頁面； • 點一個按鈕； • 輸入一段文字； • 截圖； • 看一下 console； • 保存 trace；
那每次都把大量結構塞進上下文，未必划算。
Playwright CLI 的思路是：
別把瀏覽器搬進模型上下文，讓模型發命令就行。
比如：
playwright-cli open https://demo.playwright.dev/todomvc --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli screenshot這些命令非常短。
Agent 不需要“讀懂整個網頁世界”，只需要在必要時通過 snapshot 獲取可交互元素引用，然後用 ref 操作。
官方 README 裏也強調：CLI + Skills 的方式可以避免把大型工具 schema 和冗長 accessibility tree 加載進模型上下文，從而更適合高吞吐的 coding agents。
這才是 Playwright CLI 的核心價值：
它不是比 MCP 更萬能，而是在大量工程場景裏，比 MCP 更輕。
四、它真正解決的是 AI 編程裏的“最後一公里”
今天的 AI Coding Agent 已經能做很多事：
• 讀代碼； • 改代碼； • 寫測試； • 跑命令； • 看日誌； • 修報錯； • 開 PR。
但它們經常卡在一個地方：瀏覽器現場。
比如你讓 Agent 修一個前端 bug：
登錄後點擊設置頁，切換主題，再刷新頁面，按鈕狀態不對。
純代碼視角下，Agent 可能會猜：是不是狀態沒持久化？是不是 localStorage key 錯了？是不是 hydration 出問題？
但人類開發者會怎麼做？
打開瀏覽器，復現一遍。
看頁面有沒有報錯。
看 Network 請求有沒有失敗。
看 localStorage 有沒有寫入。
截個圖，確認 UI 狀態。
必要時錄 trace。
Playwright CLI 正好把這些動作變成 Agent 可以穩定調用的命令：
• open/goto：打開和跳轉；• click/fill/type/press：模擬用戶操作；• snapshot：獲取頁面狀態和元素 ref；• screenshot/pdf：保存結果；• console：查看控制枱消息；• network：查看網絡請求；• state-save/state-load：保存登錄態；• route：mock 網絡請求；• tracing-start/tracing-stop：錄製 trace；• video-start/video-stop：錄屏；• generate-locator：生成 Playwright locator。
這就讓 Agent 從“代碼編輯器裏的聰明助手”，往“能跑完整開發閉環的工程夥伴”邁了一步。
不是隻會改代碼，而是能：
這就是 AI 編程真正有生產力的地方。
五、Session 設計：讓 Agent 不再每次從零開始
Playwright CLI 還有一個很重要但容易被低估的設計：session。
README 裏寫得很清楚：默認情況下，Playwright CLI 會把瀏覽器 profile 保存在內存中。同一個 session 內，cookies 和 storage state 會在 CLI 調用之間保留；如果使用 --persistent，還能持久化到磁盤。
也就是說，Agent 不需要每次操作都重新登錄、重新初始化。
例如：
playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com --persistent
playwright-cli list還可以通過環境變量指定 session：
PLAYWRIGHT_CLI_SESSION=todo-app claude .這對真實工程場景很重要。
因為大量問題不是發生在一個靜態頁面，而是發生在一組連續狀態裏：
• 登錄後的狀態； • 多標籤頁狀態； • 表單填寫一半的狀態； • 某個用戶權限下的狀態； • 某次接口 mock 後的狀態； • 某個項目 workspace 對應的瀏覽器狀態。
Session 讓 Agent 可以像人類開發者一樣“接着剛才的瀏覽器繼續做”，而不是每次都像失憶一樣重開。
這也是 CLI 面向 Agent 的關鍵體驗。
六、show dashboard：人類重新回到監督位
另一個很有意思的功能是：
playwright-cli show它會打開一個可視化 dashboard，讓你看到所有正在運行的瀏覽器 session。
根據 README，這個 dashboard 包含：
• session grid：展示活躍 session、當前 URL、頁面標題、實時預覽； • session detail：展示選中 session 的實時視圖、標籤頁、導航控制； • 人類可以點擊 viewport 接管鼠標鍵盤； • 可以關閉 session 或刪除 inactive session 的數據。
這件事背後其實有一個很重要的產品判斷：
AI Agent 不應該是黑盒。
尤其當 Agent 在後台操作瀏覽器時，人類需要一種方式觀察、接管、糾偏。
這和很多自動化系統的方向一致：
• AI 做重複操作； • 人類做監督和關鍵判斷； • 系統提供可觀測性； • 必要時允許人工介入。
如果沒有 show 這種能力，Agent 自動化很容易變成“它好像在跑，但我不知道它在幹嘛”。
有了 dashboard，開發者可以看到 Agent 到底點了哪裏、卡在哪個頁面、是否進入了錯誤狀態。
這對團隊採用 AI Agent 非常重要。
因為真正阻礙落地的，往往不是工具能力，而是信任。
七、Playwright CLI + Skills：微軟在押注一種新交互方式
playwright-cli install --skills 這一點尤其值得注意。
Skills 的價值，不是多一份文檔。
它更像是給 Agent 的“操作手冊”。
傳統文檔是寫給人看的：概念、教程、API、示例。
Skill 是寫給 Agent 用的：什麼時候調用什麼命令，遇到某類任務該怎麼拆解，複雜能力如何按需加載。
第三方文章也提到一個關鍵詞：progressive disclosure，漸進披露。
意思是：不要一次性把所有複雜信息都塞給模型，而是讓 Agent 在需要時再讀取具體操作指南。
這和 Playwright CLI 的 token-efficient 目標是一致的。
真正優秀的 Agent 工具，不是暴力提供更多上下文，而是減少不必要上下文。
因為模型上下文不是垃圾桶。
上下文越滿，推理越容易被噪音干擾，成本也越高。
所以 Playwright CLI + Skills 的組合，本質上是在探索一種新的 Agent 工具形態：
命令短、狀態外置、指南按需、結果可驗證。
八、它適合哪些場景？
我認為 Playwright CLI 最適合以下幾類場景。
1. 前端 Bug 復現
比如：某個按鈕點了沒反應、表單提交失敗、彈窗狀態異常、路由跳轉錯誤。
Agent 可以直接打開頁面，按步驟復現，保存 screenshot / console / network，再回頭改代碼。
2. Agent 自測
開發者讓 Agent 改完代碼後，不只是跑單元測試，還要打開頁面做一次真實路徑驗證。
例如：
修改登錄頁樣式後，用 playwright-cli 打開本地頁面，驗證按鈕可點擊，截圖保存。
這比“代碼看起來沒問題”更可靠。
3. 輕量 E2E 探索
在還沒寫正式 Playwright 測試前，Agent 可以先通過 CLI 探索頁面流程，然後再沉澱成測試代碼。
配合 generate-locator，還能生成更穩定的 locator。
4. 多 Agent 並行瀏覽器任務
session 支持讓不同 Agent 使用不同瀏覽器實例。
比如一個 Agent 負責用戶 A 的路徑，另一個 Agent 負責管理員路徑，互不干擾。
5. 帶人工監督的自動化
通過 playwright-cli show，人可以觀察 Agent 操作，必要時接管。
這特別適合早期團隊試用，不必把瀏覽器完全交給黑盒自動化。
九、但別神化它：CLI 不是萬能鑰匙
要寫清楚一點：Playwright CLI 不是要取代所有東西。
它不等於 Playwright Test。
正式、穩定、可維護的自動化測試，仍然應該沉澱成測試代碼，進入 CI，配合斷言、報告、trace、重試、併發策略。
它也不等於 Playwright MCP。
如果你的場景需要長期、多輪、深度理解頁面結構，或者需要 richer introspection，MCP 仍然有價值。
CLI 的優勢在於輕、快、省、適合 coding agent 高頻調用。
MCP 的優勢在於結構化、協議化、適合更復雜的工具生態。
所以最好的判斷不是“CLI 和 MCP 誰贏了”。
而是：
• 高頻、明確、工程閉環裏的瀏覽器動作：優先 CLI； • 複雜、長程、需要豐富頁面結構推理的 Agent 流程：考慮 MCP； • 穩定迴歸測試：沉澱到 Playwright Test。
工具不是宗教，場景才是答案。
十、真正的大趨勢：工具開始為 Agent 重新設計
Playwright CLI 最值得關注的，不只是它本身。
而是它代表的趨勢：
未來會有越來越多工具，不再只面向人類開發者，而是同時面向 AI Agent。
過去我們設計 CLI，是為了讓人敲起來方便。
現在我們設計 CLI，要考慮：
• Agent 能不能低成本發現命令？ • 返回信息能不能足夠短？ • 狀態能不能外置？ • 失敗能不能可診斷？ • 結果能不能被截圖、trace、日誌驗證？ • 人類能不能隨時觀察和接管？
這是一整套新的工程設計原則。
Playwright CLI 正好踩中了這個方向。
它不是炫技項目，而是一個很具體的工程答案：
當 AI Agent 開始接管越來越多開發流程時，瀏覽器自動化必須從“給人用的測試工具”，進化成“給 Agent 用的操作接口”。
結尾：AI 編程的分水嶺，不是會不會寫代碼
很多人還在用“能不能生成代碼”判斷 AI 編程工具。
但這已經不是最關鍵的問題了。
真正的分水嶺是：
它能不能完成閉環。
能不能理解需求。
能不能改代碼。
能不能跑起來。
能不能打開瀏覽器驗證。
能不能看到錯誤。
能不能留下證據。
能不能自己修正。
Playwright CLI 的意義，就在這裏。
它把瀏覽器這件原本偏“人類現場操作”的事情，進一步壓縮成 Agent 可以調用的工程接口。
這會讓 AI Coding Agent 從“會寫代碼的助手”，更接近“能交付結果的工程協作者”。
所以，如果你現在已經在用 Claude Code、GitHub Copilot、Cursor、Windsurf，或者任何 coding agent，不妨留意這個項目。
不是因為它命令很多。
而是因為它透露了一個非常明確的方向：
下一代開發工具，不只是給人用的。它們也會給 AI 用。
而誰能讓 AI 更省上下文、更穩定地操作真實世界，誰就更接近下一代軟件工程的入口。
參考資料
• https://github.com/microsoft/playwright-cli • https://playwright.dev/docs/getting-started-cli • https://www.npmjs.com/package/@playwright/cli