← 随机比特 / 所有内容

你接了3个MCP Server,在第一条消息之前,AI已经烧掉了143,000 token的上下文。

2026-03-17 · 随机比特

MCP 工具接得越多,AI 反而越傻——这不是玄学

有人问我,为什么他的 AI 助手最近越来越奇怪。

他接了 GitHub、Slack、Sentry 三个 MCP Server,按理说工具更全了,AI 应该更强。但实际上,AI 开始频繁说"我不太确定"、“让我重新理解一下你的需求”,回复速度变慢,还偶尔忘记刚聊过的事。

他以为是模型的问题。

其实是数学的问题。


先做一道算术题

MCP(Model Context Protocol)的设计很优雅:每个工具定义自己能干什么,AI 自动选择调用。接上 GitHub,就能查 PR;接上 Slack,就能搜消息;接上 Sentry,就能看报错。听起来是工具箱越来越大,AI 越来越全能。

但这个"定义"不是免费的。每一个 MCP 工具,都要把它的名称、描述、JSON Schema、字段说明、枚举值、系统提示,全部塞进上下文窗口。不是你调用它的时候才占位,而是只要接入了,就一直在那里。代价是多少?实测数据显示:每个工具定义消耗 550 到 1,400 个 token。

接上 GitHub,假设 20 个工具:约 18,000 token 消失。
再接 Slack,30 个工具:再消失 25,000 token。
再接 Sentry,40 个工具:再消失 30,000 token。

第一条消息还没发出去,已经烧掉了 73,000 token。这是 Claude 200k 上下文窗口的 36%。

而有工程师实测,三个真实 MCP Server 加起来消耗了 143,000 token——对话还没开始,上下文就用完了 72%。AI 剩下 57,000 token 来完成对话历史、检索内容、推理和输出。

这就是为什么它越来越"傻"。


这不是优化能解决的问题

你可能想说,那把工具描述写短一点不就行了。

当然可以,但你要在工具描述、参数说明、错误处理、边界条件之间做取舍。写太短,AI 不知道什么时候用这个工具,会调错,会乱调。

更根本的是,这是一个三难困境(trilemma)——三条出路,每条都有代价。

路径 A:全部预加载。 把所有工具放进上下文,AI 什么都能用,但记忆耗尽。对话越长,AI 越糊涂。

路径 B:限制集成数量。 只接 2–3 个服务,控制 token 消耗。但 MCP 的价值就是"什么都能接",你把它砍回去,还不如用 CLI。

路径 C:动态工具加载。 需要用到哪个工具再加载进来。听起来完美,但需要一套中间件:AI 先推断要用什么工具,再触发加载,再真正调用。延迟叠加,复杂度叠加,边界情况也叠加。

David Zhang 是 Duet 的创始人,他把三条路全试了一遍,最后把 MCP 集成整个拆掉了——即使 OAuth 和动态注册已经跑通了。他说这是一个不可能三角,选哪条路都有代价。

<figure><img src=“images/mcp-trilemma.jpg” alt=“MCP三难困境”></figure>


量化有多夸张

Scalekit 做了一组有意思的基准测试:75 次对比,相同模型(Claude Sonnet 4)、相同任务、相同 Prompt,分别用 MCP 和 CLI 完成。

结果是 MCP 比 CLI 消耗 4 到 32 倍的 token。

最极端的例子:检查一个 repo 的主要编程语言——这是一个再普通不过的任务。

CLI 方式:1,365 token。
MCP 方式:44,026 token。

这 43,000 个 token 的差距,几乎全是工具定义 schema——那 43 个工具的定义,没有一个参与了这次任务,但全部在场消耗资源。它们就像一个坐满了 43 个人的会议室,但会议只需要一个人发言,其余人只是把椅子占满了。

<figure><img src=“images/mcp-cli-comparison.jpg” alt=“MCP vs CLI对比”></figure>


工程师在怎么应对

三难困境不等于无解。目前工程师在用的出路大概有三种。

一是换协议层,回到 CLI。不是因为 CLI 更高级,而是 CLI 的调用不需要预先声明 schema。AI 直接输出命令,执行器跑命令,不占用上下文。适合明确的、重复性高的操作。

二是加工具路由层,在 AI 和 MCP Server 之间插一个"路由器":先让一个轻量 AI 判断这次任务需要哪几个工具,只把相关工具的 schema 注入上下文。核心挑战是这个路由层自身也需要上下文,而且可能路由错。

三是压缩 schema + 按需展开:默认只注入工具名和一行描述(1–2 token/工具),当 AI 声明要用某个工具时,再注入完整 schema。这是目前最多人尝试的方向,但需要改造 MCP Server 本身的实现。

没有哪条路完美。这是 2026 年 MCP 生态的真实状态。


MCP 不会死,但协议需要进化

MCP 解决的问题是真实的:让 AI 能标准化地调用外部工具。这个需求不会消失。

但这一代设计是"静态、预声明、全量加载"的。下一代要解决的核心问题是让上下文开销与实际使用的工具数量成正比,而不是与接入的工具总数成正比。这件事有人在做,只是还没有成为标准。

在那之前,如果你正在接 MCP,有一个实用的建议:数一下你接入了多少工具,估算一下它们的 schema token 总量,把这个数字放在你的上下文预算里。

工具越多越好的直觉,在上下文窗口有限的世界里并不成立。

你的 AI 没有变傻。只是空间不够用了。


数据来源:Apideck 技术博客(2026-03-16)、Scalekit MCP vs CLI 基准测试(75 组对比)、@dzhng on X

对 MCP token 开销有实测数据的,欢迎在评论区分享——样本越多越有参考价值。