MCP vs Skills：AI Agent 工具擴展的兩條路，我怎麼選？

AI Agent 要真的有用，光會聊天是不夠的。它得能操作工具——查資料、呼叫 API、讀寫檔案、跑腳本。但「怎麼讓 AI 使用工具」這件事，目前有不同的做法，而且各有各的哲學。最近我在幫自己的 AI 助理擴充功能的時候，反覆在兩種方式之間掙扎：MCP（Model Context Protocol） 和 Skills。這篇來聊聊我的思考和實際選擇。

什麼是 MCP（Model Context Protocol）

MCP 是由 Anthropic 提出的一個標準化協議，目標是建立 AI model 和外部工具之間的通用溝通方式。你可以把它想像成 AI 世界的 USB——不管什麼設備，只要符合 USB 規格就能接上電腦用。

架構上大概長這樣：

1	AI Agent ↔ MCP Client ↔ MCP Server ↔ 外部服務（API、DB、檔案系統等）

MCP Server 是一個獨立的 process，它把外部服務封裝成 MCP 協議定義的 tool、resource、prompt 等介面。AI Agent 透過 MCP Client 跟 MCP Server 溝通，不需要知道外部服務的實作細節。

優點

標準化：不同的 AI client（Cursor、Claude Desktop、OpenClaw 等）都可以用同一個 MCP Server，寫一次就到處用
社群生態：因為是開放協議，社群已經有大量現成的 MCP Server——GitHub、Slack、Google Calendar、各種資料庫…幾乎你想得到的服務都有人做了
即時雙向通訊：MCP 支援 WebSocket 連線，可以做到 server push 和 streaming，不是傳統的 request-response

缺點

需要跑 MCP Server process：多了一個要管理的服務。要啟動、要監控、crash 了要重啟
多一層抽象：AI → MCP Client → MCP Server → 外部服務。多了一層就多了一個可能出問題的地方
Debug 比較複雜：問題可能出在 AI 理解 tool 的方式、MCP Client 的實作、MCP Server 的邏輯、或外部服務本身。四層裡面要找到 bug 在哪，有時候蠻頭痛的

什麼是 Skills

Skills 是另一種讓 AI Agent 使用工具的方式。以 OpenClaw 為例，一個 Skill 就是一個資料夾，裡面包含：

SKILL.md：說明書，用自然語言描述這個 skill 是什麼、怎麼用、有哪些參數
**scripts/**：實際執行的腳本（shell script、Python、Node.js 都行）
**references/**：參考資料（API 文件、dataset 說明等）

運作方式很直覺：AI 讀了 SKILL.md 就知道這個工具能幹嘛，需要的時候就呼叫 scripts 裡面的腳本來執行。

比如一個「查股票」的 Skill 可能長這樣：

skills/stock-query/
├── SKILL.md          # 說明怎麼查股票、支援哪些參數
├── scripts/
│   ├── query.sh      # 呼叫股票 API 的腳本
│   └── market-scan.py  # 市場掃描腳本
└── references/
    └── datasets.md   # 支援的 dataset 列表和欄位說明

優點

簡單直覺：就是檔案和腳本，沒有什麼協議要學，沒有 server 要管
不需要額外 process：AI 直接讀檔 + 跑腳本，不需要另一個持續運行的服務
AI 可以直接讀腳本理解邏輯：這一點很關鍵。如果 AI 不確定某個 skill 做了什麼，它可以直接讀 script 的 source code。這比 MCP 的 tool description 提供的資訊多很多
快速迭代：改個 shell script 就生效，不需要重新建構或部署任何東西

缺點

和特定 agent 框架耦合：OpenClaw 的 Skills 格式跟 Cursor 不一樣、跟其他框架也不一樣。你在 OpenClaw 建的 Skill，不能直接搬到其他地方用
不同 client 要重複設定：如果你想在兩個不同的 AI agent 裡用同一個功能，可能要各設一次
沒有標準化的雙向通訊：Skills 本質上是「AI 呼叫腳本 → 腳本回傳結果」，不支援 server push 或 streaming

我的決策框架

面對「要用 MCP 還是 Skills」這個問題，我不覺得有標準答案。但經過一段時間的實作，我整理出了一個自己的決策框架：

場景一：只在一個 agent 裡用

如果這個工具只有一個 AI agent 會用到，Skills 夠了。

理由很簡單：少了 MCP Server 要管、設定更簡單、debug 更直覺。除非有其他原因需要 MCP，否則何必多一層抽象？

比如我的 AI 助理需要查台股資料，目前只有這一個 agent 需要這個功能。那我就建個 Skill：寫個 query.sh 呼叫 API、寫個 SKILL.md 說明怎麼用，五分鐘搞定。

場景二：多個 client 都要用同一個工具

這時候 MCP 的價值就出來了。

比如你想讓 Cursor IDE 和你的 AI 助理都能查詢同一個內部 API。如果用 Skills，你得在兩邊各設一次。但如果用 MCP，跑一個 MCP Server，兩邊都連上去就好了。

不過，我目前的實際經驗是：這種場景沒有想像中常見。大部分時候，不同的 client 需要的工具是不一樣的，或者雖然看起來一樣但細節不同（比如 Cursor 需要的 codebase 查詢和 AI 助理需要的 codebase 查詢，prompt 和回傳格式可能不同）。

場景三：快速 prototype

毫無疑問選 Skills。

1
2
3

mkdir -p skills/my-tool/scripts
echo '#!/bin/bash\ncurl -s "https://api.example.com/$1"' > skills/my-tool/scripts/query.sh
chmod +x skills/my-tool/scripts/query.sh

再寫個 SKILL.md，一個新工具就能用了。從零到可用可能不到十分鐘。

MCP 的話，你得寫 server code、定義 tool schema、設定連線、測試連線……最快也要半小時以上。

場景四：需要即時雙向通訊

這是 MCP 的強項。

如果你的工具需要 push notification（比如監控告警）、streaming response（比如即時數據流）、或長時間運行的操作回報進度，MCP 的 WebSocket 連線模式比 Skills 的 request-response 模式更適合。

Skills 要做到類似的效果也不是不行，但會比較 hacky（比如用 polling 或寫暫存檔）。

實際案例

講完框架，來說說我實際的選擇。

金融 API 查詢 → Skills

目前只有我的 AI 助理需要查股票和財報資料。用 Skill 來實作：一個 query.sh 負責打 API、一個 market-scan.py 負責做市場掃描、一個 datasets.md 列出支援的 dataset 和欄位。

整個 Skill 建好之後，AI 助理可以自然地回答「最近某檔股票的融資融券變化」這類問題。不需要額外的 server，不需要複雜的設定。

Codebase 查詢 → 目前不需要 MCP

理論上，codebase 查詢是一個「多個 client 都需要」的場景——Cursor IDE 能查、AI 助理也想查。按照決策框架應該用 MCP。

但實際上，我目前的做法是讓 AI 助理在需要查 codebase 的時候呼叫 cursor-agent 的 ask mode（上一篇有聊到）。這個做法雖然不優雅，但夠用。等到真的有瓶頸了再考慮抽成 MCP Server。

天氣查詢、圖片生成 → 社群現成的

這類常見功能，社群通常已經有現成的 Skill 可以直接裝。不需要自己從頭寫，也不需要搞 MCP。

混合使用的可能性

有一點我覺得很重要：MCP 和 Skills 不是非此即彼的選擇。

你完全可以在一個 Skill 的 script 裡面呼叫 MCP server。比如：

#!/bin/bash
# skills/my-tool/scripts/query.sh
# 這個 skill 的腳本裡面呼叫了一個 MCP server 來取得資料
mcp-client call my-mcp-server query --params "$1"

這樣 AI agent 看到的還是一個 Skill（簡單的 SKILL.md + script），但底層已經透過 MCP 去跟外部服務溝通了。

我認為比較健康的演進路徑是：

先用 Skills 快速實作，驗證需求和流程
如果發現多個 client 真的都需要同一個工具 → 再抽成 MCP Server
原本的 Skill script 改成呼叫 MCP server 就好，SKILL.md 不用大改

這個漸進式的做法比一開始就 over-engineer 一個 MCP Server 要務實得多。

MCP vs Skills 快速對比

用列表整理一下兩者的差異（各有優劣，沒有絕對好壞）：

設定複雜度：Skills 低，建個資料夾寫幾個檔案就好 / MCP 中高，需要寫 server code 並管理 process
跨 client 重用：Skills 低，每個 client 框架格式不同 / MCP 高，標準化協議讓不同 client 都能用
Debug 容易度：Skills 高，就是檔案和腳本，直接 cat 和 bash -x 就能 debug / MCP 中等，要分辨問題在 client、server 還是外部服務
社群生態：Skills 看框架，OpenClaw 的生態跟 Cursor 的不一樣 / MCP 快速成長，主流服務幾乎都有 MCP Server 了
即時通訊：Skills 不支援，本質是 request-response / MCP 支援，WebSocket 連線可以做 push 和 streaming
學習曲線：Skills 低，會寫 shell script 就會寫 Skill / MCP 中等，要理解協議概念和 server 開發
維運成本：Skills 幾乎為零，就是檔案 / MCP 要管一個 server process

結語

AI Agent 的工具擴展沒有銀彈。MCP 和 Skills 各有擅長的場景，硬要說哪個比較好是不公平的。

我自己的原則很簡單：

能用 Script 解決的不用 Server，能用 Skill 解決的不開 MCP。

大部分的日常需求，一個 Skill 就搞定了。Shell script + SKILL.md，五分鐘上線，出問題了直接 cat 腳本就能 debug。只有當「跨 client 重用」的需求明確出現時，才值得花時間去建 MCP Server。

而且，因為 Skills 可以呼叫 MCP server，所以從 Skill 遷移到 MCP 的成本其實不高。先用 Skill 快速驗證，確定流程和需求都穩定了，再考慮抽成 MCP 也不遲。

過早抽象是萬惡之源，在 AI 工具擴展這個領域也一樣。先讓東西能動、好用，再來想要不要標準化。畢竟，你的 AI 助理不會因為你用的是 Skill 而不是 MCP 就罷工——它只在乎你給的工具能不能幫它完成任務 🙂