目錄
這篇文章的重點
- Claude Code 是七個元件組成的系統，不是一個單一工具。只用 Main Agent 等於浪費了六成功力
- 四個維度分清所有元件：有沒有 context window、能不能執行動作、怎麼觸發、消不消耗 token
- Plugin 是教科書、Skill 是讀書筆記、MCP 是實驗器材——三者本質完全不同
- Hooks 是最被低估的元件——零 token 成本的自動化，應該優先考慮
- Subagents 的獨立 context 是長任務的救星——把耗 token 的子任務隔離出去
- 面對問題先問「我需要什麼類型的能力」，再選對應的元件
Claude Code不是一個工具
Claude Code 不是一個單一工具——它是一個由多個元件組成的系統。
但到了這個階段，你應該已經親手操作過 Claude Code，體驗過 Plan Mode、寫過 prompt、跑過完整的工程流程。現在，是時候把底層的系統架構攤開來看清楚。
為什麼這件事重要？
因為大多數人在使用 Claude Code 的時候，只用到了 Main Agent——也就是「你打字，它回答」這一層。這就像買了一整套專業工具組，卻只用螺絲起子。不是螺絲起子不好，而是你面對的問題不全是螺絲。
當你理解了這七個元件各自的角色和邊界，你就能在面對不同類型的挑戰時，精準地選出最適合的元件組合。這是從「會用 Claude Code」到「精通 Claude Code」的關鍵分水嶺。
七大元件完整對照表
使用Claude Code的過程中，不外乎會用到這七大元件。
四個維度，把七個元件分清楚
它有自己的 context window 嗎？
這是最根本的區分。
在這七個元件裡，只有兩個有自己的 context window：Main Agent 和 Subagents。
Main Agent 擁有主 context window——也就是你整個對話的上下文。你說的每一句話、它的每一個回覆、中間呼叫的工具結果，全部都在這個 context 裡。
Subagents 有自己獨立的 context window。這是一個關鍵的設計。當主 Agent 把一個子任務委派給 Subagent，那個 Subagent 會帶著任務描述啟動一個全新的 Claude 實例。它的思考、工具呼叫、中間結果，都在自己的 context 裡面，不會回灌到主 Agent 的 context。
其餘五個元件——Skills、MCP、Hooks、Slash Commands、Plugins——都沒有自己的 context window。它們要嘛是被載入主 context（像 Skills），要嘛是完全在 context 之外運作（像 Hooks）。
為什麼這個區分重要？因為 context window 就是 token，token 就是成本和速度。理解哪些元件會佔用 context，是做出高效配置的前提。
它能執行動作嗎？
第二個關鍵問題：這個元件能不能「做事」？
能執行動作的：Main Agent（能用全部工具）、Subagents（受限工具集）、MCP Servers（提供外部工具）、Hooks（執行腳本）。
不能執行動作的：Skills（只是 prompt 文字）、Plugins（只是容器）。
介於兩者之間的：Slash Commands——它本身不執行動作，但它會展開成 prompt 文字注入到對話中，間接驅動 Main Agent 去執行動作。
這個區分幫你理解一件事：當你需要 Claude Code 做一件新的事情時，你要問自己——我需要的是「教它怎麼想」（Skill），還是「給它新工具」（MCP），還是「在特定時機自動觸發」（Hook）？
它怎麼被觸發？
觸發機制直接決定了使用體驗。
手動觸發：
- Main Agent——你直接對話
- Slash Commands——你輸入
/xxx
自動觸發：
- Subagents——主 Agent 判斷需要並行處理時自動委派
- Skills——Claude 根據當前情境自動判斷是否載入
- Hooks——特定事件（如 commit、檔案變更）發生時自動執行
被動提供：
- MCP Servers——它不主動觸發，而是把工具註冊給 Claude，等 Claude 決定要不要呼叫
- Plugins——安裝時一次性載入，之後它裡面包含的各種擴展各自按自己的機制運作
注意 Skills 的觸發機制：Claude 不會一開始就把所有 Skills 全塞進 context，而是根據你當前的任務，根據Skills的描述，自動判斷哪些 Skills 跟當前情境相關（可參考Claude Code系列文5 – 建立自己的Claude Code SKILL優化工作流程），才載入。這個設計大幅減少了不必要的 token 消耗。
它消耗 token 嗎？
瞭解Claude Code如何在使用工具時消耗你的token，這是使用token的效率最佳化的關鍵。
幾個值得注意的重點：
Subagents 是長對話的救星。 當你的任務很複雜，主 context 快要爆的時候，Subagents 的獨立 context 設計就是關鍵。主 Agent 把耗 token 的子任務丟出去，Subagent 在自己的 context 裡完成後，只把結論傳回來。主 context 只多了一句結論，而不是整個思考過程。
Hooks 是最被低估的元件。 零 token 成本、自動觸發、不佔 context——但它能在每次 commit 前自動跑 lint、在每次檔案變更後自動跑格式化。這些如果讓 AI 做，每次都要消耗 token。用 Hook 做，永遠免費。
MCP、Skills 的隱藏成本。 每個 MCP Server 註冊的 tool schema 和 Skills 的描述都會佔 context。如果你裝了 10 個 MCP Server，每個有 5 個 tool，光是 tool 描述就已經佔掉不少 context space。安裝 MCP、Skills 時要有意識地選擇：你真的需要這個工具嗎？
最容易搞混的三個：Plugin vs Skill vs MCP
這三個概念是我在剛開始使用最常搞混的。讓我用一個比喻把它們徹底分清楚。
Plugin = 教科書。 它是一個打包好的容器。一本教科書裡面可能有課文（Skill）、實驗器材清單（MCP 配置）、課後練習（Slash Commands）、自動評分規則（Hooks）。但教科書本身不教你東西——裡面的內容才教你。Plugin 本身不執行任何動作，它只是一個分發格式，把多種擴展打包在一起，讓你可以一鍵安裝。
Skill = 讀書筆記。 它是一份 Markdown 文件，裡面寫的是「遇到這類情況，你應該怎麼做」。它教 Claude 怎麼想、怎麼做，但它自己不做任何事。它就像你整理的讀書筆記——記下最佳實務、操作步驟、注意事項。當 Claude 遇到相關情境，它會翻開這份筆記參考。
MCP Server = 實驗器材。 它是一個實際運行的外部服務，提供 Claude 可以呼叫的工具。就像實驗室裡的顯微鏡、離心機、光譜儀——它們有實際的執行能力，能做 Claude 本身做不到的事。查資料庫、呼叫外部 API、操作瀏覽器——這些都是 MCP 的領域。
把這三個放在一起看：
一個具體的例子：假設有一個叫 frontend-design 的 Plugin。安裝它之後，你得到的是：
- 一個 Skill：告訴 Claude 如何做高品質的前端設計（設計原則、CSS 最佳實務、元件結構建議）
- 一個 MCP 配置：連接 Playwright，讓 Claude 可以截圖檢查 UI 呈現效果
- 一個 Slash Command：
/design快速啟動設計審查流程
Plugin 把這三樣東西打包在一起。你安裝一次，就全部到位。但真正在工作的，是裡面的 Skill、MCP 和 Slash Command——不是 Plugin 本身。
決策指南：我該使用哪個元件？
理論講完了，回到實務。當你面對一個具體的挑戰，應該選哪個元件？
「我想教 Claude 遵循團隊的 coding style」→ Skill
寫一份 Markdown 文件，描述你們的命名規則、檔案結構慣例、commit message 格式。放進 .claude/skills/ 資料夾。Claude 在相關情境下會自動參考。
「我想讓 Claude 能查詢我們的 Notion 文件」→ MCP Server
你需要的是一個新工具。找一個 Notion MCP Server 安裝，或自己寫一個。Claude 就能在需要時呼叫它查資料。
「我想在每次 commit 前自動跑 ESLint」→ Hook
這是一個不需要 AI 參與的自動化動作。設定一個 pre-commit hook，零 token 成本，每次都自動執行。
「我想讓團隊成員一鍵啟動 code review 流程」→ Slash Command
寫一個 /review 命令，把 code review 的完整 prompt 包進去。團隊成員只要打 /review 就能啟動標準化的審查流程。
「我想把上面這些全部打包，讓新成員一鍵安裝」→ Plugin
把 Skills、MCP 配置、Slash Commands、Hooks 全部打包成一個 Plugin。新成員 /plugin install 一次搞定。
「我需要同時處理多個獨立的子任務」→ Subagent
當任務可以拆成多個獨立的部分（例如同時重構三個模組），主 Agent 會自動委派 Subagents 並行處理。你不需要手動呼叫 Subagent——它是主 Agent 自動決定的。
