MCP、Skills、Tools、Subagents 到底有什麼區別？2026 AI Agent 開發棧正在發生什麼變化

先給結論：Tools、MCP、Skills、Subagents 不是四個互相替代的產品名，而是 2026 年 Agent 開發棧裡四層不同職責。Tools 是模型看見的「可呼叫函式」契約（名字 + JSON Schema）；MCP 是 Host 與外部工具程式之間的發現與呼叫協議；Skills 是按需載入的程式性知識包（怎麼做事）；Subagents 是帶獨立上下文、可委派出去的子代理。把它們揉成一個詞，除錯時就會同時改錯層。

這篇按 2026 年 9 月 11 日寫。本站已有《MCP 是什麼》《Agent JSON 資料流》《JSON Schema 標準合同》。本文只回答：這四層各自管什麼、怎麼疊、以及 2026 年這套棧正在往哪邊收攏。

一張表先分清四層

口語裡「給 Agent 加個工具」可能指四件完全不同的事。按下表對號入座：

記一句就夠：Tools 是「能調什麼」；MCP 是「工具從哪來」；Skills 是「怎麼做這件事」；Subagents 是「誰去幹、用哪段上下文」。JSON Schema 貫穿 Tools 與 MCP；Skills / Subagents 更多管提示詞、策略與會話邊界。

Tools：模型面前的呼叫契約

Tool（或 Function）是大模型側看到的最小可呼叫單元。各家名字略有差別——OpenAI 的 Tools / Function Calling、Anthropic 的 Tool Use、Gemini 的 Function Declarations——本質一樣：你宣告一組工具，模型在回覆裡返回結構化 tool_calls（或等價欄位），Host 執行後再把結果塞回對話。

一份工具定義通常長這樣：

{
  "type": "function",
  "function": {
    "name": "validate_json",
    "description": "Validate JSON text and return parse errors.",
    "parameters": {
      "type": "object",
      "properties": {
        "text": { "type": "string" }
      },
      "required": ["text"],
      "additionalProperties": false
    }
  }
}

這裡真正約束行為的是 JSON Schema：欄位名、型別、required、additionalProperties。模型可以換，Schema 不該隨模型飄。本站《Tool Calling 為什麼依賴 JSON Schema》把校驗紀律寫細了；本文只強調：沒有 Schema 的「自然語言工具說明」，在 2026 年已經不夠當生產契約。

Tools 層的邊界很清楚：它不規定工具實現跑在本程式還是遠端，也不規定多步任務怎麼拆。那些分別是 MCP 和 Skills / Subagents 的事。

MCP：跨程式的工具插座

MCP（Model Context Protocol）解決的是：工具與上下文如何從 Host 程式外被發現和呼叫。報文是 JSON-RPC 2.0；常見方法包括 tools/list、tools/call，以及 Resources / Prompts 相關方法。Host（Cursor、VS Code、Claude Desktop 等）內部的 MCP Client 連上一臺 MCP Server，把 Server 暴露的工具譯成模型看得懂的 Tools 陣列。

所以正確的疊法是：

1. MCP Server 用 inputSchema（仍是 JSON Schema）描述每個 tool；
2. Host 調 tools/list，翻譯成模型的 Tools 宣告；
3. 模型發出 tool_calls；
4. Host 再發 tools/call 給 Server，把 result 寫回對話。

把 MCP 說成「另一種 Function Calling」是 2025–2026 最常見的誤讀。Function Calling 在模型 API 邊界；MCP 在 Host ↔ Server 邊界。當前規範以 2026-07-28 為準：無會話握手，請求自帶 _meta。細節見《MCP 完整指南》與《遷移指南》。

什麼時候不需要 MCP？單程式、工具寫死在 Host 裡、不跨應用複用——直接 Tool Calling 就夠。什麼時候值得上？要跨 IDE / 桌面端複用同一套 Server、要程式隔離、要動態發現工具清單。

Skills：可複用的做事說明書

Skill 不是又一個 tool，而是一段可被 Agent 按需載入的程式性知識：何時啟用、按什麼步驟做、要檢查什麼、可以呼叫哪些工具。工程形態常見為倉庫裡的 SKILL.md（或等價規則包）：標題、觸發條件、步驟清單、禁止事項、相關指令碼路徑。

和 Tools / MCP 的差別：

2026 年 IDE Agent（含 Cursor 一類產品）把 Skills 做成一等公民：短任務用內建能力；長流程、團隊規範、重複運維劇本放進 Skill，避免每次都把整本手冊塞進系統提示詞。Skill 可以指導 Agent 去調哪些 Tools，也可以規定「先校驗 JSON 再提交」這類門禁——但它本身通常不是 JSON-RPC 方法。

落地時容易混的一點：有人把「封裝好的 shell 指令碼」既叫 Skill 又叫 Tool。分法是——若模型透過 Schema 調一次、拿結構化結果，那是 Tool；若檔案告訴 Agent「按這五步做，必要時再調工具」，那是 Skill。

Subagents：獨立上下文的委派單元

Subagent 是父 Agent 委派出去的子會話：通常有獨立上下文視窗、更窄的系統提示詞、更受限的工具集，完成後把摘要交回父會話。它解決的不是「多一個函式」，而是「上下文汙染」和「並行探索」。

典型用途：

• 隔離檢索：讓子代理去翻倉庫、讀日誌，父會話只收結論，不吞進整份噪音。
• 並行分工：前端改動、測試、文案翻譯同時跑，互不搶同一段上下文。
• 角色收窄：安全審查、程式碼探索、CI 診斷用不同提示詞與工具白名單。

實現上，Subagent 常常對父 Agent 暴露成一種特殊 Tool（例如 Task / spawn_agent）：參數是任務描述與型別，返回是子代理的最終答覆。這不意味著 Subagent = Tool。Tool 是呼叫面；Subagent 是另一個帶狀態的推理迴圈。

和 Skills 的邊界：Skill 告訴「怎麼做」；Subagent 決定「另開一個會話去做」。一個 Skill 可以規定「複雜排查必須啟動 CI 診斷 Subagent」；Subagent 內部再載入自己的 Skills 與 Tools。

四層怎麼疊在一起

一次真實任務裡，四層經常同時出現。以「寫部落格並部署」為例（示意，不是本站真實內部協議）：

1. 父 Agent 載入 Skill：「部落格釋出檢查清單」——校驗正文、多語言、sitemap、IndexNow。
2. 父 Agent 呼叫 Subagent 去探索倉庫裡的歷史文章模板，避免把幾十個 HTML 塞進主上下文。
3. 主會話透過 Tools（讀寫檔案、跑 shell）改前端；若工具來自外部程式，則經 MCP 發現與呼叫。
4. 每一步涉及結構化參數時，仍用 JSON Schema 卡住欄位——尤其是會離開本機的那一跳。

資料流可以壓成一行：

User → Host/父 Agent
      → Skills（選流程）
      → Subagents（可選委派）
      → Tools 宣告（給模型）
      → 可選 MCP Client ↔ MCP Server
      → 執行結果寫回對話

除錯口訣：模型亂調工具 → 先查 Tools / Schema；工具程式連不上 → 查 MCP；步驟經常漏項 → 補 Skill；上下文爆了或互相汙染 → 拆 Subagent。

2026 Agent 開發棧在變什麼

和 2024「把函式塞進 prompt」相比，2026 年的變化可以收成五條：

另一條主線是結構化輸出與工具參數合流：模型回覆業務 JSON、工具 arguments、MCP inputSchema，三處都在用同一套 Schema 紀律。本站《結構化輸出是什麼》《OpenAI vs Gemini 對比》寫的就是這條線。

產品側，IDE Agent 不再只是「聊天 + 補全」：預設棧裡同時有工具呼叫、MCP 聯結器、Skills 目錄、可派生子代理。對開發者的含義是——你交付的不再只是一個 API，而是可被發現的工具（MCP/Tools）+ 可被遵循的流程（Skills）+ 必要時可被委派的角色（Subagents）。

現在該怎麼選、怎麼寫

• 先寫 Schema，再暴露工具。additionalProperties: false、required 寫全；用本站校驗工具在瀏覽器裡對樣例 arguments 做語法與結構檢查。
• 工具要跨應用複用，再包 MCP Server。單指令碼、單 Host 內嵌實現，不必強行上 MCP。
• 團隊重複流程寫成 Skill。釋出、遷移、排障、安全審查——步驟穩定的，不要每次靠「記得提醒模型」。
• 上下文一長就拆 Subagent。探索型、只讀型、高噪音任務優先委派；父會話只留決策與最終補丁。
• 不要用 Skill 代替 Schema，也不要用 Subagent 代替 MCP。前者是流程，後者是契約與傳輸；混用會導致「檔案裡寫了校驗、線上卻從不跑」。

本機檢查 JSON 時，把 inputSchema、模型返回的 arguments、MCP tools/call 結果樣例存成檔案，用 JSON 校驗 與 JSON Diff 對照。資料不離開瀏覽器——和端側優先的隱私思路一致。

常見問題 FAQ

總結

Tools 定義模型能調什麼；MCP 定義工具如何從外部程式被發現與呼叫；Skills 定義怎麼按規範把事做完；Subagents 定義如何隔離上下文並委派。2026 年的 Agent 開發棧，正從「一個聊天框 + 一堆臨時函式」收攏成這四層加一條 JSON Schema 契約帶。

選型時由內向外加，不要一次上齊。先把 Schema 與 Tools 做對，再按複用、流程、上下文三個壓力點決定 MCP、Skills、Subagents。動手前用本機 JSON 工具把樣例跑通——模型可以換，欄位名和 required 不該變。