MCP 能力披露税：当每个连接的服务都在消耗你的上下文窗口

只要为你的智能体连接一个 GitHub MCP 服务端，在用户输入一个字之前，你可能就已经消耗了 1.2 万到 4 万个 token。连接一个文件系统服务端、一个日历、一个数据库、一个内部 CRM 以及一个第三方工具目录，据测算，一个重型桌面配置的纯工具披露 (tool disclosure) 就会产生 6.6 万个 token —— 这几乎占了 Claude Sonnet 200K 上下文窗口的三分之一，而且在每一个规划轮次 (planning turn) 都要付费。智能体还没开始干活，用户还没开始提问，账单就已经开始计费了。

这就是“披露税” (disclosure tax)，它是目前交付的智能体系统中定价最低估的条目。团队添加 MCP 服务端的方式就像曾经添加微服务一样 —— 每一个集成看起来都像是一个免费的组合原语 (composition primitive)，采购理由也顺理成章（“更多工具 = 更多能力”）。而单位经济效益仪表盘 (unit economics dashboard) 从未反映出每个服务端的成本，因为成本隐藏在 token 桶里，没有人将其归因于连接器。结果是，每当有人添加另一个集成时，智能体就会变得更慢、更笨、更贵，而团队却通过重新调整提示词 (prompt) 和催促模型厂商发布新版本来解释这种退化。

本文想要确立的观点是：MCP 不是一个免费的组合原语。它是一个有明确每服务端税费的上下文预算消耗者。如果团队不明确为这项税费定价，就会发现其智能体的有效上下文每个季度都在缩水，而工具蔓延 (tooling sprawl) 却在不断增长。

披露成本是每一轮都要支付的，而非一次性

关于 MCP 最常见的误解是，认为能力披露是一项设置成本 (setup cost) —— 一次性握手、初始化时的发现，或者是对话开始前的配置步骤。这种直觉是错误的，随之而来的成本模型更是错了一个数量级。

工具定义在每个规划步骤中都会被注入到模型的上下文中。每一轮，规划器 (planner) 都会重新读取完整的工具目录。一个拥有 8 个 MCP 服务端（平均每个服务端包含 40 个工具）的多轮对话智能体，在每次规划调用中都会发送 320 个工具定义。考虑到名称、描述、输入模式 (input schema)、参数文档以及协议要求的模式格式样板代码，一个中等规模的工具定义大约需要 700 个 token。这意味着在用户消息、对话历史或任何检索到的上下文之前，每一轮都会产生 1.5 万到 3 万个 token 的披露开销，并在多步任务的每个推理步骤中重复出现。

这种复利效应体现在三个无人正确归因的地方。首先，每请求的 token 账单随安装的服务端数量线性增长，而每个服务端的边际用户价值却趋于平缓 —— 第 8 个集成提供的价值仅为第一个的一小部分，但支付的披露成本却相同。其次，提示词缓存 (prompt cache) 的断点（大多数团队将其放置在工具定义块的末尾以摊销披露成本）处于提示词中最不稳定的区域 —— 任何服务端的添加、删除、重新排序，或返回略有不同的描述（例如工具描述中的时间戳、动态文件计数，或异步初始化导致重启后顺序不同的 MCP 服务端）都会导致缓存失效，团队必须支付全额费用直到下一次稳定运行。第三，模型的注意力被分散到数百个工具定义中，工具选择的准确度会下降，这种现象看起来像是提示词退化，但实际上是披露负载 (disclosure-load) 退化。

注意力成本大于 Token 成本

仅针对 token 成本进行优化的工程师只计算了一半的账单。披露税还有第二张根本不会出现在使用情况仪表盘上的发票：模型准确率。

基准测试数据非常严峻。在有 10 个可用工具时，性能出众的模型在工具选择上几乎可以获得满分。当工具有 20 个时，最好的模型仍能达到 95% 的准确率。而当工具数量超过 25 个左右时，准确率开始明显下滑。在 107 个工具的情况下，模型会彻底失败 —— 任务成功率崩溃，某些研究中的工具选择准确率从 40% 以上下降到 14% 以下，退化了三倍，智能体在大约八分之七的情况下都会选错工具。GitHub 将其 Copilot MCP 集成从 40 个内置工具削减到了 13 个，从而在 SWE-Lancer 和 SWE-bench-Verified 上恢复了 2 到 5 个百分点，并减少了 400 毫秒的延迟。这次削减并非单纯的成本优化，而是以成本优化为名进行的准确率修复。

其背后的机制是被工具过载所放大的“迷失在中间” (lost in the middle) 效应。模型必须关注整个上下文，而其中大部分是不被调用的工具描述。来自实际任务的信号被 49 个规划器本轮不需要的工具定义噪声所冲淡。团队观察到工具选择能力的退化，进行了一些提示词工程 (prompt-engineering) 实验，最后写出了一个更锐利的系统提示词，产生了短暂的提升，但随着团队又添加了两个服务端，效果再次下滑。根本问题在于披露负载。解决方案不在提示词中。

提示词缓存断点无法将你从波动中拯救出来

当发票上出现披露成本（disclosure cost）时，第一直觉是加大对提示词缓存（prompt caching）的依赖。在工具块末尾放置一个缓存断点，支付一次披露成本，并在缓存窗口内进行摊销。理论上，这能将工具前缀的输入成本削减 90%。但在实践中，缓存带来的节省虽然真实却很脆弱，依赖它们的团队离意外发生只差一个配置更改。

这种脆弱性是结构性的。提示词缓存要求按照 tools → system → messages 的严格顺序进行逐字节的前缀匹配。MCP 服务器是异步初始化的，这意味着除非代理运行时对其进行确定性排序，否则工具数组在不同的重启周期中可能会以不同的顺序返回。如果某个工具的描述包含时间戳、构建哈希或可用资源的动态计数，那么每次调用都会导致缓存失效（cache bust）。如果工具的 schema 在每次服务器启动时从类型源重新生成，那么不同版本的源代码库之间可能会产生细微差别的输出。任何这些情况都会悄无声息地将缓存前缀变成冷启动，延迟翻倍，受影响调用的成本增加 10 倍，而团队则会转而责怪模型厂商。

加载中…