別讓 MCP 吃掉
你 Agent 的 Context
199 個工具、每輪 schema 開銷 40K tokens——直到我們用五層架構砍掉 90%。
Service → SDK → CLI → MCP → Skill，讓 AI Agent 用最少的 token 做最多的事。
我們遇到了什麼問題？
三個真實痛點逼出了這套五層架構：Token 爆量、MCP 進程爆炸、Tool 太多選不準。
Token 爆量
Playwright MCP 每次呼叫消耗大量 token。即使不使用，tool schema 仍佔用 context window，每輪都在付帳。
替換成 Playwright CLI 後：
五層分別做什麼？
五層由上到下分別是 Skill（意圖路由）、MCP（寫操作）、CLI（讀操作）、SDK（唯一碰 HTTP 的封裝層）、Service（業務邏輯本體），上層一律 import 下層。
核心原則：Bug Fix 自動傳播——修一個 SDK bug，CLI 和 MCP 同時修好。 沒有 SDK 這層的話，每個消費者各自實作 HTTP + auth + error handling = 維護地獄。
Skill ──invoke──► CLI (讀) / MCP (寫)
MCP ──import──► SDK ──HTTP──► Service
CLI ──import──► SDK ──HTTP──► Service
// SDK 是唯一碰 HTTP 的地方
// 改 SDK = 所有上層消費者同步更新
為什麼少一層都不行？
| 消費者 | 最佳接入層 | 理由 |
|---|---|---|
| 其他 Core Module | Service | 同進程內直接呼叫 services.py，零 overhead |
| Python 腳本 / Notebook | SDK | 程式化存取，完整 error handling |
| 人（終端） | CLI | --help 可發現、pipe 可組合 |
| AI Coding Agent Claude Code / Codex CLI / Gemini CLI |
CLI (讀) / MCP (寫) | 讀走 Bash = 零 schema；寫需要 typed input |
| 排程系統 | CLI | shell command 是排程的通用語言 |
| AI 工作流 | Skill | 高階意圖路由，自動選擇 CLI 或 MCP |
「CLI 是零 overhead 的萬用接口——任何能跑 shell 的東西都能用，
而 MCP 只有支援 MCP protocol 的 client 才能用。」
我們是怎麼走到這裡的？
這套架構不是一次畫出來的——四個階段各解掉當下卡住的痛點，串起來才拼成現在的樣子。
Token 爆量的第一個教訓
Playwright MCP 的 tool schema 極大，每輪對話注入 system prompt。即使那一輪沒用到瀏覽器，照樣消耗 token。替換成 Playwright CLI 後，token 用量下降 98%。
領悟：能走 CLI 的就不該走 MCP。
多開 session 的乘法災難
MCP server 數量長到 23 個之後，每多開一個 Claude Code session 就等比複製所有進程。3 個 session = 69 個常駐進程，解法是 mcpproxy 聚合 + 把讀操作卸載到 CLI。
領悟：減少 MCP server / tool 數量是必要的。
業界最極端的 tool 壓縮
Cloudflare 的 Code Mode MCP 只暴露 2 個 tool：search() 和 execute()。其他所有操作都在沙盒裡即時撰寫。證明了 tool 數量和能力成反比。
領悟：我們不走那麼極端，但同樣的原則——tool 越少越好。
拋棄式 Tools — 沙盒補位
不是所有操作都需要永久的 tool。受 Cloudflare Code Mode 啟發，批量操作在沙盒中即時撰寫，不佔 MCP tool slot。
Cloudflare: 2 permanent tools + sandbox 即時寫所有操作
務實派: ≤10 permanent tools/server + sandbox 補位低頻操作
// 共同原則：永久 tool 是稀缺資源，不值得佔位的就用 sandbox
判斷標準：一個操作值不值得成為永久 tool？
→ 每週使用 ≥ 3 次 + 參數組合複雜 + 需要 discoverability → 五層覆蓋
→ 否則 → sandbox 即時寫，用完即丟
如果不用五層？
| 替代方案 | 問題 | 後果 |
|---|---|---|
| 只有 Service | 只能 HTTP 呼叫 | AI agent、cron、CLI 使用者全部要自己寫 HTTP client |
| Service + MCP | Token overhead + 進程爆炸 | 23 servers × 3 sessions = 69 進程，schema 每輪吃 token |
| Service + CLI | 寫操作缺 typed schema | LLM 傳錯參數、沒有 input validation |
| 全部走 MCP | CLI 使用者被排除 | Codex CLI、Gemini CLI、cron 全部無法接入 |
| 各層獨立實作 HTTP | 沒有 SDK 統一 | 改一處漏一處，Ghost Parameter 反模式叢生 |
用 Agent SDK 自己控制 Tool 注入
如果你用 Agent SDK 自建 client，可以在應用層完全控制哪些 tool schema 進入 LLM 的 context——不需要等平台支援。Speakeasy 的動態工具集方案用同樣的思路篩選 tool，削減了 96% token。
all_tools = mcp_server.tools_list() # 收到 199 個（protocol 層）
relevant = bm25_filter(all_tools, query) # 你自己過濾到 5 個
response = client.messages.create(
tools=relevant, # 只送 5 個給 LLM
)
關鍵區分：MCP protocol 層的 tools/list 回傳全部工具——這改不了。
但你的 client 決定放什麼進 API 的 tools[]——這完全你控制。
用 Claude Code 等現成 client？它幫你全塞。自建 client？你自己篩。
OpenCLI 社群的風向轉變
開源社群正在把 CLI 當成預設介面，不是我們自己在喊的方向。
OpenCLI 把網站和桌面應用轉成標準化 CLI；CLI-Anything 要讓所有軟體都能被 Agent 透過 CLI 操作。越來越多開發者在問「有沒有 CLI」而不是「有沒有 API」。
原因很直接：The New Stack 2025 年的報導寫過，整個產業正在進入 Agentic CLI 時代。當 AI coding tool 全都能跑 shell，CLI 自然成為跨工具的最大公約數。
不是 CLI 復興——是 AI 時代重新發現了 CLI 的價值。
199 個工具，一套邏輯
讀走 CLI、寫走 MCP——199 個工具就靠這一條分界運作，人、腳本、AI 各取所需。
從 Token 爆量到社群風向驗證，每一步都是痛點逼出來的，改一處、全部同步。
痛點 1: Playwright MCP token 爆量
→ CLI 省 98% token
痛點 2: 多開 CC → 進程等比增長
→ mcpproxy 聚合 + CLI 卸載讀操作
痛點 3: Tool 太多 LLM 選不準
→ ≤10 tools/server + sandbox 補位
驗證 1: Cloudflare 只用 2 tools 跑整個 IDE
→ 同原則，我們更務實
驗證 2: OpenCLI 社群轉向 CLI-first
→ AI 時代，CLI 是跨工具最大公約數
// 歸納
Service → SDK → CLI → MCP → Skill
199 個工具，一套邏輯，三種消費者
先算你自己的 schema 帳單
上面那筆 40K tokens 是我的環境，換成你的數字結果會完全不同。填三個欄位，用本文引用過的兩個常數（每個 tool schema 約 200 tokens、業界建議每個 MCP server ≤ 10 tools）算出屬於你的每輪開銷與常駐進程數。全部在瀏覽器裡算，沒有任何資料送出去。
常數出處都在本文：200 tokens/schema 來自「8 tools × 200 tokens/schema = 1,600 tokens/turn」，進程數來自「3 sessions × 23 MCP servers = 69 個常駐進程」的線性關係，10 tools/server 是文中引的業界建議。這裡只算 schema 常駐開銷，不含實際 I/O——真實用量還要看你怎麼呼叫。
複製給你的 AI Agent
MCP tool schema 每輪都佔 token，但你多數的 tool 其實是「讀」——根本不用 schema。工具一多，光 schema 就吃掉幾萬 token，超過 10 個 LLM 選錯的機率還會上升。這篇的五層架構就是把「讀」趕下 CLI、只留「寫」給 MCP。
把下面貼給你的 AI，讓它先實地盤點你現在的 MCP 設定，再對照這套五層判斷哪些能搬：
延伸閱讀
下面幾篇都實際讀過、也真的影響過決定，不是隨手蒐集的清單。
| 文章 | 為什麼重要 |
|---|---|
| Code Mode: Give Agents an Entire API in 1,000 Tokens | Cloudflare 實測只用 2 個 tool 跑整個 IDE，token 開銷減少 81%。驗證了「tool 越少越好」的原則 |
| Your MCP Server Is Eating Your Context Window | Apideck 分析 MCP schema 如何吃掉 context，提出 CLI 作為替代方案——80 tokens prompt vs 數萬 tokens schema |
| Advanced Tool Use — Anthropic Engineering | Anthropic 官方承認 tool schema 佔用 context 的問題，推出 Tool Search 機制實現 85% context 削減 |
| How We Reduced Token Usage by 100x: Dynamic Toolsets | Speakeasy 的動態工具集方案，做到 96% input token 削減 |
| MCPProxy — MCP Gateway | 開源 MCP 聚合閘道，用 BM25 索引動態發現工具，支援數百個 server + 數千個 tool |
| Welcome to the Agentic CLI Era | The New Stack 報導 AI coding tool 全面轉向 CLI 的產業趨勢 |
| OpenCLI — Universal CLI Hub | 專為 AI Agent 設計的通用 CLI 中心，把網站、桌面應用轉換成標準化 CLI |
| CLI-Anything — Making ALL Software Agent-Native | 香港大學研究：讓所有軟體都能被 AI Agent 透過 CLI 操作 |