別讓 MCP 吃掉你 Agent 的 Context

這份投影片是 1920×1080 畫的，在手機上會縮到很小。橫放、按下面的「全螢幕」或「＋」放大，也可以直接讀底下的旁白逐字稿 —— 每一頁的內容那裡都有。

● 工具接入五層架構context window · resident cost

199

個工具掛在 context 上

這一輪用到的0

說明書的固定開銷40K

實際輸入輸出另計

● 三個坑接下來各講一段

帳單

1,600

每輪固定成本

用不用都在付

機器

常駐進程

三個 session 等比複製

挑錯

199

個候選工具

越多越容易挑錯

● 這支片四分鐘

Skill意圖路由

MCP寫操作

CLI讀操作

SDK唯一碰 HTTP

Service業務邏輯本體

三個坑各講一段

這套拆法怎麼運作

以及它的代價

● session liveturn 01context window · resident cost

prompt

游標還在閃，一個字都還沒送出去

我送出去的字0

跟著上車的 tool schema≈ 40,000

這一輪已經花掉

全部是 tool schema。就算那一輪我一個工具都沒碰，它們照樣佔著 context window，每輪都要付一次。

turn 01tools/list → system prompt

{
  "name": "browser_navigate",
  "description": "Navigate to a URL",
  "inputSchema": {
    "type": "object",
    "properties": {
      "url":     { "type": "string" },
      "timeout": { "type": "number" }
    },
    "required": ["url"]
  }
}

錢花在哪？

工具的說明書

右邊這段 JSON 是 tools/list 回傳的其中一個 tool。 199 份這種東西排隊寫進 system prompt，才是那四萬個 token 的去處。

turn 01all resident · billed every turn

0102030405060708091011121314151617181920212223

tool schemas in context

業界建議一台 MCP server 掛 ≤ 10 個 tool。我這 23 台平均掛了 8.7 個，數量沒超標——超標的是它們加總起來的常駐量。

MCP servers

同時掛載

Tools exposed

199

全部進 context

Used this turn

一個都沒呼叫

Schema cost

40K

每輪都在付，不含實際 I/O

199 份 schema × 約 200 tokens

痛點 01

Playwright

痛點 01Token 爆量system prompt · 每輪重灌

Playwright MCPtool schema

{  "name": "browser_click",  "description": "Click an element",  "inputSchema": {    "type": "object",    "properties": {      "selector": { "type": "string" },      "timeout":  { "type": "number" }    },    "required": ["selector"]  }}

這一輪：瀏覽器沒開

token 照樣要付

痛點 01Token 爆量Playwright CLI

MCP

CLI

-98%token 用量

痛點 02MCP 進程爆炸3 × Claude Code session

MCP server 長到 23 個

0102030405060708091011121314151617181920212223

同時開啟

session Asession Bsession C

痛點 02MCP 進程爆炸69 個常駐進程

個常駐進程

RAM

CPU

RAM 跟 CPU 線性吃滿

痛點 03Tool 太多選不準工具選擇準確率下降

工具一多，就挑錯

挑錯的機率就上升

痛點 03Tool 太多選不準1,600 tokens/turn

MCP server 掛幾個 tool

業界建議 ≤ 10 tools / server

8×200=1,600

tokens/turn，用不用都在付

settle up

這筆帳

逐項核算 · 相同操作

MCP（8 個工具）

tokens/turn

8 × 200 = 1,600

CLI 透過 Bash

0tokens/turn

同樣的操作，走 CLI

實際輸入輸出另計，這裡只算常駐的 schema 開銷。

五十輪之後

1,600×50 輪=

tokens

全丟在你沒用到的說明書上。

業界最極端的壓縮

Cloudflare Code Mode

整個 IDE 只暴露 2 個 tool

兩個 tool 的樣子

search()

找到要動的目標

execute()

在沙盒裡跑

沙盒 · 即時撰寫

execute(search("*.md").batch_rename())

tool 數量 ↓成反比能力 ↑

LAYERS由下往上 · Service → Skill

拆成五層

Skill

MCP

CLI

SDK

Service

LAYER 1/5 · SERVICE業務邏輯本體

Skill意圖路由

MCP寫操作

CLI讀操作

SDK唯一 HTTP 邊界

Service業務邏輯本體

FastAPI routes + business logic + DB

FastAPI routes+ DB

→ 模組間內部呼叫

dependency graph

// 依賴方向（上層 import 下層）

LAYER 2/5 · SDK唯一碰 HTTP 的地方

Skill意圖路由

MCP寫操作

CLI讀操作

SDK唯一 HTTP 邊界

CLI 和 MCP 都 import SDK，不碰 HTTP

── HTTP ──► Service

→ Python 程式 / Notebook

Service業務邏輯本體

dependency graph

// 依賴方向（上層 import 下層）// SDK 是唯一碰 HTTP 的地方

LAYER 3/5 · CLI讀操作 · schema 開銷 0

Skill意圖路由

MCP寫操作

CLI讀操作

零 schema overhead，任何能跑 shell 的都能用

── import ──► SDK

→ 人 / AI / Cron / Script

SDK唯一 HTTP 邊界

Service業務邏輯本體

dependency graph

// 依賴方向（上層 import 下層）// SDK 是唯一碰 HTTP 的地方CLI   ──import──► SDK ──HTTP──► Service

LAYER 4/5 · MCP寫操作 · typed schema

Skill意圖路由

MCP寫操作

typed schema return —— LLM 需要 JSON schema 驗證輸入

── import ──► SDK

→ Claude Code (tool call)

CLI讀操作

SDK唯一 HTTP 邊界

Service業務邏輯本體

dependency graph

// 依賴方向（上層 import 下層）// SDK 是唯一碰 HTTP 的地方CLI   ──import──► SDK ──HTTP──► ServiceMCP   ──import──► SDK ──HTTP──► Service

LAYER 5/5 · SKILL意圖路由 · 入口

Skill意圖路由

根據操作類型決定走 CLI 還是 MCP，是 AI 工作流的入口

── invoke ──► CLI (讀)

── invoke ──► MCP (寫)

→ AI 編排器 / 自動化流程

MCP寫操作

CLI讀操作

SDK唯一 HTTP 邊界

Service業務邏輯本體

dependency graph

// 依賴方向（上層 import 下層）// SDK 是唯一碰 HTTP 的地方CLI   ──import──► SDK ──HTTP──► ServiceMCP   ──import──► SDK ──HTTP──► ServiceSkill ──invoke──► CLI (讀) / MCP (寫)

PROPAGATIONSDK → CLI + MCP

Skill意圖路由

MCP寫操作同步更新

CLI讀操作同步更新

SDK唯一 HTTP 邊界SDK · 改一行

Bug Fix 自動傳播

Service業務邏輯本體

dependency graph

// 依賴方向（上層 import 下層）// SDK 是唯一碰 HTTP 的地方CLI   ──import──► SDK ──HTTP──► ServiceMCP   ──import──► SDK ──HTTP──► ServiceSkill ──invoke──► CLI (讀) / MCP (寫)// 改 SDK = 所有上層消費者同步更新

WITHOUT SDK沒有 SDK 這層

人 / CLI 使用者AI Agent排程 Script

Service

沒有 SDK 這層的話，每個消費者各自實作 HTTP + auth + error handling = 維護地獄

改一處漏一處，Ghost Parameter 反模式叢生

● client-sidetools[] control你自己決定送什麼

還有一招更直接

自己寫 Client

Agent SDK 自建 Client，繞過平台限制

tools[] controlprotocol vs API payload

MCP Server199 tools

tools/list · 改不了

自建 ClientAgent SDK

tools[] · 你決定

LLM / API

虛擬碼 · 從 tools_list 到 tools=relevant

> all_tools = mcp_server.tools_list() # 199 個 · protocol 層

> relevant = bm25_filter(all_tools, query) # 過濾到 5-10 個

> client.messages.create(tools=relevant) # 只送 5-10 個給 LLM

tools[] control不過濾 · resident cost

tools[] · 不過濾（預設行為）

每輪 schema 開銷

199 個 tool schema，全部塞進 tools[]。約 200 tokens／個，四萬起跳。

tools[] controlBM25 filtered · resident cost

BM25 過濾後 · 只送最相關的 5-10 個

每輪 schema 開銷

外部佐證：Speakeasy 的動態工具集方案，同樣思路篩選 tool，削減了 96% token。

tools[] control現成 vs 自建

現成 Client

Claude Code 這類

它幫你全塞

199 個 · 全塞

自建 Client

Agent SDK

你自己篩

5-10 個 · BM25

SkillMCPCLISDKService

代價

邊際成本遞減，可組合性是長期收益——但維護成本也是長期的。

一次 API 變更

API

SDK

待改

CLI

待改

MCP

待改

團隊小 → 還可控✓人一多 → 靠自動化測試兜住

除錯路徑變長

Service

邏輯錯

SDK

參數漏傳

CLI

解析有誤

MCP

schema 沒更新

層越多，排查越慢。

值得嗎

核心模組

被多種消費者用到

Core ModulePython人（終端）AI Agent排程AI 工作流

划算

小工具

內部自己用

只有自己

負擔

我的判準

✓一週用超過三次
✓參數組合夠複雜
✓需要能被別人發現

永久 TOOL

沒通過

臨時腳本

沙盒用完即丟

你的帳單

23你接的 server 數

8.7平均每個 server 幾個 tool

200每個 schema 約多少 token

40,020tokens

23 個 server、平均每個 8.7 個 tool——這就是開場那句 40K 的算法。

收束一條分界

讀走 CLI·寫走 MCP

Service業務邏輯本體

▲ importSDK唯一碰 HTTP

▲ importCLI讀操作 · 零 schema

▲ importMCP寫操作 · typed

▲ invokeSkill意圖路由

完整版blog.joneshong.com

文章原文

＋算你自己帳單的互動工具

五層架構 · Service → SDK → CLI → MCP → Skill

100%

旁白

一百九十九個工具，每一輪光說明書就四萬個 token。那一輪我一個都沒用到。

逼出這套做法的是三個坑。帳單、機器、還有模型自己挑錯。

我後來把工具接入拆成五層。接下來四分鐘，三個坑跟這套做法的代價，一起講。

我打開 Claude Code，什麼都還沒問。那一輪已經花掉四萬個 token。

錢花在哪？工具的說明書。

我接了二十三個 MCP server，加起來一百九十九個工具。那一輪我一個都沒用到，schema 照樣塞進 context。

最早發現這件事，是在 Playwright 上。

Playwright MCP 的 tool schema 特別大，每一輪都注入 system prompt。那一輪我根本沒開瀏覽器，token 照樣付。

我把它換成 Playwright CLI。token 用量掉了九成八。

第二個坑是機器直接扛的。MCP server 長到二十三個以後，我同時開了三個 Claude Code session。

每開一個，所有 MCP 進程等比複製一次。三個 session，六十九個常駐進程。RAM 跟 CPU 線性吃滿。

第三個坑是 LLM 自己的。工具一多，它挑錯的機率就上升。

業界的建議是每個 MCP server 不超過十個 tool。八個 tool，一個 schema 大概兩百 token，每輪就是一千六。用不用都在付。

來算這筆帳。

MCP 八個工具，每輪一千六百 token 的 schema 開銷。同樣的操作走 CLI，每輪是零。實際的輸入輸出另計。

一千六聽起來不多。乘上五十輪對話就是八萬個 token。全丟在你沒用到的說明書上。

有人比我更極端。Cloudflare 的 Code Mode，整個 IDE 只暴露兩個 tool。

一個 search，一個 execute。其他操作全部在沙盒裡即時寫。他們證明了 tool 數量跟能力成反比。

所以我把工具接入拆成五層。由下往上是 Service、SDK、CLI、MCP、Skill。

Service 是業務邏輯本體。FastAPI 的 routes 加資料庫，就這樣。

SDK 是唯一碰 HTTP 的地方。上面每一層都 import 它，誰都不自己發請求。

讀操作全部丟給 CLI。零 schema 開銷，任何能跑 shell 的東西都能用。

MCP 只做寫的操作。因為 LLM 傳參數，得先驗證格式對不對。

最上面的 Skill 做意圖路由。判斷這次是讀還是寫，讀就走 CLI，寫才走 MCP。

這樣拆最實際的好處是 bug 只修一次。SDK 改一行，CLI 跟 MCP 同時好。

沒有 SDK 這層，每個消費者都得自己實作 HTTP、認證、錯誤處理。改一處漏一處。

如果你自己用 Agent SDK 寫 client，還有一招更直接。

MCP protocol 的 tools list 一定回傳全部工具，這個你改不了。但送進 API 的 tools 陣列放什麼，完全你決定。

我那邊收到一百九十九個。全塞，每輪四萬 token。

先用 BM25 篩到最相關的五到十個再送，每輪剩兩千。

用 Claude Code 這種現成 client，它幫你全塞。自建 client，你自己篩。

這套架構有代價，我一起講。

三套封裝要一起維護。API 改了，SDK、CLI、MCP 都得跟著改。團隊小的時候還可控，人一多就得靠自動化測試兜住。

除錯路徑也變長。出 bug 要先判斷是哪一層：Service 邏輯錯、SDK 參數漏傳、CLI 解析有誤，還是 MCP schema 沒更新。層越多，排查越慢。

還有一點，不是所有模組都值得。被多種消費者用到的核心模組才划算，內部自己用的小工具做五層只是負擔。

我自己的判準只有一條。一個操作，一週要用超過三次。參數組合夠複雜。而且需要能被別人發現。三個都沾到，才值得做成永久 tool。

不然就丟沙盒即時寫，用完就扔。

你現在可以去數一下。自己接了幾個 MCP server，每個幾個 tool。乘兩百，那就是你每輪的固定帳單。

所以整套就一條分界：讀走 CLI，寫走 MCP。SDK 是唯一碰 HTTP 的地方，Skill 決定往哪走。

完整版跟可以算你自己帳單的互動工具，掃這個 QR code。

鍵盤 ← → 翻頁；點一下投影片之後，Home / End 跳頭尾。手機左右滑。網址列的 #3 直接開到第 3 頁。