剛重新整理一下腦袋對這兩者思緒，AI編輯後的東西。

MCP 與 Skill：競爭、取代、還是根本不在同一條路上？

MCP 的幾個明確麻煩

MCP 以「服務」的形式架立，但定位非常尷尬。 作為伺服器的延伸，他完全比不上 API——他還是在實作一個個 function，這讓他會碰到一個顯而易見的問題：安全。而且他一樣得處理授權的各種形式，跟 API 沒兩樣。那對服務提供者來說，我為什麼不直接做 API 就好？ 另一方面，MCP 也可以讓 client 端來實作，變成 client 自己寫一層介面包著伺服器。這就更尷尬了——如果每個人都要寫一套自己的，那我到底為什麼要用？而且我還是得解決原生的資料來源、資料操作，該網站支不支援的問題。支援 API 的我直接打就好了，不支援 API 的我還得東裝一堆西裝一堆。MCP 真不幫我省事。

效率問題：偷雞不著蝕把米

CLI 跟 API 的存在，都比 MCP 有效率。 雖然 MCP 提供 description 協定讓大家可以看，但只要工具一多，desc 吃掉的 tokens 比預期多太多了。而且當初 MCP 協定為了 AI 都寫成語意化，反而不如傳統 API 參數化（parameterized）來得簡單直接，還要花更多力氣去「理解他」。典型的偷雞不著蝕把米。

背景補充： MCP（Model Context Protocol）由 Anthropic 於 2024 年底推出，設計初衷是讓 AI agent 能透過統一協定與外部工具互動。每個 MCP server 會以 JSON Schema 描述自己提供的 function，agent 在啟動時需要讀取所有這些描述來決定可以呼叫什麼——這就是 token 負擔的來源。

未來潛力 vs 現實笨重

當然不排除未來真的能高效地在語意之間遊走，但目前沒有顯著證據證明 CLI 或 API 的形式做不到同樣的事。而 MCP 在設計上需要啟動跟關閉，不能 plug and play，這讓他顯得非常笨重。你有多少時間在用或開發 MCP 的時候想著——我得重啟 agent 讓他重讀才會生效？

Skill 的明確優勢

回到 Skill。 走 API 的可以直接把語意放在整體的探索層，利用記憶處理，而不用「逐 function」描述。這點讓 Skill 非常有優勢。他也可以只實作部分自己要的東西，把這個東西從「整包服務」變成部分負擔。也能更有效地利用 agent 對文本的存取能力，按需讀取，而不是強迫他硬要吃完所有定義才能進行。 更理想的是，Skill 明確定位就是 local 工具，所以使用者只需要考慮自己順手就好，不需要太擔心作為服務的各種安全問題。隨時可改、可控，不需要太統一——剩下的由 agent 自行在實際任務中處理就好，不需要一開始就把目標都定位完。

背景補充： 這裡的 Skill 指的是以 prompt 檔案形式存在的本地工具定義（如 Claude Code 的 /commands），agent 在需要時才讀取對應的 skill 檔案，而非啟動時載入全部定義。這種「懶載入」的方式天然地避開了 MCP 的 token 膨脹問題。

小結

在處理的負擔上、在應用的控制權上、在主動性上，Skill 都得到比 MCP 更好的效果。就目前的情況，暫時想不到為什麼要用 MCP——扣掉某些已經有現成支援的工具以外。 倒是傳統服務如果想要更好地支援 Agent，API 化或 CLI 化，並且提供有效、低 token 負載的說明文件，都是比搞 MCP 更重要的事情。

原始 Facebook 貼文