我依然偏好 MCP 而非 Skills

背景

在 AI 代理工具快速發展的背景下，開發者社群正針對如何賦予大型語言模型（LLM）外部能力展開技術路線之爭。爭論的核心在於 Model Context Protocol（MCP）與「技能」（Skills）兩種架構：前者是由 Anthropic 推動的標準化 API 抽象協議，後者則是透過 Markdown 文件與腳本定義的輕量化指令集。本文作者主張 MCP 在架構上更具前瞻性，但 Hacker News 的討論則揭示了兩者在實際應用場景中的深刻分歧。

社群觀點

Hacker News 的討論呈現出明顯的技術立場對立。支持 MCP 的觀點主要集中在企業級應用與非技術用戶的易用性。許多開發者認為，MCP 提供了標準化的授權與介面定義，這對於受限的企業環境至關重要。在這種場景下，聊天機器人通常運行在沙盒或行動端，無法直接存取本地的命令列介面（CLI）。MCP 作為一種遠端連接器，能讓模型在不接觸敏感金鑰的情況下調用工具，避免了將祕鑰暴露在對話上下文中的風險。此外，對於非技術人員而言，在 Claude Desktop 等應用中添加 MCP 伺服器，遠比在本地配置複雜的 CLI 環境與路徑變數來得直觀。

然而，反對者則批評 MCP 過於繁瑣且增加了不必要的抽象層。許多資深開發者傾向於使用「技能」結合現有的 CLI 工具，認為這才是最符合 Unix 哲學的做法。他們指出，如果模型已經具備強大的程式碼執行能力，直接讓它調用現成的 CLI 工具（如 AWS CLI 或 git）會比重新封裝一套 MCP 伺服器更有效率且更具組合性。部分留言者提到，MCP 雖然號稱安全，但本質上只是 JSON-RPC 的變體，若缺乏完善的中間件支援，其安全性並不必然優於傳統的 API 調用。更有激進的觀點認為，MCP 最終會像過往許多過度設計的協議一樣走向平庸，因為「技能」模式允許模型進行更靈活的腳本編寫與邏輯組合，這種隨機應變的能力是固定工具調用難以企及的。

在爭論之外，社群也達成了一些務實的共識。許多人認為這並非零和遊戲，而是互補關係。MCP 適合處理需要穩定連接、身分驗證與跨平台存取的「基礎設施層」；而技能則適合處理特定專案的「知識層」，例如定義程式碼風格、內部術語或特定任務的 SOP。有開發者分享了混合使用的經驗：利用技能來教導模型如何正確使用特定的 MCP 工具，解決模型在調用 API 時可能遇到的日期格式或參數限制等細節問題。這種「知識層掛載在連接層之上」的模式，被視為目前最能發揮 AI 效能的實踐方式。

延伸閱讀

在討論過程中，參與者分享了數個實用的工具與規範。針對技能的定義，有人推薦參考 Agent Skills 規範，該規範詳細定義了技能應包含的參考文件、執行腳本與靜態資源結構。在工具整合方面，mcp-cli 被提及作為連接兩者的橋樑，它能將 MCP 伺服器封裝成 CLI 命令供代理使用。此外，tmux-mcp 則展示了如何透過 MCP 讓模型與終端多路複用器互動。對於希望在本地環境與遠端服務之間取得平衡的開發者，murl 則提供了一種透過 Bash 執行遠端 MCP 的解決方案。