AI-Chain
MCP Chrome Puppeteer 瀏覽器自動化 開發工具 開源

Chrome DevTools MCP：讓 AI coding agent 直接進入瀏覽器除錯迴圈

Chrome DevTools MCP 將 live Chrome 的操作、Console、network、效能與記憶體分析能力接到 MCP，讓 AI coding agent 能在程式碼與瀏覽器狀態之間建立可驗證的除錯迴圈。本文拆解工具架構、導入方式與安全邊界。

分享:
Chrome DevTools MCP：讓 AI coding agent 直接進入瀏覽器除錯迴圈

Chrome DevTools MCP：讓 AI coding agent 直接進入瀏覽器除錯迴圈

當 AI coding agent 只能讀取程式碼與執行測試時，它仍然看不到「真正跑起來的瀏覽器」：畫面是否破版、網路請求是否失敗、Console 是否出現 source map 還原後的錯誤，以及效能瓶頸究竟發生在哪一段，都需要人手動切換到 Chrome DevTools。Chrome DevTools MCP 把這個觀察與操作層接到 MCP，讓 agent 能在同一個工作流程裡操作並檢查 live Chrome。

本文不把它描述成全自動 QA，而是從實作角度拆解它提供的能力、適合的使用情境，以及導入時必須先處理的權限與資料外洩風險。

先看查證結果

截至 2026 年 8 月 30 日，GitHub API 顯示 ChromeDevTools/chrome-devtools-mcp 有 50,157 顆 stars、3,518 個 forks，最近一次 push 是 2026 年 8 月 28 日，採用 Apache-2.0 授權，主要語言是 TypeScript。GitHub repository description 是「Chrome DevTools for coding agents」。

目前 repository 的 package.json 版本為 1.8.0。CHANGELOG 顯示 1.8.0 於 2026 年 8 月 25 日發布，包含 PWA automation、heap snapshot 查詢、Console stack trace、multiple-file upload，以及 page-scoped tool 的 pageId 強制要求等變更。

以上數字與版本會隨 repository 更新；實際部署前仍應以 GitHub repository、package registry 與 changelog 的最新內容為準。

Chrome DevTools MCP 到底是什麼

它是一個以 TypeScript 實作的 MCP server，讓支援 MCP 的 coding agent 連接到 Chrome 或 Chrome for Testing。README 將能力分成三條主線：以 Chrome DevTools 取得效能洞察、進行瀏覽器除錯，以及使用 Puppeteer 執行可靠的瀏覽器操作。

除了 MCP server，專案也提供 CLI。因此它不只適合「讓 agent 呼叫工具」，也可以在沒有 MCP client 的情況下，以命令列方式啟動與操作相關功能。

這個設計的重點不是替瀏覽器包一層單一魔法指令，而是把 DevTools 能力拆成 agent 可以組合的工具。例如先列出頁面，再選定 page，接著取得 snapshot、點擊元素、讀取 Console，最後啟動 trace 並分析效能洞察。

工具面：從操作頁面到分析記憶體

官方 tool reference 目前列出 11 個工具群組、共 57 個工具：

  • Input automation：10 個，用於 click、drag、fill、form、dialog、hover、key press 與 file upload。
  • Navigation automation：6 個，用於列出、建立、選擇、等待與關閉頁面。
  • Emulation：2 個，用於模擬裝置與調整 viewport。
  • Performance：3 個，用於啟動與停止 trace，以及分析效能洞察。
  • Network：2 個，用於列出與取得 network request。
  • Debugging：8 個，用於 evaluate script、Console、Lighthouse、snapshot、screenshot 與 screencast。
  • Memory：13 個，涵蓋 heap snapshot、retainers、dominators、edges、object details 與物件查詢。
  • Extensions：5 個，用於安裝、列出、重新載入、觸發與移除 extension。
  • Third-party：2 個，用於列出與執行第三方 developer tools。
  • WebMCP：2 個，用於列出與執行網頁提供的 WebMCP tools。
  • Progressive Web Apps：4 個，用於 PWA 安裝、啟動、移除與 OS app state。

這種廣度帶來一個實務上的好處：agent 不必把「看畫面」「查請求」「讀錯誤」「跑效能分析」拼成互不相干的外部腳本，而能在同一個瀏覽器 session 中串接上下文。

一個可重現的最小設定

README 提供的基本 MCP client 設定如下。示範使用固定版本，避免 latest 在不同時間解析到不同結果；若團隊有自己的升級流程，再把版本更新納入變更管理。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@1.8.0"]
    }
  }
}

若只需要基本瀏覽器任務，可以啟用 slim mode 與 headless：

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@1.8.0", "--slim", "--headless"]
    }
  }
}

專案要求 Node.js LTS、目前穩定版 Chrome 或更新版本，以及 npm。支援範圍以 Google Chrome 和 Chrome for Testing 為主，其他 Chromium-based browser 可能可以運作，但不在官方保證範圍內。

從頁面 snapshot 開始，而不是猜 selector

對 coding agent 而言，最重要的不是「能不能模擬滑鼠」，而是它能不能先取得足夠的頁面語意，再用穩定的識別資訊執行操作。工具 reference 中的 click 與 fill 都要求使用來自 page content snapshot 的 uid；這比讓模型自行猜 CSS selector 更容易形成可檢查、可重試的流程。

一個合理的 agent workflow 可以是：

  1. 使用 list_pages 確認目前有哪些頁面。
  2. 使用 select_page 選定工作頁面。
  3. 取得 page snapshot，找出表單或按鈕的 uid。
  4. 優先以 fill_form 一次填入多個欄位；官方 reference 明確建議表單操作優先使用它。
  5. 操作後使用 wait_for，再讀取 snapshot、Console 或 network 結果。
  6. 若發生錯誤，再以 get_console_message、get_network_request 或 evaluate_script 深入定位。

這裡的關鍵是每一步都有可觀測輸出，agent 可以根據新狀態修正下一個動作，而不是把整段 UI 流程塞進不可解釋的 macro。

效能分析不是只截一張 Lighthouse 分數

Chrome DevTools MCP 提供 performance_start_trace、performance_stop_trace 與 performance_analyze_insight。這讓 agent 可以把效能工作拆成「收集 trace」「結束 trace」「針對洞察分析」三個階段。

這種拆分符合專案的 token-optimized design principle：大量 trace、screenshot 或 video 等重資源不應直接全部塞進模型上下文，而應以檔案路徑或 resource URI 作為參照；模型先讀摘要，再決定要不要深入取用資料。

因此，一個適合 CI 或本機開發的提示流程可以要求 agent 回報：

  • 哪一個頁面與哪一種 viewport 被分析。
  • trace 的時間範圍與是否包含互動。
  • 影響 LCP、INP 或其他洞察的主要原因。
  • 建議修改的程式位置與修改後的驗證方式。

這比單純回報「分數變高」更容易和程式碼變更建立因果關係。

Debugging 與 Memory 是它和一般 browser automation 的差異

傳統 browser automation 通常擅長導覽、點擊、填表與截圖，但 Chrome DevTools MCP 進一步暴露 Console、network、Lighthouse 與 heap snapshot 能力。對前端與全端專案，這代表 agent 不必只從畫面猜測問題。

例如，當使用者回報「登入後頁面空白」時，agent 可以依序檢查：是否真的導覽到正確頁面、Console 是否有 source-mapped stack trace、API request 是否回傳錯誤、頁面是否因 JavaScript exception 停止渲染。若問題是長時間運作後的記憶體成長，1.5.0 到 1.8.0 的 changelog 也顯示專案持續增加 heap snapshot comparison、duplicate strings、object details 與 query 等分析能力。

這些工具仍然不會自動替你定義「正確行為」。它們提供的是更接近瀏覽器內部狀態的證據，測試斷言、業務規則與修復決策仍需要團隊自己建立。

可靠性來自限制與錯誤設計

專案的 design principles 提出幾項值得注意的工程取向：採用 agent-agnostic 的 MCP 標準、回傳 token-optimized 的語意摘要、提供小而可組合的 deterministic blocks、回傳含有上下文與修復方向的 self-healing errors，以及讓輸出同時適合機器與人類閱讀。

這些原則在近期 changelog 也有對應實作。例如 1.8.0 讓 page-scoped tools 預設要求 pageId，修正 page 選擇與 browser reconnect 的識別問題，並改善 CLI 錯誤訊息。這類變更看似不是新功能，卻直接影響 agent 在多分頁、重連與失敗重試時是否會操作錯目標。

導入時應把錯誤輸出當成 API 的一部分來測試，而不是只測「成功路徑」。至少要驗證：頁面關閉後的行為、Chrome 重連後 page id 是否仍可辨識、dialog 開啟時等待是否會卡住、遠端 browser 與本機檔案路徑的邊界，以及多次執行同一操作是否會造成不一致狀態。

安全與隱私：先限制瀏覽器，再交給 agent

README 明確警告，MCP client 可以取得 browser instance 的內容，並可能檢查、除錯或修改瀏覽器中的資料與 DevTools 資料。因此，不應把含有個人資料、session cookie、內部系統或敏感 token 的日常瀏覽器直接交給 agent。

另外，README 說明 usage statistics 預設開啟，收集例如 tool invocation success rate、latency 與 environment information；可以在啟動時加入 --no-usage-statistics，或設定 CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS。效能工具也可能將 trace URL 傳給 Google CrUX API 取得 real-user experience data；若不需要，可以使用 --no-performance-crux。

一個較安全的部署基線是：

npx -y chrome-devtools-mcp@1.8.0 --headless --no-usage-statistics --no-performance-crux

再搭配專用的 Chrome profile、最小化的測試資料、隔離的網路環境與明確的檔案路徑權限。--headless 不等於安全隔離；它只改變是否顯示視窗，不能取代權限設計。

適合與不適合的使用情境

適合的情境包括：

  • 前端 PR 的互動式 smoke test，讓 agent 實際走過登入、表單與主要路徑。
  • 需要同時比對畫面、Console 與 network 的 bug reproduction。
  • 針對 Core Web Vitals 或載入瓶頸建立可重複的 trace 分析流程。
  • 開發 PWA、browser extension 或 WebMCP integration 時，讓 agent 使用對應的 DevTools 能力。
  • 在本機開發環境中，將「修程式碼 → 開瀏覽器 → 讀錯誤 → 再修正」串成短迴圈。

不適合直接當成萬能替代品的情境包括：需要完整跨瀏覽器矩陣的相容性測試、需要強隔離的高敏感資料操作、需要長時間大規模平行執行的測試平台，以及沒有明確測試資料與斷言的探索性操作。Chrome DevTools MCP 是 browser debugging and automation 的工具層，不是完整的 test management、secret management 或 cross-browser farm。

導入建議：先做一條可驗證的除錯迴圈

不要一開始就啟用全部 57 個工具。先選一條最常發生、又能量化結果的流程，例如：開啟 staging 首頁、填寫一個測試表單、確認 API request、檢查 Console、截取畫面並輸出失敗原因。

接著為 agent 設定幾個硬性規則：只使用專用測試帳號、只能連線到 allowlist 網域、所有修改動作前先描述目標、輸出中不得包含 cookie 或 authorization header、每次失敗都要保留 page URL 與錯誤上下文。等這條流程穩定後，再加入 trace、heap snapshot、extension 或 PWA 工具。

最後，把版本固定、啟動參數、Chrome 版本與測試資料版本一起記錄。Chrome DevTools MCP 更新頻繁，固定依賴版本能讓問題重現更可靠；升級時則應閱讀 changelog，特別留意 page routing、telemetry、檔案路徑與 browser lifecycle 相關變更。

結語

Chrome DevTools MCP 的價值不只是「讓 AI 可以控制 Chrome」，而是把瀏覽器的操作、觀測、除錯與效能資料放進同一個 MCP workflow。它最適合用在需要快速往返於程式碼與 live browser state 的工程場景。

真正值得採用的判準也很清楚：如果它能讓團隊更快取得可驗證的錯誤證據、減少手動切換工具的成本，並且能在專用環境中控制資料暴露範圍，就值得建立一條小而可靠的導入路徑；如果只是把未定義的瀏覽器權限交給 agent，則工具越多，風險也會一起放大。

查證來源

  • GitHub repository：https://github.com/ChromeDevTools/chrome-devtools-mcp
  • README：https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/README.md
  • Tool reference：https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/tool-reference.md
  • Design principles：https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/design-principles.md
  • Changelog：https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/CHANGELOG.md
  • package.json：https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/package.json