輕量級(jí)MCP Server降低Claude Code上下文token消耗98%實(shí)戰(zhàn)方案

利用輕量級(jí)MCP Server將Claude Code的上下文token消耗降低98%
問(wèn)題在哪
Claude Code 的上下文開(kāi)銷(xiāo)高得離譜。一個(gè)中等長(zhǎng)度的代碼審查對(duì)話(huà),輕松吃掉 2000+ token——其中 90% 是重復(fù)的文件路徑、函數(shù)簽名、注釋塊和之前幾輪已確認(rèn)的結(jié)論。小團(tuán)隊(duì)沒(méi)預(yù)算為每條請(qǐng)求支付高昂的上下文費(fèi)用,又不能砍掉上下文,否則模型立刻“失憶”,給出脫離上下文的錯(cuò)誤建議。
這不是模型能力問(wèn)題,是工作流設(shè)計(jì)問(wèn)題。
Hacker News 上那個(gè)跑通的方案
有人在 HN 發(fā)帖:用不到 200 行 Python 搭了個(gè) MCP Server,把 Claude Code 的上下文 token 壓到了原來(lái)的 2%。不是靠壓縮,也不是丟信息,而是讓上下文真正“有用”。
背景很實(shí)在
團(tuán)隊(duì)做 AI 輔助的前端組件生成工具。用戶(hù)上傳一個(gè) React 組件文件,再提幾個(gè)修改需求(比如“加 loading 狀態(tài)”“支持 dark mode”)。原始流程是:每次請(qǐng)求都把整個(gè)文件 + 所有歷史修改指令 + 上一輪生成的代碼全塞給 Claude。3 輪交互后,上下文就膨脹到 3500 token,成本翻倍,響應(yīng)還變慢。
他們?cè)囘^(guò)摘要、滑動(dòng)窗口、向量檢索——效果都不穩(wěn)定。最后轉(zhuǎn)向 MCP(Model Context Protocol),不是因?yàn)樗靶隆?,而是它定義了明確的上下文生命周期:context → action → result → update。
技術(shù)怎么落地
MCP 不是跨云協(xié)議。它是 Anthropic 提出的、專(zhuān)為 LLM 工作流設(shè)計(jì)的輕量通信規(guī)范,核心就三點(diǎn):
- 上下文按語(yǔ)義分塊(file, diff, requirement, feedback)
- 每塊帶
id和version,支持增量更新 - Agent 和模型之間只傳
id引用,不傳原始內(nèi)容
他們的輕量級(jí) MCP Server 就干三件事:
- 結(jié)構(gòu)化預(yù)處理
把用戶(hù)輸入拆成標(biāo)準(zhǔn) MCP 塊:源碼存進(jìn)file://src/Button.tsx@v1,需求轉(zhuǎn)成requirement://add-loading-state,上一輪反饋標(biāo)記為feedback://v2。 - 上下文裁剪
不傳全部塊,只傳當(dāng)前任務(wù)強(qiáng)依賴(lài)的塊 ID 列表。比如“加 loading”這步,只引用file://src/Button.tsx@v1和requirement://add-loading-state,跳過(guò)前兩輪關(guān)于 dark mode 的討論。 - 結(jié)果緩存與版本聯(lián)動(dòng)
每次 Claude 返回新代碼,Server 自動(dòng)創(chuàng)建file://src/Button.tsx@v2,并把舊塊v1標(biāo)記為deprecated。后續(xù)請(qǐng)求自動(dòng)切換引用。
import mcp
from mcp.server import StdioServer
from claude_code import Client
class ClaudeMCPServer:
def __init__(self):
self.claude = Client()
self.context_db = {} # {id: content}
def handle_context_request(self, req: mcp.ContextRequest):
# 只加載 req.referenced_context_ids 對(duì)應(yīng)的內(nèi)容
context = []
for cid in req.referenced_context_ids:
if cid in self.context_db:
context.append(mcp.ContextItem(
id=cid,
content=self.context_db[cid]
))
return mcp.ContextResponse(context_items=context)
def handle_action_request(self, req: mcp.ActionRequest):
# 構(gòu)造精簡(jiǎn) prompt:只含 referenced_context_ids 對(duì)應(yīng)的語(yǔ)義塊
prompt = self.build_prompt(req)
response = self.claude.chat(prompt)
# 提取新生成的文件塊,存入 context_db 并返回 versioned id
new_file_id = self.save_new_file(response)
return mcp.ActionResponse(
result=mcp.Result(
status="success",
output={"new_file_id": new_file_id}
)
)
# 啟動(dòng):mcp run --server python:main.py部署就是一行命令:
pip install mcp-server claude-code && python server.py不需要 Kubernetes,不連 Redis,單進(jìn)程跑滿(mǎn) CPU 也能撐住日均 5000 請(qǐng)求。
實(shí)測(cè)數(shù)據(jù)
| 場(chǎng)景 | 原始上下文 token | MCP Server 后 | 下降 |
|---|---|---|---|
| 單次代碼修復(fù) | 1240 | 38 | 97% |
| 三輪迭代修改 | 3680 | 72 | 98% |
| 多文件關(guān)聯(lián)重構(gòu) | 4120 | 95 | 98% |
響應(yīng)時(shí)間平均快 1.8 秒——因?yàn)?Claude 不再花 3 秒解析重復(fù)的 node_modules 路徑和無(wú)用的 console.log 示例。
這東西為什么能直接用
- 零訓(xùn)練成本:不碰模型權(quán)重,不調(diào)超參,純工作流層改造
- 不改業(yè)務(wù)邏輯:現(xiàn)有 Agent 只需把
send_to_claude()替成mcp_client.action() - 天然兼容:LangChain、LlamaIndex、AutoGen 都已支持 MCP Action 調(diào)用
- 可審計(jì):所有上下文塊存本地 JSON 文件,隨時(shí)查哪次用了哪個(gè)版本的文件
怎么自己搭一個(gè)
pip install mcp-server- 寫(xiě)
server.py,繼承mcp.Server,實(shí)現(xiàn)handle_context_request和handle_action_request - 在
handle_action_request里調(diào) Claude,但只拼接req.referenced_context_ids對(duì)應(yīng)的內(nèi)容 - 把生成結(jié)果按語(yǔ)義存成新 context item(比如
file://...@v2) mcp run --server python:server.py
緩存用 dict 就夠,要持久化就寫(xiě) JSON 文件。別一上來(lái)就上 Redis——90% 的小團(tuán)隊(duì)根本用不到。
MCP 的價(jià)值不在協(xié)議本身,而在于它逼你把“上下文”從一坨文本,變成可標(biāo)識(shí)、可版本、可裁剪的資源。Claude 不是變便宜了,是你終于不再喂它吃垃圾。