文章目錄
從 Anthropic 開源架構看 AI 代理的模組化工程思維
Claude Skills 和 MCP 這兩個東西，在社群裡常常被拿來比較，甚至有人問「有了 Skills 還需要 MCP 嗎？」這個問題問歪了——兩者不在同一個維度上，根本比不起來。
這篇從工程角度拆一下這兩個概念，以及我們在 DietMate 和醫療協作平台的實際應用怎麼把它們組合起來用。
Claude Skills 是什麼？
如果你一直把任務指令、知識文件、執行邏輯全部塞進 system prompt，然後發現維護起來越來越痛苦——Skills 就是 Anthropic 提出的解法。
概念很直接：把一個 AI 能力拆成一個獨立的「任務資料夾」，包含它所需要的說明、工具、知識和素材。Anthropic 把這套方法開源到 GitHub（anthropic/skills），讓它從理念變成可以版本控制的實際結構。
一個 Skill 資料夾長這樣：
skill-name/
├── SKILL.md # 說明書：何時用、怎麼用、執行步驟
├── scripts/ # 工具腳本，例如 calculate_bmi.py
├── references/ # 查閱文件：API 手冊、業務規範、醫療法規
└── assets/ # 素材：模板、範例檔案
為什麼不直接全塞 system prompt？因為 context window 是有限的，而且每個 token 都有成本。Skills 的設計是分層加載：
- AI 平時只需要知道每個 Skill 的名稱和一句話說明（成本極低）
- 確定要用某個 Skill 時，才讀取 SKILL.md 裡的詳細步驟
- 執行過程需要具體腳本或查文件時，才把 scripts 和 references 載入
人類專家也是這樣工作的——不是把整個書庫背起來，而是遇到需要時才去翻對應的文件和工具。
以 DietMate 為例：我們有「食物影像分析」Skill、「飲食問診」Skill、「法規合規審核」Skill。每個 Skill 獨立維護、獨立測試、獨立更新，不會因為改了一個 Skill 的邏輯而影響其他的。
MCP 是什麼？
MCP（Model Context Protocol）解決的是另一個問題：AI 怎麼和外部世界溝通。
資料庫、院內 HIS 系統、Google Drive、排程系統——這些外部資源要讓 AI 存取，之前的做法是每個應用自己寫整合邏輯，格式各異，維護各自為政。MCP 定義了一套標準的溝通協定：工具怎麼被發現、怎麼被呼叫、參數和回傳格式長什麼樣。
一個具體的例子：我們的 Taiwan Health MCP 把台灣的 ICD-10、藥品資料、FHIR R4 介面打包成 MCP Server。任何支援 MCP 協定的 AI Client，不管是 Claude Desktop、Cursor、還是自己寫的 Agent，都能直接接上去查台灣的醫療資料，不需要每個 Client 各自實作整合邏輯。
兩者的關係
MCP 負責把路鋪好，Skills 負責教 AI 怎麼在這條路上開車。
這個比喻算精確。MCP 是連接管道，解決「AI 能不能存取外部資源」的問題；Skills 是能力封裝，解決「AI 應該用什麼邏輯處理這個任務」的問題。
一個完整的 Agent 架構，兩者都需要：
| 面向 | Claude Skills | MCP |
|---|---|---|
| 解決的問題 | AI 的思考與行動邏輯 | AI 與外部資源的連接 |
| 類比 | 工作 SOP、任務說明書 | USB-C 統一接頭 |
| 內容 | SKILL.md、scripts、references | 工具定義、傳輸協定 |
| 維護方式 | Git 版本控制的資料夾結構 | MCP Server 統一管理 |
| 替代關係 | 無，兩者在不同維度 | — |
用一個 DietMate 的實際場景說明：
患者傳了一張便當照片進來。AI 要先用「食物影像分析 Skill」——這個 Skill 的 SKILL.md 告訴 AI 要辨識哪些食物類別、估算邏輯是什麼、輸出格式長什麼樣；然後 AI 需要查這些食物的營養成分，這時候它透過 MCP 呼叫 Taiwan Health MCP 的食品營養資料庫工具；最後它要確認患者的用藥清單裡有沒有食物藥物交互作用，這個查的是另一個 MCP 工具。
Skills 管思考流程，MCP 提供資料存取。少了任何一個，系統都不完整。
對開發者的啟示
Skills 的檔案夾結構本質上就是一個 Design Pattern——把 AI 能力模組化。這件事的價值在於：
可測試性：每個 Skill 的行為是可以單獨測試的。你改了「飲食問診 Skill」的邏輯，不需要跑完整個系統測試，針對這個 Skill 測就夠了。
不鎖定模型：Skills 的概念不是 Claude 專屬的。無論後面換成 GPT、Gemini、還是開源模型，模組化能力管理的架構都適用。Anthropic 是先把這套方法論落地，但想法本身是通用的。
可維運性：一個幾千行的 system_prompt.txt 沒有人知道哪一段在做什麼、改哪裡會影響什麼。Skills 的結構強制你把邏輯拆清楚，這對長期維護很重要——尤其是醫療場景，合規要求可能隨法規更新而變，你需要知道改了哪裡、為什麼改。
我們在 DietMate 的設計是這樣組的：
- Skills 管理思考與流程邏輯：食物辨識、飲食問診、合規審核
- MCP 提供資料存取：電子病歷查詢、院內資料庫、台灣醫療標準碼
- 兩層之間的協調：由 Agent orchestrator 根據任務類型決定呼叫哪個 Skill，Skill 內部再決定需要哪些 MCP 工具
這個架構讓每一層都可以獨立更新：法規改了就更新合規審核 Skill；Taiwan Health MCP 加了新工具就直接能用，不需要改任何 Skill；換底層模型不影響 Skills 的邏輯。
結語
Claude Skills 不是黑科技，是軟體工程裡「關注點分離」原則在 AI Agent 設計上的應用。重要的不是跟上 Anthropic 的每個新功能發布，而是理解背後的設計思維——把 AI 能力模組化、讓每個模組可以獨立維護和測試。
AI Agent 能不能穩定落地，一半靠模型本身的能力，另一半靠工程架構夠不夠紮實。
想進一步了解我們怎麼把這套架構用在醫療場景？
- 🌐 DietMate AI 營養照護平台：https://www.healthymind-tech.com/dietmate
- 相關文章：Taiwan Health MCP 完整入門指南 · Agentic Healthcare Workflow
討論區 (0 則留言)