字數總計：0 個 | 閱讀時長：0 分鐘 |閱讀次數： 次

什麼是 MCP？

MCP（Model Context Protocol）是一種讓 AI Agent 接外部工具的標準介面。

簡單來說，Claude Code 原本沒有某些能力——例如操作瀏覽器、查詢資料庫、打 API 測試、連接雲端服務。MCP 就是一套標準化的協定，讓 Claude 可以「安全、有序、可管控」地呼叫這些外部工具。

Claude Code 加 MCP 前後能力對比

原本 Claude Code 可能做不到加 MCP 後可以做到
直接操作瀏覽器可以用 Playwright 控制瀏覽器
連資料庫查資料可以透過 DB MCP Server 查資料
打 API 測試可以透過 API 工具做測試
操作雲端服務可以透過雲端 MCP Server 串接
做 UI 自動化測試可以用 Playwright MCP

核心價值：MCP 不是「又一個 API wrapper」——它是第一個為 Agent 設計的標準化協定，涵蓋 discovery、auth、context、雙向通訊，打破了不同廠商之間「各自為政」的狀態。

From Chat to MCP：AI Agent 的演進

From Chat to MCP 時間軸

MCP 的出現不是憑空而生，而是 AI 能力進化的必然結果。看看時間軸就一目了然：

里程碑時間特點限制
Chat2022.11純文字對話，ChatGPT 問世只能說，不能做
Function Calling2023.6LLM 輸出結構化指令，OpenAI 率先推出能動手了，但各家不同標準
Agent2024自主推理 + 多步驟串接，AutoGPT、LangChain 爆發LLM ↔ Tool 的橋接，每個專案各自解決
MCP2024.11標準化 Agent ↔ Tool 協議，Anthropic 開源統一標準，AI 的 USB-C

關鍵演進：從「只會說」→「能動手」→「有多步驟」→「有標準介面」。前三個階段都在解決「能做什麼」，MCP 第一次真正解決「安全有序地做」。

Agent 的三層架構：MCP 落在哪一層？

Agent 三層架構：Reasoning、Orchestration、Execution

要理解 MCP 的位置，必須認識 Agent 系統的三層分工。同一個 Agent 任務，每層各司其職——搞清楚層次，才能選對工具。

層級角色職責內容工具示例
Reasoning Layer大腦決定「要做什麼」LLM 理解語意、規劃步驟、判斷工具Claude / GPT / Gemini、System Prompt、Context Window
Orchestration Layer記憶定義「怎麼做」預設工作流程、multi-step 模板、程序記憶MCP Prompt Primitive、Agent Skills、Workflow Templates
Execution Layer手腳實際「做動作」觸碰真實系統：資料庫、API、檔案系統MCP Tools (governed)、CLI Commands (efficient)、Direct API Calls

為什麼要分三層？

  • Reasoning Layer：天生隨機，這是 feature，不是 bug。LLM 的推理能力、創意、靈活應變都來自於這層的「不確定性」
  • Orchestration Layer：標準化常用路徑，減少 token 浪費，加速工作流程
  • Execution Layer：MCP 在這層提供治理與安全，讓外部工具呼叫變成「安全的、可控的、可稽核的」

MCP 在 Execution Layer，但影響三層：MCP 本身提供工具描述、權限邊界與可控的工具介面，所以它不只是執行層的工具，也是治理的中樞。

CLI vs MCP：根本差異

CLI 與 MCP 的根本差異

「Agent 也會叫 CLI——但 MCP 讓 Agent 知道有哪些工具、怎麼用、能拿到哪些資料。」這是 MCP 相比傳統 CLI 最重要的區別。

比較項目CLI（Agent 叫命令去「做事」）MCP（讓 Agent 知道「有什麼」）
執行模型Agent 擬制指令 → 執行 CLI 讀 stdout 字串Agent 直接呼叫 → 圍繞、結構化呼叫 API
Discovery❌ 沒有，Agent 需事先知道有什麼指令✅ 自動，Server 啟動時主動告知所有 Tool schema
回應格式非結構化文字（stdout / stderr）結構化 JSON、type、metadata
認證授權依賴 shell 環境、原作者本地機制OAuth 2.1 + Identity Propagation 標準化
雙向通訊不友善，CLI 不太回應給 Agent✅ 支援，Server 可反向 Sampling / Elicitation

關鍵差異解釋

Discovery 的重要性：

  • CLI 時代，Agent 只能「猜」有哪些命令，或者靠開發者提前告訴它
  • MCP 時代，Server 啟動時直接宣告「我有這些工具、這些參數、這些返回類型」，Agent 可以自動「發現」能力邊界

Structured Context 的重要性：

  • CLI 回傳純文字，Agent 要靠自然語言推理「結果是什麼」
  • MCP 回傳結構化 JSON，Agent 直接讀取 type、metadata，有效減少誤解

Playwright MCP Server：瀏覽器自動化變成 AI 的眼睛

什麼是 Playwright？

Playwright 本來是一套常見的「瀏覽器自動化測試工具」，用於做 UI 自動化測試、爬蟲、截圖等任務。

當 Playwright 接到 Claude Code（透過 MCP），Claude 就可以做這些事：

  1. 打開瀏覽器，前往任意 URL（例如 localhost:3000）
  2. 點擊按鈕、輸入文字、瀏覽頁面
  3. 看實時畫面長什麼樣子
  4. 檢查 UI 元素、驗證邏輯是否正常
  5. 根據實際畫面結果回頭修改程式碼

白話講：Claude 不再只是「猜你的 UI 會長怎樣」，而是可以「真的打開來看」。

為什麼 Playwright MCP 很重要？

開發迴圈變短了。傳統流程是「寫程式碼 → 自己開瀏覽器看 → 反饋給 Claude → 再改」，現在 Claude 可以自己完整走過一遍，甚至自動驗證效果。

安裝與權限設定

安裝指令拆解

在你的終端機（Terminal）執行以下指令——注意：不是在 Claude Code 對話框裡輸入：

claude mcp add playwright npx @playwright/mcp@latest

這條指令做了兩件事：

區塊意思
claude mcp add告訴 Claude Code：我要新增一個 MCP Server
playwright為這個 MCP Server 命名為 playwright（後續用來識別）
npx @playwright/mcp@latest在你本機啟動這個 Server 的指令

⚠️ 注意：這條指令是在 OS 終端機執行，目的是把 Server 註冊到 Claude Code，而不是在對話內呼叫工具。

首次使用：權限提示

當你第一次叫 Claude 使用 Playwright MCP 工具時，Claude 會跳出權限提示（每次操作都會問一次）：

是否允許 Claude 使用這個工具？

因為這些工具會操作瀏覽器、讀取頁面、執行動作，涉及實際系統行為，需要明確同意。

預先核准：避免每次都被問

如果你不想每次都被問，可以預先核准整個 MCP Server，做法是編輯 .claude/settings.local.json：

{
  "permissions": {
    "allow": ["mcp__playwright"],
    "deny": []
  }
}

加進 allow 陣列後，Claude 使用 Playwright 的所有工具就不會再跳提示。

「兩個底線」很重要

mcp__playwright 中間是 兩個底線（double underscores），不是一個：

  • ✅ 正確：mcp__playwright
  • ❌ 錯誤：mcp_playwright（一個底線會吃不到權限規則）

命名約定：

  • mcp = 這個工具來自 MCP Server
  • __ = MCP 命名空間分隔符
  • playwright = Server 名稱（對應 claude mcp add 時取的名字）

Playwright MCP 工作流程

Playwright MCP 工作流程

一個典型的 Claude + Playwright 開發迴圈看起來像這樣：

1. Claude 打開 localhost:3000（你的 Web App）
   ↓
2. 操作你的 Web App（點按鈕、輸入文字、滾頁面）
   ↓
3. 產生一個新的 React 元件或修改現有元件
   ↓
4. 用 Playwright 瀏覽器觀察實際畫面效果
   ↓
5. 判斷「效果是否滿足需求」或「UI 是否夠好看」
   ↓
6. 如果不滿意，修改 generation.tsx 裡的 Prompt 或邏輯
   ↓
7. 再次產生元件，回到第 4 步驗證效果
   ↓
8. 迴圈直到滿意為止

這樣的 feedback loop 比傳統開發快得多——不需要人工介入確認，Claude 可以自動迭代。

實戰範例：用 Playwright MCP 改善「元件生成 Prompt」

這是一個實務上很常見的場景。傳統做法是：你寫一個 Prompt 讓 Claude 產生 React 元件，產出來覺得不夠好，再手動回去調整 Prompt，反覆來回好幾輪。

加上 Playwright MCP 後，整個流程可以這樣自動化：

  1. Claude 打開瀏覽器進到你的應用
  2. 產生一個測試元件
  3. 觀察視覺風格與程式品質
  4. 根據觀察結果更新生成 Prompt
  5. 用新 Prompt 再產一個元件，驗證改進效果

舉例你可以這樣對 Claude 說：

Navigate to localhost:3000, generate a basic component, review the styling, and update the generation prompt at @src/lib/prompts/generation.tsx to produce better components going forward.

Claude 會用 Playwright 工具操作你的應用、檢視產出的元件、然後直接修改你的 Prompt 檔案，引導未來生成更原創、有設計感的版本。

實際成果差異

關鍵優勢是：Claude 看得到實際視覺輸出，不只是程式碼。所以它能做出有畫面感的判斷，而不是猜的。

實務上這種做法常見的改進方向例如：

改進前（常見「無聊」風格）改進後（Claude 觀察後的調整建議）
千篇一律的紫到藍漸層暖色夕陽漸層（橘 → 粉 → 紫）
標準 Tailwind 配色海洋深度主題（teal → emerald → cyan）
對稱、規矩的排版非對稱設計、元素重疊
一致的間距創意性的留白與非傳統佈局

💡 重點：這類改進不是 Claude 「想出來」的，而是它看到現在的 UI 太普通、再回頭調 Prompt——這是文字 AI 做不到的事。

探索其他 MCP Servers

Playwright 只是 MCP 生態裡的一個例子。隨著 Anthropic 開源 MCP 後，整個生態已經涵蓋很多面向：

類別用途適用場景
Database 互動連 PostgreSQL、MySQL、SQLite 查資料讓 Claude 直接讀資料、查 schema、跑分析
API 測試與監控Postman 風格的 API 呼叫、回應檢視開發 / 整合測試自動化
檔案系統操作跨目錄讀寫、批次重命名、結構整理專案重構、自動化整理
雲端服務整合AWS、GCP、Azure 等控制平面DevOps、Infra 自動化
開發工具自動化GitHub、GitLab、Jira、Linear、SlackPR 管理、issue 追蹤、團隊協作

挑選 MCP Server 時，建議從你日常工具鏈中最花時間的部分開始，例如：

  • 每天都要跑 SQL 查報表 → 安裝 DB MCP
  • 常常需要在 Slack 查訊息再回到程式碼 → Slack MCP
  • PR review 流程冗長 → GitHub MCP

裝上對的 MCP Server，Claude 就會從「程式助手」進化成「能操作整個工具鏈的開發夥伴」。

小結

MCP 的核心價值

  1. 統一標準：AI 的 USB-C，打破廠商之間的「各自為政」
  2. 安全有序：透過 discovery、auth、權限治理，讓 Agent 呼叫外部工具變成可控的
  3. 減少浪費：Orchestration Layer 預先規範常用路徑，減少推理浪費 token
  4. 雙向通訊：不只 Agent → Tool，Tool 也能反向給 Agent 反饋

Playwright MCP 的意義

Playwright MCP 是 MCP 生態中最直觀的例子——它讓 Claude 從「文本型 AI」進化成「能看、能做、能驗證」的 Agent，開發迴圈變成了「自動化 feedback loop」。Claude 看得到實際視覺輸出，所以能做出有畫面感的判斷，而不只是猜程式碼會長怎樣。

從「程式助手」到「開發夥伴」

裝上不同的 MCP Server，Claude 就能直接跨足你的整個工具鏈——資料庫、API、雲端、CI/CD、團隊協作。挑你日常最耗時的環節先導入，效果最明顯。

展望

MCP 剛開始，已經有企業推出 Notion MCP、Google Workspace MCP、Slack MCP 等。未來幾年，MCP 會成為 AI 能力擴展的標準基礎設施，就像 HTTP 對網際網路一樣。

當你看到 AI 能力越來越強、應用越來越廣，背後很大一部分功勞就是 MCP 這樣的標準化協定。

在GitHub上在編輯此頁面
Table of Contents