跳至主要內容
EMil Wu
EN

#02

Skill、Tool、MCP 差在哪？

技術框架 3 分鐘閱讀
目錄
Skill、Tool、MCP 三個概念的視覺比喻 Skill、Tool、MCP 三個概念的視覺比喻
三個概念，解決三個完全不同的問題

這三個看起來很像，但解決完全不同的問題

當你開始研究 AI Agent 系統時，很快會看到三個名詞：

  • Skills
  • Tools
  • MCP

很多人第一次看到這三個東西時會覺得他們很像。甚至常常會把它們當成同一種東西

但其實這三個工具要解決的是 完全不同的問題

而且，當你真正開始建構 Agent 系統時，你會發現光靠這三個還不夠，實務上你需要五個東西，或者應該說五層，但在談五層之前，先把這三個弄清楚

Tool — 執行動作

Tool 最好理解，Tool 就是 AI 可以執行的動作(action)，例如：

  • Read() — 讀取檔案
  • WebSearch() — 搜尋網路
  • Bash() — 執行 shell 指令
  • query_database() — 查詢資料庫

LLM 透過 tool calling 觸發這些動作，Tool 的本質是 HOW to act(怎麼動作), 也就是怎麼對世界產生作用

但這裡有一個重要的設計原則：越少工具，Agent 越專注，實務上，一個 Agent 宣告超過 10 個 Tool，行為就會開始變得不可預測 所以 Tool 不是越多越好，而是讓每個 Agent 只拿到他真正需要的工具

MCP — Tool 的一種來源，不是獨立的層

MCP（Model Context Protocol）是一個 連接外部系統的協議，讓 AI 可以安全地存取：Slack、GitHub、Google Workspace、Notion

很多人會把 MCP 當成跟 Tool 平行的獨立層。但實務上，MCP 是 Tool 的子集

graph LR T["Tool（執行層）"] T --> N["Native Tool
Read · Edit · Write · Bash · WebSearch"] T --> M["MCP Tool
Slack · GitHub · Google Workspace"]
Tool 的兩種來源：Native 與 MCP

對 Agent 來說，呼叫一個 native tool 和呼叫一個 MCP tool 沒有區別，都是 tool call，只是 MCP 解決的是連接協議的標準化問題，所以他不需要在架構上佔一個獨立的層

實際上，大部分的 Agent 系統並不依賴 MCP ，用 Claude Code 的 native tools（Read、Write、Bash、WebSearch 等）就能完成大部分工作，MCP 有用，但他不是必需品，更不是架構的核心

Skill — 知識，不是流程控制

Skill 則完全不同，Skill 不是工具，Skill 是 Knowledge，是 How to think「AI 應該怎麼思考這件事」

例如：

  • 決策框架：什麼時候該做什麼、什麼時候不該做什麼
  • 安全審計方法論：檢查什麼、按什麼順序
  • 財報分析框架：哪些指標重要、怎麼交叉驗證

Anthropic 的說法是：

MCP 提供工具連接，而 Skills 提供完成任務的方法

關鍵區分：

  • Skill → 本質：HOW to think（怎麼想）/ 性質：靜態知識 / 舉例：決策框架、分析方法論
  • Tool → 本質：HOW to act（怎麼做）/ 性質：動態執行 / 舉例：WebSearch、Read、Bash

Skill 和 Tool 不是上下游關係，而是被 Agent 同時取用的，Agent 在執行任務時，一邊參考 Skill 提供的方法論，一邊呼叫 Tool 執行動作

Skill（怎麼想）與 Tool（怎麼做）的對比 Skill（怎麼想）與 Tool（怎麼做）的對比
HOW to think vs HOW to act — 知識與執行的本質區別

還有一個常見誤解：很多人以為 Skill 決定 Workflow，但回頭拆解 Claude 的運作，Skill 實際上只提供知識，Agent 才決定 Workflow，Skill 做的是告訴 Agent「做 XXXX 時要先檢查 XXX，然後才能做 XXXX」，但最終決定怎麼做、按什麼順序、用什麼工具的，是 Agent

三層不夠 — 實務上是五層

如果你只停在 Skill / Tool / MCP 這三個 AI 的「手腳」，會漏掉兩個關鍵角色。

實際運作的 Agent 系統長這樣：

graph TD CMD["Command（入口）
使用者觸發什麼流程"] AGT["Agent（編排者）
誰來做、用什麼工具做"] T["Tool（執行）
Native Tool · MCP Tool"] S["Skill（知識）
決策框架 · 分析方法論"] CTX["Context（領域知識）
事實、數據、背景資料"] CMD --> AGT AGT --> T AGT --> S T --> CTX S --> CTX
五層架構：Command → Agent → [Tool + Skill] → Context
五層架構的實體比喻：從 Context 地基到 Command 入口 五層架構的實體比喻：從 Context 地基到 Command 入口
多層架構的實體比喻 — 每一層都有自己的職責

Command — 入口，不是邏輯

2026/3/31 更新： Claude Code 預計將 Custom Commands 合併進 Skills。原本 Command 指令現在被視為 Skill 處理，仍可使用但載入行為已改變。文章描述的 Command 概念（作為使用者觸發的入口點）依然成立，但實作層面建議改用 Skills 格式。詳見這篇新聞報導 [1]。

Command 是使用者觸發流程的入口點，例如 /analyze、 /research、 /audit

Command 本身不包含業務邏輯，它只負責「啟動什麼」，然後把工作交給 Agent，就像你在終端機輸入一個指令，指令本身不做事，是背後的程式在做事。

Agent — 編排者，整個系統的核心

Agent 是整個系統真正的核心角色。他宣告自己能用哪些 Tool，載入需要的 Skill，然後決定怎麼完成任務。

一個設計良好的 Agent 長這樣：

name: researcher
model: opus
tools:
  - Read
  - Glob
  - Grep
  - WebSearch

注意他只宣告了 4 個 Tool 這是刻意的，設計 Agent 時，最重要的決定之一就是「不給他什麼工具」

另外一個實務中的重要模式：Plan-Only 和 Execute 要分開，負責設計的 Agent（architect）不該有寫入權限； 而負責執行的 Agent（scaffolder）不該做設計決策，引入這個隔離的設計可以防止很多衍生的問題。

Context — 地基

Context 是「Agent 需要知道的事實和資料」— 公司資訊、產品定價、品牌語調、市場數據等等。

  • Context = WHAT to know（知道什麼）
  • Skill = HOW to think（怎麼想）

沒有 Context，Skill 就缺少做決策的資料來源，一個財報分析的 Skill 告訴你「要看毛利率趨勢」，但具體的毛利率數字來自 Context。

所以完整的關係是?

  • Command → 啟動什麼？ → /analyze、 /research
  • Agent → 誰來做？用什麼？ → researcher agent（持有 WebSearch + Read）
  • Tool → 怎麼執行？ → WebSearch、Bash、Slack（MCP）
  • Skill → 怎麼思考？ → 決策框架、分析方法論
  • Context → 知道什麼？ → 公司財報、產品規格、市場數據

這個五層架構看起來很清楚、很完整，但它有一個根本問題

一個違反直覺的建議

Anthropic 在 2026 年初說過一段話：

「很多團隊花了幾個月建構精巧的 Multi-Agent 架構，結果發現在單一 Agent 上改善 Prompting 就能達到同等效果。」

為什麼？其實現在模型的成長已經超過你的想像，有時候太多雜訊跟 Agent 跟 Agent 之間的交接反而會降低效果，所以，先從一個 Agent + 好的 Context 開始，不要急著蓋 Multi-Agent 架構，只有當你碰到具體的瓶頸，比如 Context Window 不夠用、或者不同任務需要不同的工具集，才加第二個 Agent。

等等？Context Window 不夠用？

對，這五層架構有一個沒說出來的前提：所有東西都要塞進同一個 Context Window，從 Agent 定義、Tool schema、Skill 知識、Context 資料、對話歷史，這些全部擠在一起，而 Context Window 是有限的。

當你的系統越來越複雜、層越來越多、塞進越來越多的前提，Context 就會開始爆炸，這時候架構設計得再漂亮都沒用，因為真正的瓶頸不在架構，在 Context，所以，這就是我們下一篇要繼續談的。

Context Window 的有限空間裝載著所有層次的資料 Context Window 的有限空間裝載著所有層次的資料
五層架構的所有元素都要擠進同一個 Context Window

參考資料

[1] Claude Code 將 Custom Commands 合併進 Skills 的新聞報導 /news/claude-code-deprecate-command

[2] MCP Specification（官方規格）— MCP 的 Server features 包含 Resources、Prompts 和 Tools，明確定義 MCP 標準化的是工具連接 https://modelcontextprotocol.io/specification/2025-06-18

[3] Anthropic: “Writing Effective Tools for AI Agents” — “Too many tools or overlapping tools can also distract agents”；工具是執行介面，Skill 提供知識方法論 https://www.anthropic.com/engineering/writing-tools-for-agents

[4] EclipseSource: “MCP and Context Overload: Why More Tools Make Your AI Agent Worse” — Agent 只需要三個函式卻收到四十個；超過 40% context 使用量後模型行為不可靠 https://eclipsesource.com/blogs/2026/01/22/mcp-context-overload/

[5] Anthropic: “Building Effective Agents” — “Start with simple prompts… add multi-step agentic systems only when simpler solutions fall short” https://www.anthropic.com/research/building-effective-agents

[6] LangChain: “Choosing the Right Multi-Agent Architecture” — 列出四種 multi-agent pattern；Agent 在專注任務上比有數十個工具時更容易成功 https://blog.langchain.com/choosing-the-right-multi-agent-architecture/

[7] OpenAI: “A Practical Guide to Building Agents” — “Maximize a single agent’s capabilities first”；描述分層架構 https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/

支持這個系列

如果這系列文章對你有幫助，考慮請我喝杯咖啡