Agent Skillsvs
MCPvs
RAG
一份完整的技術比較文檔，拆解三種 AI 系統整合模式的本質差異、適用場景與混搭策略——從 function calling 的生命週期，到通用協議層，再到知識檢索 pipeline。
執行 · Action
Agent Skills
讓模型不只「說話」，而能輸出結構化工具呼叫去執行操作。低延遲、語義精確、生態成熟。
通訊 · Protocol
MCP
AI 界的 USB-C。一個開放協議，標準化 AI 應用與外部工具/資料源之間的雙向通訊。
知識 · Knowledge
RAG
生成前先動態注入外部知識。可即時更新、可追溯來源、降低幻覺。
01
Agent Skills — 工具調用與 Function Calling
讓 LLM 從「對話者」變成「執行者」。
1.1什麼是 Agent Skills
Agent Skills 是 LLM Agent 的核心能力：讓模型不只是「說話」，還能執行操作。模型輸出結構化的工具呼叫指令（通常是 JSON），由應用層解析後執行對應的函數或 API，再將結果送回模型繼續推理。
1.2Function Calling 的生命週期
圖 P2 Agent Skills 運作流程
Input使用者查詢
→
ModelLLM 推理
→
JSON工具呼叫指令
→
Execute執行工具 / API
→
Result結果回傳
→
Model最終回應
不同 LLM 供應商對 function calling 的實作有細微差異，尤其在平行呼叫與串流的支援上：
| 供應商 | 工具定義欄位 | 平行呼叫 | 串流支援 | 特殊要求 |
|---|---|---|---|---|
| OpenAI | tools[].function.parameters | ✅ 原生支援 | ✅ 增量 delta.tool_calls | tool_choice: auto/required/none |
| Anthropic | tools[].input_schema | ❌ 每次僅一個 | ✅ payload 一次性送出 | 結果以 tool_result block 回傳 |
| Google Gemini | FunctionDeclaration | ❌ 每次僅一個 | ✅ payload 送出 | 需低溫 temperature=0 |
| 開源模型 | 取決於 prompt 格式 | 不穩定 | ❌ 串流常破壞 JSON | 需大量 prompt engineering |
1.3典型應用場景
| 場景 | 範例 | 為什麼適合 |
|---|---|---|
| 外部 API 呼叫 | 查天氣、發郵件、Slack 通知 | 操作有明確的 input/output schema |
| 資料庫查詢 | SQL 查詢、CRM 讀取 | 結構化查詢，結果可預期 |
| 運算任務 | 數學計算、數據分析 | 不適合 LLM 直接推理，交給專用工具 |
| 檔案操作 | 讀寫檔案、產生報告 | 精確的檔案系統操作 |
| 工作流程觸發 | 建立 Jira ticket、部署程式 | 觸發既有系統的操作 |
1.4優點與限制
◆ 優點
- 延遲低（直接呼叫，無需中間層）
- 語義精確（schema 定義決定行為邊界）
- 易於除錯（工具回傳即為結果）
- 成熟的生態系（所有主流 LLM 都支援）
◆ 限制
- 工具清單需預先定義（寫死在程式碼或設定檔）
- 服務間通訊缺乏標準化（各工具自行實作連線）
- 動態發現能力弱（只能用已註冊的工具）
02
MCP — Model Context Protocol
AI 界的 USB-C：一個通用的連接標準。
2.1什麼是 MCP
MCP（Model Context Protocol）是由 Anthropic 提出的開放協議，旨在標準化 AI 應用與外部資料來源/工具之間的通訊方式。你可以把它想成 AI 界的 USB-C——一個通用的連接標準。
MCP 解決什麼問題？ 在傳統 Agent Skills 模式中，每個工具都要自己實作認證、錯誤處理、資料格式轉換。MCP 提供一個統一的協定層，讓任何 MCP-compatible 的 client 都能與任何 MCP server 通訊。
2.2Client–Server 架構
圖 P3 MCP 通訊架構
| 角色 | 說明 | 範例 |
|---|---|---|
| MCP Host | 承載 LLM 的應用程式，透過 MCP 協議與 server 溝通 | Claude Desktop, Hermes Agent, VS Code |
| MCP Server | 暴露工具（Tool）或資源（Resource）的服務 | 檔案系統 / 資料庫 / Slack server |
| Resource | 可讀取的資料來源（類似 GET endpoint） | 文件、日誌、資料庫記錄 |
| Tool | 可執行的操作（類似 POST endpoint） | 發送訊息、建立記錄、執行計算 |
2.3傳輸機制
| 傳輸方式 | 適用場景 | 優點 | 缺點 |
|---|---|---|---|
stdio | 本地子程序通訊 | 零網路設定、低延遲 | 無法跨機器 |
| HTTP (SSE) | 遠端服務通訊 | 可跨網路、可擴展 | 需處理認證與 TLS |
2.4目前生態系
MCP 仍屬早期階段（2024 年底推出），但生態系正在快速成長：
官方 Servers
檔案系統、GitHub、Slack、PostgreSQL、SQLite、Puppeteer（瀏覽器自動化）
第三方 Servers
Google Maps、Notion、Obsidian、Airbnb、Stripe
Client 支援
Claude Desktop（原生）、VS Code 擴充、Hermes Agent（native-mcp skill）、Continue.dev、Cline
03
RAG — Retrieval-Augmented Generation
不是讓模型「記住」知識，而是每次查詢時動態注入。
3.1什麼是 RAG
RAG（檢索增強生成）是一種讓 LLM 在生成回覆前，先從外部知識庫檢索相關資訊的技術。它不是讓模型「記住」知識，而是在每次查詢時動態注入相關上下文。
3.2RAG Pipeline
圖 P4 RAG 檢索生成 pipeline
Source原始文件
→
Chunk文件切分
→
Embed嵌入向量化
→
Store向量資料庫
Query使用者查詢
→
Retrieve向量檢索 Top-K
→
Re-rank重排序
→
Generate注入 → LLM 生成
| 環節 | 說明 | 常見選擇 |
|---|---|---|
| 文件切分 Chunking | 將原始文件切成可檢索的區塊 | 256–1024 tokens, 重疊 10–20%, 語義切分 |
| 嵌入模型 Embedding | 將文本轉為向量 | text-embedding-3-small, bge-m3, jina-embeddings |
| 向量資料庫 | 儲存與搜尋向量 | Pinecone, Weaviate, Chroma, Qdrant, pgvector |
| 檢索策略 | 如何找到最相關的區塊 | 向量相似度、混合搜尋、HyDE |
| 重排序 Re-ranking | 對初檢結果重新排序 | Cohere Rerank, BGE Reranker, Cross-encoder |
| 提示組裝 | 將檢索結果注入 prompt | 動態 context 管理、摘要壓縮 |
3.3RAG 的六種變體
| 變體 | 核心觀念 | 適用場景 |
|---|---|---|
| Naive RAG | 傳統檢索 → 注入 → 生成 | 簡單問答、文件摘要 |
| Advanced RAG | 加入 re-rank、hybrid search、query rewriting | 高精度問答、複雜查詢 |
| Modular RAG | 可替換的 pipeline 元件 | 需要定制的生產系統 |
| Self-RAG | LLM 自行判斷是否需要檢索 | 減少不必要的檢索開銷 |
| Agentic RAG | Agent 動態決定檢索策略 | 多輪、多來源的複雜查詢 |
| Graph RAG | 使用知識圖譜組織資訊 | 需要多跳推理的場景 |
3.4優點與限制
◆ 優點
- 知識可即時更新（不用重新訓練模型）
- 可存取私有/專屬知識庫
- 可追溯資訊來源（citation）
- 降低幻覺（提供事實基礎）
◆ 限制
- 檢索品質高度依賴 embedding + chunking 策略
- 增加端到端延遲（檢索步驟）
- 對文件來源品質依賴強（垃圾進 = 垃圾出）
- 長尾知識難以檢索到
04
三者比較
同一張地圖上看清三種技術的座標。
4.1基礎能力矩陣
| 維度 | Agent Skills | MCP | RAG |
|---|---|---|---|
| 核心目的 | 執行操作 | 標準化工具通訊 | 提供知識 |
| 資料流方向 | Agent → 外部系統 | 雙向（通訊協定） | 外部知識 → Agent |
| 輸入/輸出 | 結構化 JSON Schema | JSON-RPC | 自然語言文本 |
| 延遲影響 | 低（直接呼叫） | 中（需協議層） | 中高（檢索+注入） |
| 動態發現 | 無（需預先註冊） | 有（server 暴露能力） | 無（需預先索引） |
| 標準化程度 | 各供應商自訂 | 開放協議標準 | 業界最佳實踐（無標準） |
4.2能力雷達圖
圖 P5 三技術能力雷達（0–5）
Agent Skills成熟、低延遲、生態大
MCP動態發現最強，仍早期
RAG知識能力獨步，延遲較高
4.3技術細節對比
| 維度 | Agent Skills | MCP | RAG |
|---|---|---|---|
| 成熟度 | 高度成熟（2023 起） | 早期（2024 末推出） | 高度成熟（2023 起） |
| 實作難度 | 低（SDK 原生支援） | 中（需架 MCP server） | 中高（pipeline 調校） |
| 生態系大小 | 所有 LLM SDK 皆有 | 快速成長中 | 豐富的開源工具鏈 |
| 版本穩定性 | 穩定（API 向後相容） | 迭代中（protocol 演進） | 穩定（架構成熟） |
| 常見瓶頸 | token 預算被工具呼叫吃掉 | 網路延遲與 server 可用性 | 檢索召回率與 chunk 品質 |
4.4適用場景對照
| 問題類型 | 推薦方案 | 理由 |
|---|---|---|
| 「查一下明天的天氣」 | Agent Skills | 單一 API 呼叫，schema 明確 |
| 「分析這份 PDF 的財務數據」 | RAG + Skills | RAG 提取內容，Skills 執行分析 |
| 「訂閱 Slack #engineering 新訊息」 | MCP | 需要標準化的 Slack API 通訊 |
| 「公司內部知識庫問答」 | RAG | 需要檢索私有文件 |
| 「從 Notion 讀任務，更新到 Linear」 | MCP | 兩個 MCP server 協作 |
| 「寫一封 email 並發送」 | Agent Skills | 簡單明確的 API 呼叫 |
| 「找出跟這 bug 相關的 issue 和程式碼」 | RAG + Skills | RAG 搜尋知識，Skills 操作系統 |
| 「動態整合一個新工具」 | MCP | 只需新增 server，client 自動發現 |
05
最佳實踐 — 何時用哪一種？可以混搭嗎？
三者不是互斥的，反而經常互補。
5.1決策框架
圖 P6 方案選擇決策樹
你需要什麼？
執行一個明確的操作（發送 / 查詢 / 計算）？
工具固定且本地
Agent Skills需動態發現 / 標準化通訊
MCP提供模型不知道的知識（文件 / 規範 / 歷史）？
需檢索外部 / 私有知識
RAG兩者都需要？
知識 + 操作同時發生
混搭（見 5.2）5.2四種混搭模式
RAGSkills
RAG 提供知識上下文，Skills 執行具體操作。
讀取 SQL schema → 產生查詢 → 執行 → 回傳
MCPRAG
MCP server 暴露知識庫作為 Resource，LLM 透過 RAG pipeline 取用。
MCP 連接公司 wiki → RAG 檢索文件
MCPSkills
MCP 作為工具通訊層，Skills 作為模型層的輸出格式。
MCP 暴露 Stripe API → function calling 觸發
SkillsMCPRAG
MCP 標準化通訊、RAG 提供知識、Skills 執行操作。
見 §6 wwAIlab 案例
5.3不建議的場景
| 做法 | 為什麼不建議 |
|---|---|
| 只用 RAG 來執行操作 | RAG 不適合觸發 side effect；操作應由 Skills 或 MCP 處理 |
| 只用 Agent Skills 處理大量知識 | Skills 非為注入上下文設計；知識應走 RAG pipeline |
| 為固定簡單的 API 引入 MCP | MCP 增加不必要複雜度；直接 function calling 更輕量 |
| 把敏感 API key 寫死在 Skills 定義 | 應透過環境變數或 MCP 安全層管理 |
06
實作案例 — wwAIlab 的組合架構
真實世界裡，三種技術各司其職。
wwAIlab 是一個多 agent 協作系統，由 Hermes Agent 框架驅動。在實際運作中，三種技術都被使用，各自負責不同的層面。
6.1技術棧架構
圖 P7 wwAIlab 三層組合架構
6.2各層的實際應用
| 技術 | wwAIlab 的實作 | 用途 |
|---|---|---|
| Agent Skills | 自製 skill 系統（skill_manage, skill_view, skills_list） | 檔案操作、程式碼執行、Web 搜尋、排程 |
| MCP | native-mcp skill（內建 MCP client） | 連接外部服務（DB、Slack、GitHub）的標準化通訊 |
| RAG | LLM Wiki 系統（三層架構 raw → wiki → schemas） | 知識管理與檢索，跨 session 持久化 |
6.3實際混搭流程
場景：使用者問「上次討論的 MCP 架構，幫我查一下我之前的筆記，然後總結給 Slack」
1 · RAG檢索 LLM Wiki 中的 MCP 相關頁面
→
2 · SkillswwAIlab-wiki 讀原始檔 + 本地處理
→
3 · MCP透過 Slack MCP server 發送總結
6.4wwAIlab 的選擇原則
本地優先Agent Skills 優先（低延遲、零網路依賴）
標準化通訊走 MCP需與外部服務通訊時，優先使用 MCP 而非自訂整合
知識走 wiki所有持久化知識透過 LLM Wiki（RAG 模式）管理，不走 fine-tuning
Manager 只路由Manager profile 只負責拆任務、分配、合併，不做專業工作