MCP的问题与对策

我以前非常热衷于MCP，但在发现我还没输入任何指令，我的一半上下文窗口就消失了之后，我就不再那么热衷了。MCP确实解决了正确的问题（灵活、动态的工具使用），但其方法存在根本性缺陷。Cloudflare和Anthropic发表了文章解释这个问题以及取代它的方案：代码执行环境和懒加载工具发现。我分享了自己如何适应这个新世界作为例子。AI工具使用仍然至关重要，但MCP只是途中的一站，而不是终点。

我们有时以奇怪的方式学习。有一天我在使用Claude Code时想做一个“/compact”，但我不小心输入了“/con”。这就是我发现了“/context”命令的方式。酷！它显示了上下文窗口中的内容。我把这记下来留待以后使用。

所以下次我启动Claude Code时，我输入“/context”期望它大部分是空的。相反，它看起来像这样：

这是一个真正的“哇”时刻。我还没有给出任何指令。我的一半上下文窗口就没了？这不是说我运行了50个MCP服务器。我只是运行了两个：PAL多代理桥（一个让Claude与其他AI模型交流的工具）和Chrome DevTools用于前端测试。在我开始工作之前，我就在无形的开销上消耗了令牌。

这就是MCP的结构性缺陷，简而言之。

1、上下文膨胀

随着模型本身变得更聪明（Opus 4.5和Gemini 3.0 Pro），它们暴露了压缩过程中丢失了多少上下文。将压缩视为LLM的垃圾回收等价物，只不过它非常损失性且需要数分钟的痛苦时间。

模型有有限的上下文窗口（大约可以容纳20,000行代码）。每隔一段时间，当它们处理编码任务时，必须压缩到目前为止发生的内容以腾出空间。但这种压缩会丢失信息，使你的优秀助手变成健忘的初级开发人员。并且从头到尾遍历所有这些标记需要一段时间。

MCP负责所谓的上下文膨胀。我真的很喜欢MCP所做的事：极大地扩展AI的能力。我曾写过关于它如何使AI变得更好的文章，并且它在一定程度上成功了，但现在它经常让我等待无产的几分钟。

几天前，我偶然看到一篇Cloudflare的文章，说MCP已经坏了。我以为他们只是在唱反调，甚至没读这篇文章。

然后我看到了半吃掉的上下文窗口。这一震惊让我回到Cloudflare的文章。接着Anthropic发布了他们关于MCP的代码执行的文章。我意识到是我变得过于固执。

那么这些文章说了什么？这些方法是互补的，各自解决不同的问题。

2、Cloudflare：“我们都错误地使用了MCP”

Cloudflare的文章直击要害：LLM实际上对工具调用很糟糕。工具调用中使用的特殊标记是LLM从未在现实中见过的。他们将其与“把莎士比亚送进一个月的中文课程然后让他用中文写剧本”进行比较。

训练数据的差异巨大。LLM遇到的真实代码示例远多于人为构造的工具调用演示。因此，当你将工具作为函数调用呈现时，你是在要求模型在其最弱模式下工作。

他们的解决方案？将MCP工具转换为TypeScript API。而不是直接暴露工具，代理只获得一个工具：代码执行功能。LLM编写调用API的TypeScript。代码在V8隔离器（轻量级沙盒化的JavaScript环境）中运行，MCP服务器成为提供隔离访问而不暴露API密钥的绑定。

这利用了模型的优势，而不是与之对抗。

3、Anthropic：使用MCP的代码执行

几天后，Anthropic（MCP的发明者）发布了他们自己的文章，指出了两个关键问题：

第一，工具定义开销。MCP客户端会预先加载所有工具定义。随着数千个连接的工具，代理在读取单个请求之前要处理数十万的标记。在Anthropic的测试中，一个适度的五服务器设置（58个工具）在对话开始前消耗了约55K个标记。再添加几个服务器，你很快就会接近100K+的标记开销。Anthropic报告称一些设置中仅工具定义就消耗了134K个标记，这大约是Claude整个上下文窗口的一半，在你问出第一个问题之前就消耗掉了。

第二，中间结果重复。结果多次通过模型。从Google Drive检索的转录本附加到Salesforce，会在上下文中传递两次，可能为长文档增加50,000+个标记。

他们的解决方案与Cloudflare相似：通过文件系统结构将MCP服务器呈现为代码API。每个工具成为一个具有定义接口的TypeScript文件。代理只加载当前任务所需的定义。

结果？在他们的演示中，标记减少了98.7%（从150,000减少到2,000个标记）。

4、最终一击：工具搜索工具

基于代码执行的方法，Anthropic还攻击了发现问题。如果工具定义不能存在于上下文窗口中，模型怎么知道有哪些工具？

他们的答案是工具搜索工具（是的，一个用于搜索工具的工具）。而不是预先加载所有定义，Claude按需发现工具。可以把它看作是工具的懒加载：模型只有在决定需要特定能力时才会查找手册。

准确性提升显著：Opus 4从49%提高到74%，Opus 4.5从79.5%提高到88.1%。这在保持访问完整工具库的同时，将标记使用量减少了85%。

5、我是如何应对的

我的一个项目codev大量使用了PAL“模型桥”MCP服务器。多个模型协同工作是codev的核心，所以我必须解决这个问题。

我开始思考：与其让Claude Code通过MCP与Gemini交流，不如让Claude直接调用Gemini CLI？我创建了一个consult脚本，基本上是Claude、Gemini和Codex CLI的薄包装器。没有工具模式加载，所以启动上下文保持最小。现在Claude Code可以调用Gemini。或者Claude Code可以调用Claude Code（这实际上是有用的）。

这本质上是一种原始、不安全的代码执行模式：让模型直接执行CLI命令以节省上下文。它有效，但缺乏下一代沙盒需要的安全措施。

我不是唯一一个适应的人。PAL的作者也遇到了同样的问题，并创建了clink（“CLI链接”），做类似的事情，让一个CLI启动另一个作为子代理，同时保持主会话的上下文窗口未被污染。

6、接下来往哪里去？

工具使用不会消失。它仍然是一个太强大的能力而无法放弃。一种解读是MCP是其自身成功的牺牲品：人们太喜欢使用工具，以至于开始吞噬他们的上下文窗口。

但未来也有挑战。我们从MCP的整洁、明确的界面和良好的围栏进入了编写和执行任意代码的混乱中。这就是为什么AI沙盒将变得更加重要。

“这里有工具，这里有它的模式，用这些参数调用它”的整洁世界正在让位于“这里是一个代码执行环境，自己弄清楚”。这更强大，但也更危险，更难以理解。想象一个代理决定“优化”并删除它认为不必要的文件。

MCP解决了正确的问题。只是结果发现解决方案产生了新的问题，某种程度上更糟。AI工具使用的下一步进化需要在力量与效率、灵活性与安全性之间取得平衡。

什么保障措施能确保代码执行沙盒的安全性而不限制它们？这是行业接下来需要回答的问题。

原文链接：The Evolution of AI Tool Use: MCP Went Sideways

汇智网翻译整理，转载请标明出处