先说结论：只有当模型可见的工具表面在有效工作开始前就已经很大时，MCP 工具 Schema 膨胀才是主因。如果增长发生在读文件、返回工具结果或多轮步骤之后，Schema Gateway 修错了层。

五类原因会制造同一个症状

总用量只是记账结果，不是根因分析。先看请求从什么时候开始增长。

层信号应该量测什么
常驻工具 Schema第一次有效工具调用前，输入已经很大。逐请求统计工具数量，并序列化 request/header.tools。
工具结果与历史搜索、读文件、日志或冗长调用后，输入持续增长。分别量测每条保留消息、工具参数与面向模型的结果。
重复模型步骤单次请求看似正常，但会话累计值很高。统计每个 Turn 的模型请求数，区分分请求与累计用量。
推理与输出输入已受控，但 Completion 用量仍然很高。把供应商报告的 Output 与 Reasoning 字段和 Input 分开。
Prompt Cache 未命中工具列表或 Schema 变化后，未缓存输入跳升。逐请求比较 Cache-read 与 Uncached Input，并与工具表面变化对齐。

六层审计找到最先增长的来源

  1. 定义数字。 它是单次请求还是整段会话？拆分 Input、Cache-read Input、Output 与 Reasoning。
  2. 量测 Schema。 逐请求记录工具数量和工具 Schema JSON 序列化字节。
  3. 量测历史。 把载荷归因到系统文本、消息、工具参数和渲染后的工具结果。
  4. 统计步骤。 把每次模型请求与前后工具调用对应起来。
  5. 读取供应商 Usage。 本地 JSON 大小只是诊断代理指标，不能直接换算 Token。
  6. 只改一层做对照。 固定模型、任务、Server 与 Harness 配置，只改变工具曝光方式。

原生 MCP 是基线；Progressive Disclosure 是有代价的交换

DeepSeek Harness 采用插件优先架构。插件可以扩展工具注册表，无需修改 Agent Loop。这让两条路径都能组合，但不代表其中一条永远更好。

保留官方原生 Client

  • 目录小而稳定。
  • 模型应该立即收到每个精确 Schema。
  • 直接调用比缩小常驻工具表面更重要。
  • 不希望真实调用前增加发现搜索。

测试 Progressive Disclosure

  • 目录有几十或几百个长尾工具。
  • 多个 Server 制造了巨大的常驻 Schema 表面。
  • 量测显示有效工作前 Schema 已占明显比例。
  • 可以同时评估检索质量与新增搜索步骤。

DeepSeek 固定版本的 MCP Client 文档说明，发现到的工具会注册为原生工具；只要仍处于注册状态，其数据相关 Schema 成本会出现在每次请求中。参见官方 Client 文档与固定版本架构。MCP 社区也在 SEP-1576 中讨论先搜索再曝光的通用设计。

把两组测量分开理解

固定 1000 工具组件夹具

647,962 B → 1,114 B 只量测已注册工具 Schema 的序列化 JSON 字节。它不是供应商 Token、成本、延迟、稳定性或任务质量结果。检查 rc.9 Benchmark。

独立三任务 DeepSeek Harness Pilot

两组都完成相同的三个固定任务：3/3 vs 3/3。官方直连直接调用选中工具；MCP Lens 先调用 mcp_search，再调用 mcp_call。

观察指标官方直连 ClientMCP Lens
完成任务3/33/3
MCP 路径直接调用选中工具mcp_search → mcp_call
输出 Token491794

这三个案例显示任务完成持平，并暴露了新增发现工作；它们不能证明普遍质量、延迟、成本或稳定性结果。检查完整 Pilot 记录。

MCP Lens 改变什么，又不能修复什么

MCP Lens 会做

  • 把模型可见 MCP 表面固定为 mcp_search 与 mcp_call。
  • 搜索后返回有界候选集合与精确 Schema。
  • 再次检查策略后，调用一个明确的 Server 与 Tool。
  • 以 allowTools: [] 启动，让能力曝光必须显式开启。

MCP Lens 不会做

  • 缩短 Harness 已保留的工具结果文本或会话历史。
  • 减少模型推理或最终回答长度。
  • 修复与工具表面无关的 Cache Miss。
  • 保证更低 Token、成本、延迟、稳定性或更好任务质量。
  • 隔离远程 MCP 进程或替代端点安全。

直接回答

为什么 DeepSeek Harness 会使用这么多 Token？

高用量可能来自常驻工具 Schema、保留的工具结果与历史、重复模型步骤、推理与输出，或 Prompt Cache 未命中。修改 MCP 配置前应先把这些层拆开。

如何判断 MCP 工具 Schema 是不是主因？

逐请求量测工具数量和 request/header.tools 的序列化 JSON。如果任何工具结果出现前这个表面就很大，而且只减少可见工具的对照运行让同一层收缩，Schema 膨胀才是合理主因。

MCP Lens 能保证总 Token 更低吗？

不能。Schema JSON 字节不是 Token；独立三任务 Pilot 还显示 Lens 增加了一次搜索，并在这些案例中使用了更多输出 Token。