MCP 的未來：從常態開啟到按需載入
一個關於 Claude Code 架構演進的提案 - 將 MCP 伺服器指派給特定 Agent 和 Skill，而非在 Session 開始時全部載入。
問題：Context 預算的壓力
如果你使用 Claude Code 搭配多個 MCP 伺服器，你可能已經注意到：在你輸入第一條訊息之前，context window 就已經開始被佔用了。
這是一個典型的情況：
| MCP 伺服器 | 大約 Token 消耗 | 來源 |
|---|---|---|
| GitHub (27 tools) | ~18,000 | Issue #11364 |
| AWS MCP servers | ~18,300 | Issue #7172 |
| Cloudflare | ~15,000+ | 社群回報 |
| Sentry | ~14,000 | 社群回報 |
| Playwright (21 tools) | ~13,647 | Scott Spence |
| Supabase | ~12,000+ | 社群回報 |
| 平均每個 tool | ~550-850 | Issue #11364 |
實測影響：啟用 7 個 MCP 伺服器時，光是工具定義就消耗 67,300 tokens（200k context 的 33.7%）。即使是最小化的 3 伺服器配置也消耗 42,600 tokens（21.3%）。
諷刺的是，這些 MCP 中有很多在特定 session 中根本不會被使用。那個佔用 14,000 tokens 的 Sentry 整合？你今天可能根本不需要它。但它就在那裡，每次都在消耗 context。
觀察：Fork 架構已經存在
Claude Code 2.1.x 引入了一個強大的功能：Skills 的 context: fork。這允許 skills 在隔離的 context 中運行，擁有自己的工具權限和狀態。
# 具有 forked context 的 skill
---
description: 部署到生產環境
context: fork
allowed-tools: [Bash, Read]
---當這個 skill 運行時，它會獲得自己的 context 泡泡。變更不會污染主對話。乾淨、隔離、有效。
關鍵洞察：如果我們可以 fork context，為什麼不能 fork MCP 存取權限呢？
提案：MCP Context 隔離
重要區別：這個提案與一般的「延遲載入」方案有本質上的不同。我們不是建議在主 context 中動態載入 MCP。相反，我們提議將 MCP 隔離到 forked agent/skill context 中，讓主 context 永遠保持乾淨。
| 方案 | 主 Context | 載入時機 | 複雜度 |
|---|---|---|---|
| 傳統 Lazy Loading | 需要時被 MCP 佔用 | Runtime 動態 | 高（狀態管理） |
| 我們的提案：Context 隔離 | 永遠保持乾淨 | Fork 時一次載入 | 低（使用現有 context: fork） |
傳統 Lazy Loading:
Main Context ──[需要 MCP]──> 載入 MCP ──> Main Context（被佔用）
我們的提案（Context 隔離）:
Main Context（保持乾淨）
└── Fork Agent Context ──> 載入 MCPs ──> 隔離的 Context
└── 結束後釋放想像這樣的架構：
# agents/database-specialist.md
---
name: database-specialist
description: 資料庫操作專家
tools: [Read, Bash, Grep]
mcp: [postgres, redis] # ← 只有這個 agent 運行時才載入
context: fork
---# skills/deploy/SKILL.md
---
description: 部署到生產環境
mcp: [vercel, github] # ← 只有執行 /deploy 時才載入
context: fork
---主 session 保持精簡：
Main Session（精簡）
│
├── 只有基礎 MCP：filesystem, memory
│ （~1,300 tokens 而非 20,000+）
│
├── Task: database-specialist（forked）
│ └── 載入：postgres, redis（僅在此處）
│
└── Skill: /deploy（forked）
└── 載入：vercel, github（僅在此處）真實案例：現代工作中樞的困境
這是許多人每天面對的情況：
多平台現實
現代知識工作者需要同時處理大量平台：
| 類別 | 平台 |
|---|---|
| 程式碼託管 | GitHub, GitLab, Bitbucket |
| 專案管理 | Jira, Linear, Asana, Notion |
| 通訊協作 | Slack, Discord, Teams, Email |
| CI/CD | Vercel, Netlify, AWS |
| 監控 | Sentry, Datadog, PagerDuty |
| CRM/商務 | Salesforce, HubSpot, Stripe |
這些都有對應的 MCP。現在想像這個兩難：
選項 A：全部安裝
Session 開始時載入所有 MCP：
- github (~2,000 tokens)
- gitlab (~2,500 tokens)
- slack (~3,000 tokens)
- jira (~4,000 tokens)
- notion (~2,500 tokens)
- sentry (~14,000 tokens)
- ...還有另外 10 個
總計：50,000+ tokens，在你開始工作之前就消耗了。
這可能是你 context 預算的 50%。沒了。選項 B：按專案分開
專案 A: github + vercel
專案 B: gitlab + jira
專案 C: slack + notion這完全違背了初衷。Claude Code 的強大之處在於它是統一的指揮中心 - 一個協調所有工具的地方。按專案分割意味著：
- 不斷切換 context
- 失去跨平台洞察
- 無法統一自動化工作流
選項 C：按需載入的未來
# skills/work-hub/SKILL.md
---
description: 統一工作管理中樞
mcp:
communication: [slack, discord]
code: [github, gitlab]
projects: [jira, notion]
monitoring: [sentry]
context: fork
---現在 Claude Code 成為它應該成為的樣子：你數位工作生活的真正中樞神經系統。需要：
- 檢查 GitHub PR + 通知 Slack + 更新 Jira？一個指令。
- 審查 GitLab MR + 發到 Discord + 記錄到 Notion？一個指令。
- 除錯 Sentry 錯誤 + 建立 GitHub issue + 在 Linear 分配？一個指令。
每個工作流只載入它需要的 MCP。你的主 context 保持乾淨。
目前的變通方案（不理想）
是的，你現在可以使用 skills 來包裝功能而不使用 MCP - 透過 bash/curl 直接呼叫 API。但這樣：
- 更脆弱（沒有 MCP 的錯誤處理）
- 更囉唆（原始 API vs. 語意工具）
- 錯失重點（我們有 MCP 是有原因的）
最關鍵的問題是認證：
| 面向 | MCP | Skills + Scripts |
|---|---|---|
| 認證管理 | 集中在 settings.json | 散落在 .env、scripts、環境變數 |
| 安全性 | 環境隔離 | 容易外洩到 logs/shell history |
| Token 刷新 | 自動處理 | 需自己實作 |
| 錯誤處理 | 標準化回應 | 各 API 不同 |
# MCP 方式 - 乾淨且安全
mcp: [github]
# 認證在 settings.json，隔離，永不暴露
# Script 方式 - 認證散落各處
# 選項 1：.env 檔案（需要管理）
# 選項 2：寫死在 script 裡（危險）
# 選項 3：每次都要傳遞（繁瑣、易出錯）MCP 的價值不只是工具本身——而是集中且安全的認證管理。Context 隔離保留了這個優勢，同時解決了 context 消耗的問題。
按需載入架構不只是優化。它是解鎖 Claude Code 作為通用工作協調器潛力的關鍵。
為什麼這是合理的
1. Context 效率
你的主對話保持完整的 context 預算。MCP 只有在需要它們的特定 agent 或 skill 運行時才載入。
2. 細粒度權限
不再是「這個 session 可以存取所有東西」，而是分層控制：
Layer 0: 主 Context（最小權限）
└── filesystem（只讀）, memory
Layer 1: 開發 Agents
└── code-reviewer: + git（讀取）
└── debugger: + bash（沙盒）
Layer 2: 專門 Skills
└── /deploy: + vercel, github（推送）
└── /db-migrate: + postgres（寫入）
Layer 3: 管理操作
└── /production-access: 全部（需確認）3. 漸進式安全
不再是「全有或全無」的權限，而是縱深防禦。程式碼審查不需要資料庫寫入權限。部署不需要 Sentry 存取權限。
4. 生態系統可擴展性
MCP 生態系統正在爆發式成長。每週都有數十個新伺服器。「在開始時載入所有東西」的模式根本無法擴展。
實現可能性
理想的解決方案結合雙向配置，以達到最大靈活性和向後相容：
MCP 端：延遲載入標記
在 settings.json 中，每個 MCP 可以聲明是否在 session 開始時載入：
{
"mcpServers": {
"memory": {
"command": "...",
"lazy": false // 總是載入（預設，向後相容）
},
"github": {
"command": "...",
"lazy": true // 請求前不載入
},
"postgres": {
"command": "...",
"lazy": true // 請求前不載入
}
}
}向後相容：省略 lazy 或設定 lazy: false 維持現行行為。
Agent/Skill 端：Frontmatter 聲明
Agents 和 skills 聲明它們需要哪些 MCP：
# agents/database-specialist.md
---
name: database-specialist
description: 資料庫操作專家
tools: [Read, Bash, Grep]
mcp:
required: [postgres] # 必須有
optional: [redis] # 有最好
context: fork
---載入邏輯
MCP lazy 設定 | Agent/Skill 聲明 | 結果 |
|---|---|---|
false（或省略） | - | ✅ Session 開始時載入（現行行為） |
true | 未聲明 | ❌ 不載入 |
true | mcp: [xxx] | ✅ Agent/Skill 執行時載入 |
這種雙向方式實現：
- 漸進式遷移：逐一將大型 MCP 改為
lazy: true - 零破壞性變更：現有配置照常運作
- 細粒度控制：基礎設施層和應用層都可設定
證據：Claude Code 正朝這個方向發展
看看演進過程：
| 版本 | 功能 | 趨勢 |
|---|---|---|
| 2.0.65 | Context awareness, status line | 追蹤 context 使用 |
| 2.1.0 | Skills 的 context: fork | 隔離架構 |
| 2.1.1 | Agent frontmatter | 可配置 agents |
| 2.1.3 | Skills = Commands 統一 | 簡化 |
| 2.2.x? | 按需 MCP？ | 邏輯下一步 |
架構基礎已經存在。系統已經支援。需求很明確。
需要考慮的挑戰
| 挑戰 | 可能的解決方案 |
|---|---|
| MCP 啟動延遲 | 預熱池，首次提及時預連接 |
| Fork 結束後的狀態 | 無狀態設計，session 級快取 |
| 工具發現 | 延遲清單 - 工具已聲明但未載入 |
| 憑證範圍 | 帶限制的環境繼承 |
這些都是可解決的問題。Fork 架構已經處理了大部分。
願景：Claude Code 作為通用工作協調器
這個提案不只是為了節省 token。它是關於釋放 Claude Code 真正能夠成為的東西。
今天，Claude Code 是一個強大的 coding 助手。有了按需 MCP 載入，它將轉變為更有野心的東西：你整個數位工作生活的通用協調器。
架構組件已經就位：
context: fork提供隔離- Agent/Skill frontmatter 提供聲明
- MCP 生態系統提供整合
缺少的是連接：讓 agents 和 skills 能夠聲明並按需載入它們自己的 MCP。
這是自然的下一步。問題不是這會不會發生，而是何時和如何發生。
本提案發布於 claude-world.com，作為我們持續探索 Claude Code 架構可能性的一部分。