MCP 的肮脏秘密：你的 Agent 正在大量消耗 Token
你的 AI Agent 每调用一次 MCP 服务器，都要支付一笔隐藏税。这笔税不是以美元计费，而是以 Token 计费。
如果你大规模运行 Agent，这项成本会迅速增长。我追踪了自己的 Token 使用情况，发现出现了巨大的峰值。问题不在于模型的推理能力，而在于上下文开销（context overhead）。
当你将 Agent 连接到 MCP 服务器时，服务器会将工具定义（tool definitions）发送到系统提示词（system prompt）中。这些定义包含了每一个参数和描述。
如果你使用了 5 个 MCP 服务器，每个服务器包含 20 个工具，那么每一轮对话都会增加高达 15,000 个 Token。而这一切发生在模型开口说话之前。
以下是 10 轮对话测试的数据：
• 无 MCP：每轮 2,400 个 Token • 3 个 MCP 服务器：每轮 18,700 个 Token • 5 个 MCP 服务器：每轮 31,200 个 Token
按目前的定价，一个每天运行 50 场对话且使用 5 个服务器的团队，仅在 MCP 开销上每月就可能花费 23,400 美元。
这会导致两个主要问题：
- 质量下降。当工具 Schema 占据了 40% 的上下文窗口（context window）时，模型留给历史记录的空间就变少了。模型会因为空间不足而开始遗忘信息。
- 成本固定。每一轮对话你都要为这些系统提示词支付全额费用。
以下是三种解决方法：
使用网关 (Gateway) 不要一次性加载所有工具定义。使用网关仅注入当前任务所需的工具。这可以将单次调用的开销从 8,000 个 Token 降低到 400 个 Token。
使用意图分类器 (Intent Classifier) 先进行一次低成本的模型调用，以决定哪个服务器是相关的。分类器带来的微小成本可以减少 60% 到 80% 的 MCP 开销。
压缩你的 Schema MCP Schema 使用了大量的词汇。将描述精简为核心名词，并移除示例字段。我发现，如果你简化文本，一个 400 Token 的 Schema 在 120 Token 时依然能完美运行。
不要再把上下文视为无限的资源了。上下文预算就是基础设施。要像对待真实成本一样去管理它。
在你的生产级 Agent 中，你是如何处理 MCP 开销的？请在评论区告诉我。
Optional learning community: https://t.me/GyaanSetuAi