【技術洞察】AI Agent 的大腦與手腳:深度解析 Claude Skills 與 MCP 的關鍵差異

從 Anthropic 開源架構看 AI 代理的模組化工程思維

在當前的 AI 浪潮中，我們經常聽到「Agent（代理）」、「MCP（模型上下文協議）」以及最近 Anthropic 推出的「Claude Skills」。對於許多開發者甚至技術決策者來說，這些名詞容易混淆：它們是互相取代的嗎？還是不同維度的工具？

在療心智能（HealthyMind Tech），我們始終認為：AI Agent 的核心驅動力永遠是 LLM 本身，但要讓這個「大腦」穩定落地，我們需要良好的「工程鷹架」。今天，我們就從工程架構的角度，深入拆解 Claude Skills 的本質，並釐清它與 MCP 之間的關係。

一、什麼是 Claude Skills？AI 的「標準作業程序（SOP）」

如果說 LLM 是一個剛入職的高智商實習生，Skill 就是我們交給他的「標準化任務資料夾」。

以往我們習慣把所有指令寫進一個巨大的 System Prompt 裡，但 Claude Skills 提出了一種更優雅的解決方案——模組化封裝。Anthropic 甚至將這些標準開源（GitHub: anthropic/skills），把方法論落實為可維護的檔案結構。

一個典型的 Skill 資料夾，會將完成特定任務所需的一切，打包成四個部分：

SKILL.md（說明書）：定義「你是誰」、「何時使用此技能」、「具體執行步驟」。
scripts/（工具箱）：放入 Python 或 Shell 腳本。例如在我們的 DietMate 系統中，可提供 calculate_bmi.py 來保障數值準確性，而不是讓 AI 自己估算。
references/（知識庫）：放 API 手冊、業務規範或醫療法規，作為查閱的「教科書」。
assets/（素材包）：存放模板、圖檔與其他輔助資源。簡單來說：Skill = 任務說明書 + 工具代碼 + 專業知識 + 素材資源。這體現了一種「約定優於配置」的工程理念。

為什麼不直接把所有東西丟給 AI？因為 LLM 的上下文窗口（Context Window）既昂貴又有限。Claude Skills 的設計精髓在於分層加載策略，大幅節省 Token 並提升任務聚焦度。

第一層（快速篩選）：AI 只需記住 Skill 的「名稱」與「簡介」，在用戶提需求時快速比對相關性，成本極低。
第二層（讀取指令）：確定要使用某技能時，才讀取 SKILL.md 的詳細步驟。
第三層（按需調用）：執行過程中需要具體代碼或查閱文檔時，才載入 scripts 與 references。這就像人類專家：遇到問題才打開對應的書本與工具，而不是把整個書庫背在腦中。

社群最常問的問題是：「有了 Skills，還需要 MCP 嗎？」

答案很清楚：兩者不同維度，互補而非替代。

MCP（Model Context Protocol）是「連接管道」：定義 Agent 如何與外部世界（資料庫、Google Drive、Slack 等）標準化溝通，解決的是「連接」問題。
Claude Skills 是「能力封裝」：定義 Agent 應具備的知識與工作流，解決的是「思考與行動邏輯」問題。舉個實際例子：在開發我們的 CRM 系統時，我們可以編寫一個「客戶數據分析 Skill」。SKILL.md 指導 AI 如何判讀數據趋勢；而當 AI 需要實際「抓數據」時，會依該 Skill 的指示，去調用一個遵循 MCP 協議的資料庫接口。

MCP 負責把路鋪好，Skills 負責教 AI 怎麼在這條路上開車。

既然 Skills 本質上就是一組可版本化的檔案夾結構，為什麼值得重視？

對開發者而言，關鍵價值在於**設計模式（Design Pattern）**的借鑑。當 AI 應用變得複雜，已經不能再用一個幾千行的 system_prompt.txt 維持所有邏輯。

Claude Skills 提供了一種解耦的實踐：

Claude Skills 並不是遙不可及的黑科技，它更像是AI 工程化成熟的一個標誌。它告訴我們：AI Agent 的未來，一半靠強大的模型基座，另一半靠精細的軟體工程架構。

在療心智能，我們正把這種模組化思維落地到 DietMate 與醫療協作平台的研發上，確保我們的 AI 營養師不僅聪明，還要嚴謹、可控、可維運。

想進一步交流或合作？