![[MCP·Skill #3] MCP、Skill 與子代理：何時該用哪個？ 封面圖](/assets/images/posts/1bb00db5-c156-4575-854c-7218ac263b2c/1.jpg)
擴充 AI 程式設計工具的方法最近越來越多：用 MCP 連接工具、用 Skill 登錄流程，再把工作委派給子代理。
問題在於，三者都被描述為「擴充模型的能力」，因此實際選擇時很容易混淆。
用一句話總結：MCP 是手，Skill 是手冊，子代理是同事。
本文整理三者各自擴充的對象、選擇標準，以及組合後的整體架構。
先看重點摘要。
- MCP 擴充模型能做的事（工具與資料存取）
- Skill 擴充模型知道如何做的事（工作流程與領域知識）
- 子代理擴充執行工作的人力（具有獨立情境的執行主體）
- 三者不是競爭關係，而是組合關係。由子代理讀取 Skill 並使用 MCP 工具，是很自然的架構
三者各自擴充的對象
先用表格比較，再逐一說明。
| 分類 | MCP | Skill | 子代理 |
|---|---|---|---|
| 擴充對象 | 能力（工具・資料） | 知識（流程・技巧） | 執行主體 |
| 實體 | 協定・伺服器程序 | Markdown 資料夾 | 獨立情境工作階段 |
| 比喻 | 手 | 手冊 | 同事 |
MCP 是伸向模型外部系統的通道，能讓模型單獨無法實際完成的工作成為可能，例如查詢 DB、呼叫公司內部 API、操作瀏覽器。其特徵是存在一個執行程式碼的獨立伺服器。
Skill 不是賦予新能力，而是讓模型把原本能做的事做好。它會將版本說明格式、審查檢查清單、公司內部文件規則等「如何做」的知識，保存於檔案中。其實體就只是 Markdown。
子代理是擁有獨立情境視窗的另一個模型執行個體。它可以在不污染主工作階段對話記錄的情況下，接手探索與調查等工作。即使要求它搜尋大量檔案，主情境也只會收到結論。
選擇該使用什麼的三個問題
感到困惑時，依序問自己三個問題即可。
第一，這是模型目前在實體上做不到的事嗎？如果像查詢公司內部 DB 一樣，連存取本身都不可能，答案就是 MCP。再多知識也無法憑空長出一隻不存在的手。
第二，雖然做得到，卻必須每次說明方法嗎？那就使用 Skill。所有重複的提示詞都是 Skill 的候選。
第三，工作量太大，導致情境受到污染嗎？如果調查與探索結果讓對話變得雜亂，就該交給子代理隔離處理。
換句話說，沒有存取就用 MCP，沒有技巧就用 Skill，沒有情境（或情境不足）就用子代理。
實務上要組合三者
三者不是非此即彼。實際上，設計良好的自動化大多是這種形式。
以自動化程式碼審查為例：定義一個審查者子代理（主體），讓它遵循團隊的審查檢查清單 Skill（方法），再透過 GitHub MCP 伺服器留下 PR 留言（能力）。
你會發現，角色並未重疊，而是分屬不同層次。它們分別回答「誰／如何／用什麼」三個問題。
兩種常見的錯誤選擇
看清界線後，也就能看見反模式。
其中一種，是為了 Skill 就能處理的工作建立 MCP 伺服器。例如「套用提交訊息規範」是知識問題，用幾行 Markdown 就能完成，為此撰寫伺服器可說是本末倒置。伺服器還會帶來維護成本與安全性審查成本。
另一種，是把所有事情都在單一主工作階段中處理。若直接在主工作階段探索大型程式碼庫，檔案傾印會填滿情境，反而沒有空間進行實作。標準做法是將探索委派給子代理，主工作階段只接收結論。
總結
總結來說，沒有能力就用 MCP，沒有技巧就用 Skill，沒有人手就用子代理。
MCP 篇與 Skill 篇分別詳細介紹了各自的內容，建議先依本文標準判斷目前要建立的自動化屬於哪一層的問題。