# Claude Code 變慢了：如何選擇 Skills、Subagents、MCP 和 Plugins > 比較 Claude Code 擴充功能、脈絡使用量、七個常見錯誤與最精簡的可行設定，並保留技術範例。 Source: https://ailoot.ai/blog/zh-hant-tw/claude-code-skills-subagents-mcp-plugins/ Canonical: https://ailoot.ai/blog/zh-hant-tw/claude-code-skills-subagents-mcp-plugins/ Language: zh-Hant-TW Publisher: Ailoot (https://ailoot.ai/) Translation: guide-038 Revision: sha256-aa296fac05f35c8d2c2d71548f5e5ec89607c17ccbf5485d021196ffeae18b91
重要重點 Skill 是由觸發條件載入、可重複使用的指示（閒置時約 100 個 tokens）。Subagent 是具有獨立權限的隔離式 200K 脈絡。MCP 可連接外部資料與 API。Plugin 則是將前三者打包好的現成套件。2026 年的主要組合公式是：Haiku subagent + 預先載入慣例的 skill + 一個範圍明確的即時資料 MCP。其餘的東西不是會產生幻覺，就是會塞滿脈絡。
Ailoot 的實用操作說明請見[文件](https://ailoot.ai/docs/)。
## 為什麼「把 Claude Code 塞滿東西」在 2026 年成了最大的痛點？
重要重點 截至 2026 年 6 月，Claude Code 有四種擴充機制：skill、subagent、MCP 和 plugin。官方登錄庫有 101 個 plugins，社群目錄則有數千個。什麼都想安裝的誘惑，會讓 Claude 變慢、混淆相似功能，並在每則訊息中耗盡使用額度。讀者最關心的問題是：每種任務該用哪種機制，才能避免把 agent 變成垃圾場？
就連官方文件也沒有對「何時該選哪一種？」提供完整現成的答案。 本文描述的一個月經驗，涵蓋了實際專案中使用的全部四種機制：處理一項複雜任務的 subagents 組合、用於重複流程的一小組 skills、幾個提供即時資料的 MCP servers，以及從大約兩打 plugins 中挑選出的幾個。本指南將這些例子整理成選擇矩陣，並提供可直接使用的決策樹、Anthropic 引言，以及七種會讓 Claude 變得無法使用的反模式。 ## Skill、Subagent、MCP 和 Plugin 有何不同？一張表看懂
重要重點 四種機制是同一套架構中的四個層次。Skill 教 Claude 一套流程。Subagent 將任務隔離在獨立脈絡中。MCP 連接外部資料。Plugin 則把前三者打包成一個套件。每種機制都有適合的任務、token 用量，以及讓脈絡變雜亂的風險。只有選錯層次時，它們才會互相衝突。
選擇矩陣： | 特性 | Skill | Subagent | MCP server | Plugin | |----|----|----|----|----| | 隔離的脈絡 | 否 | **是**（全新的 200K） | 否 | 透過自己的 subagents | | 外部資料與 API | 否 | 僅能透過指派給它的 MCP | **是** | 透過自己的 MCP servers | | 節省 tokens | 70–90%（漸進式揭露） | 複雜任務最多 70% | 取決於工具搜尋 | 取決於套件內容 | | 工具限制 | 透過 `allowed-tools` | 在 frontmatter 中嚴格限制 | 透過 subagent 或政策 | 套件的一部分 | | 選擇更便宜的模型 | 透過 `model` 欄位 | 在 frontmatter 中**可以** | 不適用 | 透過自己的 subagents | | 設定時間 | 幾分鐘 | 幾分鐘 | 幾小時到幾天 | 在市集一鍵安裝 | | 主要用途 | 檢查清單、慣例、風格 | 產生雜訊的委派任務 | 資料庫、API、即時資料 | 現成的社群工作流程 | | 主要陷阱 | 超過 500 行的臃腫 SKILL.md | 權限與 parent 同級的 subagent | 超過 3 個 MCP servers | 未檢查內容的套件 | 給創業者一個簡單的比喻：想像你是十人公司的執行長： - **CLAUDE.md** — 公司章程。一直貼在牆上，人人都讀，沒人爭辯。 - **Skill** — 內部流程。「我們如何做審查」、「如何撰寫發布說明」、「如何收款」。 - **Subagent** — 有獨立辦公室和有限權限清單的專家。把所有鑰匙都交給他，你得到的會是第二位執行長，而不是員工。 - **MCP server** — 公司系統：CRM、銀行、倉庫。它不是知識，而是連線。 - **Plugin** — 從商店購買的現成解決方案，把流程、專家和整合功能裝進同一個盒子。 一旦理解這四者是同一個系統的四個層次，而非四個互相競爭的選項，「哪個比較好？」這個問題就消失了。剩下的問題是「什麼該放在哪裡？」 ## Claude Code 的 Skill 是什麼？什麼時候該安裝？
重要重點 Skill 是包含 `SKILL.md` 檔案（YAML frontmatter + Markdown 指示）的資料夾，位置在 `~/.claude/skills//`，或專案中的 `.claude/skills//`。它採用漸進式揭露：啟動時只載入名稱與描述（約 100 個 tokens）；只有任務符合觸發條件時，才會載入完整內容。這是四種機制中閒置時成本最低的一種。
Anthropic 的官方定義：

Skills 是可重複使用的檔案資源，能為 Claude 提供領域專業知識：工作流程、脈絡與最佳實務，讓通用型 agent 成為專家。

— Anthropic Docs, https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
Skill 有三個層次： 1. **Metadata。** 在工作階段啟動時一律載入：frontmatter 中的名稱與描述。每個 skill 在啟動時約使用 100 個 tokens。 2. **Instructions。** 只有 Claude 看到觸發請求時才載入。最多 5,000 個 tokens，也就是 SKILL.md 的本文。 3. **Resources。** 只有指示明確要求時才載入。套件檔案、`scripts/` 中的 scripts，以及 `references/` 中的參考資料。Scripts 透過 `bash` 執行；程式碼本身不會進入脈絡。 Anthropic 將這個原則稱為漸進式揭露：

漸進式揭露是讓 Agent Skills 保持靈活並能擴充的基礎設計原則。

— Anthropic Engineering, https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
同一篇文章中還有一個比任何說明都更能解釋這個概念的比喻：

為 agent 建立 skill，就像替新進員工撰寫到職指南。

— Anthropic Engineering, https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
**適合使用 skill 的情況：** - 你一再重複的標準流程，例如 PR 審查、發布說明，或依照你的風格指南進行程式碼審查。 - `CLAUDE.md` 中某一節已從事實資訊變成操作流程，開始妨礙其他所有工作。 - 你希望不同專案都能一致遵循同一套指示。 一個實用的公式：**同一件事做超過幾次，就交給系統處理**。第一次使用手動 prompt；第二次就可以考慮做成 skill。 **不適合使用 skill 的情況：** - 任務需要**即時資料**（資料庫、API、搜尋、目前的股市資料）。這是 MCP 的工作，不是 skill。試圖「取得目前價格」的 skill 會產生幻覺。 - 任務需要**隔離的脈絡**。這是 subagent 的工作。 - 如果需要**強制檢查**（「阻擋含有 .env 的提交」），應為涵蓋的提交路徑設定 hook，不能只靠 skill。請審查並測試實際涵蓋範圍；hook 不會限制讀取、複製或發布該檔案的所有方式。 事先應了解的限制： - Skill 名稱最多 64 個字元，只能使用小寫字母、數字和連字號。`anthropic` 和 `claude` 是保留字。 - Description 最多 1,024 個字元。清單中的 `description` + `when_to_use` 合計超過 1,536 個字元時會遭到截斷。 - SKILL.md 本文建議不超過 500 行。超出的內容移到 `references/` 和 `scripts/`。 - 自動脈絡壓縮（auto-compaction）時，每個啟用中的 skill 會重新附加前 5,000 個 tokens。所有 skills 的總預算是 25,000 個 tokens。 ## Subagent 是什麼？為什麼最多可以巢狀 5 層？
重要重點 Subagent 是子 Claude，擁有自己的 200K-token 脈絡、system prompt、有限工具清單和獨立權限。它的主要用途是隔離：雜亂的搜尋結果、冗長的 logs 和探索性工作都留在 subagent 中，只有最後的摘要會回到主要脈絡。自 2026 年 6 月 10 日起，subagents 最多可以巢狀遞迴 5 層。
官方文件摘錄：

Subagents 是處理特定類型任務的專用 AI 助理。如果某個附帶任務可能會讓主要對話塞滿搜尋結果、logs 或你不會參考的檔案內容，就使用 subagent。Subagent 會在自己的脈絡中完成工作，並只回傳摘要。

— Claude Code Docs, https://code.claude.com/docs/en/sub-agents
Claude Code 有三個你早已在使用、可能卻不知道的內建 subagents： | Subagent | 模型 | 存取權限 | 工作範圍 | |----|----|----|----| | **Explore** | Haiku | 唯讀 | 搜尋程式碼；略過 CLAUDE.md 和 git status 以節省脈絡 | | **Plan** | Haiku | 唯讀 | Plan mode — 撰寫程式碼前先思考 | | **General-purpose** | Sonnet/Opus | 所有工具 | 複雜的多步驟任務 | 2026 年 6 月 10 日，Anthropic 發布 Claude Code v2.1.172，移除了自 subagents 推出以來一直存在的限制：子 agents 現在可以產生自己的 subagents，最多深入 5 層。 數字 5 是安全上限，不是最佳化目標。 YAML orchestrator 範本的完整功能說明，請見[巢狀 subagents 指南](https://ailoot.ai/blog/zh-hant-tw/claude-code-nested-subagents/)。 **適合使用 subagent 的情況：** - 探索程式碼或 logs，而你最後只需要簡短結論。 - 可以同時並行執行的任務。 - 依專業分工委派：backend / frontend / test / review，各自負責一項功能。 - 控制成本：用 Haiku subagent 取代 Sonnet 或 Opus，費用可降低 5–7 倍。 **不適合使用 subagent 的情況：** - 一次性的簡單小任務或簡單工具呼叫。啟動 subagent 有額外成本。 - 任務需要共享狀態時。Subagents 看不到彼此的脈絡；相關工作應留在主執行緒中。 主要反模式： 給 subagent Opus 和所有工具，只會讓它成為另一個主要工作階段。如果它的工具清單和主要 agent 相同，就代表沒有適當限制這個 subagent。 換句話說，權限與 parent 相同的 subagent，只是第二位執行長。既無意義，又昂貴。 ## MCP Server 是什麼？什麼時候該連接到 Claude Code？
重要重點 MCP（Model Context Protocol）是 Anthropic 制定的開放標準，用來將 AI 連接到外部系統：資料庫、API、檔案系統和 SaaS。截至 2026 年 6 月，Claude、ChatGPT、Cursor、VS Code 及數十種其他用戶端都支援 MCP。modelcontextprotocol.io 提供了一個好懂的比喻：MCP 是 AI 應用程式的 USB-C 連接埠。
官方定義：

把 MCP 想成 AI 應用程式的 USB-C 連接埠。就像 USB-C 標準化了電子設備的連接方式，MCP 也提供連接 AI 應用程式與外部系統的標準方式。

— modelcontextprotocol.io, https://modelcontextprotocol.io/introduction
實際上，MCP 可以讓你做到： - 將 Claude 連接到 Google Calendar 和 Notion，打造個人助理。 - 連接 Figma，讓 Claude 根據設計產生可直接使用的 Web 專案。 - 將企業聊天機器人一次連接到多個資料庫。 - 連接 Blender 和 3D 印表機，建立模型後立即列印。 最常被優先安裝的知名 MCP servers： | MCP server | 連接內容 | 取得方式 | |----|----|----| | **Context7** | 任何程式庫的最新文件 | claude-plugins-official 的 plugin | | **GitHub** | Issues、PRs、repositories | claude-plugins-official | | **Filesystem** | 獲准資料夾中的檔案（在 Claude Code 中只限工作資料夾） | 參考用 MCP 專案伺服器，repository modelcontextprotocol/servers | | **Postgres** | 直接存取資料庫 | 參考伺服器已停止維護；目前的替代方案是 Bytebase 的 DBHub | | **Magic MCP by 21st.dev** | 動畫和 UI 元件 | MCP 目錄 | | **Slack / Linear / Jira / Notion** | 工作場所整合 | claude-plugins-official | MCP 目錄整理了連線方式和安裝指令。 **適合使用 MCP 的情況：** - 任何連接外部資料或執行外部操作的需求，例如「從資料庫取得資料列」、「讀取 Jira 工單」、「在 Slack 發文」。 - 多個專案或 agents 都需要同一個服務時，集中使用一個 server 會更簡單。 **不適合使用 MCP 的情況：** - 靜態知識或流程。這是 skill 的工作，不是 MCP。「程式碼審查的操作說明」是 skill。「讀取 GitHub 上最新的 PR 並進行審查」則需要 MCP。 - 一次性的 CLI 指令。使用 `Bash` 比設定 server 簡單。 - 只為了「架構更正確」而打造 MCP。那只是講究形式，不是解決任務。 2026 年「Claude Code 變笨了」的抱怨來源中，MCP 的主要陷阱是最常見的原因之一： 一次安裝所有這些 MCP，最後會塞爆 LLM 的脈絡視窗：所有可用工具都會載入脈絡。 實用的經驗法則是：針對特定任務啟用的 MCP servers 不要超過 2–3 個。文中描述的多伺服器使用經驗顯示，啟動速度變慢，錯誤也更常發生。 **MCP tool search** 在 Claude Code v2.1.x 中推出：工具不再一股腦載入脈絡，而是先建立索引，需要時再擷取。這降低了「專案中有很多 MCP」的成本，但沒有完全消除成本。 ## Plugin 和 Skill 有何不同？為什麼兩者的界線變模糊？
重要重點 Plugin 是打包好的組合，可以任意搭配 skill、subagent、MCP server 和 hook。Anthropic 將這些內容整合成一種格式，只要一個 `/plugin install` 指令就能安裝並自動更新。`claude-plugins-official` marketplace 在 2026 年 2 月推出；到了 6 月，已有 101 個 plugins。「單獨的 skill」和「只包含一個 skill 的 plugin」之間，差別純粹在打包方式。
官方說明：

Plugins 透過 skills、agents、hooks 和 MCP servers 擴充 Claude Code。Plugin marketplaces 是用來尋找及安裝這些擴充功能的目錄，讓你不必自行組裝。可以把它想成連接應用程式商店：加入商店後，就能瀏覽其中的集合，但要下載哪些應用程式由你決定。

— Claude Code Docs, https://code.claude.com/docs/en/discover-plugins
2026 年 6 月依安裝數排名的領先 plugins： | 排名 | Plugin | 安裝數 | 內容 | |----|----|----|----| | 1 | **Frontend Design** (Anthropic) | 829 316 | 設計用 skills + subagents | | 2 | **Context7** (Upstash) | 348 660 | 文件用 MCP wrapper | | 3 | **Code Review** (Anthropic) | 347 221 | 5 個平行執行的審查 subagents | | 4 | **Code Simplifier** | 284 632 | 簡化用 skill + hook | | 5 | **TypeScript LSP** | 177 136 | LSP plugin | | 6 | **Pyright LSP** | 91 225 | LSP plugin | 完整選擇分析請見101 個 plugins 中的十大精選指南。 **適合使用 plugin 的情況：** - 可涵蓋大部分工作流程的現成社群套件，例如設計或審查。 - 不想手動組裝「skill + subagent + MCP + hook」時，可以改用現成套件。 - 企業內部發佈：管理員建立團隊 marketplace，開發人員即可透過單一前綴安裝。 **不適合使用 plugin 的情況：** - 一個 skill 就能解決任務，套件卻「以防萬一」多帶了五個 MCP。這純粹是在脈絡中堆垃圾。 - 無法稽核的封閉原始碼 plugin。它會以你的權限執行，安裝前先閱讀內容。 - 你已經有同一主題的 plugin。脈絡中出現重複項目，麻煩也會加倍。 Claude Code v2.1.143+ 在安裝前會顯示 **Context cost**，估算 plugin 對每則訊息增加的 tokens。自 v2.1.145+ 起，也會顯示 **Will install** 欄位，完整列出套件中的 commands、agents、skills、hooks、MCP 和 LSP。按下安裝前，應先開啟這個畫面。 ## 2026 年該用哪一種選擇矩陣？
重要重點 本指南最主要的成果是一棵包含六個問題的決策樹。由上往下回答，遇到第一個符合的答案就停止。這套演算法涵蓋 95% 的任務。剩下的 5% 是複雜情境，需要組合 Haiku subagent、預先載入慣例的 skill，以及範圍明確的即時資料 MCP server。這就是值得採用的「2026 年公式」。
依優先順序排列的六個問題： 1. **這是會重複使用的流程、風格或檢查清單嗎？** 如果是，選 **skill**。 2. **你需要外部資料或操作**（資料庫、API、Slack、GitHub、Figma）嗎？如果是，選 **MCP server**。 3. **你需要獨立脈絡，以免弄亂主要脈絡嗎？** 如果是，選 **subagent**。 4. **你需要在指定事件執行檢查或自動步驟嗎？** 如果是，選 **hook**，並測試其涵蓋範圍；更廣泛的存取邊界需靠權限或環境隔離。 5. **你想一鍵取得包含 1–4 的現成套件嗎？** 如果是，選 marketplace 的 **plugin**。 6. **這是需要資料、脈絡和風格的複雜任務嗎？** 那就使用**組合**：Haiku subagent + 預先載入的 skill + 一個範圍明確的 MCP。 組合公式： Haiku subagent 搭配預先載入慣例的 skill，以及範圍明確、提供即時資料的 MCP server，是一種確實能發揮效果的模式。 依賴方向的主要規則是： Subagents 可以使用 MCP servers。MCP servers 無法使用 subagents。 換句話說，MCP 永遠負責資料與操作，不是 agents。若要委派任務，應由呼叫 MCP 的 subagent 負責，而不是讓 MCP 反過來呼叫 subagent。 本文描述了一個具體例子：某數位代理商的編輯引擎，可在 60 分鐘內撰寫一篇 SEO 文章。內部有 **25 個 subagents 和 14 個審查階段**，依序執行，每個都擁有自己的脈絡、權限，以及編輯慣例 skill。一個 subagent 會連接到 MCP server，從中存取現成標籤和舊文章的資料庫。主要 orchestrator agent 使用 Opus；子 agents 使用 Haiku，讓預算維持在合理範圍。 這不是「文章工廠」，而是示範當任務追求品質深度而非速度時，如何將四種機制結合成一個系統。 ## 現在應該從 Claude Code 移除哪 7 個錯誤做法？
重要重點 以下是本文討論的七個主要錯誤。每個錯誤都會降低回答品質並消耗 tokens，也都能在 5–15 分鐘內修正。如果你上個月安裝了超過十個 plugins，幾乎可以確定至少犯了其中三個錯誤。
1. **因為熱門就安裝了所有前 10 名 plugins。** 每個 plugin 都會為每則訊息增加 tokens。開啟 `/plugin list` 並檢查每個項目的 Context cost。兩週沒用過的就移除。 2. **從別人的 `.mcp.json` 複製了 15 個 MCP servers。** 別人的設定是為別人的專案和任務量身打造。目前專案啟用的 MCP 不要超過 2–3 個。多出來的移到另一個專案的獨立設定，或現在就刪除。 3. **Skill 和 MCP plugin 做了同一件事。** Skill 說「進行程式碼審查」，而 `pr-review-toolkit` plugin 也會執行自己的審查流程。它們開始爭奪優先順序。症狀是：「Claude，你為什麼一直來回改變做法？」解決方法是保留一個唯一可信來源。文中介紹的設定選擇保留 skill，以掌控指示內容。 4. **需要 hook 強制執行時，卻使用 skill。** Skill 是建議，不是保證。若要「阻擋在提交中加入 `.env`」，**pre-commit hook** 可檢查該提交路徑。請分別測試暫存內容與替代路徑；它無法阻止所有讀取或其他發布方式。單靠 skill 不能強制執行這項邊界。 5. **Subagent 的權限和 parent 相同。** 你給了它 Opus 和所有工具，結果又得到一個主要工作階段。官方文件的 system prompt 建議為 subagent 設定有限的工具清單和受限的獨立任務，否則它只是昂貴的複製品。 6. **安裝 plugin 前沒有檢查 Will install。** 在 Claude Code v2.1.145+ 中，這個欄位會顯示套件的完整內容。號稱只處理一件小事的 plugin，往往會包含三個 MCP servers、兩個 subagents 和五個 hooks。它們全都會進入脈絡。 7. **舊的 `.claude/commands/` 和新的 skills 重複。** Anthropic 在文件中指出：

自訂 commands 已整併至 skills。檔案 .claude/commands/deploy.md 和 skill .claude/skills/deploy/SKILL.md 都會建立 /deploy，而且運作方式相同。

— Claude Code Docs, https://code.claude.com/docs/en/skills
舊的 `commands/` 資料夾仍可使用，但 skills 現在才是標準。文中介紹的例子同時使用了兩個資料夾；後來移除 `commands/`，保留包含套件檔案與觸發條件的 skills。 Claude Code 變得「雜亂」的跡象： - 每則訊息一開始就列出 200 多行可用工具。 - 簡單任務比一個月前花更久時間。 - Claude 混淆兩個相似的 skills 或 plugins。 - 工作階段啟動時出現名稱衝突警告。 - Claude 呼叫錯誤的工具，例如需要 MCP B 時卻使用 skill A。 如果你至少遇到其中兩種症狀，現在就開啟 `/plugin list` 和 `/skill list`。先移除兩週沒用過的項目，再檢查每個項目的 Context cost，最後處理上述反模式。 ## Skills 和 MCP 最多能保留多少，才不會耗盡脈絡？
重要重點 沒有嚴格上限，但有實用門檻。最多保留 10–12 個啟用中的 skills，否則 Anthropic 的 meta 限制會在 auto-compaction 時開始截掉每個 skill 的內容。每個專案最多保留 2–3 個啟用中的 MCP servers。Plugin 只在每則訊息的 Context cost 低於 1,000 個 tokens 時使用。這些門檻來自實際經驗，而非理論。
Claude Code 會直接顯示的內容： - `/skill list` — 所有啟用中 skills 的清單和 token 大小。 - `/plugin list` — 所有 plugins 的清單和 Context cost。 - `/mcp list` — MCP servers 和工具數量。 實際的 token 預算： | 機制 | 閒置時的成本 | 觸發時的成本 | 上下文容量 | |----|----|----|----| | **Skill** | 約 100 個 tokens（只有 metadata） | 實際載入的指示與資源 | 使用呼叫端的上下文 | | **Subagent** | 約 50 個 tokens（名稱和描述） | 實際輸入、輸出、工具結果與後續回合 | 獨立視窗；200K 範例表示容量，不是每次委派的費用 | | **MCP server** | 用戶端載入的工具描述 | 載入的參數與結果；服務執行可能另計費 | 使用呼叫端的上下文 | | **Plugin** | 已載入內部元件的總和 | 內部元件的實際使用量 | 取決於所含元件 | 上下文視窗是可用的最大工作空間，不是每項任務一定消耗的 tokens。請以相同成果比較實測輸入、快取輸入、輸出與後續回合；隔離可縮小主對話，但子代理仍有自己的用量。 Anthropic 在技術部落格中提供了 skills 的 auto-compaction 數據：每個啟用中 skill 的前 5,000 個 tokens 會重新附加，總預算為 25,000。這代表同時啟用超過 5 個「重量級」skills 時，Claude 開始遺失部分指示。 簡單的實用規則： - **Skills：** 目前專案啟用的數量不超過 5–7 個。其餘放在 `~/.claude/skills/disabled/`；需要時可以移回來。 - **MCP：** 每個專案不超過 2–3 個。文件用的 Context7 幾乎總是值得保留；其他的按任務需求使用。 - **Plugins：** 一次只安裝一個，兩週後檢查是否用過。沒用就移除。 另一篇指南詳細分析 Anthropic 的 2026 Agentic Coding Trends Report，並探討為什麼 80% 的開發者無法將任務完整委派給 Claude。該報告的主要數字是：人們有 60% 的工作會使用 AI，但完全交出去的任務只有 0–20%。主要原因是脈絡過載，以及失去對工具的控制。 ## 初學者該從哪裡開始：最精簡的可行設定
重要重點 如果你剛開始使用，還不知道該選什麼，就先不要安裝這裡列出的任何項目。先打好基礎：`CLAUDE.md`、一個整理專案脈絡的獨立資料夾，以及基本的任務結構。先用最精簡的 Claude Code 實際處理任務兩週。之後你就會清楚看出哪些是重複流程（適合做成 skill）、哪些地方缺少即時資料（需要 MCP），以及哪些任務開始塞滿脈絡（適合交給 subagent）。
工作兩週後的最精簡組合： 1. 在根目錄放一份列出專案規則的 **CLAUDE.md**。 2. 如果你計畫使用 Claude Code 以外的工具，加入 **AGENTS.md** 以保持相容。詳情請見[「如何為 Claude Code、Codex 和 Cursor 製作一份共用的指示檔」](https://ailoot.ai/blog/zh-hant-tw/agents-md-claude-md-one-instruction-file/)。 3. 為主要的重複任務準備 **1 個 skill**。例如，先從符合你風格指南的 `code-review` 開始。 4. 使用 **1 個 MCP server**：以 Context7 查閱最新文件。沒有它，Claude 仍會幻想出不存在的 API。 5. 第一個月使用 **0 個 plugins 和 0 個 subagents**。這不是為了省錢，而是為了掌控。在了解基礎之前，套件只會讓你困惑。 接著依照任務需求調整。出現重複流程？把它做成 skill。需要特定服務的即時資料？加入 MCP。大型任務開始塞滿主要脈絡？交給 subagent。 這就是三層架構：**先整理脈絡**，接著**把重複做幾次的工作交給系統**，最後**加入自動檢查，避免系統自行犯錯**。前一層運作正常後，再加入下一層。
### 來源 - [Agent Skills Overview - Anthropic Docs](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) - [Skills - Claude Code Docs](https://code.claude.com/docs/en/skills) - [Subagents - Claude Code Docs](https://code.claude.com/docs/en/sub-agents) - [Plugins - Claude Code Docs](https://code.claude.com/docs/en/discover-plugins) - [Equipping Agents for the Real World with Agent Skills - Anthropic Engineering](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) - [MCP Introduction - modelcontextprotocol.io](https://modelcontextprotocol.io/introduction) - [GitHub anthropics/skills - open repository](https://github.com/anthropics/skills) - [Anthropic 2026 Agentic Coding Trends Report](https://resources.anthropic.com/2026-agentic-coding-trends-report)
你可以前往 [ailoot.ai](https://ailoot.ai/) 繼續探索 Ailoot。
## 常見問題：Claude Code 變慢了：如何選擇 Skills、Subagents、MCP 和 Plugins ### 委派一次子代理就會自動消耗 200K tokens 嗎？ 不會。上下文視窗表示容量，實際用量來自真正處理的輸入、輸出、工具結果及後續回合。請比較包含快取輸入的實測總用量，不要把最大容量當成固定委派費。 ### 什麼時候該選 skill、MCP server 或子代理？ 重複流程適合 skill；存取即時系統適合 MCP；範圍明確、但細節會塞滿主對話的工作適合子代理。Plugin 是這些元件的套件，安裝前先檢查內容。 ## Ailoot · 公司及其專案組合 Ailoot以累積的營運經驗、廣大的客戶群、穩定的服務及持續的KPI管理為基礎。 公司及其專案組合：數百萬客戶，每月銷售額達數十億。 Ailoot將這些營運經驗用於API存取，讓客戶的產品、代理、應用程式及自動化流程使用AI功能。