文章为解决MCP令牌臃肿问题，提出10种策略。关键在于精简工具设计、智能上下文管理、自动化发现、利用子代理及外部化控制，以优化AI代理性能，避免混乱。
译自：10 strategies to reduce MCP token bloat
作者：Bill Doerrfeld
模型上下文协议（MCP）已达到一个拐点。
尽管一些 MCP 部署仍处于实验阶段，但许多正在将该技术投入到日常运营使用中。
但随着团队开始在实际工作流中扩展 MCP，他们发现同时运行多个MCP 服务器会引入严重的臃肿问题。
Merge（一个统一的 API 平台）的首席技术官兼联合创始人 Gil Feig 告诉《The New Stack》，急于添加数十种工具的团队现在正面临扩展问题。他说：“代理无法可靠地选择正确的工具，上下文窗口充满了定义，并且延迟加剧。”
大量使用 MCP 可能会迅速用内存、模式、代码和数据淹没 AI 编码代理的上下文窗口。仅工具定义本身就占据了大量空间。Feig 补充说：“我们看到工具元数据占用了可用上下文的 40-50%。”
总体而言，MCP 的采用仍处于早期阶段，解决这些问题的最佳实践仍在不断涌现。Solo.io（一家云原生基础设施提供商）的副总裁兼全球现场首席技术官 Christian Posta 表示，答案取决于你问谁。
Posta 告诉《The New Stack》：“如果你问我关于企业用户的情况，那仍然非常早期，并且正在出现一些危险的模式。”“最大的缺点是 LLM 的混淆和上下文臃肿。”他建议，通常一次使用的工具不要超过 10-15 个。
我们如何减少 MCP 工具臃肿？
那么问题是：我们如何减少 MCP 工具臃肿？为了优化令牌使用并提高性能，专家们指出了几个相对简单的转变——例如在运行时最小化服务器使用、按领域对工具进行分组以及部署子代理。
其他技术，包括即时上下文加载、外部化计算结果以及更高级的数据过滤方法，也可能有所帮助。
下面，我们将深入探讨这些 MCP 令牌优化策略，了解专家们在 2026 年初的建议，以及团队在实践中看到了什么。
1. 有意图地设计工具
如果您正在构建 MCP 服务器，请不要偏离范围。仅仅将 MCP 叠加到现有 REST API 之上并一对一地封装它们并不是最佳选择。
“大多数 MCP 服务器只是简单地封装了 API，并非为代理工作流而构建。”
相反，普遍的建议是创建高度有意图的 MCP 工具。Arcade.dev（一个 AI 工具调用平台）的联合创始人兼首席执行官 Alex Salazar 告诉《The New Stack》：“从工具质量开始。”
Salazar 说：“大多数 MCP 服务器只是简单地封装了 API，并非为代理工作流而构建。”“使用或构建为代理优化的 MCP 服务器，并将安全性、评估和可靠性内置到工具本身中。”他补充说，如果做得好，这种方法可以提高准确性并降低令牌成本。
SmartBear（一家 API 管理和测试公司）的高级技术产品经理 Marcin Klimek 告诉《The New Stack》：“使用 MCP 工具提高令牌使用和性能始于保持工具清晰并专注于用户意图。”
对于 Klimek 来说，有效的 MCP 工具是精确的，并且只返回完成任务所需的内容——不多不少。他说：“宽泛或模糊的请求会浪费令牌并拖慢速度。”他补充说，MCP 工具应该具有明确的输入、有限的输出和单一的用途，就像生产 API 一样。
换句话说，一个 MCP 工具应该类似于一个特定的 API 方法，而不是一个镜像平台中每个端点的臃肿服务器。
Solo.io 的 Posta 为 MCP 工具中以体验为中心的 API 设计提出了类似的观点。他说：“正确的方法是专注于 MCP 服务器设计，这包括将多步骤、细粒度的 API 调用隐藏在单个工具 API 后面。”
2. 最小化预置上下文
AI 代理需要适量的上下文——太少则无法运行，太多则会陷入困惑。因此，当使用许多 MCP 工具时，专家建议最小化预置上下文，并且仅在必要时才扩展它。
当工具描述包含过多数据时，常常发生上下文溢出，Layered System（一家 API 和 MCP 咨询公司）的 API 策略师 Kevin Swiber 告诉《The New Stack》。“这会浪费令牌，并使 LLM 更难选择正确的工具，”他们说。
“首先加载最小模式，并且仅在实际使用工具时才扩展它们。”
开发人员可以预先减少部分上下文。R Systems（一家数字产品工程公司）的数据和 AI 副总裁 Neeraj Abhyankar 告诉《The New Stack》：“首先加载最小模式，并且仅在实际使用工具时才扩展它们。”
他补充说，模式去重和标准化、将工具限定在命名空间内以及缓存常用工具元数据，结合起来可以将令牌使用量减少 30-60%，并提高响应能力。
Sonar 的首席产品官 Ori Yitzhaki 同意模式最小化对于优化令牌使用至关重要。Yitzhaki 告诉《The New Stack》：“开发人员经常提供大量的 JSON 模式。”相反，他建议将描述精简到基本要素，并使用模型仍可解释的速记符号。
3. 采用渐进式披露
与其一次性暴露所有工具，不如将可用的 MCP 工具限制在与当前任务相关的工具。
根据 Linear（一个产品管理应用程序，其 MCP 服务器拥有超过 25 万用户）的工程主管 Tom Moor 的说法，相关性很重要。
Moor 告诉《The New Stack》：“在启用哪些服务器和工具时要非常挑剔。”“大多数开发人员只使用一到两个核心 MCP 服务器。”
其他人也认为 MCP 工具应仅在需要时启用。Clockwise（一家 AI 驱动的日历公司）的联合创始人兼首席执行官 Matt Martin 提出了类似的观点。
“大多数开发人员只使用一到两个核心 MCP 服务器。”
Martin 告诉《The New Stack》：“你不能同时启用所有这些工具。”他补充说，团队可以手动启用工具，也可以依靠特定案例的代理来激活所需的工具子集。
Swiber 说：“答案一直回到渐进式披露。”广义上讲，这种做法包括预先只提供基本信息，同时隐藏高级功能，直到需要时再显示。
对于 MCP 工具，这相当于将发现与执行分离，Feig 补充道。他说：“使用渐进式披露，并考虑构建工具层次结构，让代理首先选择类别，然后选择特定工具。”
4. 自动化工具发现
为了以自动化方式实现渐进式披露，专家们建议采用智能检索过程来发现可用工具。为此，MCP 注册表正在作为目录出现，以帮助索引 MCP 工具并使其更易于搜索。
Posta 说：“使用渐进式发现，配合搜索工具类型的工具。”这可能涉及首先调用一个元工具作为抽象。例如，一个简单的 find_tool 工具可以利用 MCP 注册表，根据语义、身份验证、功能或令牌成本来查找工具。
你可以把它想象成检索增强生成（RAG），但应用于工具本身。Yitzhaki 说：“将工具集视为一个图书馆，只有根据用户提示检索到的‘top-k’个最相关的工具。”“这使代理的工作内存保持精简和专注。”
“使用轻量级检索来根据请求识别相关工具”
Yitzhaki 将此过程称为语义路由。他说：“与其加载五十个工具，不如加载一个路由器工具。”“代理告诉路由器它想做什么，路由器动态地只注入该特定子任务的三个相关工具。”
Merge 的 Feig 建议：“使用轻量级检索来根据请求识别相关工具，然后只加载那些特定的模式。”他补充说，这个过程可以帮助将 100 个工具缩小到几个相关的工具。
5. 使用子代理
基于这个想法，一些人建议使用工具专用的子代理，每个子代理都可以访问自己的功能，而不是使用一个可以访问所有工具的单一整体代理。这样做可以通过按需使用 MCP 工具来优化令牌使用。
Aviator（一个协作式 AI 编码助手）的首席执行官 Ankit Jain 表示，分段式方法为每个子代理提供了清晰的边界。例如，如果你总共有十五个工具，你可以将对单个工具的访问分离给专注于特定领域的子代理，例如只读 MCP 工具、只用于文件编辑的工具或只用于测试的工具。
Jain 告诉《The New Stack》：“令牌开销下降 50-60%，而且角色没有混淆。”
为工具组创建更高级别的工具可以帮助特定案例的代理理解要访问什么。Merge 的 Feig 说：“将相关的操作捆绑到更高级别的工具中。”“与其分别创建创建、更新和删除工具，不如创建一个处理常见工作流的管理工具。”
6. 尝试基于代码的执行
解决令牌效率低下问题的另一种方法是使用一种称为代码模式（也称为代码执行样式）的架构，其中代理编写并执行代码以调用 MCP 服务器。
这种架构避免了 LLM 不得不以自然语言编排复杂工作流和工具调用，从而减少了必须存储在上下文窗口中的状态量。
“将工作流从上下文窗口中委托出去”
Swiber 建议：“将工作流从上下文窗口委托到单独的代码执行中。”“LLM 生成的工作流代码在其他地方运行。上下文窗口永远看不到中间结果，这样可以节省令牌。”
其他人也认为代码执行风格的工具调用是一个有前景的方向。Posta 说：“让 LLM 模型直接编写代码来调用工具，同样，基于某个真相来源，MCP 发现，例如 MCP 注册表。”
7. 执行语义缓存
语义缓存是另一种可以完全避免直接调用 LLM 和上下文窗口的过程。该方法试图将传入的用户查询与语义相似的过去查询进行匹配，并在向 LLM API 发出请求之前重用缓存的响应。
通过缓存常用数据，例如工具定义或其他不太可能更改的信息，团队可以在某些情况下避免不必要的 LLM 和 MCP 调用。
8. 记住提示工程
AppOmni（一家 SaaS 安全公司）的 AI 总监 Melissa Ruzzi 补充说，扎实的提示实践是避免不可预测结果的关键，在使用 MCP 时这种风险会加剧。
Ruzzi 告诉《The New Stack》：“在使用任何带有工具的代理时，提示说明和提示示例都是最佳实践。”“这是因为工具与 LLM 连接，这意味着模型将以无监督的方式选择和使用工具。”
9. 实践数据卫生
其他减少 MCP 臃肿的方法包括总体上保持良好的数据处理实践。
SmartBear 的 Marcin Klimek 建议增量获取数据——从小的响应（如摘要或 ID）开始，并且只有在明确需要时才请求详细数据。
“使用结构化响应并在所有工具中重用相同的模式。”
Klimek 说：“保持数据干净紧凑，使用结构化响应并在所有工具中重用相同的模式，不要在后续提示中重复大量输出。”“而是对它们进行总结。”
10. 考虑外部化控制
接着，除了工具和编排之外，还有所有其他可能使上下文窗口膨胀的运营方面需要考虑。这可能包括治理、策略执行、身份验证和错误处理。
将这些关注点外部化到运行时层，而不是直接嵌入到每个工具中，这种做法越来越受到支持。Arcade.dev 的 Salazar 说：“一个集中处理这些关注点的运行时可以保持工具精简，减少故障模式，并避免用冗余逻辑使上下文窗口膨胀。”
一个集中管理 MCP 的平台也可以帮助展示相关工具，以减少令牌开销。Salazar 补充说：“一个精心设计的运行时还可以自动处理动态工具选择，消除预先限制的需要，同时仍保持工作流高效和准确。”
Posta 同样建议使用具有虚拟 MCP 功能的代理网关。他指出，现在许多支持 MCP 的 API 网关和 AI 网关都支持这些功能。
现实正在显现
MCP 的早期采用者众多，但许多组织仍在摸索如何大规模推广 MCP。
Aviator 的 Jain 说：“MCP 的采用是混乱的。”“个人开发人员在不考虑成本的情况下添加了五到十个工具。企业团队因不可预测的令牌使用而陷入困境。”
尽管如此，MCP 正在成为代理软件开发的核心要素。Yitzhaki 补充说：“它正在从一个‘很酷的功能’转变为企业架构的核心部分。”
随着这一势头，大规模使用 MCP 的现实摩擦开始显现。这迫使人们重新思考如何最好地管理编排、工具调用和上下文。
幸运的是，通过遵循上述一些技巧——限制工具访问、采用渐进式披露以及使用元工具和子代理进行智能上下文管理——团队可以在不牺牲功能的情况下控制令牌臃肿。
在实践中，MCP 优化与其说是一种单一技术，不如说是一种有纪律的系统设计。
