別讓 MCP 吃掉
你 Agent 的 Context
199 個工具、每輪 schema 開銷 40K tokens——直到我們用五層架構砍掉 90%。
Service → SDK → CLI → MCP → Skill，讓 AI Agent 用最少的 token 做最多的事。
我們遇到了什麼問題？#
這不是先想好五層再實作的——是從三個真實痛點自然演化出來的。
Token 爆量#
Playwright MCP 每次呼叫消耗大量 token。即使不使用，tool schema 仍佔用 context window，每輪都在付帳。
替換成 Playwright CLI 後：
MCP 進程爆炸#
每開一個 Claude Code session，所有 MCP server 進程等比複製。
= 69 個常駐進程
// RAM 和 CPU 線性吃滿
Tool 太多選不準#
單一 MCP server tool 數量過多時，LLM 的工具選擇準確率下降。
業界最佳實踐：每個 MCP server ≤ 10 tools。
8 tools × 200 tokens/schema = 1,600 tokens/turn（不管用不用）
Token 成本比較#
不同呼叫方式的每輪 token 開銷（不含實際 I/O）
每輪 schema 開銷（tokens）
每輪 schema 開銷（tokens）
累計浪費在未使用的 schema
整個 IDE 只用 2 個工具
五層分別做什麼？#
每一層服務不同的消費者，由上到下逐層依賴。
核心原則：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 越少越好。
新模組完整走完五層#
Backend → SDK → CLI → MCP → Skill，缺一層就造成下游整合斷裂。有了 BaseClient DRY 模式後，新增模組的邊際成本遞減，但每多一層的可組合性是永久收益。
領悟：五層不是負擔，是複利。
拋棄式 Tools — 沙盒補位#
不是所有操作都需要永久的 tool。受 Cloudflare Code Mode 啟發，批量操作在沙盒中即時撰寫，不佔 MCP tool slot。
永久 Tool（五層覆蓋）#
高頻、穩定、需要 discoverability 的操作
search— 每天高頻使用create— 需要 typed schema 驗證render— 複雜參數組合
✓ 值得維護成本 ✓ 有 --help ✓ 可測試
拋棄式 Tool（Sandbox）#
低頻、一次性、或探索性的批量操作
- 批量掃描 + 聚合（3+ API 呼叫）
- 一次性資料轉換
- 探索性腳本（用完即丟）
✓ 零 schema overhead ✓ 不佔 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 的動態工具集方案就是這個做法，做到 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」。
原因很直接：整個產業正在進入 Agentic CLI 時代。當 AI coding tool 全都能跑 shell，CLI 自然成為跨工具的最大公約數。
不是 CLI 復興——是 AI 時代重新發現了 CLI 的價值。
199 個工具，一套邏輯#
從 Token 爆量的第一課到社群的風向驗證——每一步都是痛點逼出來的。
五層不是官僚，是讓人、腳本、和 AI 各取所需，改一處、全部同步。
痛點 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 個工具，一套邏輯，三種消費者
複製給你的 AI Agent#
把下面這段話貼給你的 AI coding agent，讓它幫你評估現有架構、規劃改造方向。
延伸閱讀#
這些是我們在摸索過程中實際參考過、借鑑過的資源。
| 文章 | 為什麼重要 |
|---|---|
| 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 操作 |