DEEPSEEK HARNESS TOKEN 分层诊断
为什么 DeepSeek Harness 会用掉这么多 Token——以及何时应归因于 MCP 工具 Schema
先审计请求层，再修改技术栈。高用量可能来自工具 Schema，但工具结果、历史、 重复步骤、推理、输出与缓存未命中是不同问题，需要不同修复。
01 / 找到真正的层
五类原因会产生同一个“Token 太多”症状。
总用量只是账单数字，不是根因分析。先观察增长发生在什么时候。
常驻工具 Schema
每个模型可见工具都会带上名称、说明和输入 Schema。DeepSeek Harness 会在每一步组装已注册的工具 Schema，因此大型或频繁变化的 MCP 目录可能主导请求体积。
量测：逐请求统计工具数量，并序列化 request/header.tools。
工具结果与历史
参数和面向模型的工具结果文本会留在会话历史中，直至被压缩。即使目录很小，长日志、文档或重复结果仍会制造巨大上下文。
量测：分别量测每条保留消息、工具参数与工具结果。
重复模型步骤
一个 turn 可以包含多次模型请求。规划、工具调用、工具结果和后续回答都可能形成新 step，所以会话累计值不等于单次请求。
量测：统计每个 turn 的模型请求数，对比分请求与累计用量。
推理与输出
推理和最终输出属于模型行为层。隐藏 Schema 不会自动缩短推理或回答；增加一次发现步骤还可能提高输出 Token。
量测：把供应商报告的 output 与 reasoning 字段和 input 分开。
Prompt Cache 未命中
稳定前缀可能被复用；增删、重命名或修改已注册工具则可能改变前缀。缓存行为取决于供应商，应直接量测，不能从总输入反推。
量测：逐请求比较 cache-read 与 uncached input，并与工具表面变化对齐。
02 / 分层量测
六层审计可以定位最先开始增长的来源。
从用量口径走到真实载荷；只有看到可疑层后，才运行受控干预。
L0 / 定义指标
先说清楚你在排查哪个数字
记录它是单次请求还是整段会话，再拆分 input、cache-read input、output 与 reasoning。不要把累计总量当作一条 Prompt。
L1 / SCHEMA
量测模型可见的工具表面
逐请求记录工具数量和工具 Schema JSON 序列化字节。比较首个请求与 tools/list_changed 或配置变化后的请求。
L2 / 历史
量测保留消息与工具结果
把系统提示、用户与助手历史、工具参数、渲染后的工具结果分别归因，找到增长开始加速的第一个 step。
L3 / 步骤
统计上下文被发送了多少次
把每次模型请求与前后工具调用对应起来。一个中等上下文发送六次，可能比一次异常大请求更贵。
L4 / 供应商
读取供应商 Usage 与 Cache 字段
以供应商响应中的 input、cache、output 与 reasoning 为准。本地 JSON 大小只是诊断代理指标，不能直接换算 Token。
L5 / 对照
只改变一层，重跑同一批任务
固定模型、任务、MCP Server 与 Harness 配置，只改变工具曝光方式；同时报告任务完成与新增请求步骤。
request/header.tools 不是首个请求的重要组成部分， Schema Gateway 大概率无法修复主导用量的那一层。03 / 选择正确的 MCP 路径
原生 MCP 是基线；Progressive Disclosure 是有代价的交换。
DeepSeek Harness 采用插件优先架构：插件可扩展工具注册表，无需修改 Agent Loop。 两种路径都能组合，但没有一种对所有目录都更好。
官方原生 MCP CLIENT
目录小且稳定时，优先直接注册。
- 每个发现到的能力都是带 Server 命名空间的原生工具。
- 模型立即获得精确 Schema，可以直接调用。
- 真实调用前不需要发现搜索。
- 只要工具保持可见，已注册 Schema 的成本会出现在每次请求中。
PROGRESSIVE DISCLOSURE
目录大、能力长尾时，考虑先搜索再曝光。
- 稳定发现表面替代常驻的 Schema 墙。
- 只在相关搜索后向模型提供候选工具的精确 Schema。
- 检索质量会成为任务质量的一部分。
- 额外模型步骤可能提高输出用量和延迟。
架构依据：DeepSeek Harness 会在每个 step 组装 Prompt 区块与工具 Schema，并提供插件扩展点。查看 47f9438 固定版本架构 ↗
04 / 阅读完整取舍
固定夹具隔离 Schema 大小；Pilot 暴露额外搜索。
固定 1,000-TOOL 组件夹具
647,962 B → 1,114 B
只量测已注册工具 Schema 的序列化 JSON 字节。这不是供应商 Token、 延迟或任务质量测量。
检查 rc.9 Benchmark ↗三任务 DEEPSEEK HARNESS PILOT
3 / 3 ↔ 3 / 3
两边都完成了三个固定任务。官方直连直接调用选中工具；Lens 先调用mcp_search，再调用 mcp_call。
| 指标 | 官方直连 Client | MCP Lens |
|---|---|---|
| 完成任务 | 3 / 3 | 3 / 3 |
| MCP 路径 | 直接调用选中工具 | mcp_search → mcp_call |
| Output Token | 491 | 794 |
解读：这三个案例显示任务完成持平、常驻 Schema 表面更小，但 Lens 用另一次调用和 更高输出用量支付了发现成本；它们不能证明普遍质量或延迟结果。
05 / 只修真正的问题
MCP Lens 改变什么，又不改变什么。
LENS 会做
- 把模型可见 MCP 表面固定为
mcp_search与mcp_call。 - 搜索后返回有界候选集合与精确 Schema。
- 再次检查策略后，调用一个明确的 Server 与 Tool。
- 以
allowTools: []启动，让远程能力曝光必须显式开启。
LENS 不会做
- 缩短 Harness 已保留的工具结果文本或会话历史。
- 减少模型推理或最终回答长度。
- 修复与工具表面无关的供应商 Cache Miss。
- 保证更低 Token、成本、延迟或更好任务质量。
- 隔离远程 MCP 进程或替代端点安全。
下一步
先量测；如果 Schema 占主导，再测试可回滚 Profile。
首页提供可复制的 DeepSeek Harness Profile、默认拒绝 Allowlist、验证命令与首条测试 Prompt。
FAQ / 直接回答
不走捷径地解释 DeepSeek Harness Token 用量。
01为什么 DeepSeek Harness 会使用这么多 Token？
高用量可能来自常驻工具 Schema、保留的工具结果与历史、重复模型步骤、推理与输出，或 Prompt Cache 未命中。修改 MCP 配置前应先把这些层拆开。
02如何判断 MCP 工具 Schema 是不是主因？
逐请求量测工具数量和 request/header.tools 的序列化 JSON。如果任何工具结果出现前这个表面就很大，而且在只减少可见工具的对照运行中同一层明显收缩，Schema 膨胀才是合理主因。
03DeepSeek Harness 官方 MCP Client 会把 Schema 放进每次请求吗？
固定版本的官方 Client 文档说明，发现到的工具会注册为原生工具；只要仍处于注册状态，其数据相关 Schema 成本就会在每次请求中支付。
04什么时候应该继续使用官方原生 MCP Client？
目录小而稳定，并且直接调用与最简单执行路径比缩小常驻工具表面更重要时，应保留官方原生 Client。它不需要额外的发现调用。
05什么时候适合 Progressive Disclosure？
有几十或几百个工具、多个 Server、长尾能力或目录频繁变化，并且量测已证明常驻 Schema 层占比明显时，可以考虑；同时必须计算检索质量和新增搜索步骤的代价。
06MCP Lens 能保证总 Token 更低吗？
不能。固定夹具量测的是 Schema JSON 字节，不是 Token。三任务 pilot 中两边都是 3/3 完成，但 Lens 多一次搜索，输出 Token 为 794，官方直连为 491。